분산 시스템의 연쇄 붕괴를 줄이기 위한 세 가지 원칙

분산 시스템의 붕괴는 겉보기에는 제한적인 오류에서 시작할 수 있지만, 많은 구성 요소가 서로 의존할 때 빠르게 일련의 장애로 변합니다. 소프트웨어 공학 독립 컨설턴트인 Sam Newman은 한 발표에서 토목공학의 연쇄 붕괴(Progressive Collapse) 개념을 디지털 시스템의 복원력 문제와 연결하며, 모든 오류를 막는 것은 불가능하지만 오류가 확산되는 가능성과 영향을 줄일 수 있다고 결론짓습니다.

Ronan Point 건물에서 클라우드 서비스까지

Newman은 1968년 런던 Canning Town 지역의 Ronan Point 타워에서 발생한 부분 붕괴 사고를 되짚습니다. Mrs. Ivy Hodge의 아파트 내부에서 발생한 제한적인 가스 폭발로 건물 일부를 지탱하던 외벽이 떨어져 나갔습니다. 폭발 지점 위에 있던 네 개 층이 무너졌고, 이어 연쇄적인 영향으로 타워 모서리 일부가 붕괴했습니다. 네 명이 사망했으며, 사고가 1968년 오전 6시 직전에 발생한 점은 희생자 수를 줄이는 데 도움이 된 요인이었습니다.

소프트웨어와 관련된 핵심은 건물과 디지털 서비스의 물리적 유사성이 아니라 장애의 양상입니다. 작은 초기 장애가 다른 구성 요소들이 의존하는 구성 요소를 마비시키고, 그 결과 피해 범위가 확대됩니다. 분산 시스템에서는 서비스, 데이터베이스, 로드 밸런서, DNS 시스템 사이의 관계가 도미노 조각의 행처럼 항상 눈에 보이는 것은 아니기 때문에 이러한 연쇄를 이해하기가 어렵습니다.

연쇄 장애의 디지털 사례

AWS의 us-east-1 리전 중단 당시 DynamoDB의 한 하위 구성 요소가 AWS 인프라 내부에서 DNS 경로를 업데이트하는 과정에서 문제를 겪었습니다. 계획 업데이트 과정의 결함으로 Route 53의 경로가 삭제되었고, 이후 네트워크 로드 밸런서, 컴퓨팅, 대기열, EKS를 비롯해 해당 경로에 의존하는 서비스가 장애를 일으키기 시작했습니다. 이러한 핵심 서비스는 다른 서비스에서도 사용되었기 때문에 문제가 최종 사용자 대상 제품과 기업으로 확산되었으며, Alexa, Ring, Slack, Snapchat, Zoom, Shopify 등이 영향을 받았습니다. 일부는 부분적으로, 다른 일부는 전면적으로 영향을 받았습니다.

AWS 보고서를 바탕으로 Newman이 설명한 바에 따르면, 시스템에는 DNS 변경 계획을 생성하는 스케줄러와 이를 적용하는 여러 실행자가 있었습니다. 한 계획은 평소보다 오래 걸렸고, 이후 다른 실행자가 또 다른 계획을 생성해 빠르게 실행했습니다. 나중에 이전 계획의 실행이 완료되자 새 계획이 생성한 경로를 제거했습니다. 그 결과 Race Condition이 발생해 DNS 항목이 삭제되었습니다.

두 번째 사례는 중고차, 오토바이, 트레일러를 판매하는 사이트로, Sauron이라는 코드명의 애플리케이션이 10대의 서버에서 작동하고 있었습니다. 이 애플리케이션은 일반적으로 동시에 30~60개의 요청을 처리했지만, 800건이 넘는 요청을 받았습니다. 종속 사이트 중 하나는 연결을 수락한 뒤 응답하지 않은 채 멈췄고, 애플리케이션은 요청을 종료하기 전까지 30초 동안 기다렸습니다. 연결 풀이 고갈되었고, 스레드가 누적되면서 프로세서가 스레드 관리에 시간을 소모해 시스템 전체가 중단되었습니다. 사용자들이 새로 고침 버튼을 반복해서 누르면서 부하가 더욱 커졌습니다.

