オートスケーラー ツールは柔軟性を考慮して設計されており、運用チームとアプリケーション チーム間にある、従来の責任分担に対応できます。Spanner インスタンスの自動スケーリングを構成する責任は、1 つのオペレーション チームで一元管理することも、それらの Spanner インスタンスによって処理されるアプリケーションに近いチームに分散することもできます。
このドキュメントは、次のドキュメントを含むシリーズの一部です。
このシリーズは、運用上のオーバーヘッドを削減し、Cloud Spanner のデプロイコストを最適化したいと考える、IT、オペレーション、サイト信頼性エンジニアリング（SRE）のチームを対象としています。
このページでは、要件に応じて Autoscaler を Cloud Run 関数にデプロイする 3 つの方法について説明します。
- プロジェクト別のデプロイ トポロジ。オートスケーラー インフラストラクチャは、自動スケーリングを必要とする Spanner と同じプロジェクトにデプロイされます。このトポロジは、独自のオートスケーラー構成とインフラストラクチャを自分たちで管理したい独立したチームに適しています。また、プロジェクトごとのデプロイ トポロジは、オートスケーラーの機能をテストする出発点としても有用です。
- 集中デプロイ トポロジ。1 つのプロジェクトにオートスケーラー ツールがデプロイされ、異なるプロジェクトの Spanner インスタンスを 1 つ以上管理します。このトポロジは、1 つ以上の Spanner インスタンスの構成とインフラストラクチャを管理する一方で、オートスケーラーのコンポーネントと構成を一元化したいチームに適しています。一元化されたトポロジでは、オートスケーラー プロジェクトに加えて、第二のプロジェクトを設定します。このチュートリアルでは、これをアプリケーション プロジェクトと呼びます。アプリケーション プロジェクトは、Spanner を含むアプリケーション リソースを保持します。
- 分散デプロイ トポロジ。ほとんどのオートスケーラー インフラストラクチャが 1 つのプロジェクトにデプロイされますが、一部のインフラストラクチャ コンポーネントは、異なるプロジェクトで自動スケーリングされる Spanner インスタンスを使用してデプロイされます。このトポロジは、複数のチームがある組織に適しています。Spanner インスタンスを所有するチームは、インスタンスのオートスケーラー構成パラメータのみを管理し、残りのオートスケーラー インフラストラクチャは中央のチームが管理します。
デプロイと管理が容易なサーバーレス
このモデルでは、Autoscaler ツールは、Cloud Run functions、Pub/Sub、Cloud Scheduler、Firestore などのサーバーレスで管理の手間が少ないツールのみを使用して構築されます。 Google Cloud これにより、Autoscaler ツールの実行コストと運用上のオーバーヘッドが最小限に抑えられます。
組み込みの Google Cloud ツールを使用することで、オートスケーラー ツールは認証と認可に Identity and Access Management（IAM）を活用できます。
構成
オートスケーラー ツールは、Cloud Scheduler で定義された構成を使用して Spanner インスタンスを管理します。複数の Spanner インスタンスを同じ間隔でポーリングする必要がある場合は、同じ Cloud Scheduler ジョブでそれらを構成することをおすすめします。各インスタンスの構成は JSON オブジェクトとして表されます。1 つの Cloud Scheduler ジョブで 2 つの Spanner インスタンスを管理する構成の例を次に示します。
[
{
"projectId": "my-spanner-project",
"instanceId": "my-spanner",
"scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
"units": "NODES",
"minSize": 1,
"maxSize": 3
},
{
"projectId": "different-project",
"instanceId": "another-spanner",
"scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
"units": "PROCESSING_UNITS",
"minSize": 500,
"maxSize": 3000,
"scalingMethod": "DIRECT"
}
]
Spanner インスタンスでは、異なる Cloud Scheduler ジョブの複数の構成を保持できます。たとえば、1 つのインスタンスには、通常運用に対する線形方式のオートスケーラー構成を保持できますが、それに加えて、計画されたバッチ ワークロード用に直接方式による別のオートスケーラー構成を保持することもできます。
Cloud Scheduler ジョブが実行されると、Pub/Sub メッセージがポーリング Pub/Sub トピックに送信されます。このメッセージのペイロードは、同じジョブに構成されたすべてのインスタンスに対する構成オブジェクトの JSON 配列です。構成オプションの一覧は、Poller README ファイルをご覧ください。
プロジェクト トポロジ
プロジェクトごとのトポロジのデプロイでは、自動スケーリングが必要な Spanner インスタンスのプロジェクトごとに、オートスケーラー コンポーネントの独立したデプロイが設定されています。このトポロジは、独自のオートスケーラー構成とインフラストラクチャを自分たちで管理したい独立したチームに適しています。また、Autoscaler ツールの機能をテストするための出発点としても役立ちます。
次の図は、プロジェクトごとのデプロイの概念図を示しています。
前述の図に描かれたプロジェクトごとのデプロイには、次のような特徴があります。
- アプリケーション 1 とアプリケーション 2 の 2 つのアプリケーションがそれぞれ固有の Spanner インスタンスを使用します。
- Spanner インスタンス（A）は、それぞれのアプリケーション 1 とアプリケーション 2 プロジェクトに存在します。
- 独立したオートスケーラー（B）が各プロジェクトにデプロイされ、プロジェクト内のインスタンスの自動スケーリングが制御されます。
プロジェクトごとにデプロイするメリットとデメリットは次のとおりです。
メリット:
- 最もシンプルな設計: プロジェクトごとのトポロジは、3 つのトポロジの中で最もシンプルな設計です。すべてのオートスケーラー コンポーネントが、自動スケーリングされる Spanner インスタンスと一緒にデプロイされます。
- 構成: スケジューラ パラメータの制御機能は、Spanner インスタンスを所有するチームに属しているので、一元化または分散されたトポロジよりも、オートスケーラー ツールをチームのニーズに合わせて自由に適応させることができます。
- インフラストラクチャの責任の明確な境界: プロジェクトごとのトポロジの設計は、オートスケーラー インフラストラクチャに対する責任とセキュリティを明確に定めることになります。Spanner インスタンスのチームオーナーは、オートスケーラーのインフラストラクチャのオーナーでもあるためです。
デメリット:
- 全体的なメンテナンスが増える: オートスケーラー構成とインフラストラクチャは、各チームが担当しているため、社内全体ですべてのオートスケーラー ツールが同じアップデート ガイドラインに沿っているかを確認するのは難しい場合があります。
- 監査がより複雑になる: 各チームの管理レベルが高いため、一元化された監査が複雑になる可能性があります。
プロジェクトごとのトポロジを使用してオートスケーラーを設定する方法については、プロジェクトごとのデプロイのチュートリアルをご覧ください。
一元化されたトポロジ
プロジェクトごとのトポロジと同様に、一元化されたトポロジのデプロイでは、オートスケーラー ツールのすべてのコンポーネントが同じプロジェクトにあります。ただし、Spanner インスタンスは別々のプロジェクトに配置されています。このデプロイは、複数の Spanner インスタンスの構成とインフラストラクチャを、中央のオートスケーラー ツールの単一のデプロイから管理するチームに適しています。
次の図は、一元化されたプロジェクト デプロイの概要図を示しています。
上の図の一元的なデプロイでは、次の特徴があります。
- アプリケーション 1 とアプリケーション 2 の 2 つのアプリケーションがそれぞれ固有の Spanner インスタンスを使用します。
- Spanner インスタンス（A）は、それぞれのアプリケーション 1 とアプリケーション 2 プロジェクトに存在します。
- オートスケーラー（B）は、別のプロジェクトにデプロイされ、アプリケーション 1 とアプリケーション 2 の両方のプロジェクトにある Spanner インスタンスの自動スケーリングを管理します。
一元的なデプロイには次のメリットとデメリットがあります。
メリット:
- 一元化された構成とインフラストラクチャ: 単一チームが、スケジューラ パラメータとオートスケーラー インフラストラクチャを管理します。この手法は、規制が厳しい業界で役立つ可能性があります。
- 全体のメンテナンスが減少: メンテナンスとセットアップは、プロジェクトごとのデプロイよりも少ない労力で済みます。
- 一元化されたポリシーと監査: チーム間でのベスト プラクティスを規定し、実行することが容易になるかもしれません。監査も実行しやすくなるかもしれません。
デメリット:
- 一元化された構成: オートスケーラーのパラメータを変更する際は、変更をリクエストしているチームが Spanner インスタンスを所有していても、一元管理されたチームを経由する必要があります。
- 追加リスクの可能性: オートスケーラー インフラストラクチャが高可用性を念頭に置いて設計されている場合でも、一元化されたチーム自体が単一障害点になる可能性があります。
一元化されたトポロジを使用してオートスケーラーを設定する方法については、一元化されたデプロイの詳細なガイドをご覧ください。
分散トポロジ
分散トポロジのデプロイでは、自動スケーリングが必要な Cloud Scheduler インスタンスと Spanner インスタンスは同じプロジェクトにあります。オートスケーラー ツールの残りのコンポーネントは、一元管理のプロジェクト内に存在します。このデプロイは、ハイブリッドなデプロイです。Spanner インスタンスを所有するチームは、インスタンスのオートスケーラー構成パラメータのみを管理し、中央のチームが残りのオートスケーラー インフラストラクチャを管理します。
次の図は、分散プロジェクト デプロイの概要図を示しています。
上図に示すハイブリッド デプロイには、次の特徴があります。
- アプリケーション 1 とアプリケーション 2 の 2 つのアプリケーションが固有の Spanner インスタンスを使用します。
- Spanner インスタンス（A）は、アプリケーション 1 とアプリケーション 2 の両方のプロジェクトにあります。
- 各プロジェクト（アプリケーション 1 とアプリケーション 2）に、独立した Cloud Scheduler コンポーネント（C）がデプロイされます。
- 残りのオートスケーラー コンポーネント（B）は別のプロジェクトにデプロイされます。
- オートスケーラー ツールは、各プロジェクト内の独立した Cloud Scheduler コンポーネントによって送信された構成を使用して、アプリケーション 1 とアプリケーション 2 の両方のプロジェクトの Spanner インスタンスを自動スケーリングします。
フォワーダー関数
Cloud Scheduler では、同じプロジェクト内のトピックにのみメッセージをパブリッシュできます。そのため、分散トポロジでは、フォワーダー関数と呼ばれる中間コンポーネントが必要です。
フォワーダー関数は、Cloud Scheduler から Pub/Sub に公開されたメッセージを取得し、JSON 構文をチェックして、ポーラー Pub/Sub トピックに転送します。このトピックは、Cloud Scheduler の別のプロジェクトに属することができます。
次の図は、転送メカニズムに使用されるコンポーネントを示しています。
上の図に示すように、Spanner インスタンスは、Application 1 と Application 2 という名前のプロジェクト内にあります。
- Cloud Scheduler は、Spanner インスタンスと同じプロジェクトです。
（2a）Cloud Scheduler は、Application 1 と Application 2 プロジェクトのフォワーダー トピックにメッセージをパブリッシュします。
（2b）フォワーダー関数は、フォワーダー トピックからメッセージを読み取ります。
（2c）フォワーダー関数は、オートスケーラー プロジェクト内のポーリング トピックにメッセージを転送します。
ポーラー関数は、ポーリング トピックからメッセージを読み取り、ポーラーで説明するように、プロセスが続行されます。
分散デプロイには、次のメリットとデメリットがあります。
メリット:
- アプリケーション チームが構成とスケジュールを制御する: Cloud Scheduler は、自動スケーリングされる Spanner インスタンスと一緒にデプロイされるため、アプリケーション チームは構成とスケジューリングをより細かく制御できます。
- 運用チームによるインフラストラクチャの制御: オートスケーラー ツールのコア コンポーネントは一元的にデプロイされ、運用チームはオートスケーラー インフラストラクチャを制御することができます。
- 一元化されたメンテナンス: スケーリング インフラストラクチャは一元化され、オーバーヘッドが削減されます。
デメリット:
- 構成がより複雑になる: アプリケーション チームは、ポーリング トピックに書き込むサービス アカウントを提供する必要があります。
- 追加リスクの可能性: インフラストラクチャが高可用性を念頭に置いて設計されている場合でも、共有インフラストラクチャが単一障害点になる可能性があります。
分散トポロジを使用してオートスケーラーを設定する方法については、分散デプロイのチュートリアルをご覧ください。
次のステップ
- オートスケーラー ツールを GKE にデプロイする方法を学習する。
- Spanner の推奨しきい値について確認する。
- Spanner の CPU 使用率の指標とレイテンシの指標の詳細を確認する。
- Spanner スキーマ設計のベスト プラクティスで、ホットスポットを回避し、データを Spanner に読み込む方法を確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。