카오스 엔지니어링(Chaos Engineering): 일부러 서버를 부수는 이유

1. 백신을 맞는 것과 같다

우리는 왜 백신(Vaccine)을 맞을까요? 약화된 바이러스를 우리 몸에 일부러 투입해서, 면역 체계가 싸우는 법을 연습하게 하기 위해서입니다. 그래야 나중에 진짜 강력한 바이러스가 침투했을 때 당황하지 않고 이겨낼 수 있습니다.

카오스 엔지니어링(Chaos Engineering)은 소프트웨어 시스템을 위한 백신 접종입니다. "서버가 갑자기 꺼지면 어떡하지?", "네트워크가 10초 동안 끊기면 어떡하지?" 이런 걱정만 하는 대신, 실제로 서버 코드를 뽑아보는 것입니다. 가장 평화롭고 우리가 제어 가능한 시간에 고의로 장애를 주입(Fault Injection)합니다. 이를 통해 시스템이 자동으로 복구되는지(Resilience) 확인하고, 숨겨진 약점을 찾아내어 진짜 위기 상황에 대비하는 훈련입니다.

2. 넷플릭스와 원숭이 군단 (The Simian Army)

이 개념을 전 세계에 유행시킨 것은 넷플릭스(Netflix)입니다. 2011년, 넷플릭스는 자체 데이터 센터에서 AWS 클라우드로 이주하면서 다음과 같은 고민을 했습니다. "클라우드 인스턴스는 언제든 예고 없이 사라질 수 있다. 그런데도 우리 스트리밍 서비스가 안 끊기게 하려면 어떻게 해야 할까?"

그래서 그들은 무시무시한 도구, 카오스 몽키(Chaos Monkey)를 만들었습니다. 이 프로그램은 매일 근무 시간 중에 무작위로 운영 중인 서버 인스턴스 하나를 골라 강제로 종료시켜 버립니다. 개발자들은 처음에는 "무모한 짓 아니냐"며 기겁했지만, 곧 "서버가 언제 죽을지 모른다"는 가정하에 코드를 짜기 시작했습니다.

"서버 A가 죽으면 자동으로 서버 B로 연결되게 하자." (Failover)
"DB 연결이 끊기면 재시도(Retry)를 하되, 너무 많이는 하지 말자." (Circuit Breaker)
"Stateless하게 설계하여 어느 서버가 요청을 받아도 상관없게 하자."

결과적으로 넷플릭스는 AWS 전체 리전(Region)이 장애가 나도 서비스가 멀쩡히 돌아가는 괴물 같은 복원력을 갖추게 되었습니다. 현재 이 '원숭이 군단(Simian Army)'에는 다양한 병사들이 추가되었습니다.

Latency Monkey: REST API 응답을 일부러 3초 늦게 줍니다. (타임아웃 설정 테스트)
Chaos Kong: 서버 한 대가 아니라 리전(Region) 전체를 날려버립니다. (재해 복구 DR 훈련)
Janitor Monkey: 안 쓰고 방치된 리소스(Unused EBS, ELB)를 찾아내서 지워버립니다. (비용 절감)

3. 카오스 엔지니어링의 4원칙과 폭발 반경

카오스 엔지니어링은 아무거나 마구 부수는 스트레스 해소가 아닙니다. 체계적인 과학 실험입니다. Principles of Chaos에 따르면 다음 4단계를 따릅니다.

1단계 - 정상 상태(Steady State) 정의

"지금 시스템이 정상이다"라는 기준을 잡습니다. 기술적 지표(CPU 50%)보다는 비즈니스 지표가 좋습니다.

예: "분당 주문 성공 수(Orders Per Minute)가 100건 이상 유지되어야 한다."

2단계 - 가설 수립 (Hypothesis)

"DB 마스터 노드가 죽어도, 30초 안에 슬레이브가 승격(Promote)되어 주문 성공 수는 유지될 것이다." 구체적이고 측정 가능한 가설을 세워야 합니다.

3단계 - 실험 설계 및 실행 (Experiment)

실제로 DB 마스터 노드를 강제 종료하거나 네트워크 패킷을 차단합니다. 이때 중요한 개념이 폭발 반경(Blast Radius)입니다. 처음부터 전체 고객(100%)을 대상으로 실험하면 회사가 망할 수 있습니다. 처음에는 사내 테스트망 → 베타 서버 → 운영 서버 1% → 운영 서버 10% 순으로 폭발 반경을 조금씩 넓혀가야 합니다.

4단계 - 검증 (Verification)

가설대로 주문이 성공했는가? 아니면 에러 페이지가 떴는가?

성공했다면: 우리 시스템의 복원력이 증명된 것입니다. 자신감이 +1 상승했습니다.
실패했다면: 축하합니다! 치명적인 약점을 발견했습니다. 실제 장애가 터지기 전에 고칠 기회를 얻은 것입니다.

4. 실제! 'GameDay' 진행 가이드

회사에서 실제로 카오스 엔지니어링을 처음 도입하려면 어떻게 해야 할까요? AWS나 많은 기업에서는 GameDay라는 이름의 '소방 훈련'을 진행합니다.

준비물

참석자: 개발자, 운영자(SRE), 기획자 등 관련자 모두. (피자와 간식 필수!)
롤(Role) 분담:
- Commander: 훈련 전체를 지휘하고 "Start/Stop"을 결정하는 사람.
- Observer: 대시보드를 보며 시스템 지표를 감시하는 사람.
- Scribe (서기): 타임라인(몇 시 몇 분에 장애 주입, 몇 분에 알람 울림)을 기록하는 사람.

진행 순서

시나리오 선정: 너무 위험한(결제 DB) 것 말고, 영향도가 적은 서비스(이미지 리사이징, 검색)부터 시작합니다.
공격 주입: 공격 도구(Gremlin, Chaos Mesh 등)를 사용해 장애를 유발합니다.
관찰: 모니터링 대시보드(Grafana, Datadog)를 봅니다.
- 핵심 질문 1: 알람(Alert)이 제대로 왔는가? (안 왔다면 모니터링 설정부터 고쳐야 함)
- 핵심 질문 2: 사용자가 에러를 겪었는가, 아니면 우회(Fallback) 처리되었는가?
학습(Learning): 예상치 못한 동작이 발견되면 기록하고, 이를 수정할 티켓(Jira Task)을 생성합니다.
Stop Button: 고객에게 너무 큰 피해가 가면 Commander가 즉시 실험을 중단(Abort)하고 원상 복구해야 합니다.

5. 최신 도구: Chaos Mesh & Gremlin

이제 스크립트를 직접 짤 필요가 없습니다. 훌륭한 오픈소스와 SaaS 도구들이 있습니다.

1. Chaos Mesh (Kubernetes Native)

CNCF 프로젝트로, 쿠버네티스 환경에서 가장 널리 쓰이는 오픈소스입니다. YAML 파일로 장애를 정의할 수 있습니다.

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-example
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - default
    labelSelectors:
      "app": "nginx"

이걸 적용하면(kubectl apply) Nginx 파드 중 하나가 무작위로 죽습니다. NetworkChaos(지연 주입), StressChaos(CPU 부하), DNSChaos 등 다양한 실험이 가능합니다.

2. AWS FIS (Fault Injection Simulator)

AWS 리소스(EC2, RDS, EKS)에 특화된 관리형 서비스입니다. "특정 AZ의 전원을 차단한다" 같은 인프라 레벨의 장애를 쉽게 테스트할 수 있습니다.

6. 마무리 - "안전벨트를 매라"

전통적인 운영 방식은 "장애가 나지 않게 막는 것(Prevention)"에 집중했습니다. "장애 발생 = 누군가의 실수"라고 생각했습니다. 하지만 현대의 복잡한 분산 시스템(MSA)에서 장애는 피할 수 없습니다. 수천 개의 서버 중 하나는 지금 이 순간에도 고장 나고 있습니다.

카오스 엔지니어링은 관점을 "장애는 어차피 발생한다. 그러니 빨리 복구하는 능력(Recovery)을 키우자"로 바꿉니다. 불이 나지 않기를 기도하는 것보다, 정기적으로 소방 훈련을 하는 것이 훨씬 안전합니다.

여러분의 시스템을 믿지 마세요. 직접 부숴보고, 그 위에서 살아남는 법을 배우게 하세요. 그것이 진정한 신뢰성(Reliability)을 얻는 유일한 길입니다. "오늘의 장애는 내일의 평온한 밤을 위한 예방주사입니다."