요기요 카오스 엔지니어링 (1): 카오스 실험 시작하기

카오스 엔지니어링을 요기요의 membership-yo와 stage-integration 환경에서 시작했다. 운영 영향이 비교적 낮고 최근에 개발된 서비스를 대상으로, 실제로 발생 가능한 장애를 먼저 좁혀 실험 범위를 정했다.

시나리오는 두 가지였다.

• pod network latency를 단계적으로 늘려 서비스 반응을 확인
• 외부 API 통신을 차단해 탈퇴 흐름과 DB 정합성을 검증

도구는 AWS FIS를 선택했다. 대상 서비스가 AWS EKS에서 운영되고 있었고, FIS가 네트워크 레이턴시 주입을 명확히 지원했기 때문이다. 모니터링 지표는 latency, pod 수 변화, 5xx HTTP 상태코드로 잡았다.

실험 준비 과정에서 두 가지 문제가 드러났다. 첫째, Istio가 적용된 FIS pod가 기동 직후 Kubernetes API server와 통신하지 못해 종료됐다. 해결은 FIS pod에 sidecar.istio.io/inject: false annotation을 넣어 Istio sidecar 주입을 막는 방식이었다.

둘째, pod에 주입되는 임시 container가 장애 주입을 위해 root 권한을 필요로 했지만 서비스는 비-root 실행을 강제하고 있었다. 운영 환경은 건드리지 않고 stage 전용 PodTemplate에만 runAsNonRoot: false, runAsUser: 0, privileged: true, allowPrivilegeEscalation: true를 적용해 문제를 풀었다.

1부는 카오스 실험을 어떻게 시작했고, 어떤 시행착오를 해결했는지에 집중한다. 실제 관찰 결과와 인사이트는 2부에서 이어질 예정이다.