このページでは、Spanner 用のオートスケーラー ツール（Autoscaler）について説明します。このオープンソースのツールは、Spanner のコンパニオン ツールとして使用できます。このツールを使用すると、使用中の容量に基づいて、1 つ以上の Spanner インスタンスのコンピューティング容量を自動的に増減できます。
Spanner でのスケーリングの詳細については、Spanner の自動スケーリングをご覧ください。Autoscaler ツールのデプロイについては、以下をご覧ください。
このページでは、オートスケーラーの特徴、アーキテクチャ、構成、デプロイ トポロジについて説明します。このシリーズに続くトピックでは、さまざまなトポロジーでのオートスケーラーのデプロイについて説明します。
オートスケーラー
Autoscaler ツールは、Spanner デプロイの使用率とパフォーマンスを管理するのに役立ちます。コスト管理とパフォーマンス ニーズのバランスをとるために、オートスケーラーはインスタンスをモニタリングし、自動的にノードや処理単位を追加または削除して、次のパラメータに収まるようにします。
- CPU 使用率の推奨最大値。
-
に、構成可能なマージンを加減した値。
Spanner デプロイの自動スケーリングを使用すると、インフラストラクチャが自動的に調整とスケーリングを行い、ユーザーがほとんどまたはまったく介入せずに負荷要件を満たすことができます。自動スケーリングにより、プロビジョニングされたインフラストラクチャのサイズも適正化され、費用の削減に役立ちます。
アーキテクチャ
このセクションでは、オートスケーラーのコンポーネントとそれぞれの目的について詳しく説明します。
オートスケーラー ツールのアーキテクチャは、Cloud Scheduler、2 つの Pub/Sub トピック、2 つの Cloud Run functions、Firestore で構成されています。Cloud Monitoring API を使用して、Spanner インスタンスの CPU 使用率とストレージ指標を取得します。
Cloud Scheduler
Cloud Scheduler を使用して、Autoscaler ツールが Spanner インスタンスのスケーリング指標のしきい値を確認する頻度を定義します。Cloud Scheduler のジョブは、単一または複数のインスタンスを同時にチェックできます。ジョブのスケジュールは、いくつでも定義できます。
Cloud Run Functions の Poller 関数
Cloud Run Functions の Poller 関数は、1 つ以上の Spanner インスタンスの時系列指標の収集と処理を担当します。Poller は、各 Spanner インスタンスの指標データを前処理して、最も関連するデータポイントのみを評価し、Cloud Run Functions の Scaler 関数に送信します。Cloud Run Functions の Poller 関数によって行われた前処理により、リージョン、デュアルリージョン、マルチリージョンの Spanner インスタンスのしきい値の評価プロセスが簡単になります。
Cloud Run Functions の Scaler 関数
Cloud Run Functions の Scaler 関数は、Cloud Run Functions の Poller 関数から受信したデータポイントを評価し、ノードや処理単位の数の調整が必要かどうかを判断します。必要な場合はその数で調整します。Cloud Run Functions は、指標の値としきい値（許容されるマージンも考慮）を比較して、構成されたスケーリング メソッドに基づいてノードや処理単位の数を調整します。スケーリング メソッドの詳細については、オートスケーラーの機能をご覧ください。
オペレーション フロー
このセクションでは、次のアーキテクチャ図に示すオートスケーラー ツールの運用モデルについて詳しく説明します。
- 自動スケーリング ジョブのスケジュール、時間、頻度を Cloud Scheduler で定義します。
- Cloud Scheduler は、定義したスケジュールで、1 つ以上の Spanner インスタンスのオートスケーラー ツール構成パラメータを持つ JSON ペイロードを含むメッセージを、ポーリングの Pub/Sub トピックに push します。
- メッセージがポーリング トピックに公開されると、メッセージを処理するために Cloud Run Functions の Poller 関数のインスタンスが作成されます。
- Cloud Run Functions の Poler 関数がメッセージ ペイロードを読み取り、Cloud Monitoring API にクエリを実行して、各 Spanner インスタンスの使用率指標を取得します。
- メッセージに列挙されている Spanner インスタンスごとに、Poller 関数は 1 つのメッセージをスケーリング Pub/Sub トピックに push し、特定の Spanner インスタンスに対して評価する指標と構成パラメータを格納します。
Scaler トピックに push されたメッセージごとに、Cloud Run Functions の Scaler 関数は次の処理を行います。
- Spanner インスタンスの指標と構成可能なしきい値を比較します（構成可能なマージンも考慮）。
マージンは、自分で構成することも、デフォルト値を使用することもできます。 1. インスタンスをスケーリングするかどうかを判断します。 1. 選択したスケーリング方式に基づいて、インスタンスをスケーリングする必要があるノードや処理単位の数を計算します。
Cloud Run Functions の Scaler 関数は、インスタンスが Firestore から最後にスケーリングされた時刻を取得して現在の時刻と比較し、クールダウン期間に基づいてスケールアップまたはスケールダウンが許可されているかどうかを確認します。
構成されたクールダウン期間が経過すると、Cloud Run Functions の Scaler 関数は Spanner インスタンスをスケールアップまたはスケールダウンするためのリクエストを送信します。
フロー全体を通して、オートスケーラー ツールは推奨事項とアクションの概要を Cloud Logging に書き込み、トラッキングと監査を行います。
選択したデプロイ トポロジに関係なく、Autoscaler ツールの全体的なオペレーションは変わりません。
オートスケーラーの機能
このセクションでは、オートスケーラー ツールの主な機能について説明します。
複数のインスタンスを管理する
Autoscaler ツールは、複数のプロジェクトにまたがる複数の Spanner インスタンスを管理できます。マルチリージョン インスタンス、デュアルリージョン インスタンス、リージョン インスタンスには、スケーリング時に使用される使用率のしきい値が異なります。たとえば、マルチリージョン デプロイとデュアルリージョン デプロイは高優先度 CPU の使用率 45% でスケーリングされ、リージョン デプロイは高優先度 CPU の使用率 65% でスケーリングされます。両方とも、マージン分のプラスまたはマイナスが許容されます。さまざまなスケーリングのしきい値の詳細については、高い CPU 使用率に関するアラートをご覧ください。
独立した構成パラメータ
自動スケーリングの Spanner インスタンスごとに 1 つ以上のポーリング スケジュールを設定できます。各ポーリング スケジュールには固有の構成パラメータのセットがあります。
これらのパラメータは、次の要因によって変動します。
- インスタンスの増減を制御するノードや処理単位の最小数と最大数。これはコストの管理に役立ちます。
- ワークロードに固有の Spanner インスタンスを調整するのに使用されるスケーリング メソッド。
- Spanner がデータ分割を管理できるようにするためのクールダウン期間。
ワークロードごとに異なるスケーリング手法
オートスケーラー ツールには、Spanner インスタンスのスケールアップとスケールダウンに対応する 3 つのスケーリング メソッド（段階的、線形、直接）があります。それぞれのメソッドは、さまざまな種類のワークロードをサポートするように設計されています。別々のポーリング スケジュールを作成する際、自動スケーリングされる Spanner インスタンスごとに 1 つ以上のメソッドを適用できます。
段階的
段階的スケーリングは、ワークロードに小規模または複数のピークがある場合に便利です。単一の自動スケーリング イベントで、これらをスムーズに調整できる機能をプロビジョニングできます。
次のグラフは、負荷の増減に複数のステップがある負荷パターンを示しています（ステップごとに小さなピークがあります）。このパターンは、段階的なメソッドに適しています。
この方法では、負荷のしきい値を超えると、構成可能な固定値を使用してノードや処理単位がプロビジョニングまたは削除されます。たとえば、スケーリング アクションごとに 3 つのノードが追加または削除されます。構成を変更することで、いつでも容量の増減を行うことができます。
線形
線形スケーリングは、負荷パターンが徐々に変化する場合や大きなピークが少ない場合に適しています。この方法では、使用率がスケーリングしきい値を下回った状態を維持するために必要なノードや処理ユニットの最小数を計算します。 スケーリング イベントごとに追加または削除されるノードや処理単位の数は、固定されたステップ量に制限されません。
次のグラフの負荷パターンは、負荷の急激な増加と減少を示しています。前のグラフと同様に、これらの変動は識別可能なステップにグループ化されません。このパターンは、線形スケーリングを使用すると簡単に処理できます。
オートスケーラー ツールは、観測された使用率と使用率のしきい値に対する比率を使用して、現在の総数からノードまたは処理単位を追加または減算するかどうかを計算します。
新しいノード数や処理ユニット数の計算式は次のとおりです。
newSize = currentSize * currentUtilization / utilizationThreshold
直接
直接接続スケーリングにより、容量がすぐに増加します。この方法は、開始時刻がわかっているスケジュールで、事前に定義された数より多いノード数が定期的に必要になるバッチ ワークロードをサポートすることを目的としています。この方法は、スケジュールで指定されたノードや処理単位の最大数までインスタンスをスケーリングします。これは、線形または段階的な方法に加えて使用する必要があります。
次のグラフは、想定される負荷の大幅な増加を示しています。これは、オートスケーラーが直接メソッドで事前にプロビジョニングした容量です。
バッチ ワークロードが完了して使用率が通常のレベルに戻ると、構成に応じて、線形または段階的スケーリングが適用され、インスタンスが自動的にスケールダウンされます。
デプロイ方法
Autoscaler ツールは、個々のプロジェクトにデプロイすることも、管理する Spanner インスタンスと一緒にデプロイすることもできます。オートスケーラー ツールは柔軟性を考慮して設計されており、運用チームとアプリケーション チーム間にある、従来の責任分担に対応できます。Spanner インスタンスの自動スケーリングを構成する責任は、1 つのオペレーション チームで一元管理することも、それらの Spanner インスタンスによって処理されるアプリケーションに近いチームに分散することもできます。
各デプロイモデルについては、デプロイ トポロジで詳しく説明しています。
デプロイと管理が容易なサーバーレス
オートスケーラー ツールは、Cloud Run functions、Pub/Sub、Cloud Scheduler、Firestore などのサーバーレスで管理の手間が少ない Google Cloud ツールのみを使用して構築されます。これにより、Autoscaler ツールの実行コストと運用上のオーバーヘッドが最小限に抑えられます。
組み込みの Google Cloud ツールを使用することで、オートスケーラー ツールは認証と認可に IAM（IAM）を活用できます。
構成
オートスケーラー ツールには、Spanner デプロイメントのスケーリングの管理に使用できるさまざまな構成オプションがあります。以降のセクションでは、基本構成オプションと、より高度な構成オプションについて説明します。
基本構成
オートスケーラー ツールは、Cloud Scheduler で定義された構成を使用して Spanner インスタンスを管理します。複数の Spanner インスタンスを同じ間隔でポーリングする必要がある場合は、同じ Cloud Scheduler ジョブでそれらを構成することをおすすめします。各インスタンスの構成は JSON オブジェクトとして表されます。1 つの Cloud Scheduler ジョブで 2 つの Spanner インスタンスを管理する構成の例を次に示します。
[
{
"projectId": "my-spanner-project", "instanceId": "spanner1",
"scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
"units": "NODES", "minSize": 1, "maxSize": 3
},
{
"projectId":
"different-project", "instanceId": "another-spanner1", "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 メッセージが Polling Pub/Sub トピックに送信されます。このメッセージのペイロードは、同じジョブに構成された全インスタンスに対する構成オブジェクトの JSON 配列です。構成オプションの一覧は、Poller README ファイルをご覧ください。
詳細構成
オートスケーラー ツールには、Spanner インスタンスの管理のタイミングと方法をより細かくコントロールできる高度な構成オプションがあります。以降のセクションでは、これらのコントロールの一部を説明します。
カスタムしきい値
Autoscaler ツールは、次の負荷指標の推奨される Spanner しきい値を使用して、インスタンスに増減するノードや処理単位の数を決定します。
- 優先度の高い CPU
- 稼働平均 24 時間 CPU
- ストレージの利用率
Spanner 指標用のアラートを作成するで説明されているように、デフォルトのしきい値を使用することをおすすめします。ただし、いくつかのケースでは、オートスケーラー ツールが使用するしきい値を変更したい場合もあります。たとえば、低いしきい値を使用して、オートスケーラー ツール に高いしきい値より早く反応させることが可能です。この変更により、アラートが高いしきい値でトリガーされないようにできます。
カスタム指標
オートスケーラー ツールのデフォルト指標では、ほとんどのパフォーマンスとスケーリングのシナリオに対処できますが、スケールインとスケールアウトを行うタイミングを決定するために使用する独自の指標の指定が必要になることがあります。これらのシナリオでは、metrics プロパティを使用して、構成でカスタム指標を定義します。
余白
マージンは、しきい値の前後の上限と下限を定義します。オートスケーラー ツールは、指標の値が上限を超えているか、下限より小さい場合にのみ、自動スケーリング イベントをトリガーします。
このパラメータは、しきい値付近の小さいワークロードの変動で自動スケーリング イベントがトリガーされないようにし、オートスケーラーの操作で変動の発生回数を減らすことを目的としています。しきい値とマージンは、指標の値に応じて次のような範囲で定義します。
[threshold - margin, threshold + margin]
指標のマージン パラメータの指定はオプションであり、デフォルトでは、パラメータの前後に 5% のポイントが指定されます。
デプロイ トポロジ
オートスケーラー ツールをデプロイする場合は、以下のトポロジから、技術的な要件と運用上のニーズを満たす最適なトポロジを選択してください。
- プロジェクトごとのトポロジ: オートスケーラー インフラストラクチャは、自動スケーリングを必要とする Spanner と同じプロジェクトにデプロイされます。
- 一元化されたトポロジ: 1 つのプロジェクトにオートスケーラー ツールがデプロイされ、異なるプロジェクトの Spanner インスタンスを 1 つ以上管理します。
- 分散トポロジ: ほとんどのオートスケーラー インフラストラクチャが 1 つのプロジェクトにデプロイされますが、一部のインフラストラクチャ コンポーネントは、異なるプロジェクトで自動スケーリングされる Spanner インスタンスを使用してデプロイされます。
プロジェクト トポロジ
プロジェクトごとのトポロジのデプロイでは、自動スケーリングが必要な Spanner インスタンスのプロジェクトごとに、オートスケーラー コンポーネントの独立したデプロイが設定されています。このトポロジは、独自のオートスケーラー構成とインフラストラクチャを自分たちで管理したい独立したチームに適しています。また、Autoscaler ツールの機能をテストするための出発点としても役立ちます。
次の図は、プロジェクトごとのデプロイの概念図を示しています。
前述の図に描かれたプロジェクトごとのデプロイには、次のような特徴があります。
- アプリケーション 1 とアプリケーション 2 の 2 つのアプリケーションがそれぞれ固有の Spanner インスタンスを使用します。
- Spanner インスタンス（A）は、それぞれのアプリケーション 1 とアプリケーション 2 プロジェクトに存在します。
- 独立したオートスケーラー（B）が各プロジェクトにデプロイされ、プロジェクト内のインスタンスの自動スケーリングが制御されます。
プロジェクトごとのデプロイのより詳細な図については、アーキテクチャのセクションをご覧ください。
プロジェクトごとにデプロイするメリットとデメリットは次のとおりです。
メリット:
- 最もシンプルな設計: プロジェクトごとのトポロジは、3 つのトポロジの中で最もシンプルな設計です。すべてのオートスケーラー コンポーネントが、自動スケーリングされる Spanner インスタンスと一緒にデプロイされます。
- 構成: スケジューラ パラメータの制御機能は、Spanner インスタンスを所有するチームに属しているので、一元化または分散されたトポロジよりも、オートスケーラー ツールをチームのニーズに合わせて自由に適応させることができます。
- インフラストラクチャの責任の明確な境界: プロジェクトごとのトポロジの設計は、オートスケーラー インフラストラクチャに対する責任とセキュリティを明確に定めることになります。Spanner インスタンスのチームオーナーは、オートスケーラーのインフラストラクチャのオーナーでもあるためです。
デメリット:
- 全体的なメンテナンスが増える: オートスケーラー構成とインフラストラクチャは、各チームが担当しているため、社内全体ですべてのオートスケーラー ツールが同じアップデート ガイドラインに沿っているかを確認するのは難しい場合があります。
- 監査がより複雑になる: 各チームの管理レベルが高いため、一元化された監査が複雑になる可能性があります。
プロジェクトごとのトポロジを使用してオートスケーラーを設定する方法については、Spanner 用のプロジェクトごとまたは一元的なオートスケーラー ツールをデプロイするをご覧ください。
一元化されたトポロジ
プロジェクトごとのトポロジと同様に、一元化されたトポロジのデプロイでは、オートスケーラー ツールのすべてのコンポーネントが同じプロジェクトにあります。ただし、Spanner インスタンスは別々のプロジェクトに配置されています。このデプロイは、複数の Spanner インスタンスの構成とインフラストラクチャを、中央のオートスケーラー ツールの単一のデプロイから管理するチームに適しています。
次の図は、一元化されたプロジェクト デプロイの概要図を示しています。
上の図の一元的なデプロイでは、次の特徴があります。
- アプリケーション 1 とアプリケーション 2 の 2 つのアプリケーションがそれぞれ固有の Spanner インスタンスを使用します。
- Spanner インスタンス（A）は、それぞれのアプリケーション 1 とアプリケーション 2 プロジェクトに存在します。
- オートスケーラー（B）は、別のプロジェクトにデプロイされ、アプリケーション 1 とアプリケーション 2 の両方のプロジェクトにある Spanner インスタンスの自動スケーリングを管理します。
一元的なプロジェクト デプロイのより詳細な図については、Spanner にプロジェクトごとまたは一元化されたオートスケーラーをデプロイするをご覧ください。
一元的なデプロイには次のメリットとデメリットがあります。
メリット:
- 一元化された構成とインフラストラクチャ: 単一チームが、スケジューラ パラメータとオートスケーラー インフラストラクチャを管理します。この手法は、規制が厳しい業界で役立つ可能性があります。
- 全体のメンテナンスが減少: メンテナンスとセットアップは、プロジェクトごとのデプロイよりも少ない労力で済みます。
- 一元化されたポリシーと監査: チーム間でのベスト プラクティスを規定し、実行することが容易になるかもしれません。監査も実行しやすくなるかもしれません。
デメリット:
- 一元化された構成: オートスケーラーのパラメータを変更する際は、変更をリクエストしているチームが 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 インスタンスを自動スケーリングします。
一元的なプロジェクト デプロイのより詳細な図については、Spanner 用の分散オートスケーラー ツールのデプロイをご覧ください。
分散デプロイには、次のメリットとデメリットがあります。
メリット:
- アプリケーション チームが構成とスケジュールを制御する: Cloud Scheduler は、自動スケーリングされる Spanner インスタンスと一緒にデプロイされるため、アプリケーション チームは構成とスケジューリングをより細かく制御できます。
- 運用チームによるインフラストラクチャの制御: オートスケーラー ツールのコア コンポーネントは一元的にデプロイされ、運用チームはオートスケーラー インフラストラクチャを制御することができます。
- 一元化されたメンテナンス: スケーリング インフラストラクチャは一元化され、オーバーヘッドが削減されます。
デメリット:
- 構成がより複雑になる: アプリケーション チームは、ポーリング トピックに書き込むサービス アカウントを提供する必要があります。
- 追加リスクの可能性: インフラストラクチャが高可用性を念頭に置いて設計されている場合でも、共有インフラストラクチャが単一障害点になる可能性があります。
分散デプロイでオートスケーラーを設定する方法については、Spanner 用に分散オートスケーラー ツールをデプロイするをご覧ください。
データ スプリット
Spanner は、スプリットと呼ばれるデータの範囲を、ノードや処理単位と呼ばれるノードの下位区分に割り当てます。ノードや処理単位は、分割されたスプリットのデータを個別に管理して提供します。データ スプリットは、データ量やアクセス パターンなど、いくつかの要因に基づいて作成されます。詳細については、Spanner - スキーマとデータモデルをご覧ください。
データはスプリットに整理され、Spanner はスプリットを自動的に管理します。そのため、オートスケーラー ツールがノードや処理単位を追加または削除する場合は、インスタンスに新しい容量が追加または削除されたときに、Spanner バックエンドがスプリットの再割り当てや再編成を行うのに十分な時間を確保する必要があります。
オートスケーラー ツールは、スケールアップ イベントとスケールダウン イベントの両方でクールダウン期間を使用して、インスタンスに対してノードや処理単位を追加または削除する速度を制御します。この方式を使用すると、コンピューティング ノードや処理単位とデータ スプリット間の関係を再編成するために必要な時間をインスタンスに追加できます。デフォルトでは、スケールアップとスケールダウンのクールダウン期間が次の最小値に設定されています。
- スケールアップ値: 5 分
- スケールダウンの値: 30 分
スケーリングの推奨事項とクールダウン期間の詳細については、Spanner インスタンスのスケーリングをご覧ください。
費用
Autoscaler ツールのリソース消費量は最小限であるため、ほとんどのユースケースでは費用は無視できます。Google Cloud でオートスケーラーを使用する場合、費用はかかりません。 たとえば、3 つの Spanner インスタンスを管理するオートスケーラー ツールを、各インスタンスに 5 分間隔でポーリングする場合に、無料で使用できます。この見積もりには、以下が含まれます。
- 3 つの Cloud Scheduler ジョブ
- 0.15 GB の Pub/Sub メッセージ
- 51,840 回の Cloud Run functions 関数の 500 ミリ秒の呼び出し
- 10 MB 未満の Firestore のデータ
見積もりには、Spanner データベースのオペレーション費用は含まれません。料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを出すことができます。
次のステップ
- プロジェクトごとまたは一元化されたトポロジでオートスケーラー ツールをデプロイする方法を学習する。
- 分散トポロジに Autoscaler ツールをデプロイする方法を確認する。
- Spanner の推奨しきい値について確認する
- Spanner の CPU 使用率の指標とレイテンシの指標の詳細を確認する。
- Spanner スキーマ設計のベスト プラクティスで、ホットスポットを回避し、データを Spanner に読み込む方法を確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。