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

このリリース チェックリストには、Spanner で本番環境アプリケーションを起動する前に検討すべき考慮事項の一覧を記載しています。網羅的なものではありませんが、リスクを最小限に抑え、パフォーマンスを最適化して、ビジネス目標と運用目標との整合性を確保するための重要な考慮事項をハイライトし、シームレスで信頼性の高い Spanner デプロイを実現するための体系的なアプローチを提供します。

このチェックリストは、以下のセクションで構成されています。

設計、開発、テスト、最適化

Spanner の分散アーキテクチャを使用して高パフォーマンスとスケーラビリティを実現するには、スキーマ設計、トランザクション、クエリを最適化することが不可欠です。本番環境規模の厳格なエンドツーエンドのテストにより、本番環境でのボトルネックや障害のリスクを最小限に抑えながら、システムが実際のワークロード、ピーク負荷、同時オペレーションを処理できることを確認します。

チェックボックス アクティビティ
❑  
スケーラビリティと Spanner の分散アーキテクチャを考慮してスキーマを設計します。ホットスポットを回避するために適切な主キーとインデックスを選択するなどのベスト プラクティスに従い、関連データのテーブルのインターリーブなどの最適化を検討します。スキーマ設計のベスト プラクティスを確認して、想定されるワークロードでスキーマが高パフォーマンスとスケーラビリティの両方をサポートしていることを確認します。
❑  
ロックを最小限に抑え、パフォーマンスを最大化するためにトランザクションとクエリを最適化します。整合性、スループット、レイテンシのバランスを取るために、Spanner のトランザクション モード（ロック読み取り / 書き込み、強整合読み取り専用、パーティション化 DML ステートメントなど）を使用します。クエリには読み取り専用トランザクションを使用し、DML スループットを最大化するためにバッチ処理を使用します。大規模な更新と削除にはパーティション化 DML ステートメントを使用して、ロックスコープを最小限に抑えます。隔離レベルが異なるシステム（PostgreSQL や MySQL など）から移行する場合は、トランザクションを使用してパフォーマンスのボトルネックを回避します。詳細については、トランザクションをご覧ください。
❑  
大規模な厳格な負荷テストを実施して、スキーマ設計、トランザクション動作、クエリ パフォーマンスを検証します。さまざまなトランザクション シェイプやクエリパターンなど、実世界のアプリケーションの負荷を模倣したピークシナリオと高同時実行シナリオをシミュレートします。これらの条件下でレイテンシとスループットを評価し、データベース設計とインスタンス トポロジがパフォーマンス要件を満たしていることを確認します。開発中に負荷テストを反復して使用し、実装を最適化して改良します。
❑  
負荷テストを拡張して、分離されたアプリケーションだけでなく、相互作用するすべてのサービスを対象にします。データベースにアクセスするバッチ読み込みや管理タスクなどの並列プロセスとともに、包括的なユーザー ジャーニーをシミュレートします。本番環境の Spanner インスタンス構成でテストを実行し、負荷テストドライバとサービスが、想定される本番環境デプロイ トポロジと地理的に一致していることを確認します。この包括的なアプローチにより、潜在的な競合を事前に特定し、実際の運用中にスムーズなデータベース パフォーマンスを確保できます。
❑  
予測可能なクエリ パフォーマンスを確保するには、ワークロードがテストされたオプティマイザーのバージョンを使用します。デフォルトでは、Spanner データベースは最新のクエリ オプティマイザー バージョンを使用します。制御された環境で新しいオプティマイザー バージョンを定期的に評価し、互換性とパフォーマンスの向上を確認した後にのみ、デフォルト バージョンを更新します。詳細については、クエリ オプティマイザーの概要をご覧ください。
❑  
効率的なクエリ実行プランをサポートするために、クエリ オプティマイザーの統計情報が最新の状態であることを確認します。統計情報は自動的に更新されますが、大規模なデータ変更（一括挿入、更新、削除など）、新しいインデックスの追加、スキーマの変更などのシナリオでは、手動で新しい統計パッケージを作成することを検討してください。クエリ オプティマイザーの統計情報を最新の状態に保つことは、最適なクエリ パフォーマンスを維持するために重要です。

移行（省略可）

データベース移行は包括的なプロセスであり、個々の移行の詳細を詳しく把握する必要があります。移行戦略では、次の点を考慮してください。

