[reinvent 2024] 실수 없이 실패하는 법: AWS에서 배운 교훈들

AWS는 대규모 시스템에서 발생하는 가장 큰 도전 과제로 가용성 감소 문제를 언급했습니다. 시스템의 총 가용성은 개별 구성 요소의 가용성을 곱한 값으로 계산됩니다. 이를 수치로 살펴보면, 구성 요소가 10개일 때 시스템의 가용성은 99.9%로 유지되지만, 10,000개로 늘어나면 가용성은 36.8%로 급감합니다. 이는 시스템 규모가 커질수록 장애 가능성이 기하급수적으로 높아진다는 것을 의미합니다.

특히 네트워크 통합(network convergence), 부하 급증(load spikes), 배포(deployment) 중 오류, 인스턴스 손상(instance impairment) 등이 주요 리스크 요인으로 꼽혔습니다. 이러한 문제들은 대규모 시스템이 복잡해질수록 더 빈번히 발생하며, 시스템 운영에 치명적인 영향을 미칠 수 있습니다.

AWS는 이와 같은 리스크를 해결하기 위해 단순히 장애를 피하려 하기보다는, 장애를 예측하고 이를 관리할 수 있는 설계를 통해 시스템 안정성을 확보해야 한다고 강조했습니다.

AWS Route 53의 사례에서는 Anycast 네트워크 기술을 활용하여 POP(Point of Presence)를 주기적으로 제거 및 복구함으로써, 장애 발생 시에도 고객 경험에 영향을 주지 않는 방식을 구현했습니다. 이는 복구 워크플로우가 단순한 반복 작업을 넘어 시스템의 안정성을 확보하는 중요한 전략임을 보여줍니다.

AWS는 시스템에서 병목 현상을 탐지하고 이를 해결하기 위해 Little’s Law를 활용합니다. Little’s Law는 시스템 동시 처리량(concurrency)이 요청 도착 속도(arrival rate)와 지연 시간(latency)의 곱으로 계산된다는 점에서 병목 구간을 파악하는 데 유용합니다.

예를 들어, 초당 100개의 요청이 들어오고 각 요청 처리에 0.5초가 걸린다면 시스템의 동시 처리량은 100×0.5=50100 \times 0.5 = 50입니다. AWS는 이와 더불어 “Sum of Latency”라는 지표를 도입하여 병목 구간을 시각화하고 문제 발생 전에 조치를 취할 수 있도록 했습니다.

특히 배포 과정에서 병목 현상이 발생하면 특정 인스턴스나 노드에 과부하가 집중되는데, AWS는 이를 탐지하여 문제가 있는 인스턴스를 격리하고 교체하는 방식을 통해 빠르게 복구를 진행합니다. 이러한 데이터 기반 접근 방식은 AWS의 시스템 복구가 얼마나 치밀하게 설계되었는지를 보여줍니다.