Spanner のリリースチェックリスト

このリリースチェックリストには、Spanner で本番環境アプリケーションを起動する前に検討すべき考慮事項の一覧を記載しています。これはすべてを網羅するものではありませんが、本番環境のパフォーマンスに大きな影響を与える可能性のある領域を重点的に示したものです。

要件を満たすインスタンス構成（リージョンとマルチリージョン）を選択します。

マルチリージョンのインスタンスタイプを選択する場合、Cloud Spanner にアクセスするアプリケーションはリーダーリージョンの近くに配置する必要があります。詳細については、インスタンスをご覧ください。

Spanner のリレーショナルデータスキーマは、従来のリレーショナルデータベースと似ていますが、考慮すべき点がいくつかあります。

自動シャーディングを実施した後、スプリットに格納すると、ターゲットを絞り込むことによってクエリのパフォーマンスが向上します。単一のインターリーブされた親とそのすべての子に絞り込むと、複数の行に影響を及ぼすクエリまたはオペレーションと比較して優れたパフォーマンスが得られます。

リリース前に問題やボトルネックを把握できるよう、ベンチマークとテストを大規模に実施することを強くおすすめします。Spanner を使用すると、スキーマ設計時にテーブルで使用できるクエリ実行プランを使用して、クエリ実行の可能性を把握できます。

考慮すべきその他のパフォーマンス要因:

データを書き込まない場合は、より高コストな読み取り/書き込みトランザクションよりも読み取り専用トランザクションを優先します。
トランザクションのスプリット参加者数を最小限に抑えるようにアプリケーションを設計します。Spanner は、さまざまなサーバー上の行にまたがるトランザクションを実行できます。ただし、経験則として、同じ場所に配置された多くの行に関わるトランザクションは、データベース全体または大きなテーブル全体に散在する多くの行に関わるトランザクションよりも高速かつ低コストです。
文字列リテラルではなくクエリパラメータを使用して、クエリのパフォーマンスと統計情報のモニタリングを改善します。

アーキテクチャ上の理由と、パフォーマンスと冗長性を維持する目的のため、Spanner にはアプリケーション設計で考慮すべき特定の割り当てと上限があります。割り当てはリードタイムで増やすことができます。

たとえば、commit ごとに 80,000 のミューテーションがあり、クエリごとに最大 15 個の結合があるとします。

これらの制限とスキーマ設計、ホットスポット防止は一括読み込みに影響するため、一括読み込みのベストプラクティスに従ってください。

上限に近づいたときに通知を受け取るように Cloud Monitoring を設定します。

Spanner インスタンスの線形スケーリングのパフォーマンス指標に到達した場合は、コンピューティング容量を増やします。CPU 使用率は、リージョン固有のインスタンスでは 65% 未満に、マルチリージョンインスタンスでは 45% 未満に保つことをおすすめします。

データベースの [クエリ] ページで [クエリテンプレート] を使用して、クエリの統計情報の表内のクエリ統計情報をモニタリングします。

Spanner へのデータの一括読み込みでは、パフォーマンスを維持するために分散アーキテクチャを考慮する必要があります。

このブログ投稿は、高スループットの書き込みを実装する際の良い例です。

データベースとインスタンスレベルでセキュリティを管理するために、関連する IAM ロールを設定します。テーブルレベルのセキュリティはアプリケーション内で管理する必要があります。

サポートを受けるための計画を策定済みであることを確認します。

Spanner のリリース チェックリスト