AWS 운영 중단으로 다시 한번 필요성이 입증된 풀-스택 옵저버빌리티

2025년 10월 19일과 20일, Amazon Web Services(AWS) 노스 버지니아(us-east-1) 리전에서 발생한 장애로 AWS에 의존하는 웹사이트와 온라인 서비스들이 마비되는 사태가 발생했습니다. 10월 19일 오후 11시 49분(PDT 기준)에 시작해 15시간 이상 지속된 이 인시던트는 140여 개 AWS 서비스에 영향을 미쳤습니다. 

이 블로그에서는 무슨 일이 일어났고, 어떤 영향을 미쳤는지, 그리고 이번 사태에서 어떤 교훈을 얻을 수 있는지 살펴보겠습니다. 

도미노 효과

us-east-1 리전의 DynamoDB API 엔드포인트에서 발생한 단일 DNS 장애는 수많은 서비스로 확산되었습니다. 다음은 이번 사태를 자세히 설명하는 AWS 인시던트 보고서입니다.

많은 내부 AWS 서비스들이 DynamoDB에 의존해 중요한 데이터를 저장하기 때문에, 초기 DNS 장애로 인해 2차 중단이 연이어 발생했습니다.

1. EC2 런치 문제: 10월 20일 오전 2시 24분(PDT), DNS 문제는 해결되었지만, 인스턴스 런칭을 담당하는 EC2의 내부 서브시스템에서 새로운 문제가 발생했습니다. DynamoDB에 의존하는 이 시스템이 새 인스턴스를 시작하려고 할 때, "용량 부족" 오류가 발생한 것입니다.
2. 네트워크 연결 문제: EC2 문제를 처리하는 동안 AWS는 네트워크 부하 분산 장치의 상태 검사가 실패하고 있다는 사실을 발견했습니다. 이로 인해 DynamoDB, SQS, Amazon Connect를 비롯한 여러 서비스로 네트워크 연결 문제가 확산되었습니다.
3. 완화 노력 및 백로그: 파급되는 오류를 억제하기 위해 AWS는 새로운 EC2 인스턴스 시작, Lambda 이벤트 소스 매핑을 통한 SQS 폴링, 비동기 Lambda 호출 같은 특정 작업을 일시적으로 제한했습니다. 이는 핵심 서비스를 안정화하는 데 도움이 되었지만, AWS Config, Redshift 및 Amazon Connect 같은 시스템에서 백로그가 생성되어 서비스 복구 후에도 완전한 처리까지 몇 시간이 걸렸습니다.

이러한 “도미노 효과”는 AWS 생태계에서 핵심적인 상호 의존성이 단일 장애의 영향을 얼마나 증폭시킬 수 있는지를 보여주었습니다. AWS Health Dashboard 및 Service Report에서 보다 자세한 내용을 확인하실 수 있습니다.

비즈니스에 미친 영향과 옵저버빌리티가 중요한 이유 

이번 중단 인시던트는 Alexa 및 Amazon.com 같은 AWS의 자체 서비스와 Snapchat, PayPal의 Venmo, Reddit 같은 주요 클라이언트는 물론, Docker와 Zoom을 포함한 중요한 유틸리티 툴에도 영향을 미쳤습니다. 클라우드 플랫폼과 서비스에 크게 의존하는 AWS 고객과 조직의 경우, 여러 AWS 서비스에서 여러 시간 동안 중단이 발생하면 비즈니스에 상당한 피해가 갈 수 있습니다.

2025 옵저버빌리티 전망 보고서에 따르면, 애플리케이션, 플랫폼 또는 글로벌 SaaS의 중단으로 인해 시간당 평균 220만 달러 또는 분당 약 33,333달러의 비용이 발생할 수 있습니다. 운영 중단으로 인한 재정적 영향이 얼마나 막대할 수 있는지를 보여주는 대목입니다. 구체적인 수치를 계산하기엔 아직 이른감이 있지만, 15시간 이상 지속된 이번 중단 사태로 인해 막대한 손실이 발생했다는 사실 만큼은 분명합니다.

또한 풀-스택 옵저버빌리티를 활용하는 조직은 복원력이 향상되고 위험이 완화되어 운영 중단 비용을 시간당 100만 달러로 크게 줄일 수 있는 것으로 나타났습니다.

비즈니스에 미치는 영향은 금전적인 것에서 그치지 않습니다. AWS 운영 중단, 특히 제한이 가해진 작업은 엔지니어링 팀들에게 상당한 부담을 안겨주었습니다. 당직 엔지니어, 데브옵스 직원 및 사이트 안정성 엔지니어들은 근무 시간의 약 33%를 발생한 문제와 인시던트 해결에 할당해 서비스 복구에 나섰습니다.

이 부분에서 옵저버빌리티가 패러다임을 바꿀 수 있습니다.