チェックボックス アクティビティ
❑  
移行のカットオーバーに関する詳細な標準作業手順（SOP）を作成します。これには、アプリケーションのロールアウト、データベースのスイッチオーバー、手動操作を最小限に抑える自動化の手順が含まれます。潜在的なダウンタイム期間を特定し、関係者に事前に通知します。堅牢なモニタリングとアラート メカニズムを実装して、移行プロセスをリアルタイムで追跡し、異常を迅速に検出します。スイッチオーバー プロセスに、移行後のデータの完全性とアプリケーションの機能を確認するための検証チェックが含まれていることを確認します。
❑  
移行中に重大な問題が発生した場合にソースシステムに戻すための詳細なフォールバック計画を準備します。ステージング環境でフォールバック プロシージャをテストし、信頼性が高く、ダウンタイムを最小限に抑えて実行できることを確認します。フォールバックがトリガーされる条件を明確に定義し、この計画を迅速かつ効率的に実行できるようにチームをトレーニングします。

デプロイ

適切なデプロイ計画により、地理的要件と運用上の考慮事項を考慮しながら、Spanner 構成が可用性、レイテンシ、スケーラビリティのワークロード要件を満たすようにします。サイズ設定、リソース管理、フェイルオーバー シナリオ、自動化を調整することで、リスクを最小限に抑え、最適なパフォーマンスを確保し、重要なオペレーション中にリソースの制約や停止が発生しないようにします。

チェックボックス アクティビティ
❑  
地理的な考慮事項を考慮しながら、Spanner のインスタンス構成（リージョン、デュアルリージョン、マルチリージョン）がアプリケーションのワークロードの可用性とレイテンシの要件に沿っていることを確認します。想定されるストレージ サイズ、トラフィック パターン、推奨される使用率の上限に基づいてターゲットのコンピューティング容量を計算し、ゾーンまたはリージョンの停止に十分な容量を確保します。自動スケーリングを有効にして、トラフィックのピークを計画します。コンピューティング容量の上限を設定することで、費用の安全を確保できます。詳細については、コンピューティング容量、ノード、処理ユニットをご覧ください。
❑  
デュアルリージョンまたはマルチリージョン インスタンス構成を使用している場合は、レイテンシに最も敏感なロケーションにデプロイされたサービスからのアプリケーション書き込みのレイテンシを最小限に抑えるため、リーダー リージョンを選択します。さまざまなリーダー リージョンがオペレーション レイテンシに与える影響をテストし、アプリケーションのパフォーマンスを最適化するように調整します。リージョンの停止中にアプリケーション トポロジがリーダー リージョンの変更に適応できるように、フェイルオーバー シナリオを計画します。詳細については、データベースのリーダー リージョンを変更するをご覧ください。
❑  
運用の明確化と Google Cloud リソースのトラッキングのために、タグとラベルを適切に構成します。タグを使用して、環境またはワークロードの種類別にインスタンスをグループ化します。費用の分析と権限管理に役立つメタデータにラベルを使用します。詳細については、タグを使用してアクセスを制御し、インスタンスを整理するをご覧ください。
❑  
Spanner のウォームアップが必要かどうかを評価します。特に、リリース時に急増するトラフィックを想定しているサービスの場合は注意が必要です。初期負荷が高い状態でレイテンシをテストすると、最適なパフォーマンスを確保するためにリリース前のウォームアップが必要であることが判明する場合があります。ウォームアップが必要な場合は、人工的な負荷を生成します。詳細については、アプリケーションの起動前にデータベースをウォームアップするをご覧ください。
❑  
デプロイする前に Spanner の上限と割り当てを確認します。必要に応じて、 Google Cloud コンソールから割り当ての増加をリクエストして、ピーク時の制約を回避します。デプロイ後に問題が発生しないように、ハードリミット（データベースあたりの最大テーブル数など）に注意してください。詳細については、割り当てと上限をご覧ください。
❑  
Terraform などの自動化ツールを使用して Spanner インスタンスをプロビジョニングして管理し、構成が効率的でエラーのない状態を維持します。スキーマ管理には、Liquibase などのツールを使用して、更新中にスキーマが誤って削除されないようにすることを検討してください。詳細については、Spanner で Terraform を使用するをご覧ください。

障害復旧

データの保護、ダウンタイムの最小化、予期しない障害発生時のビジネス継続性を確保するには、堅牢な障害復旧（DR）戦略を策定することが不可欠です。復元手順を定期的にテストし、バックアップを自動化することで、運用の準備、復元目標への準拠、組織のニーズに合わせてカスタマイズされた信頼性の高いデータ保護を実現できます。

