Five Nine 문제들

번역

제목: Five Nine 문제들

나의 숨은 즐거움 중 하나는 완벽함을 추구하는 것이다. 대부분의 상황에서는 확실히 결점이지만, 해결책이 일정 수준의 완벽함을 요구하는 문제들이 있다. 이러한 문제들을 나는 “5-9 문제”라고 부른다: 어떤 차원에서 다섯 개의 9(또는 그 이상)가 필요한 문제들이다. 보통 이 9들은 어떤 종류의 정확성을 의미하지만, 가용성이 될 수도 있고, 일부 시스템의 경우 속도가 될 수도 있다.

오늘날 많은 소프트웨어 엔지니어링은 1개의 9, 기껏해야 2개에서 멈춘다. AI가 이것의 대표적인 예다: 작동하는 경우에 놀라운 결과를 제공하기 위해 가끔 실패하도록 설계된 시스템. 이는 제품을 빠르게 만드는 환상적인 방법이지만, 더 많은 9가 필요한 문제에는 부적절하거나 완전히 실용적이지 않은 접근법일 수 있다. 이것이 대기업이 스타트업에 비해 느리게 움직이는 큰 이유다: 9의 개수와 그것을 가지고 있다는 증명.

소프트웨어 엔지니어링 외부에서, 많은 엔지니어들은 정기적으로 5-9 문제를 다룬다. 어느 수준에서, 이러한 문제들은 실제로 구축보다는 올바른 것을 구축했는지 확인하는 것에 관한 것이며, 이는 매우 다른 프로세스로 이어진다. 그러나 소프트웨어 엔지니어들은 종종 이 엔지니어링 프로세스가 얼마나 느린지 비난하며, 많은 다른 엔지니어링 분야들도 과하게 할 수 있다: 1개의 9만 필요하다면, 5개는 큰 낭비다.

5-9 문제 해결하기

5-9 문제는 종종 사고, 구축, 증명의 과정으로 해결된다. 마지막 단계부터 시작하겠지만, 이 세 단계는 모두 종종 섞여 있다. 증명은 이상적으로 구축한 것이 100% 시간 동안 작동한다는 것을 증명하는 것을 포함하지만, 실용적으로는 거의 거기까지 도달하는 것을 의미할 수 있다. 이것은 종종 5-9 문제의 가장 어려운 측면이며, 자체 섹션을 가질 것이지만, 대부분의 소프트웨어 엔지니어링과 달리, 테스팅만으로는 보통 충분하지 않다. 지향적인 단위 테스트는 알려진 코드 경로에 대한 큰 확신을 제공하지만, 그 너머에 숨어 있는 알려지지 않은 버그에 대해서는 아무것도 말해주지 않는다. 5개의 9에 대한 보장은 알려지지 않은 미지의 것들이 없다는 보장을 의미한다.

코드 작성과 별개로 생각하는 것은 안타깝게도 당신이 옳다는 것을 증명할 수 있어야 할 때 피할 수 없다. 5-9 문제를 해결하는 가장 좋은 방법 중 하나는 그것을 제약하고 복잡성을 제한하는 것이다. 또한 무엇을 증명할 수 있는지 생각해야 한다. 제약된 공간에서 문제를 해결하고, 그 경계 내에서 당신이 옳다는 것을 증명할 방법이 있으면, 해결책을 구축하기 시작할 수 있다. 그러나 생각만으로는 종종 무엇을 구축해야 하는지 알기에 충분하지 않다 - 프로토타이핑과 벤치탑 실험이 매우 도움이 된다.

구축 단계는 문제의 해결책을 설계하고, 소프트웨어 엔지니어의 경우 실제로 구축하는 것을 포함한다. 나는 이것이 프로세스에서 가장 짧고 간단한 부분이라는 것을 종종 발견했다. 문제의 증명과 사고 부분이 여기서 쉬운 성공을 위해 당신을 준비시킨다. 다리를 건설하는 사람들에게 “구축” 단계는 실제로 다리를 건설하는 것을 의미하지 않고, 올바른 것으로 증명될 수 있는 다리의 모델을 구축하는 것을 의미한다. 소프트웨어 엔지니어들도 같은 일을 할 수 있지만, 최종 제품이 모델과 일치한다는 것을 증명하는 추가 단계는 소프트웨어에는 어렵지만, 다리에는 꽤 쉽다.

