編集部からのお知らせ
新着PDF:「Emotetの脅威」
新着記事まとめ「6G始動?」

AWSが11月の大規模障害について説明

Liam Tung (ZDNet.com) 翻訳校正: 編集部

2020-12-01 12:55

 Amazon Web Services(AWS)は、米国時間11月25日に発生した大規模障害についての説明を公開した。この障害では、何千ものサードパーティーのオンラインサービスが数時間にわたって影響を受けた。

 数十におよぶAWSのサービスも影響を受けたが、同社によれば、障害が発生したのはバージニア北部のUS-EAST-1リージョンだけだった。同社によれば、ことが起こったのはKinesisサーバーのフロントエンドフリートに「小規模な容量の追加」を行った後だったという。

 Kinesisはデータや動画のストリームをキャプチャーし、AWSの機械学習プラットフォームで処理するサービスであり、顧客にも使用されているが、「CloudWatch」や認証サービスの「Cognito」などをはじめとするAWSの他サービスでも使用されている。

 Kinesisサービスのフロントエンドでは認証やスロットリングの処理を行っているほか、「シャーディング」と呼ばれるデータベースのメカニズムを介してワークロードをバックエンドの実働クラスターに分散している。

 AWSが長々とした障害対応経緯のまとめで説明しているように、容量の追加は障害発生のきっかけではあったが、根本的な原因ではなかった。原因は、容量の追加作業が午前2時44分(太平洋標準時〈PST〉)から約1時間かけて行われた後、Kinesisのフロントエンドフリートに属する全てのサーバーで、スレッド数が現在のOSの設定で許容されている最大値を超過し始めたことだった。

 最初のアラームが発生したのは午前5時15分(PST)で、問題の解決までには約5時間かかった。Kinesisが完全に復旧したのは午後10時23分(PST)だった。

 Amazonは、Kinesisのフロントエンドサーバーがバックエンドにデータを分散させる方法について、「フロントエンドの各サーバーは、バックエンドクラスターのメンバーシップの詳細やシャードの所有権を含む情報のキャッシュを保持しており、このキャッシュはシャードマップと呼ばれている」と説明している。

 AWSによれば、この情報はメンバーシップ情報や「DynamoDB」からの設定情報の取得、他のKinesisフロントエンドサーバーからのメッセージの継続的な処理を行うマイクロサービスを呼び出すことで取得されている。

 問題は、スレッド数がOSの設定を超えたことが原因で、フロンドエンドサーバーのシャードマップが使い物にならなくなり、リクエストをKinesisのバックエンドクラスターにルーティングすることができなくなってしまったことだったという。AWSは障害のきっかけとなった追加された容量を取り外したが、障害対応中は復旧に遅れが生じることを恐れてスレッドの上限値を上げるのを避けたと説明している。

 AWSは「今回の事態がお客さまに与えた影響についてお詫びしたい」と述べている。

この記事は海外Red Ventures発の記事を朝日インタラクティブが日本向けに編集したものです。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

特集

CIO

モバイル

セキュリティ

スペシャル

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNet Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]