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発の記事を朝日インタラクティブが日本向けに編集したものです。
