オープンソースの Autoscaler で Memorystore for Redis Cluster を最適なサイズに調整

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

クラウド コンピューティングの最も魅力的な側面の一つは、リソースを自動的にスケールアップできることですが、それと同じくらい重要なのが、コストとパフォーマンスを管理するためにスケールダウンもできることです。これは、たとえば Compute Engine のマネージド インスタンス グループのような仮想マシンでは一般的な運用方法ですが、データベースなどのステートフル サービスでは、その本質的な複雑さのために、あまり一般的ではありません。

昨年は、手動でスケールアウトやスケールダウンをトリガーできる機能を備えた Memorystore for Redis Cluster をリリースしました。このたび、最新の Memorystore ワークロードの極めて高い弾力性に対応するため、オープンソースの Memorystore Cluster Autoscaler を GitHub で公開しました。これは、2020 年にリリースしたオープンソースの Spanner Autoscaler を基に構築されています。

クラスタのスケーリングを理解する

Memorystore for Redis Cluster の容量は、ダウンタイムなしで増減可能なクラスタ内のシャード数と、基盤となるノードタイプに対応するクラスタのシャードサイズによって決定されます。現時点では、クラスタのノードタイプは変更できません。クラスタの容量をスケールインまたはスケールアウトするには、クラスタ内のシャード数を変更します。このプロセスを自動化するために、Memorystore Cluster Autoscaler を導入することで、クラスタ指標をモニタリングし、その情報に基づいてクラスタを適切なサイズに調整できます。Autoscaler は、クラスタの可用性に影響を与えることなく、メモリと CPU の使用率を評価するルールセットを使用して、必要なリソースの調整を実施します。

次のグラフはメモリ使用率の増加に伴って Memorystore for Redis Cluster インスタンスが自動的にスケールアウトする、Autoscaler の動作を示しています。緑の線は、クラスタに 5 分ごとに 1 GB のペースでデータが書き込まれている様子を表しています。青の線は、クラスタ内のシャード数を表しています。メモリ使用率に比例してシャード数が増加し、クラスタがスケールアウトしていく様子がわかります。その後、書き込みが停止すると増加が止まり、テストの最後にキーがフラッシュされると、再びスケールインします。

デプロイと運用

Autoscaler を使用するには、いずれかの Google Cloud プロジェクトにデプロイしてください。Autoscaler は非常に柔軟で、デプロイの方法にも複数のオプションがあるため、リポジトリには複数の Terraform デプロイ構成例とさまざまなデプロイモデルを説明するドキュメントが含まれています。

Autoscaler をデプロイしたら、管理対象の Memorystore インスタンスのスケーリング要件に従って、ワークロードの特性に合わせた構成を行います。これは、各 Memorystore インスタンスに対して Autoscaler の構成パラメータを指定することで行います。構成が完了すると、Autoscaler は Memorystore インスタンスを自律的に管理し、スケーリングを行います。これらのパラメータについて詳しくは、この投稿の後半および Autoscaler のドキュメントをご覧ください。

Autoscaler のアーキテクチャ

Autoscaler は、Poller と Scaler という 2 つの主要コンポーネントで構成されています。これらは Cloud Run functions または Google Kubernetes Engine（GKE）に Terraform を使用してデプロイでき、ユーザーが定義したスケジュールに従って Autoscaler が動作するように、これらを構成できます。Poller は、あらかじめ設定された間隔で Cloud Monitoring の Memorystore の指標にクエリを実行し、使用状況を判断して Scaler に渡します。Scaler は、取得した指標をルールセットで指定された推奨しきい値と比較し、インスタンスをスケールインまたはスケールアウトすべきかを判断します。さらに、スケールする場合はシャードの増減数も決定します。サンプル構成を変更することで、最小および最大クラスタサイズや、環境に適したその他のしきい値を指定できます。

フロー全体で、Autoscaler は推奨事項やアクションの詳細を Cloud Logging に記録し、追跡や監査を可能にします。また、指標を Cloud Monitoring に送信することで、アクションに関する洞察を提供します。

