개요

설정 변경 및 비즈니스 로직을 수정한 것이 없었으나, 외부 API와 통신을 주고 받는 마이크로서비스 컨테이너의 재기동 이후 해당 컨테이너에서 DB 연결 문제가 발생했다.

문제

Hikari Pool Connection timed out

Hikari CP 프레임워크가 DB 커넥션을 설정하지 못했을때 발생하는 Exception 중 하나로 말 그대로 연결을 맺는 도중 타임아웃이 발생한 경우이다.

해당 마이크로 서비스 컨테이너가 실행하고 있는 스프링부트 애플리케이션에서 DB 작업이 필요한 순간 위와 같은 Hikari CP 프레임워크 관련 Exception이 발생하며 DB 작업을 수행하지 못한다.

원인

node selector 부재에 따른 파드 오배포

결론적으로, 이번 문제의 원인은 애플리케이션의 문제나 DB등의 문제가 아니었다.

당행 API 시스템 컨테이너 오케스트레이션 플랫폼의 구성 노드 중, 해당 컨테이너 파드 deployment config에 node selector가 제대로 설정되지 않은 것,
즉, 노드 배포 정책이 없어 방화벽이 적용되지 않은 다른 노드로 배포된 것이 원인이었다.

어떤 소스 수정이나 DB 설정의 변경이 없었기에 애플리케이션에 직접 원인이 있지는 않을 것이다.

그렇지만, 로그에 출력되는 Exception이 Hikari CP 예외 였다는 점과 Hikari 프레임워크 자체가 DB 커넥션 풀 프레임워크였다는 점에 갇혀, 애플리케이션이나 DB의 문제로 단정 짓고 있었다.

비즈니스 관련 수정에 따른 재배포가 아니라, 단순히 컨테이너 재기동을 한 시점부터 DB 연결이 안되기 시작한 것이기에 좀 더 컨테이너를 지휘하는 플랫폼, 즉, 쿠버네티스나 OCP의 관점에서 원인을 확인해 볼 필요가 있다는 생각이 들기 시작했다.

쿠버네티스나 OCP는 구체적인 노드 선택자를 지정하지 않는 이상, 노드의 자원 사용 현황을 보고 최적의 노드를 선택하여 파드를 배포하는 것을 떠올린 시점에서, 파드를 확인해보자 아니나 다를까, 워커 노드에 배포되어 있어야 할 파드가 인프라 노드로 배포되어 있는 것이 아닌가..

해결 방법

node selector 설정 및 노드 지정 배포

해결 방법은 아주 단순하다

해당 애플리케이션의 deploment config에 직접 node selector 지정 후 재배포 해준다

yaml
      nodeSelector:
        node-role.kubernetes.io/worker: ''

워커 노드로 배포되면 해결이 되었기 때문에 위와 같이 간단한 쿠버네티스 디폴트 워커 라벨 키를 통해 매핑을 시켜주었다