옳다는 것을 증명하기

5-9 문제의 일반적인 문제는 당신이 옳다는 것을 증명하는 것이 거의 항상 문제를 해결하는 것보다 어렵다는 것이다. 이것은 종종 형식 검증이나 다른 형태의 컴퓨터 보조 논리적 추론의 영역이다. 다행히도, TLA+와 같은 시스템과 Lean, Coq와 같은 정리 증명 소프트웨어 사이에, 100% 문제를 해결하는 학문적 성향의 소프트웨어 엔지니어에게 사용 가능한 여러 옵션이 있다. 이러한 정리 증명 시스템은 활발한 연구 분야이며 여전히 가장 사용자 친화적이지는 않지만, 당신이 완전히 옳다는 것을 보장하기 위한 최고의 도구들이다.

수학 라이브러리는 이러한 도구를 활용하는 시스템의 좋은 예다. 한 쌍의 64비트 double로 완전한 테스팅을 하는 것은 완전히 불가능하지만, 정리 증명기는 여전히 당신의 해결책이 항상 허용 가능한 오차 범위 내에 있다는 것을 알 수 있게 해준다.

또는, 구성에 의한 정확성(correct-by-construction) 시스템은 특정 측면에서 정확하다는 것을 스스로 증명한다. 그러나 그들은 보통 당신의 애플리케이션이 종단간 올바르다는 것을 증명하는 데까지 완전히 가지 못한다. 202x년대 구성에 의한 정확성의 대표적인 예는 Rust의 메모리 안전성 보장이다. 안전한 Rust는 메모리 안전성 문제를 갖지 않을 것이다: 그것은 구성에 의해 메모리 안전하다. 정적 분석기로 C에서 유사한 보장을 얻을 수 있지만, 존재하는 모든 C와 C++의 자연 실험은 프로그래밍적으로 허용되지 않으면 모든 메모리 안전성 오류를 제거하는 것이 본질적으로 불가능하다는 것을 보여주었다.

5-9 문제의 핵심 이슈는 테스팅만으로는 정확성을 보장할 수 없다는 것이다. 테스팅은 문제를 디버그하는 유용한 방법이지만, 테스팅은 당신이 쓰러뜨릴 테스트 케이스로 보낼 가능한 버그 공간에서 모든 버그를 찾아내려고 시도하는 예술이다. 코드 커버리지와 같은 계측을 사용하더라도, 테스팅만으로는 거의 확실한 보장을 하지 못한다.

디지털 엔지니어들은 아마도 제약된 무작위 테스팅의 개념에 익숙하고, 소프트웨어 엔지니어들도 아마 퍼징에 대해 들어봤을 것이다. 두 경우 모두, 당신은 많은 수의 무작위로 생성된 입력을 당신의 것에 던지고 무엇이 나오는지 보며, 모델과 비교한다. 나오는 것이 예상 값과 일치하면, 당신은 올바른 테스트 케이스를 가지고 있고, 그렇지 않으면 오류가 있다. 이것은 당신의 입력 공간에 대해 효과적으로 과학을 할 수 있게 해준다. 이것들은 종종 일부 시스템에서 형식 검증의 실용적인 대체물이며, 꽤 잘 작동할 수 있다. 그래도, 5개의 9에 도달하기 위해 이런 종류의 과학을 하는 것은 부담스럽고 어렵고, 가능하기나 한지도 모른다.

도달할 수 없는 이상

일부 5-9 문제는 올바름을 증명하는 것이 불가능하다. 일반적으로, 정확성의 증명은 연역적 추론으로 이루어진다. TLA+는 안전하다는 것을 증명하기 위해 모든 상태 기계 전환을 시도하고, Lean과 같은 정리 증명기는 기호 논리로 작동한다. 당신이 옳다는 것을 증명하기 위해 과학을 해야 할 때, 당신은 그렇게 하는 것이 불가능한 상황에 있고, 단지 가까이 가야 한다. 다행히도, 정리 증명기와 정적 분석 도구는 점점 더 좋아지고 있으며, 계속 개선될 것이다. 또한, 형식 검증을 위한 두 번째 레이어가 오고 있어, Coq나 TLA를 모르는 사람들이 접근할 수 있게 한다: 예를 들어, ZeroRISC는 RISC-V 프로그램을 증명하는 데 도움이 되고, Rust는 형식 검증을 얻고 있다.