スケーリング ルーブリック

Memorystore のパフォーマンスは、主にインメモリ ストレージと CPU によって制限されることが一般的です。Autoscaler はデフォルトで、CPU_AND_MEMORY プロファイルを使用して、スケーリング時にこれらの両方の要因を考慮するように構成されています。これはデプロイを開始する際の適切な構成であり、必要に応じてカスタム構成に置き換えることで、ニーズに最適化することも可能です。

デフォルト

* スケールインは、キー エビクションが進行中の場合にブロックされます。キー エビクションは、キースペースが満杯になり、キャッシュのスペースを確保するためにキーが削除される際に発生します。スケールインはデフォルトで有効になっていますが、カスタム スケーリング プロファイルを使用して構成を変更できます。これを行う方法について詳しくは、ドキュメントの「スケーリング プロファイル」セクションをご覧ください。

スケーリングのシナリオと方法

代表的なシナリオとその具体的な使用パターンを見てみましょう。それぞれのシナリオに最適な Autoscaler の構成についても紹介します。次のセクションで説明するオプションの詳細については、構成ドキュメントをご覧ください。

標準的なワークロード

Memorystore を利用する多くのアプリケーションでは、ユーザーは特定の時間帯にそのアプリケーションをより頻繁に利用するという一定のパターンを持っています。たとえば、銀行アプリケーションでは、ユーザーは朝に口座を確認し、午後から夕方にかけて取引を行い、夜間はあまり利用しない、といった傾向が見られます。

このような比較的一般的なシナリオを「標準的なワークロード」と呼び、その時系列データには次のような特長が見られます。

• 1 日の特定の時間帯における使用率の大幅な増加または減少

• しきい値を上回ったり下回ったりする小さなスパイク

このようなタイプのワークロードに推奨される基本構成には、次の内容を含める必要があります。

• スケーリング方式（scalingMethod）に LINEAR を指定することで、大規模なスケール イベントに対応できるようにする

• スケールアウトのクールダウン時間（scaleOutCoolingMinutes）を短く設定することで（5～10 分の範囲）、Autoscaler の反応時間を最小限に抑える

安定したワークロード

もう 1 つの一般的なシナリオとして、グローバル アプリ、ゲーム、チャット アプリケーションのように、日中を通じて使用率がより安定しているアプリケーションが挙げられます。これらのアプリケーションではユーザー インタラクションがより安定しているため、標準的なワークロードと比べて使用率の変動がそれほど顕著ではありません。

これらのシナリオは「安定したワークロード」を生み出し、その時系列データには次のような特長が見られます。

• 1 日の中で複数の安定した利用状態（プラトー）が現れるパターン

• 同じ安定した利用状態（プラトー）内で発生するいくつかの大きなスパイク

このようなタイプのワークロードに推奨される基本構成には、次の内容を含める必要があります。

• STEPWISE スケーリング方式を使用し、通常の 1 日の中で発生する最大の使用率の変動にわずか数ステップで対応できる十分なステップサイズ（stepSize）を設定する、または

• LINEAR スケーリング方式を使用し、特定の時間帯に使用率が大幅に増減する可能性がある場合（たとえば、ニュース速報が共有されるときなど）に対応する。この方式をスケールイン制限（scaleInLimit）と併用することで、インスタンスの容量が急激に縮小されるのを防ぐ

バッチ ワークロード

お客様は、バッチ処理や販売イベントに対応するために、Memorystore クラスタの容量増加が必要になることが頻繁にありますが、これらのタイミングは通常、事前に把握されています。これらのシナリオは「バッチ ワークロード」に分類され、次のような特性を持ちます。

• 事前に予定された明確なピークがあり、追加のコンピューティング容量を必要とする

• プロセスやイベントが終了すると、使用率が低下する

このようなタイプのワークロードに推奨される基本構成には、2 つの個別にスケジュールされたジョブを含める必要があります。