• 보다 신속한 감지: 뉴렐릭 같은 풀-스택 옵저버빌리티 툴을 구현하는 조직은 핵심적인 운영 중단을 더 빠르게 감지할 수 있습니다. 풀-스택 옵저버빌리티 솔루션이 있는 경우 평균 감지 시간(MTTD)은 보통 28분이며 없는 경우는 35분입니다.
• AI 기반 대응 및 자동화된 근본 원인 분석: 여러 곳에 분산되어 있는 현대 시스템들의 복잡성은 운영 담당자가 쉽게 관리할 수 있는 수준이 아니기 때문에 인공 지능(AI)이 반드시 필요합니다. 이는 경영진과 IT 리더들이 AI로 지원되는 문제 해결(38%)과 자동화된 근본 원인 분석(33%)을 핵심 역량으로 꼽았다는 사실에서도 드러납니다. 이러한 AI 기반 접근 방식은 인시던트 해결을 가속화하고 AWS 장애의 파급효과를 효과적으로 제한하는 데 필수적입니다.
• 종단 간 추적: 분산 추적은 운영 중단을 방지하고 해결하는 데 중요한 도구로, 트랜잭션 요청이 상호 연결된 백엔드 서비스 간에 이동할 때 추적할 수 있는 방법을 제공합니다. 포괄적인 가시성은 매우 중요합니다. 데이터베이스 장애 같은 백엔드 서비스에서 문제가 발생할 경우, 분산 추적은 느린 페이지 로드나 오류 같은 문제를 통해 고객 경험을 저하시키는 서비스를 정확하게 파악할 수 있도록 해줍니다. 또한 백엔드 엔지니어는 인프라 문제가 어떻게 고객에게 직접적으로 영향을 미치는지 명확하게 파악할 수 있습니다.
• 알림 상호 연관: 뉴렐릭과 같은 옵저버빌리티 툴은 관련된 여러 알림을 지능적으로 그룹화하여 인시던트 관리를 간소화해줍니다. 이를 통해 특정 인시던트 시나리오와 관련된 상관 관계 패턴을 찾아내어 불필요한 노이즈를 줄이고 근본 원인을 더 빨리 식별할 수 있습니다. 이러한 역량은 여러 구성 요소에서 발생한 복잡한 장애를 해결하는 데 필수적입니다.

복구 검증

옵저버빌리티 툴은 평균 감지 시간(MTTD)에 도움이 되지만 평균 해결시간(MTTR)에도 중요합니다. MTTR은 모든 것이 정상으로 돌아왔는지를 확인하는 능동적 모니터링이라고 할 수 있습니다.

AWS Health Dashboards에 종료되지 않은 지원 티켓이 "해결됨"으로 표시될 수 있지만 서비스는 여전히 백로그와 경합하고 있습니다. 이러한 문제는 보통 SQS 대기열, Lambda 함수를 트리거하는 백그라운드 프로세스 또는 기타 서드파티 종속성 같은 요소에서 비롯됩니다. 따라서 옵저버빌리티는 서비스 품질이 실제로 정상으로 돌아왔음을 확인하는 데 필요한 경험적 증거를 제공합니다.

• 업타임 및 안정성 확인: 옵저버빌리티로 애플리케이션이 시스템 업타임과 안정성이라는 핵심 비즈니스 목표를 충족하고 있음을 확인할 수 있습니다.
• 신세틱 모니터링: 신세틱 모니터링은 애플리케이션 엔드포인트가 복구 후 올바르게 응답하는지 지속적인 검사를 실행해 확인할 수 있도록 합니다.
• 성공적인 해결 측정: DORA 메트릭 및 황금 신호(레이턴시, 사용률, 오류 및 포화도) 모니터링 같은 옵저버빌리티 사용 사례는 복구 작업 및 절차 변경 후 MTTD 및 MTTR의 개선 여부를 확인하는 데 도움이 됩니다.
• 변경 사항 추적: 롤백이나 구성 업데이트, AI로 지원되는 문제 해결 작업 같은 고급 자동화 기능을 지원하는 데 중요한 역할을 합니다.

AWS가 중단되었습니다... 이 경우 무엇을 할 수 있을까요?

공동 책임 모델 하에서, AWS는 AWS 서비스를 사용하는 고객을 위해 서비스 기능을 해결하고 복원할 책임이 있습니다. 하지만 고객의 입장에서 선제적으로 무엇을 할 수 있을까요? 

해야 할 일은 단순히 AWS Health Dashboards를 모니터링하는 것 이상으로 확장됩니다. 서비스 중단을 해결하는 경우, 재해 복구(DR) 전략, 멀티 리전 설정 또는 정교한 리전 장애 조치 시스템을 갖추는 것만으로는 충분하지 않습니다.

가장 중요한 첫 번째 단계는 인시던트 발생 시 실제로 영향을 받는 서비스에 대한 명확한 가시성을 확보하는 것입니다. 복구 계획을 효과적으로 실행하기 전에 이러한 기본적인 사항을 인지하고 있어야 합니다. 현대 클라우드 환경에서 아키텍처는 레고 블록을 조립하듯 AWS 서비스들을 서로 연결해 구축됩니다. 아키텍처 전체에서 AWS 서비스가 반복적으로 활용되는 마이크로서비스와 분산 시스템의 경우 복잡성은 더욱 심화되어, 운영 중단이 발생 시 풀기 어려운 종속성의 실타래가 생성됩니다. 실시간 가시성이 없다면 근본 원인과 영향의 전체 범위를 파악하는 것이 어려워집니다.

