Google Cloudの主要サービスが10時間ものあいだ障害発生。原因は分散アクセスコントロールへの大量の変更要求が引き起こしたメモリ不足

2020年4月10日

Google Cloudは、米国太平洋時間の3月26日木曜日16時50分(日本時間27日金曜日 午前8時50分)頃から約10時間ほどのあいだ、Google Compute EngineやCloud Storage、Cloud SQLなどをはじめとする主要なサービスで障害を起こしていました。

受けた影響はリージョンごとに異なりますが、ほぼすべてのリージョンで何らかの影響を受けたようです。

Googleはその原因についての調査結果を発表。原因はGoogle Cloud内部でアクセスコントロールを司る部分に障害が発生したことだったと説明しました。

fig

アイデンティティマネジメントへの大量の更新要求がキャッシュサーバの障害に

クラウド内部では、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時間後に障害からの復旧を果たすのです。

そして今後こうした障害が発生しないように、キャッシュサーバがバルクアップデートに対応できるようにし、メモリの使用効率も改善。また、緊急時の対応用にキャッシュサーバのコンフィグレーションをリスタートなしに変更できるようにもすると説明しています。

このエントリーをはてなブックマークに追加
follow us in feedly




カテゴリ

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed


最新記事10本