インフィニティソリューションズ株式会社ブログ

昨年のクリスマス・イブのAWS障害の詳細

ご存知の方も多いかと思うが、昨年のクリスマスイブに、AWSのバージニア北部のデータセンターで障害が発生。完全回復にほぼ丸一日かかり、クリスマス・イブの夜に自宅で映画でも見ようと考えていた一般ユーザに影響が出たのであった。

これまでAWSに障害が発生しても、いまひとつ詳細が明らかならなかった。今回はどうか。InformationWeekの「Amazon’s Dec. 24th Outage: A Closer Look」から。

‘Explanations in the press of what happened, based on the Dec. 29 statement, were relatively brief. The Wall Street Journal, for example, stated that Amazon spokesmen blamed the outage “on a developer who accidentally deleted some key data … Amazon said the disruption affected its Elastic Load Balancing Service, which distributes incoming data from applications to be handled by different computing hardware.”’

「12月29日の発表に基づいたマスコミの解説はどちらかと言えば簡単だ。例えばウォールストリートジャーナルによれば、アマゾンの広報は、障害について、重要なデータを偶然削除してしまったある開発者を非難した。アマゾンによれば、『障害は、アプリケーションから送られてきた受信データを異なるコンピューティングハードウェアで処理できるように配分するElastic Load Balancing Serviceに影響与えた』としている。」

Image courtesy of kibsri at FreeDigitalPhotos.net

Image courtesy of kibsri at FreeDigitalPhotos.net

‘The developer, Amazon took pains to explain, was “one of a very small number of developers who have access to this production environment.” Amazon is a large organization with many developers; how many developers had access?’

「アマゾンが苦心して解説したところによると、『その開発者は、本番環境にアクセスできる極めて少ない開発者の1人』だという。アマゾンは多数の開発者を抱える大企業だ。何人の開発者がアクセスできるのだろうか。」

— 本番と開発の分離が常識なのだが、この開発者は何故本番にアクセスしたのだろうか?

‘The developer launched a maintenance process against the running production system which deleted the state information needed by load balancers. “Unfortunately, the developer did not realize the mistake at the time. After this data was deleted, the ELB control plane began experiencing high latency and error rates for API calls to manage ELB load balancers,” the Amazon team’s statement said.’

「この開発者は、稼働中の本番システムに対して、メンテナンスプロセスを起動し、ロードバランサーが必要としている状態情報を削除した。『不幸にも、この開発者はその時間違いに気づかなかった。このデータが削除された後、ELBコントロール・プレーンでは、ELBロードバランサーを管理するためのAPI呼び出しで高いレイテンシーとエラー率が発生した』とアマゾンチームの発表文に記されている。」

— この障害が始まったのが、太平洋時間午後0時30分。

‘The AWS trouble shooters spotted the error rates for API calls, but a larger underlying problem was developing out of sight. When a customer sought to modify his load balancer configuration, the Elastic Load Balancer control plane needed the state information that had been deleted. “Load balancers that were modified (by customers) were improperly configured by the control plane. This resulted in degraded performance and errors for customer applications,” and the problem began to spread.’

「AWSのトラブルシューターがAPI呼び出しのエラー率に気付いたが、見えないところでより根本的な問題が進行していた。顧客が自身のロードバランサーの構成を変更しようとする際、Elastic Load Balancerコントロールペインは、削除されてしまった状態情報が必要であった。『(顧客によって)変更されたロードバランサーは、コントロールペインによって不適切な構成になってしまった。この結果、顧客のアプリケーションにおいて、パフォーマンスの劣化やエラーが発生する』ということになり、問題が広まっていった。」

‘The AWS trouble shooters noticed more load balancers were issuing increased error rates and realized some sort of infection was spreading out. It didn’t affect newly created load balancers, only those that had been operating prior to the developer’s maintenance procedure. They dug “deeply into these degraded load balancers (and) identified the missing ELB state data.”’

「AWSのトラブルシューターは、より多くのロードバランサーでエラー率が増加していることに気付き、ある種の悪い影響が広まっていると認識した。新規作成されたロードバランサーは影響を受けず、開発者がメンテナンス手順を行なう前に運用中であったもののみが影響を受けた。詳しく『低下したロードバランサーを調査し、ELB状態データがないことを特定した』」

‘At that point, it became a containment and recovery problem. After 4.5 hours of disruption, with 6.8% of load balancers affected, the team disabled the control plane workflows that could spread the problem. Other running load balancers couldn’t scale up or be modified by customers, a serious setback on the final day of the Christmas shopping season.’

