3月末のGoogle Cloud障害の原因判明 分散アクセスコントロールへの大量の変更要求が引き起こしたメモリ不足
この記事は新野淳一氏のブログ「Publickey」に掲載された「Google Cloudの主要サービスが10時間ものあいだ障害発生。原因は分散アクセスコントロールへの大量の変更要求が引き起こしたメモリ不足」(2020年4月10日掲載)を、ITmedia NEWS編集部で一部編集し、転載したものです。
米Googleが提供するパブリッククラウドサービス「Google Cloud Platform」は、米国太平洋時間の3月26日木曜日 午後4時50分(日本時間27日金曜日 午前8時50分)頃から10時間ほど、Google Compute EngineやCloud Storage、Cloud SQLをはじめとする主要なサービスで障害を起こしていました。
受けた影響はリージョンごとに異なりますが、ほぼ全てのリージョンに何らかの影響があったようです。
Googleはこのほど、その原因についての調査結果を発表。原因は「Google Cloud内部でアクセスコントロールをつかさどる部分に障害が発生したことだった」と説明しました。
アイデンティティーマネジメントへの大量の更新要求がキャッシュサーバの障害に
クラウド内部では、APIへのアクセス時やリソースの確保などあらゆる場面で適切な権限によって実行されているかを確認するための認証が行われています。この認証はアイデンティティーマネジメント(IAM:Idenntity and Access Management)の一環として分散アクセスコントロールサービスによって実行されています。
そして分散アクセスコントロールサービスは分散データベースによって構築されています。
Google Cloud内部では、この分散データベースに対する最新の状態を反映するアップデート処理として、つねにリアルタイム処理とバッチ処理の2つのプロセスが走っています。
しかし何らかの原因でリアルタイムのアップデート処理のどこかであまりにも大きな遅延が発生すると、古いデータによって更新が行われてしまい、これが関連するサービスに悪影響を及ぼすことがあります。
これがGoogle Cloudの主要なサービスを障害に巻き込んだ原因でした。以下はGoogleが公開した報告書の「ROOT CAUSE」(根本原因)の部分から引用します。
The trigger of the incident was a bulk update of group memberships that expanded to an unexpectedly high number of modified permissions, which generated a large backlog of queued mutations to be applied in real-time. The processing of the backlog was degraded by a latent issue with the cache servers, which led to them running out of memory; this in turn resulted in requests to IAM timing out. The problem was temporarily exacerbated in various regions by emergency rollouts performed to mitigate the high memory usage.
インシデントの引き金となったのは、グループメンバーシップの一括更新でした。これによって予想以上にパーミッションの変更が多くなり、リアルタイムに適用すべきキュー遷移に大量のバックログが発生しました。
この大量のバックログ処理はキャッシュサーバの潜在的なバグを引き起こし、(キャッシュサーバの)メモリを使い尽くしたのです。これがIAMに対するリクエストのタイムアウトを発生させる結果となりました。しかもこれは、メモリ使用量の増加を緩和するために実施された各地の緊急のロールアウトにより、一時的に悪化しました。
IAMへの大量の変更要求によるバックログがキャッシュサーバのバグを呼び、メモリ不足を誘発。それがタイムアウトにつながったということです。
そしてアクセスコントロールが止まってしまえば、APIへのアクセスもリソースの確保も新たに実行できなくなります。これが主要なサービス全体に障害が影響した理由です。
Googleはその後この原因を発見し、更新されたキャッシュを反映するためのオフラインジョブを手動で開始しました。さらに、追加のメモリを使用してキャッシュサーバを再起動させるなどして障害対応を進めていき、約10時間後に障害からの復旧を果たすのです。
そして今後こうした障害が発生しないように、キャッシュサーバがバルクアップデートに対応できるようにし、メモリの使用効率も改善。また、緊急時の対応用にキャッシュサーバのコンフィグレーションをリスタートなしに変更できるようにもすると説明しています。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
こんなメディアも見られています
ITmedia NEWSに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
SpecialPR
本日の新着記事
アクセスランキング
-
1
なぜ酒蔵の許諾なしに? 「VTuberコラボ日本酒」騒動、主催者が経緯説明 仲介者による調整で「準備進んでいると認識」
-
2
かっぱ寿司「配布前のコラボグッズ、フリマで買わないで」 プリキュアコラボ発表日に注意喚起
-
3
「食事量は1日1200kcal以下、でも肥満」な人を14日間追跡調査 痩せない理由は……米コロンビア大などの研究
-
4
本物そっくり“AI生成レシート“が経費精算の脅威に マネフォ「自力で見破るのは難しい」 企業はどう備える?
-
5
「菜の花がおかしい」――イラストレーター制作うたうマラソン大会ポスターに指摘相次ぐ 事務局がAI使用明かす【訂正あり】
-
6
「ペンギンを返して」→「3匹全部採用して」 批判殺到のSuica新キャラ、ファンアートが空気を変えた? SNSの声
-
7
藤井風のリサイタル、公式サイトがインターネット老人会すぎると話題 公民館のチラシみたいだけど東京ドーム開催
-
8
「iPhone Duo」純正ケース話題、「面白いけど高い」……1万4800円と2万4800円
-
9
「ランジェリーパープルじゃない」「買おうと思ってたのに」 iPhone 18 Pro/Pro Maxの色に落胆の声
-
10
松本デジタル相、24.6万件漏えい可能性について説明 「既知の脆弱性を対応前に悪用」
ITmedia NEWS SNS
インフォメーション
注目情報をチェック
ITmediaNEWSをフォロー
あなたにおすすめの記事PR