• 1 つはバッチ処理またはイベント用のジョブで、DIRECT スケーリング方式を使用するオブジェクトを構成に含み、プロセスまたはイベントを処理するために必要なシャード / ノードのピーク数を最小サイズ（minSize）として指定

• もう 1 つは通常の運用のためのジョブで、同じプロジェクト ID（projectId）とインスタンス ID（instanceId）を持つ構成となっており、LINEAR または STEPWISE スケーリング方式を使用。このジョブは、プロセスやイベントの終了後に容量を減少させる役割を担う

2 つの構成が競合しないように、適切なスケーリング スケジュールを選択してください。Cloud Run functions と GKE へのデプロイの両方において、Autoscaler がインスタンスのスケールインを開始する前に、バッチ処理が開始されるようにしてください。必要に応じて、scaleInLimit パラメータを使用してスケールインの操作速度を遅くできます。

急激に変動するワークロード

負荷状況によって、Memorystore がクラスタ トポロジを更新し、新しい容量を完全に活用するまでに数分程度かかることがあります。そのため、トラフィックに極端なスパイクや突発的な負荷パターンがある場合、Autoscaler は十分な速さで容量を確保できず、レイテンシの回避が難しくなる可能性があります。また、効率的にスケールできないため、コスト削減の効果が得られないこともあります。

このような急激に変動するワークロードに対する基本構成は、次の要件を満たす必要があります。

• 通常のインスタンス ワークロードをやや上回るように minSize を設定する

• スパイク終了後のさらなるレイテンシを防ぐために、scaleInLimit と組み合わせて LINEAR スケーリング方式を使用する

• 小さなスパイクを吸収しつつ、大きなスパイクには適切に対応できるように、十分な余裕を持ったスケーリングしきい値を設定する

高度な使い方

上述のように、Autoscaler は事前構成済みのスケーリング ルールを備えており、CPU およびメモリ使用率に基づいてクラスタサイズを最適化するよう設計されています。しかし、ワークロードによっては、使用率、パフォーマンス、予算目標に適合させるために、これらのルールの調整が必要になる場合があります。

スケーリングに使用されるルールセットをカスタマイズする方法はいくつかあり、必要な作業量が少ない順に以下のとおりです。

1. メモリ指標のみ、または CPU 指標のみを基準にスケーリングするよう選択します。これは、クラスタのサイズが頻繁に増減を繰り返す（フラッピング）現象が発生している場合に効果的です。これは Autoscaler の構成において、デフォルトの CPU_AND_MEMORY をオーバーライドする形で scalingProfile を CPU または MEMORY のいずれかに指定することで実現可能です。

2. scalingProfile を CUSTOM に指定し、Autoscaler の構成でカスタムルール セットを提供することで、独自のカスタム スケーリング ルールを使用できます。詳細は、こちらの例をご参照ください。

3. 独自のカスタムルール セットを作成し、スケーリング プロファイルの一部として、組織内のすべてのユーザーが利用できるようにします。既存のスケーリング プロファイルのいずれかをカスタマイズし、自身のニーズに適合させることで、これを実現できます。まずは、既存のスケーリング ルールやプロファイルを確認し、それを基にカスタマイズを作成することを推奨します。

次のステップ

OSS Autoscaler には、導入を簡単に始められる Terraform 構成が含まれており、本番環境へのデプロイのためにコードベースに統合できます。まずは本番環境以外で導入を開始し、Autoscaler の動作がアプリケーションと適切に連携していることを確認したうえで、本番環境へ移行することを推奨します。本番環境へのデプロイに関する追加ヒントについては、こちらのドキュメントをご参照ください。

Autoscaler への新機能のご要望がある場合や、ご自身で機能追加にご協力いただける場合は、GitHub の issues ページからお気軽に issue を作成してください。皆様からのご連絡をお待ちしております。

-ソリューション アーキテクト Henry Bell
-カスタマー エンジニア Chris Mague