「その時点で、抑制と回復の問題となった。障害から4.5時間後、ロードバランサーのうち6.8%が影響を受けており、チームは問題を広げてしまうコントロールペインのワークフローを使えないようにした。その他の実行中のロードバランサーは、スケールアップできない、あるいは、顧客によって変更できない状態となり、クリスマス・ショッピングの最終日としては深刻な逆行となった。」

— アクセス増大に対応するために増大する、というわけにいかなくなってしまったわけだ。

‘”The team was able to manually recover some of the affected running load balancers” by that evening and “worked through the night to try to restore the missing ELB state data.” But initial effort went awry, consuming several more hours but “failed to provide a usable snapshot of the data.”’

「その日の夜までに『チームは、影響を受けた稼働中のロードバランサーのいくつかをマニュアルで回復することができ』、『夜を徹してなくなったELB状態データのリストアを試みた』。しかし、最初の試みは不首尾に終わり、さらに数時間を要したが、『そのデータのまともなスナップショットを得るには至らなかった。」」

‘A second recovery attempt worked. At 2:45 a.m. Pacific Dec. 25, or more than 14 hours after the disruption started, the missing state data was re-established, but even this was a near thing. The recovery occurred “just before the data was deleted,” the Amazon statement acknowledged. The troubleshooters merged the state data back into the control plane “carefully” to avoid disrupting any running load balancers. By 10:30 a.m. Pacific Dec. 25, 22 hours after its start, most load balancers were back in normal operation.’

「2度目のリカバリーはうまくいった。太平洋時間12月25日午前2時45分、言い換えれば障害発生から14時間以上経って、無くなった状態データは再構築されたが、これは近いものではなかった。リカバリーは、『データが削除される直前の状態』であったとアマゾンは発表している。トラブルシューターは、稼働中のロードバランサーを中断させないよう、『注意深く』コントロールペインに状態データをマージしていった。太平洋時間12月25日午前10時30分、障害から22時間後、ほとんどのロードバランサーは通常運用に戻った。」

‘AWS continued to monitor its running load balancers closely and waited until 12:05 p.m. Pacific before announcing that operations were back to normal.’

「AWSは稼動中のロードバランサーを注意深く監視を続け、太平洋時間午後0時05分まで、運用が通常状態に戻ったことを宣言するまで待った。」

‘Even so, potential cloud users will frown on the fact that some developers have some access to running EC2 production systems. “We have made a number of changes to protect the ELB service from this sort of disruption in the future,” the AWS team stated.’

「そうであっても、潜在的なクラウドユーザは、何人かの開発者が稼働中のEC2の本番システムにアクセスできるという事実に眉をひそめる。AWSチームは『今後のこの種の障害からELBサービスを守るためにいくつもの変更を既に行なった』としている。」

— 変更したらしたで、心配の種はなくならない。

‘Normally a developer has one-time access to run a process. The developer in question had a more persistent level of access, which Amazon is revoking to make each case subject to administrative approval, controlled by a change management process. “This would have prevented the ELB state data from being deleted. This is a protection we use across all of our services that has prevented this of problem in the past, but was not appropriately enabled for this ELB state data.”’

「通常、開発者はプロセスを実行するために一回限りのアクセスを行なう。問題の開発者は持続的なレベルのアクセス健を持っており、アマゾンは無効にし、ケースごとに、管理者の承認が必要で、変更管理プロセスによりコントロールすることとする。『これにより、ELB状態データが削除されることを防御する。これは、過去、このような問題を起こさないようにするために全てのサービスにわたって使用している保護策だが、ELB状態データについては、適切に適用されていなかった。」

‘So the official explanation says an unexpected event occurred but it won’t occur elsewhere, due to protections already in place. The team said it could now reprogram the control plane workflows “to more thoughtfully reconcile current load balancer state” with a central service running the cloud.’

「そこで、正式な説明では、予期せぬ出来事が発生したのだが、保護策がうたれているため、他のところで起こるものではないとしている。チームによれば、クラウドを実行するセントラルサービスと、その時点のロードバランサーの状態とが一致しているかどうかを、より注意深く行なうために、コントロールプレーンのワークフローをプログラムできる、としている。」

‘”We want to apologize. We know how critical our services are to our customers’ businesses, and we know this disruption came at an inopportune time. We will do everything we can to learn from this event and use it to drive further improvement in the ELB service.”’

「『申し訳ない。我々のサービスがお客様のビジネスによってクリティカルであることを認識しており、今回の障害が都合の悪い時期に起こったことも認識している。我々は出来る限り、今回の出来事から学び、ELBサービスの更なる改善に活用していく。」