AWS 로드 밸런서 Pre-warming 사용하기 (feat. Elb.InternalError)

우연한 계기로 AWS 로드밸런서 Pre-warming 기능을 사용하게 되어

그 경험을 정리해보았다.

 

이슈 발생

사내 담당 프로젝트에서 AWS Elastic Beanstalk의 Amazon Linux 2(AL2) 플랫폼 Node.js 16 버전을 사용 중이었다.

그런데 이 플랫폼이 2024년 10월 10일부로 지원이 중단되어, (AWS 지원 중단 안내문)

Elastic beanstalk 플랫폼 변경과 Node.js 버전 업그레이드가 필요했다.

 

버전 업그레이드를 위해 사용하던 빈스톡을 복제하고

복제한 빈스톡으로 트래픽을 모두 옮긴 뒤

기존에 사용하던 빈스톡을 Amazon Linux 2023 플랫폼 Node.js 18 버전으로 업그레이드 한 후

다시 기존 빈스톡으로 트래픽을 옮겨오는 계획을 세웠다.

(복제한 빈스톡을 업그레이드 하지 않은 것은 코드 파이프라인을 수정하지 않고 사용하기 위함이었다.)

 

복제한 빈스톡의 인스턴스를 당장 들어오는 요청을 처리할 수 있을 만큼 충분히 스케일 아웃하고

AWS 빈스톡의 블루/그린 배포 기능을 사용하여 기존 빈스톡에서 복제한 빈스톡으로 트래픽을 옮겼다.

(AWS Elastic Beanstalk 블루/그린 배포 공식 문서)

 

그런데 블루/그린 배포 과정에서 처음보는 에러가 발생했다.

Process default has been unavailable for 3 minutes (Elb.InternalError).

3분간 서버가 정상적으로 응답을 하지 못하고 503 에러를 반환했다.

 

프로젝트에서 운영 중인 빈스톡이 여러개가 있었는데

그 중 트래픽이 적은 빈스톡에서는 발생하지 않은 이슈였다.

이슈가 발생한 빈스톡은 초당 약 1만 3천 건의 요청이 들어오는 상황이었다.

 

빈스톡의 인스턴스는 넉넉했고

Elb Internal Error 라는 메시지를 보아 로드밸런서의 이슈이지, 빈스톡의 이슈는 아닌 것 같았다.

Internal Error 라고 하니 AWS의 내부적으로 발생한 이슈이고 우리는 손 쓸 수 없는 것일까 하는 생각도 들었다.

 

기존 빈스톡으로 트래픽을 다시 옮기는 블루/그린 배포 진행이 필요했기에

해당 작업을 트래픽이 적은 새벽 시간대에 진행하자는 의견도 있었으나,

팀원이 새벽에 일하도록 하는 것은 최대한 지양하고 싶기도 했고, 

편법을 사용하지 않고 문제를 정면으로 해결하고 싶었다.

 

AWS ELB Pre-warming

팀장님께 해당 이슈를 논의드렸고,

팀장님도 해당 이슈를 경험한 적이 있으며,

로드 밸런서도 대량의 트래픽을 받기 전에 워밍업이라는 과정이 필요하다는 이야기를 듣게 되었다.

 

AWS 공식 문서 - 로드밸런서의 함정

Pre-Warming the Load Balancer
Amazon ELB is able to handle the vast majority of use cases for our customers without requiring "pre-warming" (configuring the load balancer to have the appropriate level of capacity based on expected traffic). In certain scenarios, such as when flash traffic is expected, or in the case where a load test cannot be configured to gradually increase traffic, we recommend that you contact us to have your load balancer "pre-warmed". We will then configure the load balancer to have the appropriate level of capacity based on the traffic that you expect. We will need to know the start and end dates of your tests or expected flash traffic, the expected request rate per second and the total size of the typical request/response that you will be testing.

 

요약하자면, AWS 로드밸런서는 웬만한 경우에는 pre-warming 과정 없이도 

대량의 트래픽에 정상적으로 대응할 수 있지만,

트래픽이 점진적으로 증가하지 않고 아주 급격하게 증가하는 등 특수한 경우에는

로드밸런서의 pre-warming이 필요할 수 있다.

 

필요한 경우에는 AWS에 직접 컨택해서

예상 트래픽 양, pre-warming이 필요한 날짜 시간, 초당 요청량, 요청/응답 크기 등을 전달며

특정 로드밸런서의 pre-warming을 요청하는 Support Case를 오픈해야 한다.

 

AWS 콘솔에서도 이에 관해 설정하는 부분이 없고,

로드밸런서 pre-warming에 대해 안내하는 공식 문서도 별도로 없어서 (위 내용도 다른 문서의 일부로 짧게 실려있다.)

이 기능의 존재에 대해 알기가 아주 어려운 상황이었다.

 

사내에 AWS와 컨택을 지원해주시는 팀이 있어서

그 분들께 컨택을 요청드렸고, 아래와 같은 내용을 작성하여 전달드렸다.

 

AWS에서 요청을 거부할 수도 있어, 최대한 자세히 적어야 하며,

Support Case 오픈 후 AWS 측에서 승인하기까지 며칠이 소요될 수도 있다고 한다.

1. ELB DNS Name
: ELB 명

2. Event start date/time
: 이벤트 시작 시간

3. Event end date/time
: 이벤트 종료 시간

4. Expected percent of traffic going through the ELB that will be using SSL termination.
: SSL 사용 비욜 (%)

5. An approximate percentage increase in traffic, or expected requests/sec that will go through the load balancer.
: 예측되는 트래픽, 요구되는 Request per second 성능 수치 (ex. 1,500 request/sec)

6. Average amount of data passing through the ELB per request/response pair (In Bytes)
: 요청 + 응답 데이터 사이즈

※ 200KBytes와 같은 크기는 요청과 응답 데이터 사이즈로는 너무 크고 통상적이지 않습니다.
보통은 20KBytes 이내 입니다.

7. Number of Availability Zones enabled
: Target Group에 속해 있는 AZ들 (ex. ap-northeast-2a, ap-northeast-2c)

※ 주의: Pre-Warming 요청 시, 등록되어 있는 모든 AZ에 target instance가 존재해야 합니다.

8. Is the back-end currently scaled to the level it will be during the event?
: AutoScaling 등이 적용되어 있는가? (보통 AutoScaling 이라고 작성하시면 됩니다.)

9. A description of the traffic pattern you are expecting
: 트래픽 패턴이 어떤지? (Spiky 라고 작성하시면 됩니다.)

10. A brief description of your use case.
: 사용 사례 설명 (New game launch 혹은 Game event 등)

11. Are the back-end instances using persistent connections (Keep-alive)?
: Target instance가 keep alive를 사용하는가?

#정기 이벤트인 경우만 해당
A). (정기적인 이벤트가 예상되는 경우) Event 주기
: ex. Weekly 매주 목요일 20:20 ~ 20:40 (KST/UTC 표기)

B). (정기적인 이벤트가 예상되는 경우) Event 총 기간
: 몇개월 동안 이벤트가 진행되는지 (시즌 기간)

 

결과

다시 기존 빈스톡으로 블루/그린 배포하는 시간에 맞추어 Pre-warming을 적용했고

이전에 발생했던 에러 발생하지 않고 깔끔하게 작업 완료했다.