信頼性の高いシステムを（信頼性のないコンポーネントを使用して）構築する方法: 会話

※この投稿は米国時間 2022 年 3 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

「VM に懐疑的な人」と「VM ファン」のキュレーションによる対談シリーズの「VM エンドツーエンド」のエピソードを公開しました。毎回、Brian、Carter、そして特別ゲストとともに、VM が Google の最も信頼できるプロダクトである理由、そして VM がクラウドで大規模に事業を展開する会社にどのような利益をもたらすかを探ります。ここでは、そのエピソードを紹介します。

Carter: 「VM エンドツーエンド」にようこそ。この番組は、VM ファンと VM に懐疑的な人、あるいは以前は VM に懐疑的だった人が、VM に関するあらゆることを語り合うというものです。前シーズンの番組を覚えている方は、信頼性、自動化、費用、そしてクラウドネイティブ VM から得られるすべての利点について話し合いました。しかし、まだ混乱している部分もあります。そこで、Brian をもう一度招いて、話を聞くことにしました。Brian、こんにちは。薄っぺらい小さな部品の代わりに、よく機能する巨大なスーパーマシンが 1 台ないのか知りたいと思います。

Brian: それはすごいことですよね。ただ、無限に動く大きなマシンのようなものがあればすばらしいですが、そんなものはありません。今回のシーズンでは、ゲストをお招きして、このコンセプトをより深く掘り下げていきます。そこで、Steve McGhee を招き、なぜそれがモノにならないのか、どうすればモノから信頼性を引き出せるのか、詳しくお話を伺いました。こんにちは、Steve。

Steve: こんにちは。お元気ですか？

Carter: こんにちは、Steve。お迎えできてうれしいです。自己紹介をお願いします。

Steve: もちろんです。Steve McGhee です。私は Google で 10 年ほど SRE をしていましたが、その後退職し、クラウドの顧客となり、クラウドの使い方、さまざまなクラウドの使い方、意思決定がいかに難しいかなどを学びました。そして、より多くのお客さまに同じ体験をしていただけるように、再び Google に戻りました。私は、サイト信頼性エンジニアリングを担当していたため、信頼性を重視する傾向があります。

Carter: このように、アップグレードして多くのリソースを投入する 1 つのハードウェアを持つことは、通信しなければならない小さな部品がたくさんあって、それらがすべて故障する可能性を考えるよりは、はるかに信頼性が高いと思います。何か間違っていますか？

Steve: はい。その意図は正しいと思います。完璧で、無限に密度が高く、無限に速いコンピュータがあれば、それはすばらしいことだと思います。ノートパソコンでシステム作業をする場合、

「私のマシンでは動いたのに、何が問題なんだ？」というフレーズをよく聞きますね。本番環境に入るとスケールアップするわけですが、1 人用のサービスでは困るので、スケールアップする必要があります。できれば、多数の人を対象とすることが好ましいです。可能性としては世界全体などでもいいんです。しかし、本番環境をスケールアップするということは、物理の基本法則にぶつかるということです。そこでは、光の速さや、物質の密度も関係してきます。たとえば、密度が高くなりすぎて、すべてが火事になっては大変です。

それはつまり、モノを拡大することから始めなければならないということです。つまり、1 台のコンピュータだったものを、多くのコンピュータを使うことで、ある意味、時空を超えて拡大しているのです。何が根本的な問題なのか、ご理解いただけるかと思います。

Carter: この話は何度もしましたから、そうですね。Brian は先回のシーズンで、クラウドの VM は特定のマシンの一部であるというよりもデータセンターの一部である、という点を強調していました。そして、それがここでも発揮されているようです。しかし、私が理解できないのは、Google が、信頼性が高く、長時間稼働していることを売り物にしていることです。しかし、ディスクのように常に故障しそうな部品がたくさんあるのに、どうしてそんなことができるのでしょうか？

Steve: かつてのドットコム ブームの頃を思い出すと、金メッキサーバーと呼ばれたものです。一番高価な、しっかりしたサーバーを作る必要があります。それらは、かなりすばらしいものでした。でも、とても高額でした。そして、1 台のマシンの信頼性を高めることに全力を注いでも、メンテナンスなどのためにダウンタイムが発生するため、収穫が少なくなってしまうことがわかりました。

つまり、一度に多くのマシンを追加して、何十億人ものユーザーを抱えるような、地球規模のスケールを実現したいと思います。1 台のスーパーマシンに何十億人ものユーザーを乗せることはできません。ですから、水平スケーリングを始めると、わずかなリターンで最も高価なマシンを使うことは意味がありません。

