Agile Cat — in the cloud

Amazon の障害に関する オフィシャル・レポートを解説する – Data Center Knowledge

Posted in .Selected, Amazon by Agile Cat on April 30, 2011

Amazon: Networking Error Caused Cloud Outage
April 29th, 2011 : Rich Miller

_ DC Knowledge

Last week’s lengthy outage for the Amazon Web Services cloud computing platform was caused by a network configuration error as Amazon was attempting to upgrade capacity on its network. That error triggered a sequence of events that culminated in a “re-mirroring storm” in which automated replication of storage volumes maxed out the capacity of Amazon’s servers in a portion of their platform.

先週の Amazon Web Services クラウド・コンピューティング・プラットフォームにおける長時間におよぶサービス停止は、Amazon がネットワーク・キャパシティを引き上げた際の、ネットワーク・コンフィグレーション・エラーが原因だった。 そのエラーにより、ストレージ・ボリュームの自動リプリケーションが、Amazon プラットフォームの一部分で1部で、キャパシティを限界まで使い切ってしまった。そして、「再ミラーリングの嵐」の反復となる、イベントのシーケンスを引き起こした。Image(5)

Amazon provided a detailed incident report this morning in which it discussed the outage, apologized to customers and outlined plans to make its platform more resilient in the future. The company also issued a 10-day credit to customers using the US East Region at the time of the outage.

そして、今朝(4/29)になって Amazon は、このサービス停止に関する詳細なインシデント・レポートを提供して、顧客に対して陳謝し、そのプラットフォームの弾力性を将来へ向けて強化する計画を概説した。さらに同社は、この  US East Region におけるサービス停止で被害を受けた顧客に、10日間のクレジットを発行した。

Traffic Shift ‘Executed Incorrectly’

The incident began at 12:47 a.m. Pacific time on April 21, when Amazon began a network upgrade in a single availability zone in the US East region. “During the change, one of the standard steps is to shift traffic off of one of the redundant routers in the primary EBS (Elastic Block Storage) network to allow the upgrade to happen,” Amazon said. “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.”

『 この変更の際に、主要な EBS(Elastic Block Storage)ネットワークで、余剰のルーターにトラフィックをシフトするという、標準的なステップの 1つが、アップグレードを引き起こした。 そしてトラフィックのシフトが、間違って実施された。 つまり、主要なネットワーク上のルーターへ向けた、トラフィックのルーティングが行われるのではなく、よりキャパシティの低い予備的な EBS ネットワークにルーティングされてしまった 』と、 Amazon は発言している。

AmazonThe traffic routing error overloaded the storage network. When network connectivity was restored, volumes stored on EBS began an automated mirroring process designed to preserve data during system failures. “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,” Amazon reported. “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.”

このトラフィックのルーティング・エラーが、ストレージ・ネットワークに負担をかけ過ぎることになった。 そして、ネットワーク接続が復活したとき、 EBS にストアされたボリュームが、システム障害の間にデータを維持するようデザインされている、自動化されたミラーリングプロセスを開始した。 『 こうした状況において、大量のボリュームに対する影響が同時に発生したため、EBS クラスタ内の余剰のキャパシティは短時間で使い尽くされ、多数のノードをループ状態にスタックさせ、空きスペースを探すための、クラスタ・サーチを繰り返すことになった 。そして、たちどころに「再ミラーリング嵐」が導かれ、新しいレプリカのために必要なストレージ・スペースがサーチされる間に、多数のボリュームが急激にスタックしていくという状況に陥った』と、Amazon はレポートしている。

The company said it would take steps to improve its customer communication, which was the focus of sharp criticism during the outage. The incident report was released early Friday, as global media attention focused on the royal wedding in England.

同社は、顧客とのコミュニケーションを改善するためのステップをとり、今回のサービス停止の間に生じた痛烈な批判に取り組んでいく。 このインシデント・レポートは、グローバル・メディアがEngland のロイヤル・ウェディングに釘付けになってる、金曜日の朝にリリースされた。

Amazon: No ‘Significant’ Impact to Other Zones

Amazon’s report sought to deflect criticism that the outage affected multiple availability zones, a key point of contention for some unhappy customers. In theory, using multiple availability zones should allow customers to continue to operate if a single availability zone experiences a failure. There were numerous reports that EBS access was impaired across multiple availability zones, but Amazon challenged the notion that this was widespread.

