Skip to main content 집밥서선생

Chaos Engineering

Published: 2025-03-15

우끼끼

Abstract

우린 분산환경에서 페일오버가 잘 돌아가는지 확인하고 싶어요

그러기 위한 기술들을 Chaos engineering이라 부를 거에요. 뭐가 이쓴ㄴ지 알아볼거에요

Introduction

  • 요즘 세상에서 서비스 제공하려면 매일 새로운 기능이 추가되어야 함. 근데 이제 가용성을 곁들인
  • 그래서 넷플릭스는 무작위하게 인스턴스 골라서 꺼버리는 ChaosMonkey라고 하는 원숭이를 만들었음

    인스턴스 좀 죽어도 잘 살아있는 서비스를 만드는 게 목표

  • 그래서 엔지니어들도 인스턴스 죽는 건 웬만큼 대응 잘 해서, 한 발 더 나가보기로 했음

    리전 전체에 장애상황이 발생하는 것도 가정해서, 리전 샤따 내렸을 때 graceful하게 잘 종료되는지 그런것도 확인 (Chaos Kong)

  • 하드웨어 실패, 요청 수 급증, 런타임 파라미터 설정 미스 등에 의해 분산 시스템이 잘못 돌아갈 수도 있는데, 그걸 확인할 수 있음

Distributed System Perspective

  • 실질적으로 분산 시스템에서는 함수 사양으로 시스템의 모든 예상 동작을 설명할 수가 없음
  • 그래서 프로덕션에서 돌아가고 있는 프로세스의 동적 관점에서 설명하려고 함
    • 이미 배포된지 좀 되어서 별 문제 없이 AU를 받고 있는 상태, (steady-state)
    • 이 상태에서 사용자 요청에 의해 or 개발자들에 의해(배포 등) or 의존성이 있는 서드파티 변경에 의해 할 수 있음
    • 사양을 잘 구현하고 있는가? 보다는 잘 굴러가고 있는 것처럼 보이는가?에 초점

Principle of Chaos Engineering

  • Chaos Engineering에서 실험을 시작하려면 다음의 항목들을 지정해야 함
    1. 가설
    2. 독립 변수
    3. 종속 변수
    4. 맥락
  • 그리고 네 가지 원칙
    1. 가설은 steady state 기준으로 세우고
    2. real-world 이벤트는 다양하게
    3. 실험은 produciton에서 (!)
    4. 실험을 계속 돌리기 위해 자동화하기

Build a hypothesis around steady state behavior

  • 넷플릭스에서는 가용성(availability)를 가장 중요한 목표로 삼고 있음
  • 제공하는 서비스는 여러가지가 있는데(별점, 추천, 북마크 등), 각각이 다른 서비스로 이루어져 있음
    • 이 중 하나가 잠재적으로 실패할 수 있지만, 전체 시스템 가용성에 큰 영향은 없음
    • graceful degradation을 위해 fallback을 사용하여, 덜 중요한 서비스의 실패가 사용자 경험에 영향을 덜 미치도록 함
      • e.g. 캐시 서비스가 안 돌면 레이턴시가 좀 높아지긴 하겠지만 단기적으로는 큰 문제 없음
      • e.g. 비디오 추천 서비스가 실패하면 기본값 제공
  • 넷플릭스에서는 SPS(stream Starts Per Second)라고 하는 지표를 통해 시스템이 전반적으로 잘 굴러가고 있는지 판단
    • 그 외애도 초당 생성된 신규 유저 수 등등으로 판단가능
    • 다른 도메인에서는 다른 지표를 활용할 수 있을 것
  • 카오스 엔지니어링 실험을 설계할 때는 시스템의 steady state에 어떤 영향을 끼칠 지에 대해 가설을 세움
    • e.g. 특정 지역의 배포가 실패하는 경우, 다른 지역으로 페일오버함으로써 SPS에 최소한의 영향을 끼칠 것
  • SPS에 영향이 없어도 다른 세부 지표로 실험 결과를 결정 가능