チェックボックス アクティビティ
❑  
データ保護、復元の目標、障害シナリオを含む、Spanner の包括的な障害復旧戦略を定義します。ビジネス継続性の要件に沿って、明確な目標復旧時間（RTO）と目標復旧時点（RPO）を確立します。バックアップ頻度と保持ポリシーを指定し、ポイントインタイム リカバリ（PITR）を使用して、障害発生時のデータ損失を最小限に抑えます。障害復旧の概要を確認し、アプリケーションの可用性、信頼性、セキュリティを遵守するための適切なツールと手法を確認します。詳細については、Spanner のデータ保護 / 復元ソリューションのホワイトペーパーをご覧ください。
❑  
さまざまな復元シナリオの手順ガイドなど、バックアップと復元の手順に関する詳細なドキュメントを作成します。これらの手順を定期的にテストして、運用の準備状況を確認し、RTO と RPO の要件を検証します。テストでは、実際の障害条件とシナリオをシミュレートしてギャップを特定し、復元プロセスを改善する必要があります。詳細については、復元の概要をご覧ください。
❑  
自動バックアップ スケジュールを実装して、一貫性と信頼性の高いデータ保護を確保します。ビジネスニーズと規制上の義務に合わせて、頻度と保持設定を構成します。Spanner のバックアップ スケジューリング機能を使用して、バックアップの作成、管理、モニタリングを自動化します。詳細については、バックアップ スケジュールを作成、管理するをご覧ください。
❑  
フェイルオーバー プロシージャをアプリケーションのインスタンス構成トポロジと調整して、停止した場合のレイテンシの影響を最小限に抑えます。障害復旧シナリオをテストして、リーダー リージョンがフェイルオーバー リージョンに移動したときにアプリケーションが効率的に動作することを確認します。詳細については、データベースのリーダー リージョンを変更するをご覧ください。

クエリ オプティマイザーと統計情報の管理

予測可能で効率的なクエリ パフォーマンスを維持するには、クエリ オプティマイザーのバージョンと統計情報を管理することが重要です。テスト済みのバージョンを使用し、統計情報を最新の状態に保つことで、安定性が確保され、予期しないパフォーマンスの変化を防ぎ、クエリ実行プランを最適化できます。これは、特にデータやスキーマの大幅な変更を行う場合に重要です。

チェックボックス アクティビティ
❑  
デフォルトでは、Spanner データベースは最新のクエリ オプティマイザー バージョンを使用します。予測可能なクエリ パフォーマンスを確保するには、ワークロードがテストされたオプティマイザー バージョンを使用します。制御された環境で新しいオプティマイザー バージョンを定期的に評価し、互換性とパフォーマンスの向上を確認した後にのみ、デフォルト バージョンを更新します。詳細については、クエリ オプティマイザーの概要をご覧ください。
❑  
効率的なクエリ実行プランをサポートするために、クエリ オプティマイザーの統計情報が最新の状態であることを確認します。統計情報は自動的に更新されますが、大規模なデータ変更（一括挿入、更新、削除など）、新しいインデックスの追加、スキーマの変更などのシナリオでは、手動で新しい統計パッケージを作成することを検討してください。クエリ オプティマイザーの統計情報を最新の状態に保つことは、最適なクエリ パフォーマンスを維持するために重要です。
❑  
一括削除後や、新しい統計情報の生成がクエリのパフォーマンスに予測できない影響を与える可能性がある場合など、特定のシナリオでは、特定の統計情報パッケージを固定することをおすすめします。これにより、新しいパッケージを生成してテストできるまで、一貫したクエリ パフォーマンスが提供されます。統計情報の固定の必要性を定期的に確認し、更新されたパッケージが検証されたら固定を解除します。詳細については、クエリ オプティマイザーの統計情報パッケージをご覧ください。

セキュリティ

機密データを保護し、Spanner での不正アクセスを防止するには、アクセス制御対策を実装することが不可欠です。最小権限アクセス、きめ細かいアクセス制御（FGAC）、データベースの削除保護を適用することで、リスクを最小限に抑え、コンプライアンスを確保し、重要なアセットを偶発的または悪意のあるアクションから保護できます。