나는 최근 진정한 무작위성에 대해 작업하는 시간을 보냈다. 이것은 5-9 문제의 또 다른 형태이며, 내가 (과신하지만) 다른 많은 사람들보다 해결에 더 가까워졌다고 믿지만, 우리 모두 같은 문제를 가지고 있다: 당신이 완전한 엔트로피를 생성하고 있다는 것을 실제로 증명하는 것은 불가능하다. 완전한 엔트로피의 주장을 테스트하는 데 최선은 엔트로피를 생성하는 시스템의 물리학에 기반한 “상향식” 증명 접근법을 난수 생성기의 출력에 적용되는 무작위성 테스트의 “하향식” 스위트와 결합하는 것이다. 테스팅은 기본 모델과 종단간 시스템 모두에 대한 경험적 증거를 제공하지만, 100%에 도달하는 것은 없다.

우리는 다양한 방식으로 RNG를 공격하면서 테스트한다. 우리는 이러한 테스트에 신뢰성을 추가하기 위해 제3자 감사자를 참여시킨다. 우리는 다양한 환경 조건 하에서 오랜 시간 동안 많은 수의 장치를 테스트한다. 이 모든 것은 테스팅이 원하는 수의 9에 도달하고 어떤 것도 놓치지 않았다는 확신을 향상시키기 위해 이루어진다. 이 경우, 알려진 테스트 케이스의 9의 수는 5개보다 훨씬 많지만, 주요 작업은 알려지지 않은 미지의 것들을 제거하는 것이다.

문제 분류

엔지니어링 계획에서 흥미로운 범주 오류 중 하나는 필요한 9의 수를 잘못 추정하는 것이다. 너무 많거나 너무 적은 9는 문제를 초래할 수 있다. 너무 많은 9를 목표로 하면 - 예를 들어 다운타임을 허용할 수 있을 때 고가용성 서비스를 구축하는 것 - 이것은 시장에 더 느리게 도달하는 결과를 낳는 노력의 낭비다. 반대로, 너무 적은 9는 고객의 사용에서 중요한 시점에 오류나 다운타임을 초래할 수 있다.

가용성에 대해, 다음 가이드가 도움이 될 수 있다:

  • 90% 가용성은 연간 36.5일 또는 약 50,000분의 총 다운타임
  • 99% 가용성은 3.65일 또는 약 5,000분의 다운타임
  • 99.9% 가용성은 약 9시간(500분)의 다운타임
  • 99.99% 가용성은 52분의 다운타임
  • 99.999% 가용성은 5분의 다운타임
  • 99.9999% 가용성은 30초의 다운타임

이런 가용성이 필요하지 않은 서비스의 흥미로운 예는 미국 온라인 뱅킹이다. 대부분의 미국 은행들은 주말 동안 ATM에서의 현금 인출을 제외하고는 송금을 실행하지 않는다. 변하지 않을 잔액을 확인하는 것 외에는, 할 수 있는 것이 거의 없다. 무작위 다운타임이 없는 한, 온라인 뱅킹 서비스에서 90% 가용성을 가질 수 있다. 대조적으로, Google과 Facebook은 주로 광고 회사이지만, 오프라인 상태에서 초당 엄청난 금액을 잃으며, 가능한 한 많은 9의 업타임을 목표로 한다.

정확성에 대해서는:

  • 99% 정확은 100번 중 1번 오류를 예상할 수 있다는 의미
  • 99.99% 정확은 10,000번 중 1번 오류를 예상할 수 있다는 의미
  • 99.9999% 정확은 1,000,000번 중 1번 오류를 예상할 수 있다는 의미

