Zipkin 로그 최적화: AWS ALB 헬스 체크 설정과 로그 추적 간소화

Zipkin 추적 로그에서 ALB가 헬스체크를 진행하다보니 계속해서 로그가 남았던 문제를 해결해 보고자 한다.

 

이번 포스트는 아래의 내용에서 이어지는 글입니다!

SpringBoot MSA 로깅: Zipkin을 사용한 분산 추적에서 예외상황을 다루는 방법

지금까지 진행한 MSA 프로젝트에는 멤버와 레시피 서버 두 가지가 있었다. 이 서버들은 SNS와 SQS를 통해 서로 데이터베이스를 동기화하는 방식으로 설계되었고 Zipkin을 도입하여 로그 추적을 강화했다.

Zipkin을 적용한 후에, 분산 추적 로그를 확인하기 위해 Zipkin 웹 페이지에 접속했는데 내가 직접 보낸 요청한 HTTP 요청으로 인해 발생한 추적 로그보다는, ALB가 상태 검사를 위해 보낸 HTTP 요청으로 인한 로그가 훨씬 많이 남아 있는 상황이 발생했다. ALB가 서버 상태를 지속적으로 체크하기 위해 요청을 보내는 과정에서 이렇게 로그가 쌓인 것이다. 이 문제를 해결하기 위해서 ALB의 요청이 Zipkin에 기록되는 것을 최소화하려고 두 가지 방법을 시도해 봤다. 

1. Ping을 던지는 주기를 늘린다.
2. 기존에는 /test/ping이라는 url에 요청을 보냈지만 이것을 루트경로인 "/" 로 변경한다.

이번 포스트에서는 1번 Ping을 던지는 주기를 늘려보도록 하자

 

 

이 포스트는 아래의 글에서 설계한 MSA 프로젝트에서 이어지는 내용이니 괜찮으시다면 한번 읽고 와주시면 이해가 더 쉽게 되실겁니다!

Spring Boot MSA 환경에서 트랜잭션을 관리하며 스프링 이벤트/SNS/SQS를 사용하여 DB 정합성 보장하기1

 

 

글을 시작하기 전에 ALB의 헬스 체크가 무엇인지 간단하게 설명하겠다.

 

1. AWS ALB의 헬스 체크란?

---

1-1. 헬스 체크의 기본 원리

• ALB는 AWS에서 제공하는 로드 밸런서 중 하나다. 웹 트래픽을 여러 서버에 균등하게 분배해주는 역할을 하는데, 이때 중요한 것이 바로 '헬스 체크' 기능이다. 헬스 체크는 ALB가 연결된 서버들의 건강 상태를 주기적으로 검사하는 것을 말한다. 즉, 서버가 정상적으로 동작하고 있는지, 요청에 응답할 준비가 되어있는지를 확인하는 것이다.
  
  

1-2. 헬스 체크의 중요성과 기능

• ALB의 헬스 체크는 매우 중요한데, 왜냐하면 이 기능 덕분에 ALB는 트래픽을 정상적으로 처리할 수 있는 서버에만 요청을 전달하기 때문이다. 만약 어떤 서버가 문제를 일으키고 있다면, ALB는 그 서버로의 요청을 중단하고, 다른 건강한 서버로 트래픽을 보내게 된다.
  
  

1-3. 헬스 체크 응답의 해석

• 헬스 체크는 주로 HTTP 요청을 통해 이루어지는데, ALB는 설정한 주소로 HTTP 요청을 보내어 서버의 응답을 확인합니다. 서버가 정상적으로 응답하면 '건강하다'고 판단하고, 응답이 없거나 오류가 있다면 '비정상' 상태로 간주한다.
  
  

1-4. 헬스 체크와 서버 안정성

• 이런 헬스 체크 기능은 서버의 안정성과 가용성을 높이는 데 큰 역할을 한다. 사용자에게 끊임없이 안정적인 서비스를 제공할 수 있게 해준다. 하지만 이 기능이 로그에 많은 기록을 남길 수도 있다. 특히 Zipkin 같은 로그 추적 시스템을 사용할 때, ALB의 헬스 체크 요청이 로그에 많이 남게 되면 원치 않는 로그가 쌓일 수 있다. (지금 내 상황이다.)

 

 

지금 나의 Zipkin은 ALB의 헬스 체크를 어떻게 기록하고 있는지 확인해보자

 

 

2. 현재의 Zipkin 추적 상황 확인하기

---

2-1. alb ping 검증 전용 컨트롤러 소개

• 이전에는 아래와 같이 내가 스프링부트에서 healthcheck용으로 작성해준 컨트롤러 GetMapping 경로인 "/member/test"에 1분 간격으로 요청을 보내도록 설정했었다.

멤버 컨트롤러 경로

 

2-2. Zipkin에서 추적한 alb의 http요청 확인