そこで、スタックの多くのレイヤでレジリエンスを導入したわけです。そして、その方がサービスにとってずっと良いということがわかりました。より経済的で、より速く移動できるのです。突拍子もない話に聞こえますが、事実です。

Brian: これは Google Cloud の多くの場所、特に VM の周りに現れています。VM 自体は、ライブ マイグレーションによって、基盤システムからある程度切り離されています。その間に異なるゾーンを設けています。また、ロードバランサのようなものを使って、さまざまな部分にアクセスできるようにしています。でも、ここに 1 つ 2 つ、核となる原理があるような気がするんです。そのあたりをもう少しお話しいただけないでしょうか。

Steve: はい。私はコンピュータ サイエンスの学校に通っていたので、自分ではコンピュータ サイエンティストというか、ソフトウェア エンジニアのようなものだと思っていました。コンピュータ サイエンスが好きな人なら誰でも知っていると思いますが、神聖なものは抽象化のレイヤなのです。よろしいですか？抽象化がすべてを解決します。

私は冗談で、これをマトリョーシカ人形と呼んでいます。マトリョーシカ人形は、よくある小さな入れ子人形で、一番真ん中にある小さな人形が、あなたの CPU のようなものです。そして、マシンがあって、その周りに VM があります。さらに、それはデータセンターにあります。データセンターはゾーンの一部であり、ゾーンはリージョンの一部です。

そして、このスタックの各レイヤで、レジリエンス エンジニアリングを行い、そのレイヤを活用できるようにすれば、多層防御が可能になるわけです。ディスクの故障、CPU の故障、太陽フレアによるメモリ破壊など、このスタックのどのレベルでも不具合に対応できるわけです。データセンターへの光ファイバー回線は、誰かが切ることができますよね？そして、ビル全体がオフラインになる可能性もあります。

洪水や火災は起こるものです。まれなことですが、考慮しなければならない潜在的な故障モードがたくさんあり、それらは多くのレベルで発生しています。そのため、それらをすべて認識し、緩和策を準備しておくことがとても重要です。

Brian: 私たちはクラウド上の仮想マシンと呼んでいますが、実際には仮想マシン、仮想ディスク、仮想ロードバランサです。

Steve: そのとおりです。前回のエピソードで、「データセンターの一部を手に入れる」とおっしゃったのはとてもよかったですね。というのも、私たちはこれらのパーツをすべて抽象化し、お客様にお見せすることができるからです。お客様は、このコンピュータとこのディスク、そしてこのネットワークを見ています。そして、実際には、1 枚のディスクは 3 枚なのですが、3 枚とも見せているわけではありません。このレジリエンスと冗長性も、まるで魔法のように提供されます。

Carter: はい。なるほど、下位レイヤを抽象化して、「このリージョン下にどのゾーンがあるかは問題ではない。そのうち 1 つが稼働してさえいれば。」というのは、理にかなっています。スーパー コンピュータ 1 台では難しいですが、小型のマシンを何台も使えば十分に実行可能です。

しかし、そうなると別々のゾーンや VM を管理しなければならず、余計な複雑さが生じることになり、抽象化のデメリットの一つになります。Google はどのように対処していますか？

Steve: よい質問です。多くの企業と仕事をしていますが、まさにこのような質問をされます。彼らは「すばらしい。私たちのすべてのコンピュータを世界中に分散させるということですね。全然大変ではなさそうですね」と言います。

一体どうやってやれというのか、どうやって対処しろというのか、と言っているように聞こえます。そしてまた、その答えは抽象化に戻ってくるのです。

つまり、1 つの VM を持っていて、最初に取得するのは多くの VM と考えると、そうなりますよね。そこで、これらをまとめてロードバランサの後ろに配置しました。私たちはこれをサービスと呼んでいます。Kubernetes に慣れている人なら、大量の VM があって、それらすべてと通信するエントリー ポイントがある、というのとほとんど同じ考え方です。このサービスを複数のゾーンにまたがって実行することができれば、1 つのリージョンの多くのゾーンにまたがってライブになっていることになるので、リージョン サービスと呼ぶことができます。

そして、リージョンごとのサービスを多くのリージョンで受けられるようにしたものを、私は分散型サービスと呼んでいます。今はまだ正式な名前がないようです。しかし、これらのサービスは多くありながら、すべて同じことを行い、同じビジネスニーズを表しているということです。そして、リージョン レベルのイベントにも対応できるようになったわけです。

Carter: なるほど、ではこれを全部まとめましょう。これらの部品が頻繁に故障するにもかかわらず、何重にも重ねることで信頼性を高めているというのは、私にはまだ信じがたいことです。Brian はいつも具体的な例を挙げてくれるので聞いてみましょう。これは Google Cloud のどこで使いますか？

