デベロッパー

VM がどうしてコンピューティングのマトリョーシカ人形となるか: 会話

2022年3月26日

Google Cloud Japan Team

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

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

Carter Morgan: VM エンドツーエンドにようこそ。このシリーズでは、私のような VM に懐疑的な人と VM ファンが、クラウドネイティブな未来における VM の面白さや有用性について語り合います。前回は信頼性をめぐる考え方について話しました。しかし、実際にそれでどうするかとなるとまだ十分には知り得ていないような気がします。そこで本日は、Steve と Brian に今一度来てもらい解説してもらうことにしました。こんにちは Steve。こんにちは Brian。ようこそ。

Steve McGhee: こんにちは Carter。お招きいただき光栄です。

Carter: お迎えできて嬉しいです。Brian、まずあなたにお聞きします。先週のエピソードを終えた私ですが、実際に小規模な SaaS プロダクトを用意して、99.9% の可用性から 99.99%、99.999% に移行できる状態にあると思いますか？

Brian Dorsey: すでに多くのことをカバーしていると思います。一般的なパターンについては話しましたし、もう少し深掘りすることもできます。ただ、ここでの質問は、いつ、どのようにといったことですよね？もう少し具体的に考えてみましょう。どのようなアプリを構築することをイメージしていますか？

Carter: わかりました、では、決済処理アプリにしましょう。クラウド上にある SaaS アプリケーションで、ユーザーは支払いを実行します。それがアプリで行おうとすることです。とは言っても、それがどの程度の信頼性なのかを判断する方法さえわかりません。そこから始めましょう、Steve。

Steve: そうですね。そこから始めるのが良いでしょう。これは SRE で非抽象的なシステム設計の問題と呼ばれるものであり、最適な手法です。ノートパソコンやデスクトップでシステムを構築するような場合を考えましょう。まずは、問題なく機能するようにします。その後、他の誰かのために何かを行うためのスケールアップに、どの程度投資するかを考える必要があります。というのも、ノートパソコン上で試すだけでお金を稼ぐことはできません。世の中のためにもなりません。

そこから脱却する必要があり、これを本番環境に持っていく必要があります。そこで行うべきなのは、その信頼性をどの程度にするか考えるということですが、その答えは常に、「十分な信頼性」になるはずです。ですよね？冗談っぽい答えはともかくとして、ユーザーが誰かや、そのユーザーがシステムに何を求めているかを考える必要があります。いま話しているのは決済処理アプリですが、ユーザーは誰でしょうか？ユーザーは、ファーマーズマーケットでブレスレットを販売する友だちですか？それとも、世界中から時間を問わずにあなたに向けてトランザクションを投げかける Fortune 500 企業ですか？この 2 つの状況はまったく異なります。言いたいことが伝わっているでしょうか？

Brian: OK、この具体例は面白そうですね。ここで重要となるのは常に、ビジネスや目標に関するトレードオフですよね。

Steve: そのとおりです。

Brian: 把握するうえで何か経験則のようなものはありますか？たとえば、ビジネスではお金と時間が重視されます。しきいの間を行き来するときの金銭的、時間的コストがどの程度かをどう把握できますか？

Steve: 良いデータが十分にないのですが、感覚として、システムに 9 を加えるたびに、その前に 9 を加えたときの 10 倍の費用が発生するというのが経験則です。ですから、ノートパソコンで実行されていて、カバーを閉じると利用不可能になるような可用性が 90% の状態から、単一の VM が 99% や 99.9% の可用性で実行されているクラウドに移行する場合、さらに労力が必要になります。考え方としては、9 を加えるたびに 10 倍ということです。ですから-

Brian: 非常に大きくなります。

Steve: そうですね。ものすごいことです。

Carter: このようなシンプルでヒューリスティックな考え方は好きなのですが、まだうまく把握できていません。たとえば、インターネットです。インターネットの信頼性はどの程度でしょうか？ウェブブラウジングなどの信頼性も、9 の数のような形で表せるでしょうか？信頼性はどの程度でしょう？

Steve: そうですね。良い質問です。これまで、スマートフォンの電源をオフにしたことはありますか？

Carter: めったにないですが、あります。

