카오스 엔지니어링

카오스 엔지니어링은 돌아가는 시스템에 일부러 작은 장애를 일으켜 봅니다. 그리고 시스템이 그 장애를 견디는지 실험으로 확인합니다. 진짜 장애가 찾아오기 전에 약한 곳을 먼저 찾아내려는 일입니다.

쉽고 빠른 이해

돌아가는 서비스의 서버 한 대를 일부러 꺼 보고, 손님이 아무것도 못 느끼는지 확인하는 일입니다.

장애에 대비해 둔 장치가 정말 도는지는 장애가 나 봐야 압니다. 새벽에 진짜 장애로 처음 알게 되는 것보다, 사람들이 지켜보는 낮에 작게 일으켜 알아내는 편이 덜 아픕니다.

어떻게 하나:

1. 평소에 서비스가 어떤 모습인지 숫자로 정해 둡니다
2. 서버나 요청을 두 무리로 나눕니다. 한 무리에만 서버를 끄거나 네트워크를 느리게 만드는 식으로 장애를 작게 넣습니다
3. 장애를 넣은 무리의 숫자가 그대로 둔 무리의 숫자, 곧 평소 모습에서 벗어나는지 봅니다. 벗어나면 약한 곳을 찾은 것입니다

일부러 장애를 내는 일이라 잘못 다루면 손님이 피해를 봅니다. 그래서 작게 시작하고, 언제든 바로 멈출 수 있게 준비해야 합니다.

숫자를 늘 읽을 수단과 실험을 바로 멈출 장치가 아직 없다면 할 때가 아닙니다. 그것부터 갖춥니다.

상세

건물에서는 불이 나기 전에 소방 훈련을 합니다. 일부러 경보를 울리고 사람들이 비상구로 나가 보게 합니다. 그래야 막힌 비상구나 안 울리는 경보를 불이 나기 전에 찾습니다.

카오스 엔지니어링은 운영 중인 시스템에 장애를 일부러 넣는 실험입니다. 그 실험으로 시스템이 거친 상황을 견딘다는 믿음을 쌓습니다. 서버 한 대를 끄거나, 두 서비스 사이의 네트워크를 느리게 만들거나, 의존하는 서비스가 오류를 돌려주게 만드는 것이 그런 장애입니다.

이 실험이 필요한 까닭

요즘 서비스는 서버 여러 대와 서비스 여러 개가 네트워크로 이어진 분산 시스템입니다. 부품이 많으면 그중 어딘가는 늘 고장 나 있습니다. 고장이 드문 일이 아니라 평소의 일이 됩니다.

그래서 설계할 때부터 고장에 대비한 장치를 넣습니다. 대표적인 장치로는 서버가 죽으면 다른 서버가 이어받게 하는 페일오버, 실패한 요청을 다시 보내는 재시도, 답이 너무 늦으면 기다림을 끊는 타임아웃이 있습니다.

문제는 이 장치들이 고장이 나야 비로소 돈다는 것입니다. 평소에는 한 번도 안 불립니다. 그래서 설정이 틀렸거나 코드가 망가져 있어도 아무도 모릅니다. 장애가 난 새벽에야 대비책이 안 도는 것을 알게 됩니다.

카오스 엔지니어링은 그 첫 만남을 앞당깁니다. 사람들이 지켜보고 있고 곧바로 되돌릴 수 있는 낮에 장애를 작게 일으킵니다. 대비책이 도는지 거기서 확인합니다.

테스트와 다른 점

보통의 테스트는 답을 알고 시작합니다. 정해 둔 입력을 넣고 정해 둔 결과가 나오는지 확인합니다. 이미 아는 동작이 망가지지 않았는지를 지키는 일입니다.

카오스 실험은 답을 모르고 시작합니다. 여러 부품이 한꺼번에 얽힐 때 무슨 일이 벌어질지는 미리 다 따져 볼 수 없습니다. 그래서 장애를 넣어 보고, 시스템이 보여 주는 것에서 아직 모르던 약점을 배웁니다.

정상 상태를 숫자로 정한다

실험을 하려면 먼저 「멀쩡하다」가 무엇인지 정해야 합니다. 이것을 정상 상태라고 부릅니다. 정상 상태를 정해 두지 않으면 장애를 넣은 뒤 무엇이 달라졌는지 가릴 수 없습니다.

정상 상태는 시스템 안쪽이 아니라 바깥에서 보이는 출력으로 정합니다. 초당 처리한 요청 수인 처리량, 실패한 요청의 비율인 오류율, 손님이 기다린 응답 시간이 그런 출력입니다. 손님이 겪는 것은 결국 이 숫자들이기 때문입니다.