チェックボックス アクティビティ
❑  
データベースにアクセスするすべてのユーザーとサービス アカウントに対して、最小権限の原則に従って Identity and Access Management（IAM）ポリシーを実装します。特定のタスクの実行に必要な権限のみを割り当て、アクセス制御権限を定期的に監査して、このモデルに準拠していることを確認します。自動化プロセスに最小限の権限を持つサービス アカウントを使用して、不正アクセスのリスクを軽減します。詳細については、IAM の概要をご覧ください。
❑  
テーブル内の特定の行、列、セルへのアクセスを制限する必要がある場合は、きめ細かいアクセス制御（FGAC）を実装します。ユーザー属性またはデータ値に基づいて条件付きアクセス ポリシーを設計して適用し、きめ細かいアクセスルールを適用します。進化するセキュリティとコンプライアンスの要件に合わせて、これらのポリシーを定期的に見直し、更新します。詳細については、きめ細かいアクセス制御の概要をご覧ください。
❑  
自動バックアップ スケジュールを実装して、一貫性と信頼性の高いデータ保護を確保します。ビジネスニーズと規制上の義務に合わせて、頻度と保持設定を構成します。Spanner のバックアップ スケジューリング機能を使用して、バックアップの作成、管理、モニタリングを自動化します。詳細については、バックアップ スケジュールを作成、管理するをご覧ください。
❑  
データベースの削除保護を有効にして、誤った削除や不正な削除を防ぎます。これを厳格な IAM 制御と組み合わせて、削除権限を信頼できる少数のユーザーまたはサービス アカウントに制限します。また、Terraform などのインフラストラクチャ自動化ツールを構成して、データベースの誤削除に対する安全保護対策を含めます。この階層型のアプローチにより、重要なデータアセットに対するリスクを最小限に抑えることができます。詳細については、データベースの誤削除を防ぐをご覧ください。

ロギングとモニタリング

効果的なロギングとモニタリングは、データベース オペレーションの可視性を維持し、異常を検出して、システムの健全性を確保するために重要です。監査ログ、分散トレース、ダッシュボード、事前アラートを使用すると、問題を迅速に特定して解決し、パフォーマンスを最適化してコンプライアンス要件を満たすことができます。

チェックボックス アクティビティ
❑  
監査ロギングを有効にして、データベース アクティビティに関する詳細情報をキャプチャします。コンプライアンスと運用要件に基づいて監査ログレベルを適切に構成し、アクセス パターンをモニタリングして異常を効果的に検出します。DATA_READ リクエストと DATA_WRITE リクエストでは、すべての SQL ステートメントと DML ステートメントがログに記録されるため、監査ログが大きくなる可能性があります。詳細については、 Spanner の監査ロギングをご覧ください。

これらのログをユーザー定義のログバケットに転送すると、ログの保持費用を最適化できます（最初の 30 日間は料金は発生しません）。また、ログビューを使用してログアクセスをきめ細かく制御できます。
❑  
OpenTelemetry でアプリケーション ロジックを計測してクライアントサイド指標を収集し、トレースとオブザーバビリティを分散します。OpenTelemetry 計測を設定して Spanner からトレースと指標をキャプチャし、アプリケーションのパフォーマンスとデータベースのインタラクションのエンドツーエンドの可視性を確保します。詳細については、OpenTelemetry を使用してカスタム クライアントサイド指標をキャプチャするをご覧ください。
❑  
モニタリング指標を作成して構成し、クエリのパフォーマンス、レイテンシ、CPU 使用率、ストレージ使用量を可視化します。これらの指標は、データベースのパフォーマンスのリアルタイム トラッキングと過去の分析に使用します。詳細については、Cloud Monitoring でインスタンスをモニタリングするをご覧ください。
❑  
重要な指標のしきい値ベースのモニタリング アラートを定義して、問題を事前に検出して対処します。クエリ レイテンシの増加、ストレージの可用性の低下、トラフィックの予期しない急増などの条件にアラートを構成します。これらのアラートをインシデント対応ツールと統合して、迅速な対応を実現します。詳細については、Spanner 指標のアラートを作成するをご覧ください。

クライアント ライブラリ

オペレーションのタグ付け、セッション プール、再試行ポリシーの構成は、Spanner でパフォーマンスを最適化し、問題をデバッグして、復元力を維持するために不可欠です。これらの対策により、オブザーバビリティが強化され、レイテンシが短縮されます。ワークロードの需要と一時的なエラーが効率的に処理され、システムの動作がアプリケーション要件と調整されます。

