카오스 엔지니어링

12장. 실험 선택 문제(및 해결 방법)

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

피터 알바로

사람과 기계의 상호 작용이 없는 대규모의 실제 시스템은 상상하기 어렵습니다. 이러한 시스템을 설계할 때 가장 어려운(그리고 가장 중요한) 부분은 서로 다른 두 종류의 리소스를 가장 잘 사용하는 방법을 찾는 것입니다. 이 장에서는 회복탄력성 커뮤니티가 인간과 컴퓨터를 자원으로 활용하는 방법을 재고해야 한다고 주장합니다. 특히, 통합 가시성 인프라를 사용하여 시스템 장애 모드에 대한 직관을 개발하고 궁극적으로 카오스 실험의 형태로 이러한 직관을 방출하는 문제는 사람보다 컴퓨터가 더 잘 수행할 수 있는 역할이라고 주장합니다. 마지막으로, 커뮤니티가 이러한 방향으로 나아갈 준비가 되어 있다는 몇 가지 증거를 제시합니다.

실험 선택

이 책의 나머지 부분에서 설명한 방법론과는 별개의(그리고 보완적인) 실험 선택 문제, 즉 어떤 시스템 실행에 어떤 결함을 주입할지 선택하는 문제는 에서 다루고 있습니다. 앞서 살펴본 것처럼 올바른 실험을 선택한다는 것은 사용자보다 먼저 버그를 식별하고 대규모 분산 시스템의 동작에 대해 새로운 것을 배우는 것을 의미할 수 있습니다. 안타깝게도 이러한 시스템의 내재적 복잡성으로 인해 실행할 수 있는 실험의 수는 통신하는 인스턴스의 수에 따라 기하급수적으로 늘어납니다. 예를 들어 20개의 서로 다른 서비스가 포함된 애플리케이션에서 가능한 모든 노드 충돌 조합의 영향을 철저하게 테스트하고 싶다고 가정해 보겠습니다. 이 적당한 규모의 분산 시스템도 노드 충돌만으로 영향을 받을 수 있는 방법은^{220가지, 100만 가지가 넘습니다}!

"그건 버그가 아니에요!"

이 섹션에서는 '버그'를 찾는 것이 카오스 실험의 주요 목표라고 가정하고 있다는 것을 알 수 있습니다. 비공식적인 의미로 '버그'라는 단어를 사용하지만, 이 단어에는 좁은 의미와 매우 넓은 의미의 두 가지 해석이 똑같이 유효합니다:

• 분산 시스템에서 가장 치명적인 버그 중 일부는 내결함성 로직의 미묘한 오류(예: 복제, 재시도, 폴백, 복구 등 관련)입니다. 이러한 버그는 실제 오류(예: 머신 충돌)가 발생하는 통합 테스트 중에만 드러나는 경우가 많기 때문에 코드에 오랫동안 잠복해 있다가 프로덕션에서 발견되면 치명적인 문제를 야기할 수 있습니다. 제 연구의 대부분은 이러한 종류의 '장애 시간' 버그에 좁게 초점을 맞추고 있습니다.¹

• 이 섹션의 뒷부분에서 자세히 설명하겠지만, 가정에 따라 시스템에서 허용되어야 하는 결함을 주입하는 카오스 실험을 수행하는 것이 합리적입니다. 카오스 실험에서 예상치 못한 결과(예: 사용자가 볼 수 있는 이상 현상, 데이터 손실, 시스템 사용 불가 등)가 발생한다면 분명히 이 가정이 틀린 것이며 어딘가에서 실수를 저지른 것입니다! 이러한 실수는 앞서 설명한 것처럼 장애 발생 시간 버그일 수도 있지만, 잘못된 구성, 지나치게 보수적인 보안 정책 또는 방화벽 ...