2014년 11월 마이크로소프트 클라우드 서비스 장애

마이크로소프트 Azure 스토리지 서비스 장애

• 국제 표준시로 2014년 11월 19일 수요일 00:50AM 부터(태평양 표준시로는 2014년 11월 18일 07:00PM) 마이크로소프트의 Azure Storage 서비스가 간헐적으로 중단되었고 일부는 11시간 동안 장애가 지속됨
• 이로 인해 많은 고객의 웹사이트가 오프라인이 되었으며 Azure Storage에 의존하는 다른 서비스도 원활하지 못했음(예, Azure Virtual Machines, Bing, Xbox Live, Visual Studio Online, Virtual Network 등 대략 20개 서비스가 영향을 받음)
• Azure Storage 서비스 장애가 미국, 유럽, 아시아의 다수 지역(regions)에서 광범위하게 발생됨. 일례로 네덜란드의 한 의료 회사에서는 4천명의 직원이 Microsoft Office 365에 로그인 할 수 없었고, 이메일과 기타 Office Online 문서에도 접근 못함
• 11월 19일 10:50AM(국제 표준시)에 Storage 서비스가 완전히 온라인으로 복구되었지만 장애의 영향을 받은 Virtual Machine을 모두 복구하는데 이틀이 더 소요됨

이 장애 이벤트의 타임라인(국제 표준시 기준)이 아래와 같다.

• 11/19 00:50AM – 여러 지역에서 Storage 서비스 중단 이벤트가 발견됨
• 11/19 00:51AM~05:50AM – 고객 대다수가 Storage 장애 및 복구 노력의 영향을 받음
• 11/19 05:51AM~11:00AM – Storage 장애의 영향을 받는 고객이 일부로 축소됨
• 11/19 10:50AM – 스토리지 장애가 완전히 해결됨. 하지만 Storage 서비스 중단의 영향이 일부 Virtual Machine에서 계속됨
• 11/19 11:00 AM – Azure 엔지니어 팀이 Virtual Machine에 잔존해 있는 장애 영향을 발견하고 복구하기 위한 플랫폼 자동화를 계속 실행시킴
• 11/21 11:00 AM – Azure 환경 전반에서 자동화된 복구가 완료됨. 고객의 후속 질문이나 지원 요청에 대응하기 위해 Azure 팀이 대기함

장애 원인

Azure Table 스토리지 성능 개선을 위한 업데이트의 일환으로 수행된 구성 변경(configuration changes)이 Blob 프론트엔드에 잠복해 있던 소프트웨어 버그를 활성화시켰고, 이 버그가 Blob 프론트엔드를 무한 루프에 빠지게 하면서 Storage 서비스 중단을 야기함

 

1) Azure의 통상적인 스토리지 전개(Storage Deployments)

• Azure 스토리지 전개는 소프트웨어 전개(코드 퍼블리싱)와 구성 전개(세팅 변경)의 두 가지 타입이 있음
• 두 가지 타입 모두 광범위하게 전개하기 전에 일부 서버에서 먼저 소규모로 테스트하여 사전에 이슈를 식별하는 여러 단계의 검증을 거치며, 또한 여러 작은 묶음(small batches)으로 나뉘어서 점진적으로 Azure 인프라구조에 전개됨
• 이런 점진적 전개 방식을 “플라이팅(flighting)”이라 부름. 마이크로소프트는 플라이팅이 진행 중일 때 건강 상태 점검(health checks)을 꼼꼼히 모니터 하며, 이런 지속적인 사용과 테스팅을 통해 성공적인 결과가 증명되면 해당 변경을 Azure 인프라구조의 추가적인 슬라이스로 점차 전개해 나감

즉, Azure의 전형적인 전개 프로세스가 아래와 같다.

①    먼저 업데이트를 내부 테스트 환경(an internal test environment)에 전개하고 여기서 테스트와 검증이 이루어진다.

②    업데이트가 테스트 환경 검증을 통과하면 생산 수준의 작업 부하(production-level workloads)를 실행시키는 생산 이전 환경(pre-production environments)에 전개한다.

③    생산 이전 환경에서 검증을 마치면 업데이트를 생산 인프라구조(the production infrastructure)의 작은 슬라이스에(a small slice)에 전개한다.

④    각 슬라이스의 검증이 완료되면 업데이트를 점차 더 큰 슬라이스로 플라이트한다. 이 때, 혹시 발생할 수도 있는 문제가 한 쌍의 지역 집합(예, 서유럽과 북유럽)에서 단 한 쪽의 지역에만 영향을 미치도록 지리적으로 분리된 슬라이스를 선택함

2) 플라이팅에서 버그 발견에 실패

