아마존 클라우드 AWS 장애 발생 분석

Study/Welcom to Cloud 2011.05.13 17:40
2011년에 들어오면서 클라우드가 대세로 굳어지면서 클라우드를 도입시 위험성에 대해 별 말들이 없어졌다.. 하지만 이전에는 클라우드를 도입하면 재앙이 온다며 반대하던 세력이 있었는데 그 핵심은 인프라 관리의 자동화로 인해 작은 장애가 전체 시시템에 영향을 미쳐 시스템이 붕괴할 가능성이 오히려 높아 진다고 주장했었는데... 이번 아마존 AWS 장애로 거의 그런일이 현실화 될 뻔하였으나 결론적으로는 전체 시스템이 붕괴하지 않았고 3일만에 모두 복구하였다. 그것도 클라우드에서 자동으로 된다는 Auto-Recovery를 통해(사실 수동으로 작업을 많이 하긴 했지만 실제 물리적인 문제를 해결하고서는 거의 자동으로 복구가 진행됨) 생각보다 빠르게 복구를 한 것으로 생각된다.  


이 내용은 위의 링크에 있는 아마존의 공시 장애 보고서를 통해 자세히 알 수 있으나 사실 전문가가 아니고는 잘이해하기 힘들 것같아 일부 내용을 번역해 보았다. (네트워크와 서버, 스위치등의 장비를 잘알아야만 이해할 수 있다.. 게다가 클라우드 IaaS 까지)
이 글에서 기존에 EC2나 S3같이 많이 알려져서 대안의 Open Source 솔루션들이 나온 시스템들과 달리 EBS 시스템은 거의 알려지지 않았는데(사실 다들 그냥 iSCSI 들을 어떻게 묶었겠지 했다) 이 문서에 장애를 설명하기 위해 어쩔수 없이 그 구조를 대충 알려준 것 같다.

Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region

Now that we have fully restored functionality to all affected services, we would like to share more details with our customers about the events that occurred with the Amazon Elastic Compute Cloud (“EC2”) last week, our efforts to restore the services, and what we are doing to prevent this sort of issue from happening again. We are very aware that many of our customers were significantly impacted by this event, and as with any significant service issue, our intention is to share the details of what happened and how we will improve the service for our customers.

The issues affecting EC2 customers last week primarily involved a subset of the Amazon Elastic Block Store (“EBS”) volumes in a single Availability Zone within the US East Region that became unable to service read and write operations. In this document, we will refer to these as “stuck” volumes. This caused instances trying to use these affected volumes to also get “stuck” when they attempted to read or write to them. In order to restore these volumes and stabilize the EBS cluster in that Availability Zone, we disabled all control APIs (e.g. Create Volume, Attach Volume, Detach Volume, and Create Snapshot) for EBS in the affected Availability Zone for much of the duration of the event. For two periods during the first day of the issue, the degraded EBS cluster affected the EBS APIs and caused high error rates and latencies for EBS calls to these APIs across the entire US East Region. As with any complicated operational issue, this one was caused by several root causes interacting with one another and therefore gives us many opportunities to protect the service against any similar event reoccurring.

지난 US East Region 하나의 Availability Zone EBS 볼륨들 일부를 주로 사용하는 EC2 고객에게 발생한 문제는 읽기 쓰기 작업을 수행하는 서비스를 제공 없었다. 문서에서 우리는 문제가 볼륨을 "stuck" 볼륨이라고 한다. 또한 이들 “stuck” 볼륨을 읽고 쓰기기를 시도한 EC2 인스턴스들도 “stuck되는 원인이 되었다. 문제가 Availability Zone에서 볼륨을 복원하고 EBS 클러스터를 안정화하기 위해, 우리는 문제가 지속되는 동안 문제가 있는 Availability Zone EBS 위해 모든 컨트롤 API (: 볼륨 만들기, 볼륨 붙이기, 볼륨 분리 스냅샷 만들기) 비활성화 했었다. 문제가 발생한 부터 3일간, 성능이 저하된 EBS 클러스터는 전체US East Region API 영향을 주었고 EBS 호출을 위한 API들은 높은 에러와 지연의 원인이 되었다. 어떤 복잡 운영 문제 때문에, 문제는 서로 상호작용하는 여러 초기 문제들에 원인이 되었고 따라서 우리에게 서비스를 보호하기 위한 어떠한 비슷한 문제가 재발하는 것을 막는 많은 기회를 주었다. 