Vary real-world event

  • 온갖 엣지케이스와 에러 가능성들을 다 건드려 봐야 함 (갑작스러운 레이턴시 증가, 잘못 보내온 클라이언트 요청, 요청 수 증가 등)
  • 잠재적으로 시스템의 steady state를 방해할 수 있는 것으로 보이는 상황을 선택
    • e.g. VM 종료시키기
    • e.g. 서비스간의 요청에서 레이턴시 증가시키기
    • e.g. 서비스간의 요청에서 실패하기
    • e.g. 특정 리전 비활성화하기
  • 특정 리전 비활성화같은 건 실제로 못하기 때문에 시뮬레이션하지만, 실험하다 실제로 시스템 터트릴 수도 있으니 잘 저울질함
Simian Army
  • 넷플릭스가 페일오버에 얼마나 진심인지 보여주는 프로젝트입니다 (unknown mention type link_preview)
  • 이런 걸 돌린다는 거 자체가 리스크가 있는 만큼, 업무 시간에 확실히 모니터링할 수 있는 업무 시간대에만 실행한다고 합니다
  • 지금은 archive된 프로젝트이므로 어떤 유형의 테스트가 있었는지만 정리해보았습니다.
  1. Latency Monkey
    • REST 통신에 인공적인 레이턴시를 유발
    • 특정 종속성에 걸린 서비스의 레이턴시를 아주 큰 값으로 잡으면, 해당 종속성에 문제가 있을 때 시스템이 잘못되고 있는지 확인 가능
  2. Conformity Monkey
    • best practice를 준수하지 않는 인스턴스를 찾아서 종료시킴 (asg에 속하지 않는 인스턴스 등)
  3. Doctor Monkey
    • CPU 로드 등의 메트릭을 수집하여 비정상 인스턴스를 수집.
    • 비정상 인스턴스가 감지되면 보고 후 문제의 서비스를 날림
  4. Janitor Monkey
    • 사용되지 않는 리소스를 찾아서 날림
  5. Security Monkey
    • 보안 정책 및 취약점 등에 의해 문제가 되는 인스턴스 찾아서 날림
    • 갱신되지 않은 SSL, DRM cert 등도 찾음
  6. 10–18 Monkey
    • 여러 지역/언어로 서비스할 때 문제 없는지 확인(cjk 또 너야?)
  7. Chaos Gorilla
    • AZ 전체를 날렸을 때 페일오버 잘 되나 확인

Run experiments in production

  • 여러 서비스가 상호작용하므로 integration test가 필요하며, 일부 테스트는 production에서만 가능 (전체 기능에 대해 E2E 테스트 불가)
  • 테스트 컨텍스트에서 실행되는 테스트가 통과하더라도 prod에서 돌아가는 것과는 차이가 생기므로 테스트해보긴 해야 함

Automate experiments to run continuously

  • 시간이 지나 새로운 피처가 추가되더라도 기존 테스트 결과가 유지되는지 확인하기 위해, 자동화하여 반복적으로 테스트
  • 넷플릭스에서는 Chaos Monkey는 평일마다 돌리지만 Chaos Kong은 한 달에 한 번씩

Running a Chaos Experiment

  • 서순은 다음과 같습니다
    1. steady state 정의
    2. 대조군과 실험군에서 steady state가 지속될 것이라고 가정하는 이론을 세움
    3. 실제로 일어날 법한 일을 반영하는 변수를 도입 (서버 크래시, 네트워크 끊어짐)
    4. 대조군과 실험군을 비교하여 가설이 깨졌는지 확인
  • e.g. 마지막 시청 위치를 트래킹하는 서비스는 SPS에 큰 영향을 끼치지 않음
    • 일부 유저를 실험군으로 분류하여 해당 유저들은 북마크 기록에 실패하도록 하고, 대조군은 냅둠
    • 이후 SPS 비교하여 큰 차이가 없는지 확인

Ref.

The Netflix Simian Army

arxiv.org

© 2026 JHSeo