요기요, 카오스 엔지니어링으로 서비스 안정성 확보

본문에 따르면, 요기요는 Stage 환경에서 Locust를 사용하여 Pod Network Latency 주입 실험을 진행했다. 500ms Latency 주입 시, Pod CPU 사용량 감소 및 RPS 급감 현상이 발생했으며, 응답 시간(P99)은 최대 30초까지 증가했다. 반면, 250ms Latency 주입 시에는 RPS가 감소했지만, Happy Path Test는 정상 통과했다. 500ms 실험에서 RPS가 급감한 원인은 Redis 연결 문제로, Netty 스레드/커넥션 리소스 소진으로 인해 발생했다. 250ms 실험에서는 Pod 상태가 비교적 안정적으로 유지되었다.

500ms Latency 주입 시, 클라이언트 측 RPS가 요동친 현상과 App 로그가 적게 남은 이유를 분석하기 위해 Istio Ingress Gateway 로그를 확인했다. UH(Unhealthy Upstream Host) 플래그가 대량 발생했으며, 이는 Redis 연결 문제로 인해 Istio가 해당 Pod를 라우팅 대상에서 제외했음을 의미한다. Istio는 503 응답을 즉시 반환했고, 간헐적으로 매우 긴 응답 시간을 가진 패킷도 발생했다. 이러한 현상으로 인해 Locust는 RPS를 높였다 낮추기를 반복하며, 클라이언트 지표에서 RPS가 크게 요동쳤다.

요기요는 외부 API 통신 장애가 서비스에 미치는 영향을 확인하기 위해, 외부 API에 대한 Outbound IP를 차단하는 실험을 진행했다. Outbound IP 차단 후, wiithdraw-subscription API의 에러율이 급증하는 것을 확인했다. APM Dependency Map에서 100% 실패가 확인되었지만, DB의 멤버 정보 정합성에는 문제가 없었다. Happy Path Test 결과, 회원 탈퇴 기능을 제외한 다른 멤버십 관련 기능은 정상적으로 동작했다. 즉, 외부 벤더 장애에 대해 일정 수준의 내성을 확보했음을 의미한다.

이번 카오스 엔지니어링 실험을 통해, 요기요는 다양한 개선점을 발견했다. Redisson Error 발생 시, 예외 처리 추가를 통해 에러를 직관적으로 확인할 수 있도록 개선했다. 멤버십 서비스 다운 시, 구독 회원의 주문 실패를 방지하기 위해 비동기 처리 방안을 모색했다. EKS Pod의 헬스 체크 실패 원인인 Redis Queue 점유 문제를 해결하기 위해, Queue 관리 로직 개선을 고려했다. 또한, Pod Network Latency가 서비스에 미치는 영향도를 확인하고, AWS FIS 서비스의 기능 및 제약 조건을 이해했다.

본문에서 카오스 엔지니어링 실험을 진행하며, 시나리오 구체화 및 핵심 지표 도출의 어려움을 언급했다. 장애 주입 도구 및 부하 테스트 도구에 대한 기술적 이해와, 서비스 환경에 맞는 설정 조정이 필요하다. AWS FIS와 같은 도구는 AWS Console에서 간편하게 실험을 수행할 수 있으며, Stop Condition 설정도 가능하다는 장점이 있다. 하지만, 조직의 거버넌스와 권한 부여가 맞물릴 경우, 제약 조건이 발생할 수 있다. 카오스 엔지니어링은 지속적인 학습과 테스트를 통해, 서비스의 안정성을 확보하는 데 기여한다.