Overview of EBS System

It is helpful to understand the EBS architecture so that we can better explain the event. EBS is a distributed, replicated block data store that is optimized for consistency and low latency read and write access from EC2 instances. There are two main components of the EBS service: (i) a set of EBS clusters (each of which runs entirely inside of an Availability Zone) that store user data and serve requests to EC2 instances; and (ii) a set of control plane services that are used to coordinate user requests and propagate them to the EBS clusters running in each of the Availability Zones in the Region.

우리가 이번 장애를 설명할 있도록 EBS 아키텍처를 이해 하는 것이 필요하다. EBS EC2 인스턴스에서 낮은 지연의 읽기와 쓰기 액세스 일관성에 최적화 분산, 복제 블록 데이터 저장소입니다. EBS 서비스의 가지 주요 구성 요소는: (i) ( Availability Zone 내부에서만 전적으로 실행되는) EBS 클러스터의 ; 그리고 (ii) Rigion 안의 Availability Zone에서 운영중인 EBS 클러스터에 사용자의 요청들을 조직하고 요청들을 전달하기 위해 사용되는 control plane 서비스들의

An EBS cluster is comprised of a set of EBS nodes. These nodes store replicas of EBS volume data and serve read and write requests to EC2 instances. EBS volume data is replicated to multiple EBS nodes for durability and availability. Each EBS node employs a peer-to-peer based, fast failover strategy that aggressively provisions new replicas if one of the copies ever gets out of sync or becomes unavailable. The nodes in an EBS cluster are connected to each other via two networks. The primary network is a high bandwidth network used in normal operation for all necessary communication with other EBS nodes, with EC2 instances, and with the EBS control plane services. The secondary network, the replication network, is a lower capacity network used as a back-up network to allow EBS nodes to reliably communicate with other nodes in the EBS cluster and provide overflow capacity for data replication. This network is not designed to handle all traffic from the primary network but rather provide highly-reliable connectivity between EBS nodes inside of an EBS cluster.

EBS 클러스터는 EBS 노드 집합으로 구성된다. 이러한 노드들은 EBS 볼륨 데이터의 복제본을 저장하고 읽기와 쓰기 요청들을 EC2 인스턴스에 제공한다. EBS 볼륨 데이터는 내구성 가용성을 위해 여러 EBS 노드들에 복제 된다. EBS 노드는 피어--피어 기반으로, 만약 복사본들 하나의 씽크가 깨지거나 유효하지 않게 된다면 복제본을 적극적으로 생성하는 빠른 장애 조치 전략을 채용하고 있다. EBS 클러스터의 노드들은 개의 네트워크를 통해 서로 연결 된다. Primary 네트워크는 다른 EBS 노드와, EC2 인스턴스 EBS control plance 서비스들을 위해 사용하는 모든 필수적인 통신을 위한 일반적인 운영에서 사용 하는 높은 대역폭 네트워크이다. 번째 네트워크는, 복제(replication) 네트워크, EBS 노드들이 안정적으로 EBS 클러스터의 다른 노드와 통신하고 데이터 복제에 오버플로 용량 제공하기 위한 보조 네트워크로 사용되는 낮은 용량의 네트워크이다. 네트워크는 Primary 네트워크에서 오는 모든 트래픽을 처리 있도록 설계되지 않았지만 오히려 EBS 클러스터 내부에 EBS 노드 간의 매우 안정적인 연결을 제공 하도록 설계되었다.

When a node loses connectivity to a node to which it is replicating data to, it assumes the other node failed. To preserve durability, it must find a new node to which it can replicate its data (this is called re-mirroring). As part of the re-mirroring process, the EBS node searches its EBS cluster for another node with enough available server space, establishes connectivity with the server, and propagates the volume data. In a normally functioning cluster, finding a location for the new replica occurs in milliseconds. While data is being re-mirrored, all nodes that have copies of the data hold onto the data until they can confirm that another node has taken ownership of their portion. This provides an additional level of protection against customer data loss. Also, when data on a customer’s volume is being re-mirrored, access to that data is blocked until the system has identified a new primary (or writable) replica. This is required for consistency of EBS volume data under all potential failure modes. From the perspective of an EC2 instance trying to do I/O on a volume while this is happening, the volume will appear “stuck”.

