負荷生成ツールを使用して既存の Cloud Spanner データベースで新しい機能やゲームをリリースする

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

ゲーム デベロッパーは、新しいゲームをリリースしたり、既存のゲームに新機能をリリースしたりする際に、既存のデータベース プラットフォームを再利用することがよくあります。これを行うには、新しいスキーマ（テーブル、インデックスなど）、データ、およびトラフィックの観点からデータベースを拡張する必要があります。

Cloud Spanner データベースで構築されたゲームの場合、ほとんどのデータベース操作は、本番環境のゲーム トラフィックに影響を与えることなくシームレスに実行できます。Cloud Spanner を使用すると、ダウンタイムなしでスキーマの更新を行うことができます。また、新機能 / ゲームのリリースに向けてデータとトラフィックのバランスを自動的にとるコンピューティング容量を追加することで、データベースを拡張することもできます。

トラフィック量が着実に増加することがほとんどの機能またはゲームで予想される中、Cloud Spanner は、そのような負荷の増加に合わせて拡張できるデータベースです。ただし、精密なトラフィック増加パターンを計画する必要があるゲームには、Cloud Spanner の負荷生成ツールを使用できます。このブログでは、ウォームアップの実行および検証手順について、ベスト プラクティスを紹介しながら詳しく説明します。

スケールアップしてからリリースする

新しいデータベースまたは空のテーブルを使用して起動されるゲームや機能の場合、デベロッパーは負荷生成ツールを直接使用してデータベースまたはテーブルをウォームアップし、スプリットを作成できます。その後、リリース日の前にすべての行を削除しておくと、Cloud Spanner データベースは想定される本番環境のトラフィックに合わせて自動的に拡張されます。デベロッパーは、このブログの説明に従ってデータベースをウォームアップし、パフォーマンスを検証することで、リリースを適切に行えるようになります。

既存のデータベースまたはテーブル（つまり、既存の本番環境データを持つデータベースまたはテーブル）を使用するゲームや機能の場合は、負荷生成ツールを使用することもできますが、合成データを追加して追跡し、ゲームをリリースする前に削除することをおすすめします。

さまざまなスキーマ エンティティのウォームアップ

テーブルとインターリーブ テーブル

`gcsb load` コマンドを使用してデータをテーブルにシードすると、すべてのインターリーブ（子）テーブルで親行 1 つあたり 5 つの子行が自動的に作成されます。負荷生成ツールによって作成された子テーブルの行を自動的に削除するには、スキーマで子テーブルに TTL ポリシーを設定するか、`ON DELETE CASCADE` 句を設定します。  

インデックス

すべてのセカンダリ インデックスとインターリーブ インデックスは、ベーステーブル用に生成されたデータに基づいて合成データを自動的に入力します。これによってインデックス テーブルにもスプリットが作成され、インデックスをウォームアップするために特別な処理は必要となりません。インデックスは、ベーステーブルの行が PDML を使用して手動で削除されるか、TTL ポリシーに基づいて自動的に削除された際に、データの削除も行います。

外部キー

現時点では、負荷生成ツールでサポートされていません。

合成データの追跡と削除

1. 以下の DDL を使用して、ウォームアップで使用される関連テーブルに null 許容の commit タイムスタンプ列を追加します。既存の `allow_commit_timestamp` 列を再利用することはおすすめしません。個別の列（ゲーム アプリケーションでは使用されない）の使用は、負荷生成ツールによって自動入力され、合成データとの強い相関関係を提供します。本番環境のトラフィックによって生成されるすべての行で列の値が NULL になります。

2. 以下の DDL を使用して、Cloud Spanner TTL ポリシーを追加します。行削除ポリシーは低い優先度で実行され、増分クリーンアップに最適です。ただし、ウォームアップで十分な数のスプリットを作成するために大量のデータを生成する必要がある場合は、Cloud Spanner の内部作業スケジューラが本番環境のゲーム トラフィックを優先するため、ビジー状態のデータベースで合成データを削除するための時間が長くなる可能性があります。

3. ゲームのリリース時に想定される負荷をかけて、負荷生成ツールを少なくとも 1 時間実行します。

4. `gcsb run` を実行してデータベースのパフォーマンス、特にデータベースのレイテンシとスループットを確認してください。

5. 設定した TTL に基づいて、合成データが X 日後に自動的に削除されます（この例のステップ 2 では、すべての合成行が 1 日後に削除されます）。

6. （オプション）ゲーム アプリケーションでの混乱や誤用を防ぐため、列（LoadGeneratorDataTimestamp）を削除します。

最後に

Cloud Spanner は、アプリケーションのメジャー リリースの前にデータベースをウォームアップしておくことを推奨しています。ウォームアップは以下の手順で行うことができます。

• テストデータの負荷用に生成する主キーが同じキースペースにあることを確認します。この設定は、負荷生成ツール内の gscb.yaml config で行えます。

• リリースから 2 日以内に負荷テストを行います。少なくとも 1 時間は、想定されるピーク時の負荷でテストを行います。この負荷テストにより、Cloud Spanner は負荷に応じて分割を行い、複数のスプリットを生成します。

• 負荷テストが完了したら、負荷テストで生成された行をテーブルから削除します。ただし、テーブル自体は削除しないでください。これにより、リリース時に使用可能なスプリットが残ります。