「絶対に障害が起きないということはない」忘れずにいたい古の教え

IT業界にはロゼッタストーンに書かれるべき級な「この世に”絶対に障害が起きない”というものはない」という古代からの言い伝えがありますが、2025年6月、これがやはり正であることが、また1つ証明されてしまいましたね。

6月12日、今まで障害が少ないと言われていたGoogleのCloudサービスで、とうとう長時間のサービス停止を伴う障害が発生しましたが、皆様に影響はありませんでしたでしょうか？

とくに、驚異的な速度で世界中に利用者を広げる「Cloudflare」というCDNのサービスにも影響したため、間接的にでも影響があった方もいらっしゃるのでは。

こういった障害は、原因やその対策を研究することで自分たちを見直す絶好の契機にもなりますので、改めてどういった障害であったのか、詳細とその原因などについてまとめてみました。

1. 障害の概要
米国時間6月12日午前10:49頃（PDT）から、Google Cloudサービス全体で大規模な障害が発生していることが発見されました。

対象としては、Gmail、Googleドライブ、Google Meet、Googleカレンダー、BigQuery など多岐にわたっており、また世界中のGoogleデータセンター（アメリカ、ヨーロッパ、アジア、日本などの主要リージョン）でも通信の遅延や応答停止が報告されるという、対象サービス範囲としても地理的範囲としても大規模な障害となりました。

障害影響はGoogle Cloudサービスを基に設計された各サービスの利用者にも広がり、当日午後には世界的な影響のピークを迎え、その後段階的に復旧作業が進み、完全復旧は約18:18頃となりました。

＜Googleの公式発表＞

出典URL：https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW

2. 原因について
Google Cloudでは「Service Control」のシステム（APIリクエストの認証・利用制限を管理する機能）で5月末にバージョンアップが行われたのですが、その際に導入された新機能にバグがあり、それが引き金となって起きたものであることが調査の結果判明しました。

原因の詳細としては以下の通り：
①ポリシーとして処理すべきデータに空白フィールド（blank fields）を含むものが混入。
②これを処理しようとして「ヌルポインタ例外（null pointer exception）」が発生。
③プログラム上、ヌルポインタへのエラーハンドリングが不十分であったため、例外発生後にサービスが暴走する「クラッシュループ」に入ってしまう。
④③の結果、広範囲に影響が波及。

Googleは、問題の切り分けには約10分、復旧対応までに約40分、約4時間でほぼすべてのサービスが復旧したと報告しています。

ここはさすがのGoogleチーム、問題の切り分けや復旧対応は驚くべき速さです。ITインフラを担当した経験のある人であれば、この復旧対応までの時間（約40分）についても光の速さのように感じられるのではないでしょうか。

これだけ早く復旧に取り掛かることができたのは、障害発生から25分以内に原因となる①のポリシーの適用を巻き戻す「緊急ボタン（Red Button）」を実行したからだと言われています。この緊急ボタン機能は、幸いにも5月末の新機能の中に実装されていたものです。

３．「ヌルポインタ」「ヌルポインタ例外」とは何？
今回の障害報告で何回も出てきた用語「ヌルポインタ」ですが、まずこの意味が分からないと、どんな障害であったのか理解が難しいと思います。

まず、プログラムの世界では「ヌル（null）」という言葉は、「中身がない状態」を表します。
今回の障害のトリガーとなった「ヌルポインタ例外」は、中身がない場所を、あたかも何かあるように使おうとすると起こるエラーのことをいいます。

例えば、図書館でとある文献を探しているときに「西館４階の本棚A-2の上から3段目、左から2番目に収蔵された〇〇というタイトルの本にその原文が載っている」という情報に従って探しに行ってみたものの、その本棚が実は存在しなかったり、本棚自体はあってもそこに本がなかったり、なんなら西館自体が存在しなければ、当然「〇〇という本を見ること」自体ができませんよね。

プログラムも同じで、「そこにあるはずの情報」が空っぽだと、エラー（＝例外）になってしまい、「その先に進めない」状態になります。そこでプログラムでは「例外時には〇〇せよ」という例外処理の方法まで指定しておく必要があり、もしその指定がなければ、ずっと「その先に進めない」状態が続いてしまいます。

つまり今回の障害では、GoogleのService Controlのプログラムが「ヌル」のデータがあった時の例外処理部分が十分に作られていなかったことが原因で一気に動かなくなった、と言われています。

もちろんGoogleであれば、サービスリリース前にはバグつぶしのために多様なギミックに富んだサンプルデータで試したと思われるのですが、偶然なのか、逆に基本的ともいえる nullデータのサンプルがなかったのかもしれません。

４．世界規模の影響と被害企業・サービス
上記の通り、とても小さなシンプルなバグであったにもかかわらず、その影響はかなり大きく、影響を受けた代表的な企業・サービスとして、以下があったと言われています。

＜一例＞
Spotify：ユーザーから4万〜4.6万件の障害報告。再生などができない状態に
Discord：1万件以上の接続トラブル報告あり。
Snapchat：3千〜数千件の影響報告
GitHub：API不調や機能停止の報告あり。

冒頭にも記載した通り、今回は「Cloudflare」というCDNにも影響が発生したため、Google Cloudを直接利用してなくてもCloudflareの障害をうけて影響を受けた企業・サービスも多数あったと言われており、とくにAIプラットフォームである OpenAI や Character.AI もCloudflare経由の依存により影響を受けたと報告されています。

Cloudflareは多くのWebサイトにDNS、CDN、セキュリティ、キャッシュなどの機能を提供しており、Google Cloudの障害により一部機能の正常性を失ったことから、今回の障害により「実質、世界の半分以上のインターネットに影響が出た」とも言われたほど広範囲に影響を及ぼしました。

５．今回の障害により学ぶべきこと
今回のGoogleの障害で、改めて痛いほど知らされたこととしては以下の４つでした。

①知らない間にCDN依存が大きくなっている
②知らない間に各WEBサービス同士API連携でがんじがらめになっている
③①②より、どこかが倒れたら将棋倒し状態になる
④「絶対に障害が起きない」という神話は存在しない！

昨今、ノーコード開発、サーバレス運用などの耳障りのいい言葉ばかりが出回っていますが、根底は変わらず「“絶対に障害が起きない”ということはない」という古の教えは残り続けること、今後も忘れずにいたいですね。

その他、Googleの公式発表にはとても勉強になる改善点が書かれていますので、お時間のある時に是非ご覧になってみて下さい。