노드가 데이터를 복제하는 노드에 연결 잃으면 실패 노드로 가정한다. 내구성 유지하기 위해, 그것은 하나의 노드를 찾아 그것의 데이터를 복제(re-mirroring) 있다. Re-mirroring 프로세스의 일부로 EBS 노드는 EBS 클러스터에서 사용 가능한 서버 공간이 충분 다른 노드를 검색하고, 서버와의 연결을 설정, 볼륨 데이터를 전달한다. 정상적으로 작동하는 클러스터는, 복제본의 위치를 찾는 작업이 밀리초 내에 일어난다. 데이터가 re-mirrored 되는 동안, 데이터의 복제본들을 가지고 있는 모든 노드들은 다른 노드가 그의 담당 부분의 소유권을 가지는 것을 허가할 있을 때까지 데이터를 잡고 있다. 이는 고객 데이터 손실을 보호하는 추가적인 수준을 제공한다. 또한, 고객의 볼륨의 데이터는 re-mirrored 되고, 시스템이 (또는 쓰기 가능한) 복제를 식별할 때까지 블락된 데이타에 접근한다. 이와 같은 일이 발생하는 동안 EC2 인스턴스 관점에서 볼륨에 I/O 시도하면, 볼륨은 “stuck” 이라고 나타낼 것이다.

In addition to the EBS clusters, there is a set of control plane services that accepts user requests and propagates them to the appropriate EBS cluster. There is one set of EBS control plane services per EC2 Region, but the control plane itself is highly distributed across the Availability Zones to provide availability and fault tolerance. These control plane services also act as the authority to the EBS clusters when they elect primary replicas for each volume in the cluster (for consistency, there must only be a single primary replica for each volume at any time). While there are a few different services that comprise the control plane, we will refer to them collectively as the “EBS control plane” in this document.

EBS 클러스터뿐만 아니라, EBS시스템에는 사용자 요청을 수락하고 요청을 적절 EBS 클러스터에 전달하는 control plane서비스들의 셋도 있다. EC2 지역(Region) 마다 EBS control plane 서비스들이 셋이 있다, 그러나 control plane 가용성 내결함성을 제공 하기 위해 Availability Zone들에 매우 분산 되어있다. control plane서비스들은 또한 클러스터에 볼륨을 위한 복제 본들을 선정할 EBS 클러스터들에서 이를 선택하는 권한을 가지고 있다. (일관성을 위해, 언제든지 볼륨을 위한 하나의 복제 본이 단지 하나만 존재한다.) 동시에 여기에서는 control plane 구성하는 가지 다른 서비스들도 있다, 우리는 문서에서 이를 언급할 그것은 “EBS control plane”이다.

Primary Outage

At 12:47 AM PDT on April 21st, a network change was performed as part of our normal AWS scaling activities in a single Availability Zone in the US East Region. The configuration change was to upgrade the capacity of the primary network. During the change, one of the standard steps is to shift traffic off of one of the redundant routers in the primary EBS network to allow the upgrade to happen. The traffic shift was executed incorrectly and rather than routing the traffic to the other router on the primary network, the traffic was routed onto the lower capacity redundant EBS network. For a portion of the EBS cluster in the affected Availability Zone, this meant that they did not have a functioning primary or secondary network because traffic was purposely shifted away from the primary network and the secondary network couldn’t handle the traffic level it was receiving. As a result, many EBS nodes in the affected Availability Zone were completely isolated from other EBS nodes in its cluster. Unlike a normal network interruption, this change disconnected both the primary and secondary network simultaneously, leaving the affected nodes completely isolated from one another.

