Tech

Load Balancer의 타깃 불균형 요청 문제해결

2023. 05. 09

안녕하세요. 데브옵스팀 장영석입니다. Load Balancer의 타깃 불균형 요청 문제해결

오늘은 간단한 트러블 슈팅 경험기를 소개하려 합니다. 트러블 슈팅은 장애 발생 시 긴급 대응과 이후 근본 원인을 추적하고 액션 아이템 생성 및 이를 해결하는 과정으로 나뉩니다.

데브옵스팀 트러블 슈팅 과정

화해 엔지니어링 그룹에서 장애 상황을 인지하기 위해 다양한 메트릭을 얼럿으로 설정하고 있습니다. 얼럿은 임계치를 기준으로 Warning과 Critical 두 가지 레벨로 설정합니다.

Warning Level
- Slack alert 채널 알림
Critical Level
- Slack alert 채널 알림 + 관련 장애 담당자 Voice Call

장애 발생 시 데브옵스팀이 선제적 대응을 합니다. 이 과정에서 애플리케이션 로직상의 문제로 판단할 경우 각 플랫폼(백엔드, 프론트엔드, AOS, iOS)의 동료들과 함께 긴급 대응을 합니다.

긴급 대응으로 장애가 해소된 이후 근본 원인을 찾아내기 위한 RCA(Root Cause Analysis)를 작성합니다. 이 과정에서 동료들과 많은 커뮤니케이션을 하게 되고 결과로 단기, 중장기 액션 아이템을 생성합니다. 해당 액션 아이템을 Jira 티켓으로 생성해 관련 팀이 우선순위 높게 관리합니다. RCA 문서 작성에는 많은 노력이 들지만 근본 원인을 추적하여 해결하면 잠재적인 리스크를 해소해 장기적으로는 리소스를 효율적으로 사용하는 방법이 됩니다.

문제 상황

새로운 프로모션으로 순간 트래픽이 급증할 것을 대비하여 관련 서비스의 capacity를 늘려 대응하고 있던 상황이었습니다. 프로모션 시작 시간이 되자 Elasticbeanstalk으로 구성되어 있던 레거시 서비스에서 장애가 발생합니다.

프로모션으로 인한 트래픽 증가

해당 서비스 내 Nginx의 포트 고갈로 약 2초간 Nginx에서 502 에러를 응답한 것을 확인했습니다.

5XX 에러 발생 지표

이후 트래픽을 모두 소화하면서 장애는 자연스럽게 해소되었습니다. 해당 에러 응답으로 인해 몇 명의 사용자가 상품 주문 시 에러 팝업을 경험한 것으로 확인되었습니다. 장애 지속시간이 짧고 경험한 사용자가 적지만 무시하고 지나칠 경우 재발 및 확대 발생하여 불쾌한 사용자 경험이 증가할 수 있습니다. 근본 원인 파악 및 해결이 필요합니다.

해결 과정

현재 화해 엔지니어링 조직은 모니터링 도구로 Elastic Observability를 사용하고 있습니다. AWS ELB(Elastic Load Balancer)에서부터 애플리케이션의 여러 로그를 수집하고 장애 또는 성능 분석 시 활용하고 있습니다. 해당 시간에 발생한 nginx error는 502 응답 에러로 포트 고갈로 발생했습니다. 특이한 점은 에러가 특정 인스턴스에서만 발생했다는 점입니다.

502 응답이 발생한 target IP 별 분포

단순히 포트를 늘리거나 capacity를 늘리는 것으로는 해결이 어려울 것 같습니다. 관련 Application Load Balancer의 라우팅 알고리즘을 라운드 로빈으로 설정했기 때문에 요청이 타깃으로 고르게 분산되어야 했기에 ELB 액세스 로그를 확인해 봅니다.

개선 전 타깃당 요청 분포

장애가 발생한 인스턴스에만 트래픽이 몰린 것을 확인했습니다. 프로모션을 대비하여 타깃 capacity를 증설했으나 특정 인스턴스에 몰리면서 기대한 효과를 누리지 못했습니다.

데브옵스팀에서는 다양한 기술환경에 대한 표준화를 진행하고 레거시 환경을 이전하는 작업을 진행하고 있습니다. 해당 서비스는 컨테이너 기반의 표준화 환경인 ECS Fargate로 이관 전인 환경으로, Elastic Beanstalk으로 운영하고 있습니다. 그러므로 미처 파악하지 못한 설정이 있을 수 있기에 상세한 설정을 파악해 봅니다.

확인 결과 Elastic Beanstalk에 stickiness 기능이 활성화되어 있었습니다. stickiness 기능을 활성화하면 클라이언트 별로 요청을 보낼 타깃을 지정하게 됩니다. 지정된 타깃은 stickiness cookie duration 설정 값 동안만 유효하고 이후 타깃을 재설정하는 방식으로 동작합니다.

실제 설정이 86,400초(1 day)로 설정되어 있어 프로모션 직전에 capacity를 늘려봤자 하루 안에 접속한 사용자의 타깃은 신규 생성된 타깃으로 흘러가지 않았습니다. stickiness 기능을 비활성화하면 현재 문제는 해결할 수 있지만 당시 활성화한 이유를 확인해야 사이드 이펙트를 최소화할 수 있습니다. 데브옵스팀은 대부분의 작업을 타깃화하고 내용을 작성하기에 슬랙과 Jira를 검색하여 당시 기록을 찾았습니다. 작업 기록을 확인하니 stickiness 기능을 활성화한 이유가 있었습니다. 레거시 배포환경을 사용하면서 빌드된 결과물이 배포 전후 달라지면서 발생하는 문제를 해결하기 위한 것이었습니다.

단기 해결방안으로 stickiness cookie duration을 30분으로 설정하기로 결정합니다. capacity를 프로모션 30분 전에 늘릴 경우 cookie가 초기화되면서 요청이 고르게 분산될 것으로 기대했습니다. 실제 테스트 결과는 아래와 같습니다.

개선 후 타깃당 요청 분포

stickiness 기능을 비활성화하지 않았기에 라운드 로빈처럼 고르게 분산되지는 않습니다. 하지만 capacity를 늘리는 것이 순간 트래픽 대응에 도움이 될 수준까지 개선되었습니다. 단기 액션 아이템은 위 방식으로 해결하여 남은 프로모션을 동일한 장애 없이 소화했습니다. 장기 액션 아이템으로는 레거시 환경을 표준화 환경으로 이관하는 작업이며 글 작성 시점에 이미 완료한 상태입니다.