<div id="readability-page-1" class="page"><div><h2 id="발단">발단</h2>
Aurora MySQL 디비를 사용할 경우, <a href="https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP">minor 혹은 patch 버전에 대한 자동 업그레이드</a>가 기본 활성화돼있다.
그리고 자동 업그레이드가 진행되는 동안 기존 인스턴스를 재부팅하는 과정이 포함되므로 애플리케이션의 디비 연결에 잠깐의 끊어짐이 발생할 수 있다.
재부팅으로 인한 다운타임은 인스턴스의 사이즈나 버전 등에 따라 차이가 있지만 내 경우에는 그리 길지 않았다. (12:03 ~ 12:04, 즉 1분 미만)
<img src="https://velog.velcdn.com/images/leejh3224/post/e35dc6c4-7b46-4bab-8c77-1ed1872fbf26/image.png" alt="rds logs and event">
하지만 몇몇 서버에서 버전 업그레이드가 종료된 후에도 새로운 인스턴스에 접속하지 못하는 현상이 지속되었으며, 문제가 되는 쿠버네티스 파드를 모두 제거 &gt; 재기동한 후에야 정상화되었다.
이후 문제가 된 애플리케이션의 로그를 확인하니 아래와 같이 "Pool does Not exists" 와 같이 남아있었다.
<pre><code>[Nest] 1 - 08/05/2024, 4:00:11 AM ERROR [AllExceptions] {"statusCode":500,"code":500,"error":"Error","message":"Pool does Not exists."}</code></pre>
<h2 id="첫-시도">첫 시도</h2>
처음에는 파드 재시작을 통해 문제를 해결했기 때문에 해당 프로세스를 자동화할 방법을 생각했다.
즉 Nest.js의 ExceptionHandler 클래스에서 <code>Pool does Not exists</code> 에러 발생 시 <code>process.kill</code>을 해 애플리케이션 프로세스를 죽이고, 이를 통해 파드 재시작을 트리거하는 것이다.
<img src="https://velog.velcdn.com/images/leejh3224/post/d0f3eee4-9d9d-4407-9e63-a9c935cae68a/image.png" alt="process.kill">
이 때 프로세스가 graceful 하게 재시작될 수 있게끔 <a href="https://github.com/hienngm/nestjs-graceful-shutdown">nestjs-graceful-shutdown</a>과 같이 연계하면 <code>SIGTERM</code> 시그널 수신 &gt; 리소스 정리 &gt; 파드 재시작 순서로 애플리케이션을 재실행하게 된다.
하지만 이 방법은 파드 재시작부터 ready 상태가 되기까지 수 분이상이 걸리므로 경제적이지 않다. 또한 상식적으로 생각해보면 새로운 디비 커넥션을 생성하는게 훨씬 효율적이다.
그래서 코드를 직접 확인해보기로 했다.
확인해보니 해당 에러는 애플리케이션에서 사용 중인 <code>mysql2</code> 드라이버로부터 발생하는 것이었다.
<img src="https://velog.velcdn.com/images/leejh3224/post/fe6a5bf8-1ce5-4ec5-af38-ee2468885b95/image.png" alt="pool-does-not-exists">
코드에서 알 수 있듯, 드라이버에서 연결할 수 있는 노드를 찾을 수 없을 때 해당 에러가 발생한다.
커넥션 풀에서 새로운 커넥션을 가져오려고 (borrow) 했고 이 과정에서 노드를 찾지 못해 커넥션을 가져오기 전에 에러가 발생했다.
<h2 id="removenodeerrorcount">RemoveNodeErrorCount</h2>
<code>mysql2</code> 드라이버의 경우 <code>mysql</code> 드라이버와 <a href="https://sidorares.github.io/node-mysql2/docs/api-and-configurations">거의 호환되므로</a> <code>mysql</code> 드라이버의 pool 연결 옵션을 살펴보자.
<a href="https://sidorares.github.io/node-mysql2/docs/api-and-configurations">mysql pool 연결 옵션</a>에 따르면 커넥션 풀의 기본 동작은 <code>removeNodeErrorCount</code> 수치가 5에 다다르면 해당 노드를 더 이상 연결할 수 없는 노드로 간주, 해당 노드를 제거한다.
<img src="https://velog.velcdn.com/images/leejh3224/post/2d70b2dc-e923-46f2-bb98-0f23127c2edf/image.png" alt="pool options">
코드를 보면 더욱 명확하게 알 수 있다.
<img src="https://velog.velcdn.com/images/leejh3224/post/84b88729-10a5-4fd3-be3e-7abe71d58e1b/image.png" alt="increase-error-count">
키바나에 남은 애플리케이션 로그를 확인해보니 더욱 명확해졌다. 설명처럼 5번 같은 노드에 접속하려고 시도했고, 다른 노드에 연결을 시도했다.
<img src="https://velog.velcdn.com/images/leejh3224/post/1fda38e3-6d89-45ca-9d7e-7e362bb41c9a/image.png" alt="ECONREFUSED">
그리고 사용 가능한 모든 노드에 연결을 시도한 뒤 실패하자 <code>Pool does Not exists</code> 에러를 뱉은 것이다.
<h2 id="해결">해결?</h2>
<a href="https://github.com/mysqljs/mysql/issues/1041">깃헙 이슈</a>를 뒤져보니 나와 동일한 사례가 몇 가지 보였고, 또 <a href="https://kyungyeon.dev/posts/92/">블로그</a>에서 RDS 버전 자동 업그레이드에 대한 대처를 한 사례가 있어서 찾아본대로 <code>restoreNodeTimeout</code> 옵션을 적용해보기로 했다.
하지만 확인 결과 이미 해당 옵션이 1000 (1초)로 적용되어 있었다.
즉 옵션이 적용되어 있었음에도 동작하지 않은 것이다.
mysql2 레포지토리에서 <code>restoreNodeTimeout</code> 을 <a href="https://github.com/search?q=repo%3Asidorares%2Fnode-mysql2%20restoreNodeTimeout&amp;type=code">검색해보면</a> 해당 옵션이 아직 구현되지 않았음을 확인할 수 있다.
<img src="https://velog.velcdn.com/images/leejh3224/post/13a2a572-0b9d-48c1-b396-7f63e0ee4df1/image.png" alt="restore-node-timeout">
결국 해당 옵션을 지원하는 mysql 드라이버를 사용하기로 결정, mysql2 드라이버를 사용하고 있던 애플리케이션의 드라이버를 mysql로 교체했다.
한 가지 주의할점은 mysql 드라이버 사용 시 MySQL 8+의 <code>caching_sha2_password</code> authentication plugin 을 사용할 경우 인증을 실패한다.
그러므로 사용하는 계정이 <code>mysql_native_password</code>를 사용하는지 확인한 후 mysql 드라이버를 사용해야 한다.
<h2 id="더-나은-방법은-없나">더 나은 방법은 없나?</h2>
다른 방법이 없을까 찾아보면서 다른 드라이버에서는 디비 재시작 혹은 wait_timeout 설정 등으로 인한 연결 상실에 어떻게 대처하는지 궁금해졌고, 디비 연결에 대처하는 방법이 크게 2가지로 나뉜다는 것을 알았다.
<a href="https://docs.sqlalchemy.org/en/14/core/pooling.html#dealing-with-disconnects">SQLAlchemy Connection Pool 문서의 Dealing with disconnects 항목</a>에 따르면
첫 번째 방법은 Pessimistic 방식이다.
Pessimistic 방식은 커넥션 풀에서 커넥션을 가져올 때 모든 커넥션이 항상 stale 하거나 닫혀있을 수 있다고 가정하고, 커넥션이 사용가능한지 확인한다. (ex <code>ping()</code>)
물론 커넥션을 가져올 때마다 <code>ping</code> 을 날려 확인하는 방식은 비효율적이기 때문에 SQLAlchemy 내부에서 커넥션의 age를 확인해서 커넥션을 체크할지 말지를 결정한다.
<a href="https://github.com/sqlalchemy/sqlalchemy/blob/081a91535f9229c957c0f40e035eb8c399bf6ab7/lib/sqlalchemy/pool/base.py#L1256">SQLAlchemy pool base.py</a>를 살펴보면 커넥션이 얼마나 오래됐는지 (<code>fresh</code>) 확인 후 pre_ping 요청을 날리는 것을 확인할 수 있다.
<img src="https://velog.velcdn.com/images/leejh3224/post/49734794-e0dd-4d8d-942e-31bd075dd7f3/image.png" alt="pre_ping">
내부적으로 효율성을 높이기 위한 많은 장치가 있기 때문에 모든 커넥션을 가져올 때보다 <code>ping</code> 을 날리는 것만큼 비효율적이지는 않겠지만 pesimistic 방식은 필요하지 않은 추가 쿼리를 실행하므로 비효율을 동반할 수밖에 없다.
두 번째 방법은 Optimistic 방식이다.
이 방식은 pre_ping을 통해 적극적으로 커넥션의 유효성을 확인하는 대신 연결 도중 에러가 발생하면 해당 커넥션을 버리고 pool로 하여금 새로운 커넥션을 가져오게끔 하는 방법이다.
여기에 추가적으로 <code>pool_recycle</code> 파라미터를 사용하면 mysql의 wait_timeout으로 인한 커넥션 끊김을 대처할 수 있다. 
(커넥션의 최대 수명 즉 max-age를 셋팅하여 커넥션을 해당 시간 이상 지속될 수 없게 한다.)
<img src="https://velog.velcdn.com/images/leejh3224/post/8be15e10-fd11-49e6-afe9-6c25ce5fa2a1/image.png" alt="recycle">
다른 드라이버들도 구현의 차이는 있지만 SQLAlchemy와 비슷한 방식을 사용한다.
<a href="https://people.apache.org/%7Efhanik/tomcat/jdbc-pool.html">Tomcat JDBC Connection Pool</a> 문서를 살펴보면,
<code>testOnBorrow</code>, <code>validationQuery</code> 옵션의 설명을 살펴보면 Pessimistic 방식임을 알 수 있다. (커넥션을 가져오기 전에 ping을 날려 커넥션을 확인) 
<img src="https://velog.velcdn.com/images/leejh3224/post/b55a62ab-3d37-4ace-9adf-d1373f1c1801/image.png" alt="jdbc-options">
한 가지 다른 점은 커넥션을 가져올 때 (checkout) age 체크를 하는 SQLAlchemy와는 달리 Tomcat JDBC Connection Pool은 idle 커넥션을 정리하는 별도의 Thread를 실행시켜 주기적으로 정리함을 알 수 있다. (<code>minEvictableIdleTimeMillis</code> 값이 기본 60초로 설정. 즉 60초 이상 idle 상태가 지속되면 정리 대상이 됨)
<h2 id="mysql2에서-대처하기">Mysql2에서 대처하기</h2>
<ol>
<li><code>enableKeepAlive</code>, <code>keepAliveInitialDelay</code></li>
</ol>
위 옵션을 사용하면 드라이버에서 연결을 맺기 위해 사용하는 TCP 스트림에 keep-alive를 설정할 수 있다.
<code>keepAliveInitialDelay</code> 값을 mysql 서버의 <code>wait_timeout</code> 값보다 적은 값으로 설정하면 <code>wait_timeout</code>이 트리거되기 전에 타임아웃을 갱신할 수 있다.
<ol start="2">
<li><code>maxIdle</code>, <code>idleTimeout</code></li>
</ol>
<code>maxIdle</code> 값은 기본으로 <code>connectionLimit</code>과 동일한 10으로 설정되어 있는데 그 경우 idle 커넥션을 재갱신하는 루프가 돌지 않는다.
그러므로 <code>maxIdle</code> 값을 더 작은 값으로 설정하여 <code>idleTimeout</code>에 설정된 시간만큼 사용되지 않은 커넥션을 갱신될 수 있게 한다.
<h2 id="추가-aurora-mysql-디비-사용-시-권장사항">(추가) Aurora Mysql 디비 사용 시 권장사항</h2>
<a href="https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf">Aurora Mysql DBA 핸드북</a>에 따르면
<ol>
<li>커넥션을 주기적으로 검증/확인하라</li>
<li>Pool에 커넥션이 너무 오래 남게하지 마라</li>
</ol>
위 2가지를 권장하고 있다.
<pre><code>• Check and validate connections periodically even when they're not
borrowed. It helps detect and clean up broken or unhealthy connections
before an application thread attempts to use them.

