とりゅふの森

GCPデータエンジニアとして生きる

2020年12月14日のGoogle大規模障害とクラウドの利用について考える

2020年12月14日20時頃、いつものようにYouTubeを見て、Gmailをチェックし、個人のGCPのプロジェクトをいじって遊んでいた時、Twitterのタイムラインで「YouTube落ちた?」とのツイートが大量に流れてきた。
「え、見れてるよ」構わず視聴を続けた僕だったが、何を思ったのかF5キーをポチ、途端にお猿さんのイラストがデカデカと表示されたエラー画面へと切り替わってしまった。
f:id:true-fly:20201215003420j:plain 今回はそんなGoogleの大規模障害について考えてみましょう。

今回の障害

今回はGoogleが提供するGmail、Googleドライブ、YouTubeを始めとしたサービス、及びGoogleのクラウド環境を利用している各サービスまで、世界規模で障害が発生していたようです。

news.livedoor.com

https://news.yahoo.co.jp/articles/335f75b52cf80ca5f00c51b7a9ac243981c15b67news.yahoo.co.jp

原因については執筆時点では詳細に公表されていません。
一応以下でインシデントの報告はされているようです。 status.cloud.google.com

最近のクラウドサービスの障害

Amazon、Google、Microsoftといった各パブリッククラウドの存在は僕たちの生活にも身近なものになってきました。
AWSのサービス1つが落ちると、それを利用するいろいろなWebサービスがダウンし、Twitter上が賑わいます。
少し思い出せる範囲まで遡って検索すると、こんな感じ。たくさん記事が見つかります。

2020年9月25日 Google Cloud japan.cnet.com

2020年9月29日 Microsoft Azure www.j-cast.com

2020年11月26日 Amazon Web Service gigazine.net

クラウドの障害多くない?クラウドやめたら?という声について

GCPやAWSといったクラウドサービスの障害は、僕が仕事で触り始めた時点から思い出してみると、ここ数年それなりの頻度で発生しています。
記録とっているわけではないので、明言はできませんが、数年前より今年のほうが頻度は減っている気がします。規模はおいといて。
そして言われるわけです、クラウドで障害起きるくらいならクラウドやめたほうがいいんじゃない、と。

では、自分たちがそこそこ大きな規模のWebサービスを運用していて、クラウドをやめてオンプレミス(自社でサーバを管理)することを考えてみましょう。
他のクラウドと同等以上の可用性を担保するためには、突然のアクセス過多など、考えうる限りの負荷に耐えれれるサーバを用意しなくてはなりません。
そのサーバを24時間365日監視する体制を取らなきゃなりません。突然サーバダウンした場合、即時対応、ユーザが求める短時間での復旧をしなければなりません。
これらを可能とする優秀なインフラエンジニアをキープしなければなりません。
莫大なコストをかければもちろんクラウド以上の可用性を担保できるかもしれませんが、今の時代、現実的ではないでしょう。もっと投資すべき先がたくさんあります。

一方で、Googleの今回の障害、影響範囲こそ大規模だったものの、復旧スピードはさすがでした。
僕が翌日の業務に影響ないか情報を集めている間に、いつの間にか復旧していました。
世界的に見ると大規模な障害ですが、自分のサービスのことを考えると、嵐が一瞬訪れていつの間にか消えていたようなものです。
そういう観点では、クラウド上でサービスを運用する メリットって計り知れないですね。

僕らにできること

世はクラウドファーストの時代、何をするにしろまずはクラウドでの運用を検討することを推奨される時代。そんな時代に僕たちITエンジニアにできることはなんでしょう?

障害復旧しやすいシステム設計

例えば毎時動くジョブがあって、1時の処理が何らかの障害で失敗した場合、2時の処理も、3時の処理もう動かなくなる、極端な例ですが、障害に弱い設計です。
1時の処理が失敗しても、2時、3時の処理は動く。1時の処理の復旧は朝出社してから対応、まあありがちな設計です。
1時の処理が失敗したら、2時の処理で1時の処理、2時の処理両方を実行、3時の処理は通常通り実行、これならばたまたまその時間に障害が発生していたとしても、影響は小さくなります。
僕が新人のときに現場配属になって、いきなりクラウド上でシステム設計をやらされたときに言われたのは、「クラウドだからたまにコケることはある。コケた時にどのようにリカバリできるのかを考えた上で設計しろ」でした。リトライ、冪等性、口酸っぱく言われたのを思い出します。初めから高くない可用性だと想定し、システム設計の段階でその高くない可用性をいかにあげられるかが大切です。

障害発生時の体制作り

Webサービスのような不特定多数のユーザに大きな影響を与えてしまう場合、当然早急な説明が求めれますし、復旧も急かされます。最近はゲームやWebサービスの運営Twitterで、「AWS障害のためサービスが利用できない状態になっています」と、包み隠さず説明してしまうことも増えましたよね。こういったカスタマーサポートや、システムの運用の体制を見直し、何が起きてもすぐに対応できる体制を整えておきたいものです。

マルチクラウド化

「GCPがだめなら、AWSにすればいいじゃない?」一理あります。実際にAWS、GCPを併用、マルチクラウドで運用している企業は珍しくないです。Googleも「Anthos」という、GCPと他のクラウドと組み合わせて使うマルチクラウド、オンプレミスと組み合わせて使うハイブリッドクラウドを実現させるプラットフォームを提供しています。
IBM Watsonで簡単にAI利用できるIBM Cloudもマルチクラウド化に積極的なサービスという印象です。マルチクラウド化して、GCP使えないからサービス止まったと騒いでいる人を固めに紅茶をすすりたいものです。

まとめ ― Googleの影響力に思い知らされた時間

YouTubeで動画が見れない、Gmailでメールが送れない、Googleドライブでファイルのやりとりができない、○○のサイトにアクセスできない、
Googleの影響力の巨大さに思い知らせた時間でした。個人的には家ではテレビ一切見ずにひたすらYouTubeばかり見ているので、このような障害が発生すると困ります。仕事関係なしに。
そんな大規模なインフラを世界中に展開し、大規模障害が発生しても早期復旧ができるGoogleの技術力には到底僕らのようなITエンジニアでは敵いません。
Googleで働くすべてのエンジニアに敬意を込めて、これからもクラウドと向き合っていこうと思います。