나는 한번 입력이 0의 16비트 체크섬을 갖지 않는 한 완벽하게 작동하는 코드를 작성한 적이 있다. 체크섬이 16비트였기 때문에, 이 코드는 65,536번 중 1번 실패할 것이다. 99.998% 정확은 나쁘지 않지만, 처음 배포되었을 때, 한 시간 안에 잘못되었다. 이것은 코드 리뷰와 일부 (제한된) 퍼즈 테스팅이 오류를 잡기에는 충분히 드물었지만, 프로덕션에서 문제가 될 만큼 충분히 흔했다.

흥미롭게도, 많은 수의 9의 정확성을 가진 문제는 메모리 배열의 제조다. 메모리 배열의 일부 오류를 허용하기 위해 온디바이스 ECC를 가진 DDR5 이전에, 메모리 장치는 수천억 개의 셀의 완벽한 복사본을 가져야 했다.

더 큰 규모에서, 더 많은 9가 자연스럽게 필요하게 된다. 99% 가용성으로 1,000개의 서버를 실행하면 언제든지 최소 하나는 다운되어 있을 것이 보장된다. 이것이 더 큰 회사들이 더 많은 9를 필요로 하는 이유의 일부다. 앱에 시간을 보내는 10억 명의 고객이 있을 때, 가능한 모든 방식으로 망가질 것이 사실상 보장된다.

틀렸을 때

100% 문제라고 생각한 문제에 대해 틀렸을 때 일어나는 최악의 상황은 느려진다는 것이다. 생각하는 데 많은 시간을, 하는 데 많은 시간을, 테스팅하는 데 많은 시간을 보낸다. 한 가지에 너무 많은 시간을 보내면서 동료들과의 정치적 자본을 소진한다. 경쟁자들은 생각하거나 테스팅하는 데 거의 시간을 보내지 않고, 시장에 먼저 도달한다. 문제가 5-9 문제가 아닌 것에 대해 틀리면, 최악의 상황은 오류를 도입하는 것이다. 종종, 틀린 것에 대해 고객을 잃는다. 고객 신뢰를 잃거나 소송을 당할 수 있다. 때때로 사람을 죽일 수 있지만, 보통은 그렇지 않다.

“빠르게 움직이고 망가뜨리기”의 핵심 거래는 용서를 구하는 것이 그렇게 나쁘지 않고, 신뢰할 수 없다는 평판은 사라지며, 당신이 해결하는 것이 잘못되었을 때 보통 사람을 죽이지 않는다는 것이다. 판돈이 낮을 때 증명보다 구축에 집중하는 것이 매우 가치 있다.

다른 것 위에 구축하기

다른 제품과 서비스 위에 구축하는 것은 시장 출시 시간을 가속화하지만, 당신의 9에 영향을 줄 수 있다. 4개의 9의 업타임을 가진 제품에 의존한다면, 4개의 9의 업타임을 초과할 수 없을 것이다. 이것은 많은 서비스가 보장을 해야 하는 것들의 기반이 될 수 없다는 것을 의미한다.

한동안, AWS의 us-east-1 리전은 다운되는 것으로 악명 높았다. 그 리전에서 3개 이상의 9에 도달하는 것은 거의 불가능했을 것이다. 일부 스타트업들에게 us-east-1에서 단일 리전인 것이 자랑스러운 포인트가 될 정도였는데, 왜냐하면 나머지 인터넷도 다운되었을 때 다운되는 것은 실제로 문제가 아니기 때문이다. 오늘날 클라우드는 여전히 5개의 9의 업타임을 위해 다중 리전을 권장한다 - 일부는 다중 클라우드를 권장할 것이다.

반대로, 여러 옵션으로 구축하는 것은 더 많은 9를 추가할 수 있다. 3개의 9를 가진 두 개의 중복 서비스를 갖는 것은 그것을 신뢰성의 중요 경로에서 제거할 수 있다 - 그 서비스들의 다운타임이 상관관계가 없는 한. 이것이 리전 중복이 작동하는 이유다: 클라우드는 글로벌 종속성을 피하기 위해 열심히 일하므로, 리전 간 장애는 상관관계가 없어야 한다.

9의 사례 연구로서의 Tesla

Tesla는 전통적으로 5-9 엔지니어링으로 접근되는 문제에 90% 접근법을 취하는 회사의 대표적인 예다. 이것은 Tesla가 상상할 수 없는 일을 할 수 있게 했다: 그들은 당시로서는 완전히 새로운 시스템과 완전히 새로운 구동계를 가진 제품을 만드는 자동차 회사를 생산했다. 그들은 그것을 빠르게 했고, 믿을 수 없는 확률을 이겼다. 대부분의 자동차 스타트업은 무명이나 실패로 끝나는데, 이것은 주류가 되는 데 성공한 자동차 브랜드다. 예, 약간의 넓은 패널 간격이 있고 차가 완벽하지는 않지만, 실제 문제는 무선 업데이트로 해결될 수 있다. 소비자들은 당신이 차체 패널의 제조와 설계에 5-9 접근법을 취하는지 대체로 신경 쓰지 않는다는 것이 밝혀졌다 - 차를 팔기 위해 완벽할 필요는 없다.

그러나 Tesla가 성숙해지면서, 그들은 우울하게도 5-9 문제에 가까운 것으로 보이는 문제에 부딪히고 있다: 자율주행 자동차. Waymo는 자율주행에 도달하는 데 약간의 성공을 거뒀지만, 그들은 자동차를 온보드 슈퍼컴퓨터가 있는 믿을 수 없이 비싼 로봇으로 바꾸고, 목표 도시를 인치 단위로 매핑함으로써 그것을 한다. 그러나 차는 긴장한 십대처럼 운전하고, 교통 콘으로 무력화될 수 있다. Waymo는 또한 무엇을 할지 확실하지 않은 Waymo에게 인간이 피드백을 제공할 수 있는 풍부한 인터페이스를 그들 쪽에 추가함으로써 5-9 문제를 더 적은 9를 가진 문제로 바꾸는 데 성공했다. 점점 더 적은 인간 개입(훈련 가능한 방식으로 제공되는)을 가진 컴퓨터의 이 “켄타우로스”는 놀라운 자율주행자다.

반대로, “빠르게 움직이고 망가뜨리기” 접근법의 두 예인 Uber와 Tesla는 모두 자율주행 중 치명적인 충돌을 초래했다. 주목할 만하게, 그들은 이런 종류의 사고를 겪은 유일한 회사가 아니다: Ford도 치명적인 자율주행 충돌로 조사받고 있다.

속도와 정확성의 조화

문제를 정의하는 방식이 종종 5-9 문제를 다루기 쉽게 만드는 것이다. “해피 패스”에 집중하는 것은 전체를 다루려고 시도하는 것보다 더 빠른 진전을 만들 수 있게 한다. “90%”를 할 수 있는 차원이 대부분의 문제에 비해 바뀌었다: 정확해야 하지만, 50%의 시간에 할 수 있고 (그리고 나머지 50%에 대해 다른 것으로 신뢰성 있게 실패하거나 폴백할 수 있다면) 종종 훌륭한 것을 만들 수 있다. 나머지 50%는 긴 꼬리가 될 수 있다. 이 방법의 문제는 당신의 문제 감지가 5개의 9의 재현율을 가져야 한다는 것이다. 100% 정확하려면, 틀릴 수 있을 때 100%의 시간에 폴백할 수 있어야 한다.

이전에 존재하는 코드의 동작과 일치해야 하는 코드의 리팩토링 중에, 그 자체로 작은 100% 문제인, 시스템의 핫 패스를 재구축하는 것은 내가 매우 성공적이라고 발견한 것이다. 조건이 이상적이라는 것을 알 때 매우 간단한 멘탈 모델을 사용하여 정확할 수 있고, 일이 얼마나 이상적인지에 대해 의심이 있으면 기존 구현의 복잡한 오류 처리로 폴백할 수 있다.

5-9 문제를 하나씩 해결할 수 있는 작은 조각으로 정의하는 것은 빠른 해결책에 도달하는 다른 방법 중 하나다. 훌륭한 시니어 엔지니어나 아키텍트는 팀을 위해 이것을 할 수 있는 사람이며, 각 단계에서 구현과 검증의 문제를 처리한다. 어려운 부분은 항상 정확한지 확인하는 것이다.