Steve: そうですね。バッテリーが切れることもありますし、スマートフォンの接続が失われることもあります。インターネットにつながらない場所に行ったこともありますよね。

Carter: ありますね。

Steve: ですよね？スマートフォンでインターネットを利用できるという 100% の保証はありません。そのような考え方に基づけば、自分のためだけのシステムをクラウドで構築するのであれば、99.999% の信頼性を実現するための投資は行わないでしょう。というのも、そのサービスへの接続は、自分のスマートフォンや基地局などを介して、あるいは、場合によってはトンネルを介してなされるものだからです。

Steve: では、なぜ 99.9% のトンネルのために 99.999% のサービスを作るのでしょうか？私たちが高可用性の確保から始める理由は、そのようなサービスのほとんどが、データセンター内のサーバー間通信のためのものであり、その接続性は、パソコンやスマートフォンとサービス間の接続性よりもずっと優れているためです。また、たいていの場合ユーザーは複数存在します。私からサービスへの接続性が良くないとしても、その時点における自分以外のユーザーのほとんどの接続性は良好であるはずです。

Steve: つまり、そのようなハイエンドのサービスを実現するためには、全体像を考える必要があるということです。ユーザーは誰でしょうか？何人のユーザーがいるでしょうか？ユーザーがそのシステムを利用可能であると期待する頻度はどの程度でしょうか？また、もう一つ考慮する必要があるのは、サービスやビジネスというのは、多数の異なるサービスで構成されている可能性が高いことです。サービスやユーザーがヒットする可能性のあるエンドポイントが多数ある場合、その中にはきわめて重要になるものがあるでしょうし、重要性がずっと低いものもあるでしょう。

Steve: 私が新たにアカウントを申し込むとして、その時にダウンしていたとしても、再試行できます。大したことではありません。ですが、秒あたりで数千単位のトランザクションを送信するとして、かつ送金を要求するようなフローは、アカウント登録フローよりもずっと重要になります。言いたいことは伝わっていますよね？

Brian: ええ、わかりました。私たちは、信頼性に乏しい部品のレイヤで、より信頼性に優れたシステムを構築しています。それを行う必要があるのは、多数のユーザーがいるためです。これについては少し話しましたが、VM の信頼性はドキュメントを見れば大まかにわかります。ただ、その上に何か構築するような場合に、構築した特定のパターンの信頼性をどのように知ればよいでしょうか？たとえば、サービスなどの前面にあるロードバランサなどでです。

Steve: そうですね。良い質問です。私の知る限りですが、優れたほとんどのビジネスは、単一の VM 上で実行されてはいません。ただ一つではないということです。また、クラウドプロダクトには数多くの種類があり、Pub/Sub やデータベースなど、さまざまなものがあります。そして、クラウドを使用する会社のアーキテクト、デザイナー、エンジニアの仕事は、私たちがアーキテクチャと呼ぶものを考え出すことです。これは、互いに連携する種々のサービスをひとまとめにすることで、たとえば、コンピューティングプラットフォームなどにコードを入れることなどが含まれます。

Steve: 他には、データベースやデータストアなどにスキーマを入れることもあります。メッセージを渡すシステムなどもあるでしょうし、メッセージキューを定義しなければならない場合もあります。これがアーキテクチャになります。このアーキテクチャでのポイントは、多種多様なコンポーネントを、ものすごい数の方法で組み合わせられることです。その中には、破滅的な結果になるものもありますし、うまく機能しないものもあります。先ほどの質問は、優れたものを構築できているかを知る方法についてですよね。最適な手法は、その他のソフトウェア開発と同様によく知られたパターンを利用することです。

Steve: コンピュータサイエンスには、このような設計パターンがありますが、クラウドアーキテクチャにおいても、同様な設計パターンがあります。今年の、今から少し前に公表された論文があるのですが、その論文は、クラウドのデプロイアーキタイプに関するものです。6 から 8 パターンくらいのモデルが紹介されていて、シンプルなことから始めるやり方、1 つのリージョンに 1 つのものを構築して、そこからビルドアップするといったやり方などが紹介されています。サービスのスタック、たとえばウェブサーバーとデータベースからなるスタックを 1 つのリージョン、別のスタックを別のリージョン、そしてその 2 つの前面にロードバランサを配置するといったアーキテクチャも一般的です。