옵저버빌리티 툴은 실시간 가시성을 확보하는 데 중요한 역할을 합니다.

• 스택에서 영향을 받는 서비스 식별: 중단된 AWS 서비스는 전체 시스템이나 플랫폼에 영향을 미쳤을 수도 있고 작은 구성 요소에 영향을 미쳤을 수도 있습니다. 옵저버빌리티는 어떤 서비스가 영향을 받았는지 파악하는 데 필요한 명확성을 제공하여 문제를 효율적으로 해결할 수 있도록 합니다.
• 황금 신호 모니터링: 장애 조치 환경에서 황금 신호를 모니터링하여 안정성과 성능을 보장함으로써 재해 복구(DR) 전략이 의도된 대로 작동하고 있음을 검증할 수 있습니다.
• 매출 손실 수치화: 옵저버빌리티는 비즈니스 결과로 확장됩니다. 뉴렐릭 패스포인트(Pathpoint) 애플리케이션은 고객 여정을 시각화하고 비즈니스 지표에 미치는 재정적 영향을 수치화하여 다운타임으로 인한 잠재적 분당 매출 손실을 보여줍니다.
• 알림 및 대시보드: 통합된 알림 뷰를 활용하면 AWS 장애로 인해 영향을 받은 모든 서비스를 신속하게 찾아내고, 상황을 포괄적으로 이해할 수 있도록 관련된 모든 팀에 즉시 정보를 제공하며, 중앙의 대시보드에서 애플리케이션 또는 플랫폼의 상태와 메트릭을 빠르게 확인할 수 있습니다.

뉴렐릭을 사용한 장애 감지

뉴렐릭 역시 자체 워크로드에 AWS를 사용합니다. 대부분의 플랫폼이 us-east-1 이외의 리전에서 실행되기 때문에 10월 20일에 발생한 AWS 중단에도 핵심적인 기능들은 크게 영향을 받지 않았습니다. 데이터 수집, 스토리지, 쿼리, 알림 및 뉴렐릭 UI가 모두 제대로 작동했다는 의미입니다.

그러나 일부 워크로드가 영향을 받았습니다. 여기에는 신세틱, AWS 클라우드 모니터링, 무한 추적, 모바일 기호화 및 신제품 소비 관련 이벤트(예: NrConsumption 및 NRMTDConsumption)가 포함되었습니다. 신세틱, 클라우드 모니터링 및 무한 추적은 여러 리전에서 실행되도록 설계되었으므로 부분적으로만 영향을 받았지만, 모바일 기호화와 소비 이벤트는 us-east-1 리전에 주로 실행되고 있었습니다.

뉴렐릭 플랫폼을 사용해 이러한 서비스들을 적극 모니터링하기 때문에, 뉴렐릭은 문제가 시작되자마자 감지할 수 있었습니다. 11시 57분(PST)에 us-east-1에서 DynamoDB를 사용하는 서비스에 대한 알림이 트리거되면서 수신 오류를 즉시 식별할 수 있었습니다.

알림을 받자마자, 트리거된 인시던트를 적극적으로 모니터링하며 운영 중단의 영향을 평가했습니다. 뉴렐릭 플랫폼에는 미미한 영향을 받았지만 뉴렐릭은 고객들이 관련 문제를 해결할 수 있도록 감시 태세를 유지했습니다.

결론

AWS가 중단된 상황에서는 확신 있게 수정 사항을 배포하자고 할 만큼 정보가 없습니다. 재해 복구 전략을 재평가하거나 아키텍처 자체를 평가할 때도 아닙니다. 이미 멀티 리전 설정을 따르고 있는 경우라면 더 그러합니다.

대신, 텔레메트리 데이터를 이해하고 영향을 받는 서비스를 신속하게 식별하기 위해 뉴렐릭과 같은 옵저버빌리티 툴을 활용하는 데 중점을 두어야 합니다. 이러한 툴들은 프런트엔드 애플리케이션과 APM에서 데이터베이스 및 인프라에 이르기까지, 아키텍처 전반에서 모든 스택에 대한 가시성을 지원합니다. 여기에는 VM, 컨테이너, 쿠버네티스 클러스터 뿐만 아니라, AWS 환경 및 클라우드 제공업체의 상태에 대한 인사이트도 포함됩니다.

이와 같은 운영 중단은 비즈니스에 심각한 영향을 줄 수 있습니다. 엔지니어로서, 최우선 과제는 장애가 발생한 부분, 영향을 받은 부분, 그리고 그 수준을 파악하는 것입니다. 중요한 순간에 포괄적인 옵저버빌리티 전략을 수립하는 것은 문제를 지속적으로 인지하고 영향을 최소화하는 데 필수적입니다.