신뢰성을 고려한 설계

신뢰성은 엔지니어링 프로젝트의 종종 말하지 않는 차원이다. 종종, 그것은 엔지니어링 프로세스에서 의식적으로 고려되는 마지막 차원이며, 당황스러운 사건이 한두 번 있은 후에야 그렇다. 그러나 미리 생각하는 것은 유용한 아이디어가 될 수 있다. 정직하게 생각하는 것이 중요하지만: 수직 SaaS 스타트업은 2개의 9를 넘어서는 더 많은 신뢰성 문제를 피할 수 있다. 데이터베이스 회사나 중요 인프라 서비스는 처음부터 5개에 대해 생각해야 할 가능성이 있다. 데이터를 저장하는 누구든지 10개 이상의 9의 내구성을 얻어야 한다. 당신의 9 요구 사항을 이해하는 것은 어디서 절약할 수 있고 어디서 노력을 기울여야 하는지 파악하는 데 도움이 될 수 있다.

강력한 보장이 필요한 서비스는 내가 구축하기에 가장 흥미롭다고 생각하는 것들이다. 기존 것들은 종종 그들이 증명 가능하게 올바르다는 것을 확인하기 위한 사용 가능한 도구에 의해 제한된다. 그러나, 이것은 최첨단의 상당한 발전을 얻기 위해 새로운 도구와 새로운 시스템을 함께 구축할 많은 여지를 남긴다.

배경지식 3가지

1. 가용성(Availability)과 신뢰성 메트릭의 실제 의미

가용성의 9들(The Nines)

가용성에서 “9의 개수”는 시스템이 작동 상태에 있는 시간의 비율을 나타냅니다:

  • 99% (Two nines): 연간 약 3.65일의 다운타임
  • 99.9% (Three nines): 연간 약 8.76시간의 다운타임
  • 99.99% (Four nines): 연간 약 52.6분의 다운타임
  • 99.999% (Five nines): 연간 약 5.26분의 다운타임

실제 시스템에서의 의미

이 개념은 단순한 수학적 계산을 넘어 시스템 설계에 근본적인 영향을 미칩니다:

  • 서비스 수준 계약(SLA): 클라우드 제공업체들은 일반적으로 99.9%~99.99%의 SLA를 제공하며, 이를 지키지 못하면 환불을 제공합니다
  • 복합 시스템의 가용성: 여러 구성 요소가 직렬로 연결된 경우, 전체 시스템의 가용성은 각 구성 요소의 가용성을 곱한 값입니다 (예: 99.9% × 99.9% = 99.8%)
  • 비즈니스 영향: Amazon의 경우 1분의 다운타임이 수백만 달러의 손실을 의미할 수 있어, 5-9 가용성이 비즈니스 필수 요소가 됩니다

측정의 함정

  • 단순히 업타임만 측정하는 것으로는 불충분합니다 - 성능 저하, 부분 장애도 고려해야 합니다
  • “계획된 유지보수” 시간을 제외하는 방식으로 통계를 조작할 수 있어, 실제 사용자 경험과 괴리가 발생할 수 있습니다

2. 형식 검증(Formal Verification)과 증명 시스템

형식 검증이란?

형식 검증은 수학적 방법을 사용하여 시스템이 명세를 만족한다는 것을 증명하는 기술입니다. 단순히 “잘 작동하는지 테스트”하는 것이 아니라, “모든 경우에 올바르게 작동한다”는 것을 수학적으로 증명합니다.

주요 도구와 기술

  • TLA+ (Temporal Logic of Actions): Amazon에서 분산 시스템 설계를 검증하는 데 사용. 상태 기계의 모든 가능한 전환을 탐색하여 데드락, 레이스 컨디션 등을 찾아냅니다
  • 정리 증명기 (Theorem Provers):
    • Coq: 컴파일러(CompCert)와 같은 중요 소프트웨어 검증에 사용
    • Lean: 최근 수학 정리 증명에 혁명을 일으키고 있으며, 소프트웨어 검증으로 확장 중
  • 모델 체킹: 유한 상태 시스템의 모든 상태를 체계적으로 탐색하여 속성을 검증

