||
지난 (1)편에서는 카오스 엔지니어링을 시작하며 겪었던 이슈와 진행 과정을 소개했습니다. 이번 글에서는 카오스 실험을 통해 얻은 인사이트를 정리해보겠습니다.
작성에 앞서 실험 환경에 대해 소개하겠습니다.
24시간 365일 서비스를 운영해야 하는 특성상, 운영 환경에 직접 장애를 주입하는 것은 리스크가 크다고 판단하여 Stage 환경에서 실험을 진행했습니다.
또한 운영 환경과 최대한 유사한 트래픽 패턴을 재현하기 위해 Locust를 사용해 일정한 시나리오 기반 트래픽을 실험 기간 동안 지속적으로 발생시키고, 그 상태에서 장애를 주입하는 방식으로 테스트를 수행했습니다.
Pod Network Latency 주입 시나리오
최초 계획은 1차 실험에서 500ms, 2차 실험에서 1000ms의 Pod 네트워크 지연(Latency)을 주입하는 것이었습니다. 그러나 1차 실험 결과를 바탕으로 2차 실험 목표를 250ms로 조정했습니다.
실험 결과는 인프라 지표와 클라이언트(Locust 기반) 지표를 각각 정리한 뒤, 서비스 영향도를 Happy Path Test로 확인하는 방식으로 검증했습니다.
사전 단계에서 “기본이 되는 요청”이 지속적으로 발생하는 상황에서 Pod Network Latency를 주입해야 의미 있는 결과를 얻을 수 있었습니다. 이 부분은 QA 팀의 지원을 받아 테스트 시작 전부터 트래픽을 주입했고, 그 결과 Membershipyo 서비스에 약 350 RPS 수준의 요청을 생성할 수 있었습니다.
A. Pod Latency 실험 (500 ms)
수행시간 : 18:40 ~ 18:50
1. 인프라 모니터링
Pod CPU 사용량
실험 전에는 Pod CPU 사용량이 0.1 ~ 0.2 core 수준이었으나, 장애 주입 중에는 0.01 ~ 0.03 core로 크게 감소했습니다. 이는 Pod가 정상적인 처리(컴퓨팅)를 거의 수행하지 못한 상태로 해석할 수 있습니다.
요청 RPS (Request Per Second)
실험 전 Membershipyo 서비스의 RPS는 약 350이었으나, 장애 주입 후에는 거의 0에 수렴하며 요청이 들어오지 못하는 것으로 보였습니다. 단순히 Latency가 증가한 것만으로 이 정도까지 처리량이 떨어지는 것은 비정상적으로 보여, 추가 원인이 있을 것으로 예상했습니다.
요청 Duration 시간 (P99)
평소 25ms 이하로 처리되던 요청이 장애 주입 후 최대 30초까지 증가했습니다. 이 수준에서는 사실상 정상적인 서비스 제공이 어렵다고 판단할 수 있습니다.
2. Client Side 모니터링
(참고) Locust 환경 설정
vuser : 40 , Base RPS : 350
Locust는 기본적으로 응답 속도에 따라 RPS를 조정합니다.
“40 / 응답속도(초) ≈ 350 RPS”이므로 평균 응답속도는 약 0.11초 수준으로 추정할 수 있습니다.
Locust 메트릭
500ms Pod Latency 주입 시, RPS가 크게 요동치며 대부분 요청이 Failure로 처리되는 것을 확인했습니다. 특히 RPS와 Failure 지표가 함께 크게 출렁이는 현상이 특징적이었습니다.
Locust는 응답을 받으면 해당 응답 시간을 기준으로 RPS를 조정합니다. 그런데 RPS가 이 정도로 요동친다는 점은 일반적인 “지연 증가”만으로는 설명이 어려워, 뒤에서 추가 분석을 통해 원인을 더 살펴보겠습니다.
3. App 모니터링
App Log 확인
Datadog에서 확인되는 애플리케이션 로그 수는 많지 않았지만, 확인된 로그는 HTTP 500 응답 에러가 Uncaught Error로 처리되는 형태였습니다.
Trace Log 확인
Trace를 따라가며 Redisson 관련 에러를 확인했습니다.
Unable to write command into connection!
Check CPU usage of the JVM.
Try to increase nettyThreads setting.
메시지 내용으로 보아 애플리케이션에서 Redis 연결 과정에서 사용할 Netty 스레드/커넥션 리소스가