この Amazon レポートは、今回のサービス停止が多数のアベイラブル・ゾーンに影響を与えたという批判と、いくつかの不幸な顧客における論点を、静めるように努めている。 理論上、マルチ・アベイラブル・ゾーンの利用により、シングル・アベイラブル・ゾーンで障害が発生しても、運用の継続は可能になる。しかし、 多数のアベイラブル・ゾーンを横断するかたちで、EBS へのアクセスが損なわれていたという、多数のレポートがある。そして Amazon は、それが広範囲におよんだという指摘に、異議を唱えている。

“While our monitoring clearly shows the effect of the re-mirroring storm on the EBS control plane and on volumes within the affected Availability Zone, it does not reflect significant impact to existing EBS volumes within other Availability Zones in the Region,” the incident report states. “We do see that there were slightly more ‘stuck’ volumes than we would have expected in the healthy Availability Zones, though still an extremely small number. To put this in perspective, the peak ‘stuck’ volume percentage we saw in the Region outside of the affected Availability Zone was less than 0.07%.”

『 私たちのモニタリングにより、EBS のコントロール・プレーンおよび、影響を受けた Availability Zone 内のボリュームに対して、再ミラーリング嵐が吹き荒れたことが明らかになっている。 しかし、他の Availability Zones 内の既存 EBS ボリュームに対して、重大な影響はおよんでいない。  私たちは、健全だと思っていた Availability Zones に、少量のスタックしたボリュームが存在するのを確認しているが、それれは、きわめて小さなものだ。 その全容を確認するために、影響を受けた Availability Zone 外の Reagion を調べたが、スタックしているボリュームは、最大でも 0.07% 以下であった 』 と、そのインシデント・レポートには述べられている。

Amazon also created the AWS Architecture Center to share information on best practices for deploying cloud assets reliably. The company scheduled a series of webinars to educate customers on their options for designing their AWS deployments to survive outages.

また、Amzon は、クラウド資産を確実にディプロイするための、ベスト・プラクティスに関する情報を共有するために、AWS Architecture Center を開設した。 そして、さらに、耐障害性に富んだ AWS ディプロイメントをデザインするために、カスタマーに提供されているオプションを紹介する Webinar シリースを予定している。

The company also apologized for the outage’s impact on customers, and vowed to take steps to prevent a recurrence. “As with any significant operational issue, we will spend many hours over the coming days and weeks improving our understanding of the details of the various parts of this event and determining how to make changes to improve our services and processes,” the AWS team wrote.

そして同社は、今回のサービス停止について顧客に陳謝し、その再発を防止するための処置をとると約束した。 『 運用における重要な問題と同様に、私たちは今後の数日あるは数週のうちに、この現象における多様なパートを、詳細まで理解・改善する。そして、私たちのサービスとプロセスを改善するために、どのよな変更が必要になるのかを判断・決定するために、充分な時間を費やしていく』と、AWS チームは記述している。


Amazon だからこそ、こうしたトラブルに多くの顧客が巻き込まれ、また、世界の注目を浴びてしまいます。 そして、今回における Amazon の対処により、今後のクラウド・トラブル処理に関する規範が示されることになるのでしょう。 たいへんでしょうが、頑張ってください! ーーー __AC Stamp 2



Amazon に起こった大規模ダウンタイムを分析する – Data Center Knowledge
Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_1
Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_2

2 Responses

Subscribe to comments with RSS.

  1. sugipooh said, on May 2, 2011 at 7:26 am

    これから3,4年後 HDDが大量に寿命をまっとうするとき どのように対策を

  2. Agile Cat said, on May 2, 2011 at 8:29 am

    クラウドに置くべきデータと、置いてはいけないデータ(規約という意味で)の切り分けが進むと思います。 その意味で、米政府の が、ひとつの規範になるのではないかと考えています。 つまり、国防と外交以外の、すべての支出などを公開しているという状況です。 これも、たしか、AWS に移行したと記憶しています(うろ覚えなので、たしか・・・とさせてください)。 そして、オンプレミスもしくはプライベートと、コストの安いパブリックとのハイブリッドが始まると、個人的には予測しています(。 ちなみに、AWS では、どの顧客のデータが、どの HDD に入っているかなど、AWS サイドもわからないのでは? これは、ある種のセキュリティだともおもえますし、長くても 3年くらいを単位とした、ファシリティの大規模入れ替えが、AWS 側の負担で行われるはずです。 それが行われる時も、ユーザーは何が行われているのか、それ自体を知ることができないはずです。

Comments are closed.

%d bloggers like this: