[SpringBoot] actuator로 헬스 췤

 

문제 상황

문제는 이사하는 도중 발생했다. 새집으로 이사를 하게되어 서브넷부터 EC2, RDB 등등 새로 다시 만들고 깃허브 액션 러너도 새 인스턴스를 바라보도록 변경하고 러너를 실행했더니 원인모를 일이 발생했다.

 

헬스체크가 안되는 것이였다. 

 

 

wait for new enviroment to be healthy 에서 하는 작업은 5초 간격으로 /actuator/health로 curl을 날려서 "UP"이 되기를 기다리는 작업이다. 이전에는 약 20초 정도 걸리던 작업이였는데, 아무리 기다려도 UP이 되지 않았다. 

 

인스턴스에서 접속해서 localhost:8080(혹은 8081)로 curl 날려도 요청이 잘 가는데, /actuator/health로 요청을 보내면 응답이 오지 않았다. 

 

원인 파악

/actuator/health 가 아닌 다른 경로 / 혹은 /api/help 로 요청을 보내면 적절한 응답이 오는데, /actuator/health만 안되는 걸 봐서 뭔가 yaml 설정에서 health 엔드포인트를 안열어 준 것인가 의심을 했었지만 그 문제는 아니었다. 

 

 

 

우리의 yml은 /health를 잘 열어두고 있었다. 

 

무엇이 문제일까 로그를 뒤지기 시작했다. 문제를 로그를 통해 발견하였다. 문제는 slave 데이터베이스였다. 우선 로그에선 이렇게 친절하게 설명하고 있었다. 

 

 

 

주저리주저리 뭐가 많지만 핵심은 처음과 끝, "DataSource health check failed",  "(db/routingDataSource/reader) took 31033ms to respond" 이다. 

 

그래서 이제는 DB를 중심으로 원인 분석을 하기 시작했다. mysql에 접속하여 테이블은 잘 만들어졌는지, 어디 이름이나 비밀번호 잘못입력한 곳은 없는지 꼼꼼히 살피다가 레모네가 문제를 찾아냈다. 

 

원인은 바로! slave DB의 포트에 있었다. 현재 열려있는 slave DB 포트는 3307인데, 3306으로 들어가려 했던 것이다.😭

 

문제 해결

3306을 바라보도록 되어 있던 설정을 3307로 변경해주니 문제가 해결되었다😀

 

배운 점

액추에이터의 헬스 체크는 단순히 서버가 띄어졌는지만 체크하지 않고, DB 서버 등 다른 서버도 잘 살아있는지 확인한다는 것을 배웠다. 사실 지금까지 DB 서버에 문제가 있으면 스프링 애플리케이션도 같이 실행되지 않았던 경험만 있었기에 문제 상황처럼 스프링 애플리케이션이 잘 올라온 걸 보고 DB도 문제없이 잘 올라왔을 거라고 추측했었다. 하지만 그게 아니였고 공식 문서를 살펴보니 DB 뿐만 아니라 mail 서버, 레디스 서버, 엘라스틱서치 클러스터 등등 더 많은 헬스 정보를 가져와서 현재 헬스 상태를 판단해주었다.

 

이렇게 많은 정보를 가져와 헬스 체크를 하다보니 개발자의 의도와는 다르게 동작하는 경우도 발생할 수 있다. 예를 들어 서비스 DB와 로그 DB를 분리하고, 로그 저장을 실패하여도 서비스 로직은 실패하지 않도록 구현하였다고 가정을 하자. 그런데 만약 로그 DB에 접속에 문제가 생긴다면 /actuator/health는 UP이 아닌 DOWN을 응답하고 서버는 shut down될 것이다. 즉 로그 저장엔 실패하더라도 서비스 로직은 실패하지 않도록 구현했음에도 불구하고 장애가 발생할 수 있다. (토스사례)

 

무튼 뭐든 잘 알고 사용하자.

---

참고

Spring actuator docs