오전 12 47 PDT 4 21 일에 US East Region 하나의 Availability Zone 일반적인 AWS 증설 작업들 일부가 수행 되었다. 구성 변경은 네트워크의 용량을 업그레이드하기 위한 것이다. 변경 하는 동안, 표준 단계 하나는 업그레이드를 적용할 있도록 EBS 네트워크의 이중화 라우터 하나의 트래픽 차단(traffic off) 변경하기 위한 것이다. 트래픽 변경은 잘못 실행되었고 네트워크의 다른 라우터에 트래픽을 라우팅하지 않고, 오히려 트래픽은 낮은 용량의 이중화 EBS 네트워크에 라우팅 되었다. 문제가 발생한 Availability Zone EBS 클러스터 일부에서, 이것은 또는 네트워크로 작동하는 것이 없는 것을 의미한다. 왜냐하면 트래픽은 의도적으로 네트워크와 분리하여 변경되었고 네트워크는 그것이 받은 트래픽 수준을 다룰 없기 때문이다. 결과적으로, 문제가 발생한 Availability Zone 많은 EBS 노드들은 클러스터에서 다른 EBS 노드들과 완전히 격리되었다. 정상적인 네트워크 중단과 달리, 변경은 동시에 주와 네트워크 사이를 단절했고, 서로가 완전히 고립되는 문제가 발생하는 노드들을 남겼다.

 When this network connectivity issue occurred, a large number of EBS nodes in a single EBS cluster lost connection to their replicas. When the incorrect traffic shift was rolled back and network connectivity was restored, these nodes rapidly began searching the EBS cluster for available server space where they could re-mirror data. Once again, in a normally functioning cluster, this occurs in milliseconds. In this case, because the issue affected such a large number of volumes concurrently, the free capacity of the EBS cluster was quickly exhausted, leaving many of the nodes “stuck” in a loop, continuously searching the cluster for free space. This quickly led to a “re-mirroring storm,” where a large number of volumes were effectively “stuck” while the nodes searched the cluster for the storage space it needed for its new replica. At this point, about 13% of the volumes in the affected Availability Zone were in this “stuck” state.

네트워크 연결에 문제가 발생 했을 , 하나의 EBS 클러스터에서 많은 EBS 노드들이 그들의 복제 본들과의 연결이 끊어졌다. 잘못 트래픽 변경이 롤백 되었고 네트워크 연결이 복원 되었을 , 이러한 노드들은 그들이 데이터를 re-mirror 있는 사용 가능한 서버 공간을 위해 EBS 클러스터를 빠르게 검색하기 시작 했다. 다시 한번 말하지만, 정상적으로 작동하는 클러스터는, 이와 같은 작업이 밀리초만에 일어난다. 경우, 문제는 동시에 많은 수의 볼륨에 영향을 미쳤기 때문에, EBS 클러스터의 용량은 빨리 소모되었고, 반복해서 많은 노드들이 “stuck” 상태 남아있고, 계속해서 공간을 위해 클러스터를 검색한다. 이것은 빠르게 "re-mirroring storm" 초례 했다. 노드들은 그것의 복제 본을 위해 요구되는 스토리지 공간이 클러스터에서 검색되는 동안, 클러스터에는 많은 수의 볼륨들이 거의 “stuck” 상태였다. 시점에서 문제가 발생한 Availability Zone 볼륨들 13% "stuck" 상태였다.

After the initial sequence of events described above, the degraded EBS cluster had an immediate impact on the EBS control plane. When the EBS cluster in the affected Availability Zone entered the re-mirroring storm and exhausted its available capacity, the cluster became unable to service “create volume” API requests. Because the EBS control plane (and the create volume API in particular) was configured with a long time-out period, these slow API calls began to back up and resulted in thread starvation in the EBS control plane. The EBS control plane has a regional pool of available threads it can use to service requests. When these threads were completely filled up by the large number of queued requests, the EBS control plane had no ability to service API requests and began to fail API requests for other Availability Zones in that Region as well. At 2:40 AM PDT on April 21st, the team deployed a change that disabled all new Create Volume requests in the affected Availability Zone, and by 2:50 AM PDT, latencies and error rates for all other EBS related APIs recovered.

위에서 설명한 이벤트의 초기 시퀀스 성능이 저하 EBS 클러스터는 EBS control plane 즉각적인 영향 주었다. 문제가 발생한 Availability Zone EBS 클러스터가 re-mirroring storm상태가 되고 그것의 사용 가능한 용량을 모두 소진했을 , 클러스터는 "볼륨 만들기" API 요청들을 서비스 없게 되었다. EBS control plane(그리고 특히 볼륨 만들기 API) 오랜 time-out 기간으로 설정되고, 이러한 느린 API 호출들은 백업을 시작하였고 EBS control plane에서 스레드 부족을 초래하였다.  EBS control plane 서비스 요청에 사용할 있는 사용 가능한 스레드들의 지역적인 풀을 가지고 있다. 이러한 스레드들은 많은 대기 중인 요청들에 의해 완전히 채워졌고, EBS control plane API 요청을 처리 하는 능력이 없어졌을 뿐만 아니라 지역 (Region)안의 다른 Availability Zone들의 API 요청들도 실패하기 시작했었다. 오전 2 40 PDT 4 21 , 변경을 배치한 팀은 문제가 발생한 Availability Zone 모든 볼륨 생성 요청을 비활성 했고, 그리고 나서 오전 2 50 PDT, API들과 연관된 모든 다른 EBS 위한 지연들과 에러율들을 복구 했다.

 Two factors caused the situation in this EBS cluster to degrade further during the early part of the event. First, the nodes failing to find new nodes did not back off aggressively enough when they could not find space, but instead, continued to search repeatedly. There was also a race condition in the code on the EBS nodes that, with a very low probability, caused them to fail when they were concurrently closing a large number of requests for replication. In a normally operating EBS cluster, this issue would result in very few, if any, node crashes; however, during this re-mirroring storm, the volume of connection attempts was extremely high, so it began triggering this issue more frequently. Nodes began to fail as a result of the bug, resulting in more volumes left needing to re-mirror. This created more “stuck” volumes and added more requests to the re-mirroring storm.