Brian: 最も一般的な例は、同じジョブをする複数の仮想マシン（ウェブサーバーなど）があり、その前にロードバランサを置く場合です。そして、これは物理的なインストールにもクラウドにも現れますが、おそらくこの最も一般的な例です。

つまり、エンドポイントが 1 つあれば、その作業を行うことができる複数の異なるバックエンドがあるということです。そして、そのうちの 1 つがなくなっても、ジョブは発生します。これは私の好きな具体例ですが、Steve、もっと一般的な原則がありますか？

Steve: ええ、まったくです。例えるなら、水面に浮かぶボートを思い浮かべてみてください。物理的なボートです。ボートの底に穴を開けると、嫌なことが起こりますよね？

Carter: はい。

Steve: これを障害発生ドメインと呼んでいます。あなたの小さな船は、1 フロアしかないため障害発生ドメインになります。そして、その床のどこかに穴を開けると、洪水になります。これは困ります。しかし、コンテナ船などの大きな船は、隔壁というものがあるため、小さな船が何隻も連なっているようなものです。大きな船の底に穴を開けると、隔壁が埋まるので大丈夫です。船の他の部分は浮力があるので、浮いたままになります。

つまり、穴が開けば故障するようなものを、くっつけるということです。今では、同じ障害モードでも、システム全体としては故障しないようになっています。

Brian: そのとおりです。つまり、VM とロードバランサのようなものを使っています。では、これはどんな仕組みですか？VM やロードバランサ、ゾーン、リージョン、その他の分散型サービスがある場合、これをどのように推論すればよいでしょうか？どこまで複雑にするかをどうやって決めるのかなどです。

Steve: よい質問です。抽象的な学問的な答えみたいなものですね。「Steve、現実的な話をしましょう。」構築の基盤となるシステムに、どの程度の可用性を期待できるかを理解することが重要です。船底に穴が開くのはよくあることですか？数字を得ることはできますか？そうできればいいと思います。

私たちが提案する考え方は、1 つのゾーンに存在するものについては、99.9% の時間帯で利用できるようにする、というものです。具体的には、99.9% の確率で利用できるように設計されています。月に 40 分間、ダウンまたは利用できなくなるということです。それはベストケースやワーストケースのシナリオとは異なり、かなり当てになるものであることを知ることが不可欠です。

同様に、あるリージョンの多くのゾーンにまたがるものを 99.99% と呼びます。99.99% 利用可能です。そして、その考え方は、1 年間で 40 分のダウンタイムになります。コンピュータは長時間稼働し続けており、1 年間で 40 分というのはほんのわずかな時間です。しかし、それでも受け入れられないことがあり、結局はこれらのコンピュータに何を入れているかということになります。99.9% や 99.99% の可用性で大丈夫でしょうか？自分にとって何が適切かを判断する必要があります。

Carter: 今ならわかります。なぜなら基本的に、「私は 2 台のコンピュータを持っているが、毎年 40 分しかダウンしていない」と言っていることになるからです。片方が倒れているときに重ねれば、もう片方は倒れていないでしょうから、大丈夫です」。

独自に管理しなければならない複雑さが加わってくるのが面白いですね。デベロッパーとして、「このコンピュータを立ち上げて、もう 1 台がダウンするのを見計らってスケジュールを組む」というようなことをしなければならないのでしょうか。それとも、インフラストラクチャが面倒を見てくれるのでしょうか？

Steve: はい。良いニュースとしては、これは過去 20 年間、Google 内部で対処してきた問題だということです。そして、クラウドのお客さまにお届けするシステムには、さまざまなソリューションや改良が施されています。たとえば、機器ラックの電源を落とさなければならないことがありますね。サーバーがラックにある場合、ライブ マイグレーションというものを構築しました。これは、あなたのマシンの魂、つまり実行中のシステムやソフトウェアを、魔法のように別のマシンに転送してくれるものです。そうすれば、安全にこのラックの電源を落とし、再び立ち上げることができます。心配事が一つ減りましたね。先ほど、マシンは 99.9% の可用性を持つように設計されていると言いましたが、このようなことも想定しています。こうして、99.9% の可用性を実現しているのです。

他にもいろいろあります。マシンに問題がある場合や、ビルディングのメンテナンスが必要な場合もあります。誰もわかりません。あらゆる事態を想定し、そのリスクを 1 つの数字に集約しています。そして、その想定内容を提供することで、変な心配をする必要がなくなります。このマシンは 99.9% の確率で稼働することがわかっています。