실제 적용 사례

  • seL4 마이크로커널: 완전히 형식 검증된 운영체제 커널로, 보안이 중요한 시스템에 사용
  • 파리 지하철 14호선: 무인 운행 시스템의 안전성을 형식 검증으로 보장
  • 항공 우주: Boeing과 Airbus는 비행 제어 시스템의 일부를 형식 검증으로 검증

한계와 도전 과제

  • 복잡성: 실제 대규모 시스템을 완전히 검증하는 것은 여전히 매우 어렵고 비용이 많이 듭니다
  • 명세의 정확성: 형식 검증은 “명세대로 작동한다”는 것만 보장합니다. 명세 자체가 틀리면 소용없습니다
  • 전문 지식 필요: 형식 검증 도구를 사용하려면 수학적 논리와 정리 증명에 대한 깊은 이해가 필요합니다

3. 장애 허용(Fault Tolerance)과 중복성(Redundancy) 설계

장애 허용 시스템 설계의 기본 원칙

장애 허용이란 구성 요소가 실패하더라도 시스템이 계속 작동할 수 있도록 설계하는 것입니다. 이는 “5-9 문제”를 해결하는 핵심 전략입니다.

중복성의 유형

  • 능동-능동(Active-Active): 여러 인스턴스가 동시에 작동하며 부하를 분산. 하나가 실패해도 다른 것들이 계속 처리
  • 능동-대기(Active-Standby): 주 시스템이 작동하고 대기 시스템은 장애 시에만 활성화. 전환 시간이 필요하지만 리소스 효율적
  • N+1, N+2 중복성: N개의 활성 구성 요소에 1개 또는 2개의 여분을 추가하여 장애 시 대체

독립성과 상관관계

글에서 언급된 핵심 개념: 중복 시스템의 효과는 장애가 상관관계가 없을 때만 유효합니다.

  • 공통 원인 장애(Common Mode Failure): 같은 소프트웨어 버그, 같은 전력 공급원, 같은 네트워크 의존성 등으로 인해 중복 시스템이 동시에 실패할 수 있습니다
  • 다양성(Diversity): 다른 클라우드 제공업체, 다른 지리적 위치, 심지어 다른 구현을 사용하여 상관관계를 줄입니다
  • AWS의 가용 영역(Availability Zones): 각 영역은 물리적으로 분리되어 있지만 낮은 지연 시간으로 연결되어, 한 영역의 장애가 다른 영역에 영향을 미치지 않도록 설계

실제 설계 결정

  • CAP 정리: 분산 시스템에서 일관성(Consistency), 가용성(Availability), 분할 허용(Partition tolerance)을 모두 동시에 보장할 수 없습니다. 5-9 가용성을 위해서는 종종 일관성을 완화해야 합니다
  • 장애 감지와 복구:
    • 헬스 체크: 정기적으로 시스템 상태를 확인
    • 자동 페일오버: 장애 감지 시 자동으로 대기 시스템으로 전환
    • 회로 차단기 패턴: 장애가 전파되는 것을 방지
  • 비용 대 이득: 각각의 추가 9는 기하급수적으로 더 많은 비용이 듭니다. 99%에서 99.9%로 가는 것보다 99.99%에서 99.999%로 가는 것이 훨씬 더 어렵고 비쌉니다

카오스 엔지니어링

Netflix가 개척한 접근 방식으로, 의도적으로 프로덕션 환경에서 장애를 일으켜 시스템의 복원력을 테스트합니다:

  • Chaos Monkey: 무작위로 서버를 종료
  • Chaos Kong: 전체 AWS 리전을 시뮬레이션으로 다운
  • 이를 통해 중복성이 실제로 작동하는지, 상관관계가 없는 장애인지 확인할 수 있습니다

이 세 가지 배경지식은 “5-9 문제”를 이해하고 해결하는 데 필수적인 개념들입니다. 가용성 메트릭은 “얼마나 완벽해야 하는가”를 정량화하고, 형식 검증은 “어떻게 완벽함을 증명할 것인가”의 방법론을 제공하며, 장애 허용 설계는 “불완전한 구성 요소로 완벽한 시스템을 만드는 방법”을 보여줍니다.