가지 요인은 문제발생 초기 동안 EBS 클러스터가 추가적으로 성능이 저하되게 하는 상황을 유발했다. 첫째, 노드를 찾기 실패한 노드들은 그들이 공간을 찾지 못했을 매우 적극적으로 물러나지 않았고, 대신 반복적으로 검색을 계속 했다. 또한 EBS 노드들의 경쟁 조건 코드가 있고, 아주 낮은 확률으로, 많은 수의 복제를 위한 요청들을 동시에 닫을 실패할 있는 원인이 된다. 정상적으로 운영되는 EBS 클러스터에서, 문제는 매우 작은 결과를 초래한다, 만약 어떤, 노드가 충돌한다면; 그러나, re-mirroring storm 동안, 연결을 시도하는 볼륨들이 매우 많아졌고, 그래서 그것은 자주 문제를 발생시켰다. 노드들은 버그의 결과로 실패 하기 시작 했고, 결과적으로 많은 볼륨들이 re-mirror 필요한 상태로 담아있게 되었다. 이는 만든 "stuck" 볼륨들을 만들었고 re-mirroring storm 많은 요청이 추가되었다.

By 5:30 AM PDT, error rates and latencies again increased for EBS API calls across the Region. When data for a volume needs to be re-mirrored, a negotiation must take place between the EC2 instance, the EBS nodes with the volume data, and the EBS control plane (which acts as an authority in this process) so that only one copy of the data is designated as the primary replica and recognized by the EC2 instance as the place where all accesses should be sent. This provides strong consistency of EBS volumes. As more EBS nodes continued to fail because of the race condition described above, the volume of such negotiations with the EBS control plane increased. Because data was not being successfully re-mirrored, the number of these calls increased as the system retried and new requests came in. The load caused a brown out of the EBS control plane and again affected EBS APIs across the Region. At 8:20 AM PDT, the team began disabling all communication between the degraded EBS cluster in the affected Availability Zone and the EBS control plane. While this prevented all EBS API access in the affected Availability Zone (we will discuss recovery of this in the next section), other latencies and error rates returned to normal for EBS APIs for the rest of the Region.

오전 5 30 PDT, 지역(Region) 걸처 EBS API 호출에 대한 오류율 지연들은 다시 증가했다. 볼륨을 위한 데이터가 re-mirrored 경우, EC2 인스턴스와 볼륨 데이터를 가진EBS 노드들 간에 협상 해야만 한다, 그리고 EBS control plane ( 프로세스를 처리할 권한을 가진) 데이터의 단지 하나의 복사를 복제 본으로 지정하고 모든 접근들을 보낼 장소로 EC2 인스터스가 인지한다. 이는 EBS 볼륨의 강한 일관성을 제공한다. 많은 EBS 노드들은 위에서 설명한 경쟁 조건에 따라 계속 실패하기 때문에, EBS control plane 그런 협상을 하는 볼륨은 증가했다. 데이터가 성공적으로 re-mirrored 되지 않았기 때문에, 시스템은 재시도되었고 요청들은 들어오므로 이러한 많은 호출들이 증가했다. 부하는 EBS control plane 성능 저하와 지역(Region) 걸쳐 다시 문제가 EBS API들이 원인이 되었다. 오전 8 20 PDT, 팀은 문제가 발생한 Availability Zone 성능이 저하된 EBS 클러스터와 EBS control plane사이의 모든 통신을 불능화하기 시작했다. 문제가 발생한 Availability Zone 모든 EBS API 접근을 막은 동안(우리는 다음 섹션에서 복구 작업을 설명한다), 지역(Region) 나머지를 위한 EBS API들의 지연들과 에러율들은 정상적으로 돌아왔다.