Brian: そのため、個々の物理マシンではなくクラウド上で VM を実行することで、この種のエッジケースをすべて処理できます。

これと同じようなパターンで、たくさんのツールを手に入れることができます。たとえば、ディスクレベルでも似たようなことが起こっています。複数のマシンからロードバランサを構築しています。マネージド インスタンス グループのような VM のグループがあり、さらにゾーンやリージョンなど、さまざまな種類のものがあります。

しかし、そうなると、ある時点から、ある程度の信頼性はアプリに委ねざるを得なくなりませんか？

Carter: 年間 40 分のダウンタイムにも対応できるようなアプリケーションを設計したい、ということですか？おもしろいですね。

Brian: なるほど。つまり、VM を信頼できるところまで到達し、そこから構築していくということでしょうか。

Steve: はい。重要なのは、VM にどの程度の信頼を置けるかを知ることです。そして、その信頼をクラウド プロバイダに託し、「いいか、何が起こるか教えてくれ」と言っているのです。

GCP では、私たちの VM の場合、1 つのゾーンで 1 つの VM について 99.9% になりますとお伝えしています。そのことをすべて頭から消し去り、その数字が正確であることを信じて、今は、それを中心に仕事をすればいいということです。

その数字が 100% に近いように見えても、100% だと思ってはいけません。それは真実ではないからです。99.9 と 100 を区別すると、アプリケーションでの設計の選択が根本的に変わってきます。リトライやチェックポイントのようなものを導入し始めたり、サービスが同時に 2 つの場所に存在するようにできたりします。

ここに 1 つ、あそこに 1 つとリクエストが来て、こっちは稼働していて、こっちは稼働していないというようなことがあったらどうしますか。モデルの理解に少し不具合を許容するようになったことで、システム設計の考え方が変わってきました。Google が最初から成功できたのは、ある種の不具合を許容するシステムを設計したからだと私は考えています。そして、スタック全体で何度も何度も復元性を高めていきました。

Carter: 今の言葉でやっと理解できました。不具合を想定した計画を立てることで、どんな不具合があっても、そのケースをカバーできます。この情報が届くのが遅れるかもしれないため、送り直そうと思います。それによって、正確な故障を知らなくても、システムにもっとレジリエンスと信頼性を持たせることができます。

実社会ではこれが重要なケースもあり、だからこそ、この考え方に力が入るかもしれません。

Steve: そのとおりです。何でもかんでも最高レベルの信頼性を得ようとしないことが大切です。ウェブサイトやサービスなどがダウンすることがありますが、それは大したことではありません。しかし、他のサービスは必要不可欠で、より高い信頼性を必要とします。

たとえば、どこかの医療機関に酸素ボンベを新たに納品する必要がある場合、それに対応するサービスがあるとします。このサービスはほぼ常に稼働させたいと思います。また、リクエストをしてもすぐに実現するわけではありませんが、一度行動を起こしたら受信され、それに対して誰かがアクションを起こすというようなことがわかっています。

これは大きな例ではありませんが、社会のオンライン化を進める中で、このようなサービスのより多くが世界にとってより一層重要になってきています。COVID-19（新型コロナウイルス感染症）は、多くのサービスが加速度的に個人にとって重要なものになっていくのを目の当たりにしたため、この信頼性向上への取り組みを進めるうえで、実は興味深い時期だと思っています。

そこで、学校に通う子供たちのビデオ会議、あるいは自宅での注文などを考えてみてください。これをオンラインで行うことがより一層重要になってきています。それで、やりたいときにやれるようにすることは、昔よりもっと重要になっています。

Brian: なるほど。事態は非常に現実的になってきており、私たちの生活の多くがオンライン化さればされるほど、その重要性は増してきます。なるほど、これはすごいことになりました。今回はこれで終わりにしようと思いますが、まだまだ話したいことがたくさんあるような気がします。Steve、また次回、具体的な話を聞かせてもらえませんか？そのときは、どうすれば信頼性を向上させることができるかという方法と、実際にどのようにすればいいのかを教えてください。

Steve: はい。大丈夫だと思います。これは大事なことで、皆さんが聞きたいことだと思います。また、参加したいと思います。

Carter: Steve、ありがとうございます。Brian、ありがとうございます。ご自宅で聞いている人は、どうぞ、コメントに書いて、信頼性について学んだことがあれば教えてください。私はいくつかの点を学びましたが、皆さんもそうなのではないでしょうか。ありがとうございます。

今回のエピソードにゲストで参加してくれた Google のリライアビリティ アドボケイトである Steve McGhee に感謝します。