붕괴를 줄이기 위한 세 가지 경로

Newman은 하나의 ‘근본 원인’에만 집중하는 것은 지나친 단순화라고 봅니다. 점화 원인을 막는 것이 유용할 수는 있지만, 화재가 확산되도록 만드는 모든 조건을 해결하지는 못하기 때문입니다. 따라서 복원력 공학은 장애가 발생할 가능성을 받아들이고, 다음 세 가지 상호 연결된 범주를 통해 그 영향을 제한할 준비를 하는 데 초점을 둡니다.

• 위험 감소: 위험 요인을 제거하거나 자원을 고갈시킬 수 있는 능력을 제한합니다. AWS의 경우 문제를 해결할 때까지 자동 DNS 관리를 일시 중단하고 구성 요소에 대한 더 나은 테스트를 추가하는 조치가 포함되었습니다. Sauron 애플리케이션에서는 시스템의 처리 능력을 초과하는 요청을 누적시켜 붕괴를 초래하는 대신, 제한된 수의 요청만 수락하고 처리 능력을 초과하는 요청은 거부하는 Load Shedding을 사용할 수 있었습니다.
• 구성 요소 강화: 중복성, 모니터링, 테스트, 실행 개선을 통해 서비스 일부의 장애를 견디는 능력을 높입니다. 이는 로드 밸런서 뒤에서 여러 서비스 인스턴스를 실행하는 것을 의미할 수 있지만, 결정은 구성 요소의 중요도와 비용을 함께 고려해야 합니다. Sauron 애플리케이션은 폐기 단계에 있었고 매출에서 차지하는 비중도 일부에 불과했으므로, 당시에는 추가 백업 인스턴스를 운영하는 것이 상업적으로 매력적이지 않았습니다.
• 결합도 감소: 한 구성 요소의 장애가 시스템의 나머지 부분으로 전파되는 것을 막습니다. 여기에는 Bulkheads, 시간 제한, 대체 경로, 가능한 경우 로컬 우선 설계를 사용하는 것이 포함됩니다. 시스템의 한 부분이 다른 부분에 의존하는 정도가 낮을수록 장애를 확산시키지 않고 격리할 수 있습니다.

기술 팀에 실질적으로 달라지는 점은 무엇인가?

복원력이 있다고 해서 시스템을 자동으로 두 개의 리전이나 두 개의 클라우드에서 운영해야 한다는 뜻은 아닙니다. Newman은 백업과 복구부터, 전체 인프라를 가동하지 않고 데이터를 복제하는 Pilot Light 아키텍처, 웜 복구, 그리고 동시에 두 개의 활성 사이트를 운영하는 방식까지 선택지가 다양하다고 설명합니다. 이러한 선택지는 중단 시간과 데이터 손실을 단계적으로 줄이지만, 비용과 복잡성을 높입니다.

또한 특히 양방향 동기화를 고려해 설계되지 않은 기존 애플리케이션에 이를 추가할 때는 사이트 간 양방향 동기화를 단순한 일로 간주해서는 안 된다고 경고합니다. 멀티클라우드에도 같은 원칙이 적용됩니다. 멀티클라우드는 한 공급자에 대한 의존도를 낮출 수 있지만, 플랫폼마다 서로 다른 기술과 운영 방식이 필요합니다. AWS와 Azure에 동일한 코드를 배포하는 것만으로 독립성이 보장되는 것도 아닙니다. 동일한 소프트웨어 결함이 두 환경 모두를 중단시킬 수 있기 때문입니다.

결론

핵심 교훈은 복원력이란 장애가 발생하지 않는 환경을 찾는 것이 아니라, 한 부분이 고장 나도 시스템의 일부가 계속 작동하도록 시스템을 설계하는 것이라는 점입니다. 따라서 위험, 용량 한계, 병목 지점, 의존 경로를 평가한 뒤 중복성, 격리, 비용 사이의 균형을 맞춰야 합니다. 멀티리전 또는 멀티클라우드 운영과 같은 결정은 모든 시스템에 적용되는 일반적인 공식이 아니라 서비스의 중요도와 관련된 공학적·상업적 선택입니다.