Steve: そして、そこからさらに複雑化する可能性もあるでしょう。これら 2 つのスタック間で自動のフェイルオーバーなどを構築する場合もあります。また、ホットとコールド、ホットとウォーム、ホットとホットで用意するパターンがありますし、2 つより多いスタックになることもありえます。さまざまなデプロイメントを用意して、そのすべてを常時アクティブにする場合もあり、それらすべてでユーザーに料金を請求する場合もあります。その論文にぜひ目を通してみてください。GCP アーキテクチャに特化した話ではなく、パターンが記載されていて、そのアーキタイプで何が得られるかがわかります。

Carter: 良いですね。システムの構築、設計に関する一般的原則については、ぜひ学びたいと思っています。その論文を確認したいと思います。ただ、このことに関連して、以前に話された、抽象度を下げるということを思い出しました。たとえばですが、自分自身と友だち向けだった決済処理アプリで、初めての大口顧客を獲得したとしましょう。その顧客から何千もの領収書、請求書が私のもとに送信されるようになったとして、現状のサービスのレベルから、この新たな需要を満たせるだけのレベルに移行するにはどうすればよいでしょうか？

Steve: 現実の問題に当てはめるのは良いことです。先ほど話してもらった、少ないユーザーから開始して、徐々に成長させ、ビジネス契約を結ぶユーザーを増やしていくというパターンについてですが、これは誰にとっても当てはまる一般的な手法です。これがビジネスが成長する仕組みであり、正しい方法です。構築に 15 年を費やしてから、最初のユーザーを獲得したいとは思いませんよね。顧客からの需要に合わせて成長させるのは、正しいやり方です。

Steve: 大企業と実際に契約を締結して、99.999% の可用性を契約に盛り込むのであれば、私たちがレジリエンスエンジニアリングや信頼性エンジニアリングと呼ぶものが必要になります。これはつまり、私たちがプラットフォームと呼ぶものを構築することで、これが機能のプラットフォームになります。この機能というのは技術的なもので、コードをサービスに迅速、効果的、安全にデプロイできる機能などが該当します。たとえば、CICD のことは知っているでしょうが、CICD パイプラインとは、プラットフォーム内の一連の機能です。

Steve: その他は、オブザーバビリティとモニタリングです。これは、システムで何が起きているかの判断や、遅延している要素がなぜそうなっているのかを把握する機能です。グラフを見て詳細を確認し、リアルタイムで実行されているシステムのトレースやプロファイルを確認して、それを理解し、水面下で何が起きているかをチームで共有して、自由に使えるツールを利用可能な状態にすること。これらはすべて、プラットフォームの中に存在するものです。チームとして機能を構築して、ものすごく複雑なシステムを実行するわけです。機能があればあるほど、成功の可能性は高まります。

Brian: つまり、大企業から送信されるリクエストを処理する場合に、下流にあるものすべてが同程度に信頼性が高い必要があるということですか？

Steve: それは違います。これも面白いことなのですが、ビジネスで最も重要となるのは正面のドアですよね。私たちが大企業と契約していて、何かが私たちに送信されてきたら、ある一定の時間内にレスポンスを返す必要があります。ですが、API の背後にあるデータベースが 99.9999% である必要性や、そのデータベースが配置されているインフラストラクチャが 99.99999% である必要性、その背後の電源がさらに高信頼性である必要はあるでしょうか？

Steve: そのようなことはありません。これは朗報と言えます。より信頼性に優れたコンポーネントを、信頼性の劣るコンポーネントの上に構築できるということです。これは、達成できる一般的な抽象化のようなものです。ですから、正面のドアの可用性を 99.999% にする際、バックエンドの可用性を 99.99% や 99.9% にしても許されます。これは、レジリエンス機能を組み込むことで達成できます。システムに再試行の機能を加えることが、簡単な方法の一つです。

