そのDynamoDBで、米東リージョンにおいて9月20日午前2時頃（太平洋夏時間）から午前7時頃まで障害が発生。DynamoDBを利用しているEC2 Auto Scaling、Simple Queue Service、CloudWatch、そしてコンソールなどにも一時的な障害が発生していました。

　また、この障害はAmazonクラウドを利用している他社のさまざまなサービスにも影響を与えたと報じられています。

1. Amazon’s AWS DynamoDB experiences outage, affecting Netflix, Reddit, Medium, and more (Update: Fixed) - VentureBeat
2. AWS glitch strikes Netflix and Tinder, offering a wake-up call for others | PCWorld

　なぜDynamoDBが障害を起こしたのか、報告書として「Summary of the Amazon DynamoDB Service Disruption and Related Impacts in the US-East Region」が公開されました。

　報告書の内容を手短にまとめると、DynamoDBの新機能としてテーブルに新たなインデックスを付加できるGlobal Secondary Indexesを追加した結果、多数の利用者がこの機能を利用し、管理のためのメタデータが劇的に増大。

　そこへネットワーク障害が一時的に発生、障害からの復旧時に行われるメタデータの処理時間が予想以上にかかるようになり、メタデータの処理がパンク。それがほかのサーバを巻き込んで大きな障害へ発展していった、ということのようです。

　以下で報告書のポイントをまとめました。

ネットワーク障害が引き金に

　DynamoDBは、データを「パーティション」に分けて複数のサーバで分散保持しており、データを保持するサーバは「ストレージサーバ」と呼ばれます。一方、どのパーティションがどこに属するデータなのかなどを示す「メンバーシップ情報」があり、これも「メタデータ」としてDynamoDBで管理されています。ストレージサーバは自身が正しいメンバーシップ情報を持っていることをメタデータサービスに定期的に確認しています。

　報告書によると、過去数カ月で利用者がDynamoDBの新機能であるGlobal Secondary Indexesが急速に利用され始めたとのことです。これによってパーティションが増加し、メンバーシップ情報のサイズも増加。

　こうした中で、障害当日の午前2時19分にDynamoDBのストレージサーバ群の一部でネットワーク障害が起き、これがその後のDynamoDBの障害の引き金になります。DynamoDBの仕組みの説明も含む記述を引用します。

　On Sunday, at 2:19am PDT, there was a brief network disruption that impacted a portion of DynamoDB’s storage servers. Normally, this type of networking disruption is handled seamlessly and without change to the performance of DynamoDB,

　日曜日の2時19分（太平洋夏時間）、一時的なネットワーク障害があり、DynamoDBのストレージサーバの一部が影響を受けた。通常であれば、こうしたネットワーク障害に対してDynamoDBは性能低下を示すこともなく処理を継続しつつ対処する。

　as affected storage servers query the metadata service for their membership, process any updates, and reconfirm their availability to accept requests. If the storage servers aren’t able to retrieve this membership data back within a specific time period, they will retry the membership request and temporarily disqualify themselves from accepting requests.

　まず障害の影響を受けたストレージサーバはメタデータサービスにメンバーシップ情報を要求し、アップデート処理を行い、自身が利用者からのリクエストに応えられることを再確認する。もし規定時間内にストレージサーバがメンバーシップデータの取得を返答できなければ、リトライを行いつつ、自身のリクエスト受け入れ資格を一時的に不適格にする。

【次ページ】 メタデータ処理がパンクし始める