クラウド アプリケーションをパーティショニングして影響範囲を縮小し、グローバルなサービス停止を回避する
Karan Anand
Technical Program Management
John Lunney
Senior Staff Reliability Engineer
※この投稿は米国時間 2025 年 1 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。
Google Workspace のようなクラウド アプリケーションには、共同編集、可用性、セキュリティ、コスト効率といった利点があります。一方、クラウド アプリケーションのデベロッパーにとって、高可用性とクラウド アプリケーションの絶え間ない進化の両方を実現することは根本的に矛盾します。新しいコードの追加、構成の更新、インフラストラクチャの再配置など、アプリケーションに変更を加えると、バグが発生したり、サービスが停止したりする可能性があります。こうしたリスクは、サービスの停止を最小限に抑えながら、安定性と革新性のバランスを取らなければならないデベロッパーの課題となっています。
以前、Google Workspace サイト信頼性エンジニアリング チームは、容量を増やす必要があったため Google ドキュメントのレプリカを新しいデータセンターに移行したことがあります。ですが、膨大な関連データを移行したことでデータベースの主要インデックスに過剰な負荷がかかり、ドキュメントの新規作成機能が制限されてしまいました。幸い、迅速に根本原因を特定して問題を緩和することができました。それでも、このときの経験から、単純なアプリケーション変更がグローバルなサービス停止につながるリスクを減らすことは必要だと確信しています。
影響範囲を制限する
グローバルなサービス停止のリスクを低減するための Google のアプローチは、サービス スタックを垂直方向にパーティショニングすることにより、サービス停止の「爆発半径」（影響範囲）を制限することです。基本的な考え方は、アプリケーション サーバーとストレージを分離したインスタンス（「パーティション」）を実行することです（図 1）。各パーティションには、ユーザー リクエストをエンドツーエンドで処理するために必要なさまざまなサーバーがすべて含まれています。また、個々のプロダクション パーティションにはユーザーとワークロードが擬似的にランダムに混在するため、すべてのパーティションのリソース ニーズはほぼ同じになります。アプリケーション コードに変更を加える際は、一度に 1 つのパーティションに新しい変更をデプロイしていきます。不適切な変更があった場合、パーティション単位ではサービス停止が発生するかもしれませんが、アプリケーションがグローバルにサービス停止することはありません。
このアプローチを、カナリア手法のみを使った場合と比較してみましょう。カナリア手法では、新機能やコード変更を少数のユーザーにリリースしてから、残りのユーザーに展開します。この手法では、まず少数のサーバーに変更をデプロイしますが、問題の拡散を防ぐことはできません。たとえば、カナリア手法での変更により、デプロイ対象の全サーバーが使用しているデータが破損するというインシデントが生じたことがあります。パーティショニングを実行すれば、不適切な変更の影響は 1 つのパーティションに隔離され、そうした悪影響の伝播を防止できます。当然ですが、実際には両方のテクニックを組み合わせて、新しい変更を 1 つのパーティション内の数台のサーバーにカナリア手法でデプロイしています。
パーティショニングの利点
大まかに言って、パーティショニングには多くの利点があります。
-
可用性: 当初、パーティショニングを実行する主な理由は、サービスの可用性を向上させ、グローバルなサービス停止を回避することでした。グローバルなサービス停止が発生すると、サービス全体が停止（ユーザーが Gmail にログインできないなど）したり、重要なユーザー機能が停止（ユーザーがカレンダーの予定を作成できないなど）したりする可能性があります。それでも、パーティショニングの信頼性の利点を定量化することは難しいかもしれません。グローバルなサービス停止が生じることは比較的まれなので、しばらく生じない場合、それはパーティショニングのおかげかもしれなければ、単に運がよいだけかもしれないからです。とは言え、サービス停止を 1 つのパーティションにとどめられたケースは何度か経験しています。パーティションがなければ、グローバルなサービス停止に発展していたことでしょう。
-
柔軟性: Google は、システムへの多数の変更を、データを使ったテストで評価しています。UI 要素の変更など、ユーザー向けの多くのテストでは、別個のユーザー グループを使用します。たとえば Gmail では、メールのメッセージ本文をメッセージのメタデータと一緒にインラインで保存するオンディスク レイアウトを選択することも、複数のディスク ファイルに分割するレイアウトを選択することもできます。適切な判断は、ワークロードの微妙な側面によって変わります。たとえば、メッセージのメタデータと本文を分離すると、一部のユーザー操作の待ち時間は短縮されるかもしれませんが、本文とメタデータ列の結合を実行するために、バックエンド サーバーではより多くのコンピューティング リソースが必要となります。パーティショニングを実行すれば、このような選択による影響を、分離されたコンテナ環境で簡単に評価できます。
-
データの保管場所: Google Workspace では、企業のお客様はデータを特定の地域に保存するよう指定できます。パーティショニングされていない、これまでのアーキテクチャでこのような保証を提供することは困難でした。なぜなら、サービスは、待ち時間を短縮し、利用可能な容量を最大限に活用するためにグローバルに複製するよう設計されていたからです。
課題
パーティショニングの導入には利点もありますが、課題もいくつかあります。場合によっては、これらの課題により、パーティショニングされていない設定からパーティショニングされた設定への移行が難しくなったり、リスクが高くなったりすることがあります。また、パーティショニングした後も課題が残る場合があります。Google が考える問題点を以下に挙げます。
-
すべてのデータモデルを簡単にパーティショニングできるとは限らない: たとえば、Google Chat ではユーザーとチャットルームの両方を複数のパーティションに割り当てる必要があります。もちろん、パーティション間でトラフィックが生じないよう、チャットとチャット メンバーを 1 つのパーティションに割り当てるのが理想的です。ただし、実際にこれを行うことは困難です。複数のチャットルームとユーザーが 1 つのグラフの作成に使用されます。ユーザーは多数のチャットルームに参加し、チャットルームには多数のユーザーが参加します。最悪の場合、このグラフに 1 人のユーザーという 1 つの連結成分しかない可能性もあります。仮に 1 つのグラフを複数のパーティションに分けたとしても、すべてのユーザーが各自のチャットルームと同じパーティションに割り当てられるよう保証することはできません。
-
稼働中のサービスのパーティショニングには注意が必要である: ほとんどのサービスは稼働前にパーティショニングを行います。そのため、パーティショニングを導入することは、稼働中のサービスのルーティングとストレージ設定を変更することを意味します。最終的な目標がより高い信頼性であったとしても、稼働中のシステムでこのような変更を行うことは、しばしばサービス停止の原因となり、リスクを伴います。
-
サービス間でパーティションにずれがある: Google の各サービスは頻繁に相互通信を行います。たとえば、カレンダーの予定に新しい人物が追加されると、カレンダー サーバーは Gmail の配信サーバーにリモート プロシージャ コール（RPC）を行い、新しい招待者にメール通知を送信します。同様に、カレンダーの予定にビデオ通話リンクがある場合、カレンダーは Meet サーバーと通信して会議 ID を確認する必要があります。サービス間でもパーティショニングの利点を受けられると理想的です。ただし、サービス間でパーティションを調整することは大変です。主な理由は、使用するパーティションを決定する際、サービスによって異なるエンティティ タイプを使用する傾向があるためです。たとえば、カレンダー パーティションではカレンダー オーナーが使用され、Meet パーティションでは会議 ID が使用されます。そのため、サービス間でのパーティションの明確なマッピングが存在しないのです。
-
パーティションはサービスより小規模である: 最新のクラウド アプリケーションは、数百～数千のサーバーによって提供されています。トラフィックが飽和したサーバーは一般的にパフォーマンスが低下するため、トラフィックの急増に耐えられるよう、サーバーはフル稼働より低い稼働率で稼働させます。500 台のサーバーがあり、それぞれの CPU 使用率の目標値を 60% に設定している場合、負荷の急増を吸収するために 200 台の予備サーバーを実質的に用意していることになります。パーティション間でフェイルオーバーが行われないため、各パーティションで使用される予備容量はかなり少なくなります。パーティショニングをしていない設定では失われた容量を吸収する余裕が十分にあるため、サーバーがいくつかクラッシュしても気付かない可能性があります。ただし、より小規模なパーティションでは、このようなクラッシュにより、利用可能なサーバー容量のかなりの部分が影響を受け、残りのサーバーが過負荷になる可能性があります。
重要ポイント
サービス スタックをパーティショニングすることで、ウェブ アプリケーションの可用性を高めることができます。パーティション間でフェイルオーバーが行われないため、これらのパーティションは分離されます。ユーザーとエンティティは、リスク許容度順に変更を展開できるよう、固定された方法でパーティションに割り当てます。このアプローチにより、不適切な変更は 1 つのパーティションにしか影響しないことを確信しながら、一度に 1 つのパーティションに変更を展開していくことができます。さらに、そのパーティションに組織のユーザーしか含まれていなければ理想的です。
要するに、パーティショニングとは、より強力かつ信頼性の高いサービスをユーザーに提供しようとする取り組みを支援するものです。皆様のサービスにも適用できるかもしれません。たとえば、地域別パーティショニングをすぐに利用できる Spanner を使用して、アプリケーションの可用性を高めることができます。地域別パーティショニングのベスト プラクティスについては、こちらをご覧ください。
参照
-テクニカル プログラム マネジメント Karan Anand
-シニアスタッフ信頼性エンジニア John Lunney