• 4월 19일 장애를 일으킨 성능 업데이트(Azure 스토리지 Table 프론트엔드의 CPU footprint를 줄임으로써 성능을 개선하려는 목적의 변경)도 Azure Tables 스토리지에서 여러 주 동안 플라이팅 테스트가 수행되었으며, 모든 테스트를 통과하고 상당한 성능 향상을 보임이 증명됨에 따라 스토리지 서비스 전반에 전개하기로 결정이 내려짐
• 하지만 이 업데이트를 롤아웃 하는 중에 Blob 스토리지(비구조적 데이터를 위한 Azure의 클라우드 스토리지 서비스)에서 예상치 못한 문제가 모습을 드러냄
• 해당 업데이트를 위한 구성 변경이 Blob 프론트엔드에 적용되었을 때 무한 루프를 시작시키는 잠복 버그가 활성화되었고, 그 결과 Blob 프론트엔드가 더 이상 트래픽을 받지 못하게 되면서 Blob를 사용하는 다른 서비스들도 문제를 겪게 됨

3) 표준 전개 정책 미준수

• 생산 변경을 점진적 묶음(incremental batches)으로 전개해야 하는 Azure 팀의 표준 프로토콜이 있었지만, 해당 업데이트가 생산 인프라구조의 일부에서 이미 여러 주 동안 플라이팅 되었으므로 이를 인프라구조 전체에 활성화시키는 것이 위험이 없다고 엔지니어가 잘못된 판단을 내림
• 즉, 표준 가이드라인을 따르지 않고 업데이트를 짧은 시간 동안 생산 환경 대부분의 지역에 적용하는 휴먼 에러가 있었고, 결국 장애 영향이 전세계적으로 광범위하게 나타나게 됨

스토리지 서비스 중단 사고 발생 후 조치

• 자동 모니터링 경고(Automated monitoring alerts)가 사고 발생 몇 분내에 마이크로소프트 엔지니어링 팀에게 이를 알렸고, 엔지니어들은 해당 이슈가 시작되지 30분 이내에 구성 변경을 취소시키고 이전 상태로 되돌림
• 빠른 조치로 더 많은 Azure Blob 프론트엔드가 문제를 겪게 되는 것을 막았지만 이미 무한 루프에 들어간 Blob 프론트엔드는 어떤 구성 변경도 받아들이지 못하게 됨. 즉, 재시작(a restart) 없이는 이들을 리프레시 할 수 없게 되었고, 따라서 복구까지 시간이 길어지게 됨
• 마이크로소프트는 변경을 점진적으로 롤아웃 해야 하는 표준 플라이팅 정책을 사람이 위반하는 것을 막기 위해 이 정책이 전개 플랫폼 자체에서 강제적이 되도록 전개 시스템(tooling)을 갱신함

스토리지 장애 영향으로 인한 2차 사고 - Virtual Machine 서비스 중단

Azure Storage 서비스 중단이 해결된 후에 Azure Compute의 자동 복구 메커니즘 덕분에 거의 모든 Virtual Machine(VM)이 수동적인 개입 없이 복구됨. 하지만 일부 VM이 성공적으로 시작되지 못하거나, 또는 RDP(Remote Desktop Protocol), SSH(Secure Shell), 기타 공공 종점(public endpoints)을 통해 VM 접근이 가능하지 않아서 수동 복구가 필요하게 된 경우가 생김(이런 경우를 아래 3개 범주로 나눌 수 있음)

1. 디스크 마운트 타임아웃(Disk Mount Timeout)

• 서비스 중단으로부터 여전히 회복되고 있는 동안에 스토리지 서비스의 높은 부하 때문에 부트 프로세스에서 VM들이 디스크 마운트 타임아웃 에러를 겪음
• 대다수의 VM이 단순히 VM을 리부트 함으로써 복구됨(서비스 중단이 완전히 해결된 후 Azure 스토리지 서비스 상의 부하가 보통 수준으로 감소되었다는 전제 하에)

 

2. 셋업에서 실패한 VM(VMs Failed in Setup)

• Storage 서비스 중단 동안에 프로비전되고 생성된 Windows VM이 성공적으로 Windows Setup을 완료하지 못함
• 이런 VM들은 VM 프로비저닝(provisioning) 단계를 반복함으로써 재생성 됨(Linux VM은 영향 받지 않음)

 

3. 네트워크 프로그래밍 에러(Network Programming Errors)

• Virtual Network에 전개된 VM의 아주 일부가 자신의 공공 IP 주소 종점을 통해 연결될 수 없게 됨(해당 VM으로의 RDP와 SSH 연결성도 포함)
• 스토리지 장애 동안의 특정 조건들이 스토리지 중단 후에 네트워크를 재프로그램 하는데 있어서의 실패로 이어짐
• 마이크로소프트 측이 리부트 필요 없이 영향 받은 VM으로의 서비스를 복구하는 완화 방안(a mitigation)을 몇 시간 내로 전개하여 해결함

 

 

아래는 Azure 최고기술책임자(Chief Technology Officer: CTO)인 Mark Russinovich가 11월 18일 발생한 Azure 스토리지 장애에 대해 설명한 12분51초짜리 영상이다.

[2014년 12월 17일자 Channel 9 영상 ]