요기요 카오스 엔지니어링 (2) 카오스 실험 결과 정리

Stage 환경에서 Locust로 약 350 RPS의 시나리오 트래픽을 지속 주입한 뒤, Pod 네트워크 지연과 외부 API 통신 장애를 각각 주입해 서비스 내성을 점검했다.

Pod Network Latency 실험에서는 500ms 지연이 가장 큰 파장을 만들었다. Pod CPU는 0.1~0.2 core에서 0.01~0.03 core로 떨어졌고, RPS는 거의 0에 수렴했으며, P99 요청 지연은 최대 30초까지 치솟았다. App 로그에는 HTTP 500과 함께 Redisson / Netty 스레드 리소스 소진으로 보이는 에러가 확인됐다.

트래픽은 Locust → ALB → Istio IngressGateway → 서비스 Pod 경로로 흘렀고, Istio에서는 UH (Unhealthy Upstream Host) 응답이 대량 발생했다. 즉, 건강한 업스트림이 없어 게이트웨이가 즉시 503을 반환했고, 그 결과 Locust의 RPS가 빠른 실패 응답과 매우 느린 성공 응답 사이를 오가며 크게 요동쳤다.

반면 250ms 지연에서는 양상이 달랐다. RPS는 약 17 수준으로 비교적 안정적으로 유지됐고, P99는 약 5초로 증가했지만 Pod 상태는 유지됐다. App 에러도 없었고, Happy Path Test도 통과해 "지연은 크지만 서비스는 버티는" 구간이 어디인지 확인할 수 있었다.

이 실험으로 얻은 핵심 인사이트는 다음과 같다.

• Redisson Error를 더 직관적으로 드러내는 예외 처리가 필요하다.
• 멤버십 서비스 장애 시 구독 회원 주문 실패를 막기 위한 비동기 처리 개선 여지가 있다.
• 병목은 Redis 연결 단계의 Queue 점유에 있었고, Queue 관리 로직 보강이 필요하다.
• 단순 Health Check가 아니라 시나리오 기반 트래픽에서 Pod Latency의 영향이 훨씬 크게 드러난다.
• AWS FIS는 유용하지만, 조직의 권한·거버넌스와 맞물리면 제약도 분명하다.

두 번째 실험은 외부 API 통신 장애를 검증했다. 외부 협력사의 wiithdraw-subscription API를 호출하는 경로를 AWS NACL로 차단하자 탈퇴 API 에러율이 급증했고, App은 500을 반환했지만 DB의 Started_at / Finished_at 등 정합성은 유지됐다. 즉, 회원 탈퇴 기능은 깨졌지만 다른 멤버십 기능은 정상 동작해 외부 벤더 장애에 대한 일정 수준의 내성을 확인했다.