Steve: たとえば、フロントエンドが利用可能で、バックエンドが一時的に利用不可能な状態だとします。フロントエンドがバックエンドにリクエストを送信してエラーが発生した場合に、契約を結んでいるユーザーに「何が起きたかわかりませんが、問題があります」というレスポンスを返すのではなく、一定の時間、たとえば 200 ミリ秒などの時間だけ待ってから、再試行します。それでもうまくいかない場合は、もう少し長い時間待ちます。契約上の時間的制限を超過しない範囲内であれば、いつまでも待つことができます。待った後でも適切なレスポンスを返すことは可能ですし、ユーザーはそれを正常とみなします。

Steve: これは、抽象化レイヤの背後のエラーを隠すもう一つの手法です。基本的には、時間を犠牲に信頼性を実現するということです。ビジネスでこれが許容されるのであれば、ぜひ実行してみてください。これは、使える手法のうちの一つです。

Carter: 不完全であることを想定して計画するという考えは良いですね。前にも話しましたが、さまざまなことがありますよね。単一障害点のような地理的なものや、時間のトレードオフのような時間的要素もあります。私が関心をひかれるのは、多くのことがここに絡むのではないかということです。人間のチームが絡むという話もしましたし、あなた自身も SRE です。

Carter: これは、テクノロジーだけの話ではない気がしていて、そこが気になっています。信頼性に関しては人間などその他の要素が絡むと思うのですが、それについて少し説明をお願いします。

Steve: そうですね。大規模なシステムというと、人間、プロセス、テクノロジーの話になることが多いですよね。ということからこれはとても良い例です。システムを理解、改善、構築できるようにすること。これは人間が行いますよね？そこで Google が考え付いたモデルが、SRE と呼ばれるものです。システムを構築し、それをスケーリングするとともに人間を疲れ果てさせないようにするために Google が利用している多くの原則が盛り込まれています。そして、まったく異なるシステムということから、Google が社内でこれまで SRE の取り組みで実践した具体的事項は、ユーザーが行うことには直接適用されません。

Steve: ユーザーは、ウェブ検索をオンボードで実行しているわけではなく、Kubernetes やクラウドで決済処理アプリを実行しています。ただし原則は同じで、どのような場所にも一貫した形で適用できます。このようなツール、プロセス、人々の働き方に関する文化が、SRE としてひとまとめにされています。これについて解説している本は数多くあり、ますます一般的になってきています。

Brian: 素晴らしいです。SRE ブックと先ほど説明のあった論文については、リンクを張っておきます。ここまでで、アプリに新たに 9 を加えることに関して、人間、プロセス、技術的要素に加え、信頼性パターンについて触れました。前回の VM の抽象化の回で話したように、これらパターンの一部は、システムに組み込まれますよね。そして、アプリアーキテクチャそのもので処理しなければならない場合もあります。そうですよね？

Steve: そうです。構築するか購入するかというのはよくある話です。このようなシステムの多くで、プラットフォームの外に出るということです。機能に関してたとえば、数年前に購入したオンプレミスのマシン上で独自のソフトウェアを実行している場合に、ライブマイグレーションはできないでしょう。ビルドできますが、ある程度の時間がかかります。しかし、そうではなく、クラウドに移行するのであれば、この機能を獲得できます。プロダクトからすぐに利用できる機能というのは数多くあり、これをプラットフォームで活用できます。これはすぐにできることです。

Steve: 他にも、たとえばレイヤ 7 ロードバランサ、グローバル L7 ロードバランサがあれば、あるリージョンからトラフィックを吸い取って、別のリージョンに魔法のように送信できます。これは素晴らしいことです。これを昔ながらのインターネットで達成することは困難です。それは、さまざまな自律システム、BGP、DNS などの煩雑な要素を扱う必要があるためです。ところが、Google の L7 ロードバランサであれば簡単に行えます。Google がサービス全体で使用しているフロントエンドテクノロジーを、すぐに利用できる一連の巨大なシステムとして活用できるのです。

Carter: Steve、Brian、どうもありがとう。SRE の原則や、信頼性の考え方について深く知ることができました。人間、プロセス、テクノロジーや、非抽象的または抽象度の低いアーキテクチャ構築についてよく学ぶことができました。ありがとう。さまざまなパターンを紹介する論文については確認したいと思います。また、これを視聴している方で、この論文を確認した方がいれば、気に入った点や気に入らなかった点をコメントでお知らせください。ありがとうございました。

–

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

デベロッパー