A large majority of the volumes in the degraded EBS cluster were still functioning properly and the focus was to recover the cluster without affecting more volumes. At 11:30AM PDT, the team developed a way to prevent EBS servers in the degraded EBS cluster from futilely contacting other servers (who didn’t have free space at this point anyway) without affecting the other essential communication between nodes in the cluster. After this change was made, the cluster stopped degrading further and additional volumes were no longer at risk of becoming “stuck”. Before this change was deployed, the failed servers resulting from the race condition resulted in an additional 5% of the volumes in the affected Availability Zone becoming “stuck”. However, volumes were also slowly re-mirroring as some capacity was made available which allowed existing “stuck” volumes to become ”unstuck”. The net result was that when this change was deployed, the total “stuck” volumes in the affected Availability Zone was 13%.

성능이 저하된 EBS 클러스터의 볼륨 대다수는 여전히 제대로 작동했고 추가적으로 볼륨들에 영향을 주지 않고 클러스터를 복구하는데 초점을 두었다. 오전 11 30 PDT, 팀은 성능이 저하 클러스터에서 클러스터 내의 노드들 간의 필수적인 통신에 영향을 주지 않으면서 무의미하게 다른 서버로의 연결(이미 공간이 없는 서버) 막기 위한 방법을 개발했다. 이를 적용한 , 클러스터는 추가적인 성능 저하를 멈추고 추가 볼륨들은 "stuck" 되는 위험이 이상 발생하지 않았다. 변경을  배포하기 전에, 경쟁 상태에 의해 문제가 서버들의 결과로 문제가 발생한 Availability Zone에서 추가적으로 5% 볼륨이  "stuck" 되었었다. 변경 배포 최종 결과는 문제가 발생한 Availability Zone 13% 볼륨이 “stuck” 이었다.

Customers also experienced elevated error rates until Noon PDT on April 21st when attempting to launch new EBS-backed EC2 instances in Availability Zones other than the affected zone. This occurred for approximately 11 hours, from the onset of the outage until Noon PM PDT on April 21st. Except for the periods of broader API issues describe above, customers were able to create EBS-backed EC2 instances but were experiencing significantly-elevated error rates and latencies. New EBS-backed EC2 launches were being affected by a specific API in the EBS control plane that is only needed for attaching new instances to volumes. Initially, our alarming was not fine-grained enough for this EBS control plane API and the launch errors were overshadowed by the general error from the degraded EBS cluster. At 11:30 AM PDT, a change to the EBS control plane fixed this issue and latencies and error rates for new EBS-backed EC2 instances declined rapidly and returned to near-normal at Noon PDT.

또한 문제가 발생한 외의 Availability Zones 에서도 새로운 EBS-backed EC2 instances 실행하는 시도를 고객들은 정오 PDT 4 21 일까지 에러율의 급격한 증가를 경험 했었다. 이는 4 21 정오 PST까지 장애의 발생에서 11 시간 동안 일어났다. 위의 설명한 광범위한 API 문제의 기간을 제외하고, 고객들은 EBS-backed EC2 instances 만들 있었다 그러나 크게 상승된 오류율 대기 시간이 발생 했다. 새로운 EBS-backed EC2EBS control plane 볼륨들에 인스턴스를 붙이기위해 반드시 필요한 특정 API 문제가 있었다. 초기에, 우리의 경고 발생은 EBS control plane API 감지할 만큼 중분히 작은 크기로 조직되어 있지 않았고 시작 에러들은 성능이 저하된 EBS 클러스터로부터 발생하는 일반적인 에러에 의해 확산된다. 오전 11 30 PDT, EBS control plane 이들 문제를 고쳤고 새로운 EBS-backed EC2 instances 지연들과 에러율은 급격하게 갑소했으며 정오 PDT 정상화 되었다. 

이후에 장에가 발생한 Zone을 복구한 과정이 설명되어 있고 영향을 받은 RDS도 있으나.. 그것은 위의 링크를 따라가서 원문은...

* 다른것 보다 EBS 시스템이 iSCSI로 구축된 것이 아니라 분산파일시스템을 사용해서 구축된 냄새가 마구 난다.. 아마도 직접 개발한 DFS를 사용하는 것같다. 뭘까 문서에는 그냥 EBS Cluster 라고만 한다. 궁굼하구만

아래는 문서내용을 통해 유추한 논리 구성도



저작자 표시 비영리 변경 금지
신고

티스토리 툴바