🚨 HealthCheck 가 실패했다! 🚨

최근 진행하던 프로젝트에서 발생한 의문의 HealthCheck 실패 문제.
이를 분석하고 해결하던 과정에서 구축한 자동화 시스템을 소개한다.

1️⃣ . 문제 발생

이야기는 이렇게 시작된다.

어느날 오후에 특정 EC2 를 이용하는 페이지가 502 에러가 발생한다는 연락을 받았다.

일단 EC2 의 모니터링을 확인했을 때 문제가 없었으나 내부 컨테이너가 내려가있었고,

Elastic Beanstalk 에 무언가 문제가 생겼음을 예상할 수 있었다.

Elastic Beanstalk 이 Health 를 Red 로 띄우고 있었고 여기서부터 고민이 시작되었다.

당시에 간단하게 구조만 그려보자면 Ec2 안에 있는 Caddy 라는 오픈 소스 웹서버가

요청을 받아 인증서를 발급하여 Elastic Beanstalk 으로 프록시 해주고, 로드 밸런서가 리스닝해 이를 Elastic Beanstalk 환경과 연결된 Ec2로 분산하는 것이다.

이 과정에서 LoadBalancer 의 Target Group 이

특정 Port 로 Health Check 를 주기적으로 확인하는데, 이 과정에서 왜인지 비주기적으로 실패를 띄우는 것이였다.

2️⃣ . 시도 1 ) Health Check의 시간을 적절하게 바꾸기

당시에 LoadBalancer 와 Elastic Beanstalk 모두 Red 를 띄운 상태였고,

EC2 의 상태 자체에는 문제가 없었기에 Health Check 과정에서 어떠한 문제가 생겼다고 생각했다.

다만, 같은 시간대에 CPU 가 약간 올랐기 때문에 그 과정에서 네트워크가 잠시 느려졌을 수 있겠다고 생각했다.

EC2 > Target Groups > ~ > Edit Health Check Settings 에서 볼 수 있는 기본 화면

해당 타겟 그룹의 Health Check 의 Time Out 은 default인 5초였고 이 시간을 늘리도록 설정했다.

사실 그럼에도 이미 테스트 한 결과 1 초 이상의 결과는 절대 나오지 않아 이 방법으로 해결이 되지 않을 것 이라고 확신했다. ~~(해결되면 더 문제고)~~

다만 해당 EC2에 프론트가 남긴 로그나 ELB 에 로그와 관련된 설정이 없는 상태였기 때문에 원인을 찾을 수 없었고, 일단은 로그가 찍힐 환경을 만드는 것이 중요하다고 판단했다.

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/load-balancer-access-logs.html

엑세스 로그를 해당 공식 문서에 적혀있는 바와 같이 설정했다.

이게 본 주제는 아니니 간단히 작성하자면, S3 에 엑세스 로그를 넣을 버킷을 하나 만들었고

관련 권한을 부여해줬다.

다행히 과금은 전송이 아닌 S3 만 부여해주기 때문에 필요한 만큼만 쌓아두면 된다.

Amazon S3 > Buckets > {my_bucket} > Management LifeCycle 설정 예시

우리 프로젝트의 경우는 해당 로그를 쌓아둘 필요는 없었기 때문에 S3 의 Lifecycle Rules 를 설정하여 특정 주기 이후로는 없앴다. ~~돈 아껴 돈 소중해~~

2️⃣ . 시도 2) 로그 분석하기

ELB 로그에서 실마리를 잡았을까? 안타깝게도 주제가 주제인 만큼 여기서 실마리를 찾지 못했다.

오히려 이전과 다르게 Load Balancer는 금방 본인의 Health 를 되찾았으나,

Elastic Beanstalk 은 Load Balancer의 Health에 의존적이었기에 살아있는 인스턴스가 없다는 판단을 내리고 그대로 되살아나지 못했다.

당연하다. Elastic Beanstalk 은 스스로 HealthCheck 요청을 보내지 않기 때문이다.

결국 해당 에러에 대해 당장 실마리를 잡기엔 로그 분석에 시간이 더 필요했고,

클라이언트 쪽에도 몇가지 요청이 필요한 상황이었기에 내가 내린 판단은 하나였다.

예 이제부터 본론입니다.

3️⃣ . 진짜 HealthCheck가 안되는지 확인하기

일단 문제 상황이 특정 대상 그룹에서 발생하는 것은 알았다.

그렇다면 HealthCheck를 정말 보내기는 하는걸까? 받았으나 응답을 안하는 것일까?

이를 알기 위해서 해당 Ec2 내부에서 HealthCheck 를 하고 주기적으로 로그를 남기도록 스크립트를 작성해 실행시켰다.

잘 찍히는 것을 확인하고 해당 스크립트를 백그라운드로 실행했다.

4️⃣ . 팀원들에게 메일 보내기

이제 문제 상황이 발생했음을 팀원들에게 자동으로 알려야 한다.

문제가 발생되는 곳은 특정 Target Group 이였기 때문에 적절한 기준만 잡으면 된다.

EC2 > Target Groups > {my_target_group} > monitoring

이 모니터링은 TargetGroup 모니터링에 기본적으로 제공되니 CloudWatch 에서도 이를 기준으로 삼아 알람을 전송하도록 하면 된다.

CloudWatch > Alarms > Create alarm > Metric

CloudWatch > Alarms > Create alarm > Conditions

기준으로 잡을 Metric 을 선택한 후, 어떤 값을 기준으로 알람을 보낼지 선택하는 과정을 거치면 된다.

나같은 경우는 Healthy Host 즉 살아있는 인스턴스 값이 1 이하가 되는 순간으로 잡았다.

이제 SNS Topic 을 만들어서 누구에게 어떤 내용으로 메일을 전송할지 작성해주면 된다.

나 또한 팀원들의 메일과 어떤 문제가 발생했는지를 간략하게 적었다.

이후 인증 메일도 받고 에러가 나면 이런 식으로 문제가 발생될시 메일이 전송되게 된다.

대충 문제가 생겼으니 빨리 일해야지? 라는 내용으로 보냈다

5️⃣ . Elastic Beanstalk 살리기 자동화 하기 (1)

로그도 남겼다. 메일도 보냈다.

그러면 이제 남은 것은 적어도 클라이언트의 인스턴스가 접속에 문제없도록 자동화 하는 것이다.

https://aws.amazon.com/ko/about-aws/whats-new/2023/12/amazon-cloudwatch-alarms-lambda-change-action/

나는 럭키하다.

이 문제가 발생하기 전에 CloudWatch 경보에서 Lambda 함수를 호출하는 것을 지원해주기 시작했기 때문이다.

일단 Lamda 로 가, Elastic Beanstalk 을 살리는 스크립트를 짜면 될 것 이다.

이 과정에서 나는 Boto3 라는 AWS Python SDK 를 선택했다.

일단 파이썬이라는 언어를 다뤄본 경험도 있지만,

열심히 찾아봐도 비슷한 구축 자료가 없어 공식문서에 의존해야 했기 때문에 친절해야했다.

https://boto3.amazonaws.com/v1/documentation/api/latest/index.html

https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/elasticbeanstalk.html

여기서 Elastic Beanstalk 을 선택하면 가능한 API 목록을 보여주고

나는 여기서 update_environment 를 선택했다.

Updates the environment description, deploys a new application version, updates the configuration settings to an entirely new configuration template, or updates select configuration option values in the running environment.

-출처 : ElasticBeanstalk update_environment