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
大雨で「首都圏外郭放水路」稼働 濁流が“地下神殿”を満たすまでの動画公開 国交省
-
2
くら寿司、「ちいかわ」コラボ中止 従業員による不正行為判明で
-
3
メルカリ、くら寿司ちいかわ騒動巡りコメント 出品削除・禁止の有無は
-
4
Duolingoの新アイコンが「気持ち悪い」 世界のユーザーから「元に戻して」の声
-
5
Suica、3つの新キャラ候補を発表 ネット投票で決定へ ペンギンは27年3月末で卒業
-
6
配布前の「ちいかわ」グッズがメルカリに? くら寿司コラボ第2弾、初日から“内部犯”の臆測呼ぶ 第1弾に続き
-
7
「データセンターの排熱で温泉を作ろう」が難しい3つの理由 本職のDC技術者にガチで考えてもらった
-
8
103年前の関東大震災、どこがどれだけ揺れた? 市区町村別の「詳細震度」マップがXで話題に
-
9
東京23区で「徒歩10分以内」に駅がない地域はどこ? 駅空白地帯マップが話題
-
10
近くの“安いマック”が分かる「価格帯マップ」話題 スタバやコメダも対応 店舗の価格差、独自に調査
ITmedia NEWS SNS
インフォメーション
注目情報をチェック
ITmediaNEWSをフォロー
あなたにおすすめの記事PR