• Don't let connections remain in the pool indefinitely. Recycle
connections by closing and reopening them periodically (for example,
every 15 minutes), which frees the resources associated with these
connections. It also helps prevent dangerous situations such as runaway
queries or zombie connections that clients have abandoned. This
recommendation applies to all connections, not just idle ones.</code></pre>
<h2 id="참고">참고</h2>
<ul>
<li><a href="https://docs.sqlalchemy.org/en/14/core/pooling.html">https://docs.sqlalchemy.org/en/14/core/pooling.html</a></li>
<li><a href="https://kyungyeon.dev/posts/92/">https://kyungyeon.dev/posts/92/</a></li>
<li><a href="https://github.com/sidorares/node-mysql2/issues/1103">https://github.com/sidorares/node-mysql2/issues/1103</a></li>
<li><a href="https://github.blog/engineering/infrastructure/three-bugs-in-the-go-mysql-driver/">https://github.blog/engineering/infrastructure/three-bugs-in-the-go-mysql-driver/</a></li>
</ul></div></div>

leejh3224.log

발단
Aurora MySQL 디비를 사용할 경우, minor 혹은 patch 버전에 대한 자동 업그레이드가 기본 활성화돼있다.
그리고 자동 업그레이드가 진행되는 동안 기존 인스턴스를 재부팅하는 과정이 포함되므로 애플리케이션의 디비 연결에 잠깐의 끊어짐이 발생할 수 있다.
재부팅으로 인한 다운타임은 인스턴스의 사이즈나 버전 등에 따라 차이가 있지만 내 경우에는 그리 길지 않았다. (12:03 ~ 12:04, 즉 1분 미만)
하지만 몇몇 서버에서 버전 업그레이드가 종료된 후에도 새로운 인스턴스에 접속하지 못하는 현상이 지속되었으며, 문제가 되는 쿠버네티스 파드를 모두 제거 > 재기동한 후에야 정상화되었다.
이후 문제가 된 애플리케이션의 로그를 확인하니 아래와 같이 "Pool does Not exists" 와 같이 남아있었다.
[Nest] 1  - 08/05/2024, 4:00:11 AM  ERROR [AllExceptions] {"statusCode":500,"code":500,"error":"Error","message":"Pool does Not exists."}
첫 시도
처음에는 파드 재시작을 통해 문제를 해결했기 때문에 해당 프로세스를 자동화할 방법을 생각했다.
즉 Nest.js의 ExceptionHandler 클래스에서 Pool does Not exists 에러 발생 시 process.kill을 해 애플리케이션 프로세스를 죽이고, 이를 통해 파드 재시작을 트리거하는 것이다.
이 때 프로세스가 graceful 하게 재시작될 수 있게끔 nestjs-graceful-shutdown과 같이 연계하면 SIGTERM 시그널 수신 > 리소스 정리 > 파드 재시작 순서로 애플리케이션을 재실행하게 된다.
하지만 이 방법은 파드 재시작부터 ready 상태가 되기까지 수 분이상이 걸리므로 경제적이지 않다. 또한 상식적으로 생각해보면 새로운 디비 커넥션을 생성하는게 훨씬 효율적이다.
그래서 코드를 직접 확인해보기로 했다.
확인해보니 해당 에러는 애플리케이션에서 사용 중인 mysql2 드라이버로부터 발생하는 것이었다.
코드에서 알 수 있듯, 드라이버에서 연결할 수 있는 노드를 찾을 수 없을 때 해당 에러가 발생한다.
커넥션 풀에서 새로운 커넥션을 가져오려고 (borrow) 했고 이 과정에서 노드를 찾지 못해 커넥션을 가져오기 전에 에러가 발생했다.
RemoveNodeErrorCount
mysql2 드라이버의 경우 mysql 드라이버와 거의 호환되므로 mysql 드라이버의 pool 연결 옵션을 살펴보자.
mysql pool 연결 옵션에 따르면 커넥션 풀의 기본 동작은 removeNodeErrorCount 수치가 5에 다다르면 해당 노드를 더 이상 연결할 수 없는 노드로 간주, 해당 노드를 제거한다.
코드를 보면 더욱 명확하게 알 수 있다.
키바나에 남은 애플리케이션 로그를 확인해보니 더욱 명확해졌다. 설명처럼 5번 같은 노드에 접속하려고 시도했고, 다른 노드에 연결을 시도했다.
그리고 사용 가능한 모든 노드에 연결을 시도한 뒤 실패하자 Pool does Not exists 에러를 뱉은 것이다.
해결?
깃헙 이슈를 뒤져보니 나와 동일한 사례가 몇 가지 보였고, 또 블로그에서 RDS 버전 자동 업그레이드에 대한 대처를 한 사례가 있어서 찾아본대로 restoreNodeTimeout 옵션을 적용해보기로 했다.
하지만 확인 결과 이미 해당 옵션이 1000 (1초)로 적용되어 있었다.
즉 옵션이 적용되어 있었음에도 동작하지 않은 것이다.
mysql2 레포지토리에서 restoreNodeTimeout 을 검색해보면 해당 옵션이 아직 구현되지 않았음을 확인할 수 있다.
결국 해당 옵션을 지원하는 mysql 드라이버를 사용하기로 결정, mysql2 드라이버를 사용하고 있던 애플리케이션의 드라이버를 mysql로 교체했다.
한 가지 주의할점은 mysql 드라이버 사용 시 MySQL 8+의 caching_sha2_password authentication plugin 을 사용할 경우 인증을 실패한다.
그러므로 사용하는 계정이 mysql_native_password를 사용하는지 확인한 후 mysql 드라이버를 사용해야 한다.
더 나은 방법은 없나?
다른 방법이 없을까 찾아보면서 다른 드라이버에서는 디비 재시작 혹은 wait_timeout 설정 등으로 인한 연결 상실에 어떻게 대처하는지 궁금해졌고, 디비 연결에 대처하는 방법이 크게 2가지로 나뉜다는 것을 알았다.
SQLAlchemy Connection Pool 문서의 Dealing with disconnects 항목에 따르면
첫 번째 방법은 Pessimistic 방식이다.
Pessimistic 방식은 커넥션 풀에서 커넥션을 가져올 때 모든 커넥션이 항상 stale 하거나 닫혀있을 수 있다고 가정하고, 커넥션이 사용가능한지 확인한다. (ex ping())
물론 커넥션을 가져올 때마다 ping 을 날려 확인하는 방식은 비효율적이기 때문에 SQLAlchemy 내부에서 커넥션의 age를 확인해서 커넥션을 체크할지 말지를 결정한다.
SQLAlchemy pool base.py를 살펴보면 커넥션이 얼마나 오래됐는지 (fresh) 확인 후 pre_ping 요청을 날리는 것을 확인할 수 있다.
내부적으로 효율성을 높이기 위한 많은 장치가 있기 때문에 모든 커넥션을 가져올 때보다 ping 을 날리는 것만큼 비효율적이지는 않겠지만 pesimistic 방식은 필요하지 않은 추가 쿼리를 실행하므로 비효율을 동반할 수밖에 없다.
두 번째 방법은 Optimistic 방식이다.
이 방식은 pre_ping을 통해 적극적으로 커넥션의 유효성을 확인하는 대신 연결 도중 에러가 발생하면 해당 커넥션을 버리고 pool로 하여금 새로운 커넥션을 가져오게끔 하는 방법이다.
여기에 추가적으로 pool_recycle 파라미터를 사용하면 mysql의 wait_timeout으로 인한 커넥션 끊김을 대처할 수 있다.
(커넥션의 최대 수명 즉 max-age를 셋팅하여 커넥션을 해당 시간 이상 지속될 수 없게 한다.)
다른 드라이버들도 구현의 차이는 있지만 SQLAlchemy와 비슷한 방식을 사용한다.
Tomcat JDBC Connection Pool 문서를 살펴보면,
testOnBorrow, validationQuery 옵션의 설명을 살펴보면 Pessimistic 방식임을 알 수 있다. (커넥션을 가져오기 전에 ping을 날려 커넥션을 확인) 
한 가지 다른 점은 커넥션을 가져올 때 (checkout) age 체크를 하는 SQLAlchemy와는 달리 Tomcat JDBC Connection Pool은 idle 커넥션을 정리하는 별도의 Thread를 실행시켜 주기적으로 정리함을 알 수 있다. (minEvictableIdleTimeMillis 값이 기본 60초로 설정. 즉 60초 이상 idle 상태가 지속되면 정리 대상이 됨)
Mysql2에서 대처하기
enableKeepAlive, keepAliveInitialDelay
위 옵션을 사용하면 드라이버에서 연결을 맺기 위해 사용하는 TCP 스트림에 keep-alive를 설정할 수 있다.
keepAliveInitialDelay 값을 mysql 서버의 wait_timeout 값보다 적은 값으로 설정하면 wait_timeout이 트리거되기 전에 타임아웃을 갱신할 수 있다.
maxIdle, idleTimeout
maxIdle 값은 기본으로 connectionLimit과 동일한 10으로 설정되어 있는데 그 경우 idle 커넥션을 재갱신하는 루프가 돌지 않는다.
그러므로 maxIdle 값을 더 작은 값으로 설정하여 idleTimeout에 설정된 시간만큼 사용되지 않은 커넥션을 갱신될 수 있게 한다.
(추가) Aurora Mysql 디비 사용 시 권장사항
Aurora Mysql DBA 핸드북에 따르면
커넥션을 주기적으로 검증/확인하라
Pool에 커넥션이 너무 오래 남게하지 마라
위 2가지를 권장하고 있다.
• Check and validate connections periodically even when they're not
borrowed. It helps detect and clean up broken or unhealthy connections
before an application thread attempts to use them.
• Don't let connections remain in the pool indefinitely. Recycle
connections by closing and reopening them periodically (for example,
every 15 minutes), which frees the resources associated with these
connections. It also helps prevent dangerous situations such as runaway
queries or zombie connections that clients have abandoned. This
recommendation applies to all connections, not just idle ones.
참고
https://docs.sqlalchemy.org/en/14/core/pooling.html
https://kyungyeon.dev/posts/92/
https://github.com/sidorares/node-mysql2/issues/1103
https://github.blog/engineering/infrastructure/three-bugs-in-the-go-mysql-driver/

Node.js 서버에서 DB 연결 끊김에 대처하기

댓글