• 그리고 Zipkin에 남겨진 추적로그를 확인해봤더니 아래와 같이 1분마다 요청이 찍혀있는것을 확인할 수 있다. (캡쳐본은 1분이지만 테스트를 하느라 잠깐 늘렸을뿐 기존에는 5초마다 검증하도록 설정했었다.)

Zipkin에서 추적한 내용

 

여기서 발생한 문제점은 ALB가 서버의 상태를 확인하기 위해 http요청을 계속 보내다 보니 추적 로그가 어마어마하게 쌓이고 있었다. 이게 ALB의 설정이 5초마다 요청을 보내도록 설정되어 있다보니 하루에도 ALB관련된 로그만 해도 엄청나게 많았다. 근데 사실 이 로그는 AWS의 로그를 보면 되기때문에 Zipkin에는 필요가 없는 로그다.

 

 

이제 어떤점이 문제인지 파악했으니 이것을 해결하기 위해 ALB의 헬스 체크 주기를 변경해 보자

 

 

3. 헬스 체크 주기 변경하기

---

3-1. 로드 밸런서 찾기

• aws 상단의 검색창에서 "로드밸런서"를 입력해서 찾는다.

aws 검색으로 로드밸런서 찾기

 

• 또는 EC2메뉴로 들어간 후에 상단의 메뉴 리스트에서 "로드 밸런서"를 클릭해서 들어간다.

EC2에서 로드밸런서 찾기

 

3-2. 설정할 로드 밸런서 선택하기

• 로드 밸런서에서 주기를 변경시키고자 하는(나의 경우에는 ECS 서비스에 적용된) 것의 이름을 클릭해서 들어간다.

로드 밸런서 선택

 

3-3. 로드 밸런서 세부 정보에서 "리스너 및 규칙" 으로 들어가기

• 위에서 이름을 클릭하면 아래와 같이 세부 정보 페이지로 이동된다.

로드밸런서 세부 정보

 

• 여기서 하단의 "리스너 및 규칙"에서 "대상 그룹으로 전달" 하단의 링크를 클릭해서 대상 그룹으로 들어가 준다.

리스너 및 규칙

 

3-4. 대상 그룹 확인하기

• 위에서 선택했던 "대상 그룹"에 대한 세부 정보 페이지로 이동될 것이다. 여기서도 맨 하단의 리스트를 봐야 한다.

대상 그룹 세부정보

 

• 하단의 리스트에서 "상태 검사"를 클릭하고 우측의 "편집" 버튼을 누르자

상태 검사 리스트

 

• 아래와 같이 "상태 검사 설정 편집" 페이지로 이동될 것이다.

상태 검사 설정 편집화면

 

3-5. 상태 검사 설정 편집하기

• 여기서는 2가지를 자세히 봐야한다. 먼저 "상태 검사 경로"이다. 이 경로는 내 SpringBoot 내부에 컨트롤러 맵핑이 존재하는 경로를 적어준 것이다. (하단의 이미지처럼 컨트롤러 코드를 작성했다.)

멤버 컨트롤러 경로

 

• 두번째로는 "고급 상태 검사 설정" 이다. 처음에는 이 항목이 열려있지 않은데 화살표를 클릭해서 열어주면 아래와 같이 나올것이다. 여기서 "간격"을 설정해서 ALB가 요청을 보내는 시간을 늘릴 수 있다.

고급 상태 검사 설정

 

• 나는 간격 시간을 우선 최대치인 300초로 변경시켜 주었다. (사실 시간을 늘리는것은 권장하지 않는다. 실제 운영서버라고 생각하면 로드밸런서가 트래픽 분산을 위해 계속해서 빠르게 서버간 ping을 체크해서 판단해야 하기 때문이다.)

간격 시간 설정

 

3-6. Zipkin 로그 확인

• 변경후 Zipkin을 확인했는데 5분 간격으로 잘 적용되었다.

Zipkin 로그 추적

 

 

 

 

ping을 5분으로 늦추고 나서 하루가 지난 후에 Zipkin기록을 확인해보니 이전에 비해 로그가 확연히 줄어든 것을 볼 수 있었다. 그렇지만 내 상황에는 이렇게 설정해서 로그 추적이 적게 남는것이 근본적인 해결방법은 아니었다. 왜냐하면 ALB를 사용하는 이유가 많은 트래픽이 발생했을 때 이것을 분산 처리를 하기 위해서인데 그러기 위해서는 지속적으로 서버가 통신이 되는지 ALB에서 핑을 던져서 검증을 해야하기 때문이다. 그럼 나는 ALB의 설정은 놔두고 Spring 내부에서 설정을 해서 추적을 금지하던지 Sampling을 추가해서 특정 경로로 들어오는 추적만 Zipkin에서 추적하도록 하던지 하는 작업이 필요했다. 다음 포스트에서는 이것을 해결해 보도록 하자

이 포스트는 Team chillwave에서 사이드 프로젝트 중 적용했던 부분을 다시 공부하며 기록한 것입니다.
시간이 괜찮다면 팀원 '평양냉면7'님의 블로그도 한번 봐주세요 :)

하다보니 재미있는 개발