この数週間、まるで空が落ちてきたかのように感じていたのは、私一人ではないだろう。
この1カ月の間に、インターネットの大規模な障害が何度も発生し、世界中の何百万ものユーザーに影響を及ぼした。サイトが落ちた、サービスが止まった、画像が表示されない、ダイレクトメッセージが届かない、カレンダーと電子メールが同時に数時間利用できなくなった、などなど。
これらの障害の原因が１つに集約できるとは考えにくい。どれも極めて不運だったとしか言いようがない。
最初は米国時間6月2日の静かな日曜日だった。ほとんどの人は働いていなかったろう。大規模なGoogle Cloudの障害が米国東海岸のほとんどの地域で発生した。Discord、Snap、Vimeoといった多くのサードパーティサイトだけでなく、GmailやNestなど、Google自身のービスも、その影響を免れなかった。
定期的なものだったはずなのに、誤った設定変更がその原因だった。しかも、問題が発生したとしても、いくつかのシステム内だけに隔離されるはずだったのに、１つのバグのせいで、それがGoogleの他のサーバーにも波及してしまった。その結果、クラウド全体が3時間以上にも渡って大渋滞となってしまったのだ。
米国時間6月24日には、Cloudflareがネットワークルートのリークにより数時間にわたって全トラフィックの15％を欠損させた。同社は直ちに、Verizon（TechCrunchの親会社）がヘマをやらかしたせいだと非難した。インターネットのトラフィックが、インターネット上でどのようにルーティングされるかを管理するボーダーゲートウェイプロトコルに内在していた欠陥が原因で、事実上Verizonは「高速道路の全部のトラフィックを一般道に誘導してしまった」と、Cloudflareは事後のブログ記事で述べている。「これはあってはならないことでした。Verizonはそれれらのルートをインターネットの他の部分に転送すべきではなかったのです」。
Cloudflareのインフラに依存しているAmazon、Linode、およびその他の大企業のサービスも停止を余儀なくされた。
その1週間後の米国時間7月2日、Cloudflareは再び停止することになった。今回は、社内でコードの更新に失敗したためだった。ブログ記事で、Cloudflareの最高技術責任者であるJohn Graham-Cumming氏は、今回の約半時間の停止はウェブファイアウォールの「正規表現」コードのちょっとした不具合が原因だったと明かした。そのファイアウォールは、顧客のサイトをJavaScriptベースの攻撃から守るために設計されたものだという。しかしその正規表現のコードに誤りがあり、世界中のマシンでプロセッサーの負荷の急増を招いた。その結果、サービス全体の障害を引き起こし、それに依存したサイトをすべてダメにしたのだ。しかし、コードのロールバックが迅速に行われたので、インターネットはすぐに正常な状態に戻った。
こんなことでCloudflareの向こうを張ろうとは思っていないGoogleも、米国時間7月2日に、米東海岸地域の光ファイバーケーブルの物理的な損傷が原因で、新たな障害に見舞われた。その混乱は、約6時間ほど続いた。Googleは、トラフィックを他のデータセンターに誘導したことで、ほとんどの障害を軽減することができたとしている。
その次はFacebookだ。WhatsAppとInstagramを含むすべてのサービスが、米国時間7月3日に8時間に渡って不安定な状態となった。それらのサービスで共用している配信ネットワークの障害によるものだった。Facebookは、不具合を告知するのにTwitterを使うしかなかった。画像やビデオはまったく表示されず、機械学習によって生成された気味の悪い写真の内容説明だけが表示されるというありさまだった。
Instagramは、今回の障害で打撃を受けた多くのFacebook所有のサービスの１つだ。Twitterには、画像の自動的なタグ付けや分類に触れた投稿が多くあった（画像：Derek Kinsman／Twitter）
それとほぼ同時期に、Twitterも無関係ではいられなくなった。ダイレクトメッセージ機能が停止したことをツイートで認めたのだ。そこにあるはずのない「幽霊」メッセージが表示されるとか、新しいメッセージが来ても通知が表示されない、といった苦情が寄せられた。
そしていよいよAppleの番となった。米国時間7月4日、iCloudは3時間に渡って米国内全域で停止した。App Store、Apple ID、Apple Pay、Apple TVといったクラウドベースのサービスのほぼすべてが影響を受けた。ユーザーによっては、電子メールや写真にアクセスできなくなることもあった。
インターネットのモニタリング会社であるThousandEyesによると、この機能停止の原因もまた別のボーダーゲートウェイプロトコルの問題であり、VerizonとCloudflareの間で起こったいざこざに似ているという。
何の説明もないAppleの運用状況のページ。問題の発生は示されているが、その理由や回復の見込みなど、何もわからない（Image：TechCrunch）
多くの人にとって騒がしい月だった。CloudflareとGoogleについては、何が起こったのか、その理由が何なのかを説明しているので、まだいい。Apple、Facebook、そしてTwitterに至っては、ほどんと説明もなく、かろうじて問題の発生を認めただけだ。
ここから何を学ぶことができるだろうか？1つには、インターネットプロバイダーは、ルーティングフィルタの扱いには、もっと気をつけたほうがいいということ。もう1つは、新しいコードを実動のシステムでそのまま実行するのは止めたほうが良さそうだということ。
ここ数週間というもの、クラウドに対する印象は、あまりいいものではなかった。AmazonやGoogleといった大手のホスティング会社への信頼も揺らいでしまった。こうしたインターネットの障害は、ハッカー、あるいは何らかの攻撃者がサービス妨害攻撃をしかけたからだなどと、早急に、あるいは無責任に結論付けるのは、たいてい間違っている。まずは、サービス内部の過ちを疑ってかかるほうが、ずっと無難だ。
それでも、ほとんどの消費者にとって、そして大多数の企業にとって、自社でサーバーを運用するのに比べれば、クラウドのほうがはるかに高い回復力を備え、ユーザーのセキュリティを保護する能力も高い。
もっとも確かな教訓は、すべての卵を1つのかごの中に入れてはいけないということ。つまり、すべてのデータを1つのクラウドに保存するのは危ないということだ。しかし、この1カ月の事例が示すように、それでもなお不幸に見舞われることはあるだろう。
画像クレジット：Getty Images
［原文へ］
（翻訳：Fumihiko Shibata）