이 숫자들을 늘 읽을 수 있어야 한다는 전제도 따라옵니다. 시스템 안에서 무슨 일이 일어나는지 밖에서 알아볼 수 있는 성질을 관측성이라고 합니다. 관측성이 없으면 장애를 넣어도 결과를 못 읽습니다. 그때는 실험이 아니라 그냥 장애를 낸 것입니다.

실험의 네 단계

실험은 과학 실험과 같은 꼴로 짭니다. 한 번의 실험은 네 단계로 흐릅니다.

1. 정상 상태를 숫자로 정합니다
2. 장애를 넣어도 정상 상태가 유지될 것이라는 가설을 세웁니다
3. 서버나 요청을 두 무리로 나눕니다. 한 무리에만 서버 종료나 네트워크 지연처럼 현실에서 일어날 법한 장애를 넣습니다. 다른 무리는 그대로 둡니다
4. 가설이 틀렸음을 보이려고 해 봅니다

넷째 단계가 이 실험의 핵심입니다. 가설을 증명하려는 것이 아니라 깨려는 것입니다. 시스템이 버틸 것이라는 믿음이 틀린 곳을 일부러 찾아 나섭니다.

가설이 깨졌는지는 두 무리를 견줘서 가립니다. 그대로 둔 무리에서 잰 숫자가 지금의 정상 상태입니다. 장애를 넣은 무리의 숫자가 거기서 벗어나면 가설이 깨진 것입니다.

flowchart TD
    A["정상 상태를 숫자로 정한다"] --> B["정상 상태가 유지된다는 가설을 세운다"]
    B --> C["한 무리에만 장애를 넣는다"]
    C --> D{"넣은 무리의 숫자가 그대로 둔 무리와 같나"}
    D -->|"같다"| E["이 장애는 견딘다는 믿음이 쌓인다"]
    D -->|"다르다"| F["약점을 찾았다. 실험을 멈추고 고친다"]
    F -->|"고친 뒤 같은 실험을 다시"| C

두 무리의 숫자가 같게 나오면 그 장애에 대해서는 믿음이 한 겹 쌓입니다. 숫자가 다르게 나오면 약점을 찾은 것입니다. 찾은 약점은 고친 뒤 같은 실험을 다시 돌려 정말 고쳐졌는지 확인합니다.

넣는 장애의 종류

넣는 장애는 현실에서 일어날 법한 것으로 고릅니다. 일어날 리 없는 장애를 견뎌 봐야 얻는 믿음이 없기 때문입니다. 자주 넣는 장애를 무엇을 흉내 내는지와 함께 추리면 이렇습니다.

이렇게 장애를 일부러 만들어 넣는 기법 자체를 장애 주입이라고 부릅니다. 카오스 엔지니어링은 장애 주입을 도구로 써서, 위의 네 단계로 짠 실험을 돌리는 일입니다.

폭발 반경을 작게 시작한다

일부러 장애를 내는 일이라 실험이 잘못되면 손님이 다칩니다. 실험 하나가 망가뜨릴 수 있는 범위를 폭발 반경이라고 부릅니다. 실험은 이 반경을 가장 작게 잡고 시작합니다.

처음에는 서버 한 대, 요청의 아주 일부만 실험에 넣습니다. 가설이 버티면 범위를 한 단계 넓힙니다. 서버 여러 대로, 그다음에는 한 데이터센터 전체로 넓혀 갑니다. 가설이 깨지면 거기서 멈추고 고칩니다.

flowchart TD
    A["서버 한 대 · 요청 아주 일부"] --> B{"가설이 버티나"}
    B -->|"버틴다"| C["서버 여러 대 · 요청 더 많이"]
    C --> D{"가설이 버티나"}
    D -->|"버틴다"| E["한 데이터센터 전체"]
    B -->|"깨졌다"| F["멈추고 고친다"]
    D -->|"깨졌다"| F

어느 단계에서든 실험을 곧바로 거둘 수 있어야 합니다. 정상 상태의 숫자가 정해 둔 선을 넘으면 실험을 자동으로 멈추게 해 두는 것이 흔한 방법입니다. 멈춤 장치가 없는 실험은 시작하지 않습니다.

운영 환경에서 돌리는 까닭

실험은 손님이 실제로 쓰는 운영 환경에서 돌리는 것을 목표로 합니다. 시험용으로 닮게 꾸민 환경은 닮은 만큼만 믿을 수 있기 때문입니다. 트래픽의 모양, 데이터의 양, 옆에서 같이 도는 서비스가 다르면 무너지는 모습도 달라집니다.