チェックボックス アクティビティ
❑  
意味のあるクエリ リクエスト タグとトランザクション タグを使用するようにクライアント ライブラリを構成します。リクエストタグとトランザクション タグを使用すると、クエリ、読み取り、トランザクションを把握できます。デバッグとイントロスペクションを強化するには、タグでアプリケーション コンポーネント、リクエスト タイプ、ユーザー コンテキストなどのコンテキスト メタデータを使用することをおすすめします。パフォーマンス分析とトラブルシューティングを容易にするため、クエリの統計情報とログにタグが表示されるようにします。詳細については、リクエストタグとトランザクション タグによるトラブルシューティングをご覧ください。
❑  
クライアント ライブラリでセッション プールを有効にして、セッション管理を最適化します。レイテンシを最小限に抑えながらワークロードの需要に合わせて、セッションの最小数や最大数などのプール設定を構成します。セッションの使用状況を定期的にモニタリングして、これらのパラメータを微調整し、セッション プールが一貫したパフォーマンス上のメリットを提供するようにします。詳細については、セッションをご覧ください。
❑  
まれなシナリオでは、最大試行回数や指数バックオフ間隔など、再試行のデフォルトのクライアント ライブラリ パラメータを構成して、復元力とパフォーマンスのバランスを取る必要があります。これらのポリシーがアプリケーションのニーズに合っていることを確認するため、これらのポリシーを十分にテストします。詳細については、カスタム タイムアウトと再試行を構成するをご覧ください。

サポート

ダウンタイムと影響を最小限に抑えるため、インシデントに対する役割と責任を明確に定義し、Spanner 関連の問題に迅速かつ調整された対応を実現します。 詳細については、サポートを利用するをご覧ください。

チェックボックス アクティビティ
❑  
明確なインシデント対応フレームワークを確立し、Spanner 関連のインシデントの管理に関与するすべてのチームメンバーの役割と責任を定義します。インシデント コマンダー、コミュニケーション リード、サブジェクト マター エキスパート（SME）などのインシデント ロールを指定することで、インシデント発生時の効率的な調整とコミュニケーションを確実にします。問題の特定、エスカレーション、軽減、解決のプロセスを策定し、文書化します。Google SRE ワークブックのインシデント対応とインシデントの管理で説明されているベスト プラクティスに従います。インシデント対応トレーニングとシミュレーションを定期的に実施して、準備状況を確保し、チームが緊張状態のシナリオを効果的に管理する能力を向上させます。

費用管理

自動スケーリングや増分バックアップなどの費用管理戦略を実装すると、リソースの効率的な使用と大幅な費用削減を実現できます。リソースのプロビジョニングをワークロードの需要に合わせて調整し、非本番環境を最適化することで、パフォーマンスと柔軟性を維持しながら費用をさらに削減できます。

チェックボックス アクティビティ
❑  
Spanner の CUD を評価して購入することで、予測可能なワークロードの費用を削減します。これらのコミットメントにより、オンデマンド料金と比較して大幅な費用削減が実現する可能性があります。過去の使用パターンを分析して、最適な CUD コミットメントを決定します。詳細については、確約利用割引と Spanner の料金をご覧ください。
❑  
コンピューティング容量の使用率をモニタリングし、プロビジョニングされたリソースを調整して、推奨の CPU 使用率レベルを維持します。コンピューティング リソースを過剰にプロビジョニングすると、不要な費用が発生する可能性があります。一方、アンダープロビジョニングはパフォーマンスに影響する可能性があります。推奨される Spanner の最大 CPU 使用率のガイドラインに従って、費用対効果の高いリソース調整を行います。
❑  
自動スケーリングを有効にして、ワークロードの需要に基づいてコンピューティング容量を動的に調整します。これにより、ピーク負荷時のパフォーマンスを最適化し、アクティビティが少ない期間の費用を削減できます。上限と下限を使用してスケーリング ポリシーを構成し、費用を管理して過剰なスケーリングを回避します。詳細については、自動スケーリングの概要をご覧ください。
❑  
増分バックアップを使用して、バックアップ ストレージの費用を削減します。増分バックアップには、前回のバックアップ以降のデータ変更のみが保存されます。これにより、完全なバックアップと比較してストレージ要件が大幅に削減されます。増分バックアップをバックアップ戦略に組み込みます。詳細については、増分バックアップをご覧ください。
❑  
最適なインスタンス構成を選択し、環境が使用されていないときにリソースをプロビジョニング解除することで、非本番環境の費用を最適化します。たとえば、営業時間外にミッション クリティカルでない環境をダウンサイズしたり、開発とテストのシナリオでリソース スケーリングを自動化します。このアプローチにより、運用の柔軟性を維持しながらコストを最小限に抑えます。