그렇다고 처음부터 운영 환경에 들어가지는 않습니다. 시험 환경에서 실험을 먼저 돌려 뻔한 약점을 걸러 냅니다. 운영 환경으로 옮길 때는 폭발 반경을 가장 작게 잡고 다시 시작합니다.

한 번이 아니라 계속

시스템은 날마다 바뀝니다. 새 코드가 배포됩니다. 설정이 바뀝니다. 의존하는 서비스가 늘어납니다. 어제 견딘 장애를 오늘도 견딘다는 보장이 없습니다.

그래서 실험이 몸에 익으면 자동으로 꾸준히 돌게 만듭니다. 사람이 손으로 돌리는 실험은 드문드문 돌 수밖에 없습니다. 자동으로 돌면 배포 하나가 대비책을 망가뜨렸을 때 곧바로 드러납니다.

사람까지 시험하는 게임 데이

장애를 견디는 것은 기계만이 아닙니다. 경보가 제대로 울리는지, 대응할 사람이 경보를 받는지, 대응 절차를 적은 런북이 맞는지도 장애가 나 봐야 압니다.

그래서 날을 잡고 팀이 모여 장애를 일으켜 보는 연습을 하기도 합니다. 이것을 게임 데이라고 부릅니다. 기계가 견디는지와 함께, 사람이 알아채고 대응하는 흐름이 막힘없이 도는지를 봅니다.

이웃한 일과 가르는 선

장애를 일부러 일으키거나 대비를 점검하는 일은 여럿입니다. 이름이 섞여 쓰이기 쉬워 무엇을 알아내려는가로 가릅니다.

카오스 엔지니어링만 「아직 모르는 것」을 찾으러 갑니다. 나머지는 정해 둔 조건이나 절차가 맞는지를 확인하는 쪽에 가깝습니다.

대비책이 도는지 보는 일도 정해 둔 것을 확인하는 일처럼 들립니다. 그러나 대비책 하나하나가 어떻게 도는지는 알아도, 실제 장애 속에서 그것들이 한꺼번에 얽혔을 때 어떻게 되는지는 모릅니다. 카오스 실험이 찾는 것은 그 얽힘에서 생기는 약점입니다.

대가

이 실험은 공짜가 아닙니다. 첫째 대가는 위험입니다. 폭발 반경을 아무리 작게 잡아도 실험이 손님에게 닿을 가능성은 0이 되지 않습니다.

둘째 대가는 준비입니다. 정상 상태를 읽을 관측 장치, 실험을 곧바로 멈출 장치, 장애를 넣을 도구가 먼저 갖춰져야 합니다. 이것들이 없는 팀에게는 실험보다 이 준비가 먼저입니다.

셋째 대가는 찾은 약점을 고치는 일입니다. 실험은 약점을 보여 줄 뿐 고쳐 주지 않습니다. 찾아 놓고 고칠 시간을 못 내면 실험은 위험만 남깁니다.

관련 항목

카오스 엔지니어링이 쓰는 실험 도구와 기법

장애 주입 · Chaos Monkey · 게임 데이 · 폭발 반경 · 킬 스위치 · 대조군 · 가설 검증

실험 결과를 읽을 때 보는 지표

정상 상태 · 처리량 · 오류율 · 응답 시간 · 지연 · 백분위수 · 가용성 · 서비스 수준 목표 · 관측성 · 모니터링

실험이 제대로 도는지 확인하는 대비 장치

페일오버 · 재시도 · 타임아웃 · 서킷 브레이커 · 벌크헤드 · 우아한 저하 · 이중화 · 오토스케일링 · 로드 밸런서

실험으로 미리 찾으려는 장애

연쇄 장애 · 단일 장애점 · 네트워크 분할 · 썬더링 허드 · 재시도 폭풍 · 자원 고갈 · 회색 장애

카오스 엔지니어링과 목적이 갈리는 시험·훈련

스트레스 테스트 · 부하 테스트 · 스파이크 테스트 · 재해 복구 · 통합 테스트 · 회복 탄력성 테스트

실험 결과를 받아 쓰는 운영 작업

사후 분석 · 사고 대응 · 온콜 · 런북 · 경보 · 평균 복구 시간 · 오류 예산 · SRE

카오스 엔지니어링이 속하는 상위 분류

인프라 · 분산 시스템 · 신뢰성 · 회복 탄력성