プレイブック

複数の大陸にまたがるACIDトランザクション、強力な整合性、および99.999%の可用性を必要とするグローバルeコマースプラットフォーム。

→マルチリージョン構成 (例: nam-eur-asia) の Cloud Spanner。

理由: Spannerは、99.999%のSLAで、大規模なグローバル分散型かつ強力な整合性を持つACIDトランザクションを提供する唯一のGCPマネージドサービスです。

リファレンス↗

複雑なストアドプロシージャと分析クエリのニーズを持つ、大規模で高性能なOracle OLTPデータベースを移行する。

→AlloyDB for PostgreSQL。

理由: AlloyDBは、優れたPostgreSQLパフォーマンス、Oracle互換機能、およびトランザクションワークロードに影響を与えることなく分析クエリ (HTAP) を高速化するためのカラム型エンジンを提供します。

リファレンス↗

低遅延の読み取りと自動データ期限切れを必要とする、時系列データ (例: IoT、ログ) の高スループット (数百万OPS) インジェスト。

→`(entity_id)#(reverse_timestamp)` の行キー設計とガベージコレクションポリシーを持つ Cloud Bigtable。

理由: Bigtableは、大規模で低遅延のキー/バリューワークロード向けに設計されています。行キーの逆順タイムスタンプは、効率的なスキャンを実現するために最近のデータを共存させます。ガベージコレクションはTTLを処理します。

リファレンス↗

柔軟なスキーマ、クライアントへのリアルタイムデータ同期、およびオフラインサポートを必要とするモバイルまたはウェブアプリケーション。

→Native ModeのFirestore。

理由: Firestoreは、このサーバーレスアプリのバックエンドパターン向けに特別に構築されており、クライアントSDKを介してリアルタイムリスナーとオフライン永続性をすぐに提供します。

リファレンス↗

AI/MLアプリケーション (例: RAG、レコメンデーション) 向けの、サブ100msのレイテンシを必要とする大規模 (10M+ベクトル) な類似性検索。

→pgvector拡張機能とScaNNインデックスを備えたAlloyDB for PostgreSQL。

理由: AlloyDBは、Googleの高性能なScaNNアルゴリズムを近似最近傍 (ANN) 検索に統合しており、大規模な標準のベクトル検索実装を上回る性能を発揮します。

単一サーバーでのホットスポットを防ぐために、書き込み負荷の高いワークロード向けの Cloud Spanner スキーマを設計する。

→単調増加する値 (例: 連続ID、タイムスタンプ) を最初のキー部分として使用しない主キーを設計します。代わりに、UUID、ハッシュ値、またはビット反転シーケンスを使用します。

理由: Spannerは主キーによってデータを辞書順に分散します。連続したキーはすべての書き込みを単一の分割に集中させ、ホットスポットを作成します。ランダムに分散されたキーは、書き込みをすべての分割に分散させます。

リファレンス↗

Spannerスキーマには強力な親子関係 (例: 顧客と注文) があり、クエリは頻繁に親とそのすべての子を取得します。

→子テーブルを `INTERLEAVE IN PARENT` で定義し、インターリーブテーブルを使用します。

理由: インターリーブは、子行をストレージ内で親行と物理的に共存させます。これにより、親子結合が非常に効率的になり、単一の分割に対する高度に最適化された範囲スキャンとなります。

地理的エリア内の車両を検索するクエリを伴う、膨大な車両群 (5万+書き込み/秒) のリアルタイム位置を追跡する。

→車両の位置のGeoHashをプレフィックスとする行キーを持つ Cloud Bigtable。

理由: Bigtableは、極端な書き込みスループットを処理します。GeoHashエンコーディングは、2D座標を1D文字列に変換し、プレフィックスが地理的近接性を表すため、効率的な地理空間範囲スキャンを可能にします。

複雑な分析SQLクエリを使用して、ペタバイト規模のデータ (例: ゲノムデータ、ログ) を保存および分析する。

→Cloud Storageに生データを保存し、外部テーブルを使用してBigQueryから直接クエリを実行するか、ネイティブBigQueryストレージにロードします。

理由: BigQueryは、ペタバイト規模の分析向けに構築されたサーバーレスデータウェアハウスです。ストレージとコンピューティングの分離により、OLAPワークロードに対して比類のないクエリパフォーマンスと費用対効果を提供します。

キャッシュ無効化のためのPub/Sub機能を備えた、複雑なデータ構造 (ハッシュ、セット) 向けの高可用性インメモリキャッシュ。

→リードレプリカを備えたMemorystore for Redis Standard Tier。

理由: Standard Tierは、自動フェイルオーバーによる99.9%のSLAを提供します。Redisは、Memcachedとは異なり、複雑なデータ型とPub/Subをサポートします。リードレプリカは読み取りスループットをスケールできます。

各テナントに強力なデータ分離とパフォーマンス保証を必要とするSpanner上のマルチテナントSaaSアプリケーションを設計する。

→すべてのテーブルの主キーの最初のコンポーネントとして tenant_id を使用します。より強力な分離のためには、単一のSpannerインスタンス内でテナントごとのデータベースモデルを使用します。

理由: tenant_id プレフィックスは、単一テナントのすべてのデータを自然に共存させ、クエリを最適化し、Spannerがテナントごとにデータを分割できるようにします。テナントごとのデータベースは、最も強力な論理的分離を提供します。

Cloud SQLデータベースで、クエリパフォーマンスの低下と高いCPU使用率が発生している。

→Query Insightsを使用して、最もリソースを消費するクエリを特定し、その実行計画を分析し、不足しているインデックスや非効率なパターンを特定します。

理由: Query Insightsは、Cloud SQLでのクエリパフォーマンス診断のための主要な組み込みツールです。クエリ負荷を視覚化し、待機イベントを特定し、サードパーティツールなしで根本原因を特定するのに役立ちます。

複数のGCPプロジェクトにまたがる数十のデータベースインスタンスに対して、単一のダッシュボードとアラートポリシーセットが必要。

→中央プロジェクトにCloud Monitoringワークスペースを作成し、その「メトリックスコープ」をデータベースインスタンスを含むすべてのプロジェクトを含むように構成します。

理由: メトリックスコープにより、単一のMonitoringワークスペースで複数のプロジェクトからのメトリックを集約して表示できるため、データの重複や複雑な構成なしに統合されたビューを提供します。

開発、ステージング、本番環境全体でCloud SQLインスタンスを一貫性があり、バージョン管理された方法でプロビジョニングおよび管理する必要がある。

→Google CloudプロバイダでTerraformを使用します。Cloud SQLモジュールを定義し、各環境に個別の `.tfvars` ファイルを使用します。

理由: TerraformはInfrastructure as Code (IaC) を提供し、反復可能で監査可能、かつバージョン管理されたデプロイを可能にします。これにより、手動での構成エラーを回避し、環境間の一貫性を確保します。

契約者が4時間後に自動的に取り消される一時的な管理者権限のデータベースアクセスを必要としている。

→時間ベースの式 (`request.time < timestamp(...)`) を使用するIAM Conditionで、必要なIAMロールを付与します。

理由: IAM Conditionsは、エラーが発生しやすい手動でのクリーンアップなしに、時間制限付きアクセスを付与するためのネイティブで安全な方法を提供します。タイムスタンプの期限が切れると、アクセスは自動的に拒否されます。

セキュリティポリシーにより、すべてのデータベースディスク暗号化が、管理されたキーローテーションを伴うカスタマーマネージドキー (CMEK) を使用する必要がある。

→Cloud KMSのキーを使用するようにCloud SQLまたはAlloyDBインスタンスを構成します。KMSキーで自動ローテーションを構成します。

理由: CMEKは、保存時の暗号化に使用されるキーに対する制御と監査可能性を提供します。Cloud KMSは、自動ローテーションを含むキーライフサイクル管理をシームレスに処理します。

コンプライアンス要件により、Cloud SQL for PostgreSQLインスタンスで実行されたすべてのSQLクエリをキャプチャし、ログを7年間保持する必要がある。

→インスタンスで `pgaudit` 拡張機能を有効にします。データアクセス用にCloud Audit Logsを構成します。Cloud LoggingからBigQueryへのログシンクを作成し、長期保存と分析を行います。

理由: pgauditは詳細なSQLレベルの監査を提供します。ログをBigQueryにシンクすることは、Cloud Loggingのデフォルトを超える長期的な検索可能なログ保持のための標準的で費用対効果の高いパターンです。

データアナリストが、トランザクションワークロードに影響を与えることなく、本番のCloud SQLデータに対して重い分析クエリを実行する必要がある。

→リードレプリカを作成し、すべての分析クエリをそこへ向けます。より複雑な分析のためには、リードレプリカに対してBigQueryフェデレーテッドクエリを使用します。

理由: リードレプリカは分析読み取りトラフィックをプライマリインスタンスから完全に分離し、OLTPパフォーマンスを保護します。フェデレーションにより、個別のETLパイプラインなしでBigQueryの強力なエンジンを使用できます。

BigtableクラスターでCPU負荷が不均一であり、一部のノードが heavily utilized され、他のノードがアイドル状態になっている場合、パフォーマンスのボトルネックを示している。

→Cloud ConsoleのKey Visualizerツールを使用して、アクセスパターンを分析し、頻繁にアクセスされている特定の行キー範囲 (ホットスポッティング) を特定します。

理由: Key Visualizerは、Bigtableのパフォーマンス問題診断のために特別に構築されたツールです。キーアクセスのヒートマップを提供し、スキーマの再設計によって対処する必要があるホットスポットを容易に特定できます。

Cloud SQL OLTPデータベースからの変更をBigQueryデータウェアハウスにほぼリアルタイムでレプリケートする必要がある。

→Datastreamを使用して、ソースのCloud SQLインスタンスからBigQueryへ直接、Change Data Capture (CDC) ストリームを構成します。

理由: Datastreamは、データベースログを読み取り、ソースへの影響を最小限に抑える、マネージドの低遅延CDCサービスです。スキーマドリフトを処理し、変更をBigQueryに確実に配信します。

Cloud Runアプリケーションが、トラフィックスパイク時の急速なスケールアップにより、データベース接続を使い果たしている。

→Cloud SQL Auth Proxyをサイドカーコンテナとしてデプロイし、接続プーリング用に構成します (またはPgBouncerのような専用のプーラーと組み合わせて使用します)。

理由: サーバーレスプラットフォームは数千のインスタンスにスケール可能であり、データベース接続の制限を圧倒することがあります。接続プーラーは、これら多数の一時的なアプリケーション接続を、少数の安定したデータベース接続セットに多重化します。

大規模な (5TB) オンプレミスMySQLデータベースを、最大ダウンタイム30分でCloud SQL for MySQLに移行する。

→Database Migration Service (DMS) を使用して、連続レプリケーションジョブを構成します。DMSは初期ロードを実行し、カットオーバーまで変更をストリーミングします。

理由: DMSは、最小ダウンタイム移行のためのマネージドソリューションです。連続レプリケーションとは、ダウンタイムが書き込みを停止し、最終同期を待って、アプリケーションを新しいデータベースにポイントする時間のみであることを意味します。

リファレンス↗

複雑なPL/SQLストアドプロシージャを含むOracleデータベースをAlloyDB for PostgreSQLに移行する。

→データ移行にはDMSを使用します。スキーマ変換ツール (Ora2PgやDMSスキーマ変換など) を使用してスキーマとPL/SQLをPL/pgSQLに変換し、その後手動レビューとテストを行います。

理由: 異種移行には、データ移行 (DMSが処理) とスキーマ/コード変換の両方が必要です。自動化ツールは変換の約80%を処理しますが、Oracle固有の機能には常に手動での作業が必要です。

オンプレミスデータセンターからGoogle Cloudにデータベースを移行した後、データの整合性と完全性を検証する必要がある。

→オープンソースのData Validation Tool (DVT) を使用します。ソースとターゲットの間で、行数、列レベルの集計 (min、max、sum)、および行レベルのハッシュを比較するように構成します。

理由: DVTは、単純な行数を超えて、微妙なデータ破損や変換の問題を検出する、包括的でスケーラブルかつカスタマイズ可能なデータ検証フレームワークを提供します。

シャード化されたMySQLアプリケーションを、単一のグローバルに整合性のあるデータベースに移行する。

→複数の並列Dataflowジョブを使用して、各シャードを単一のCloud Spannerデータベースに同時に移行します。アプリケーションレベルのシャーディングの必要性を排除するためにスキーマを再設計します。

理由: Spannerは、複雑なシャードアーキテクチャを置き換えるように設計されています。Dataflowを使用した並列移行アプローチは、大規模なシャードデータセットをSpannerに統合する最も時間効率の良い方法です。

Windows認証 (Active Directory) を使用するSQL ServerデータベースをCloud SQL for PostgreSQLに移行する。

→IAMデータベース認証を使用して、Cloud SQLをCloud Identityと統合します。GCDS経由でADグループをGoogleグループに同期し、データベースロールをこれらのグループにマッピングします。

理由: このアプローチは、ADの中央集中型グループベースのアクセス制御モデルをクラウドネイティブな方法で再現し、手動でのユーザー/パスワード管理を回避し、既存のID構造を活用します。

アプリケーションをAmazon DynamoDBからCloud Bigtableに移行する。

→DynamoDBの複合主キー (パーティションキー + ソートキー) を、区切り文字 (例: `partitionKey#sortKey`) で区切られた連結されたBigtable行キーにマッピングします。

理由: この行キー設計は、DynamoDB複合キーのクエリ機能を維持し、パーティションキープレフィックスによる効率的なルックアップと、ソートキー部分での範囲スキャンを可能にします。

高可用性Cloud SQLインスタンスに接続するアプリケーションは、手動介入なしにゾーンフェイルオーバーを乗り切る必要がある。

→静的IPアドレスではなく、インスタンス接続名 (project:region:instance) を使用してCloud SQL Auth Proxy経由でデータベースに接続します。

理由: フェイルオーバー中にインスタンスのIPアドレスは変更されます。Auth Proxyとインスタンス接続名は、現在のプライマリインスタンスのIPアドレスに自動的に解決される安定したエンドポイントを提供します。

リファレンス↗

グローバルなSpannerアプリケーションに北米とアジアのユーザーがいる。書き込みは主に北米で発生するが、アジアのユーザーは低遅延の読み取りを必要としている。

→北米 (`nam*`) にリーダーリージョンを持つマルチリージョン構成を使用します。アジアでの読み取りは、ローカルの読み取り専用レプリカによって処理されます。

理由: Spannerでの書き込みはリーダーリージョンを経由するため、書き込み元の近くに配置することで書き込みレイテンシが最小限に抑えられます。他のリージョンのリードレプリカは、グローバルに分散したユーザーに低レイテンシの読み取りを提供します。

AlloyDBをバックエンドとするアプリケーションは、読み取りと書き込みの比率が10:1であり、99.99%の可用性を維持しながら高読み取りトラフィックを処理するためにスケールする必要がある。

→プライマリインスタンスを高可用性で構成し、複数のリードプールインスタンスを追加します。読み取りトラフィックをリードプールに送ります。

理由: AlloyDBの高可用性は99.99%のSLAを提供します。リードプールインスタンスは水平読み取りスケーリング向けに設計されており、プライマリインスタンスからのトラフィックを専用の読み取り最適化ノードにオフロードします。

SSDストレージを持つレイテンシに敏感なCloud SQLインスタンスのI/Oパフォーマンスが不十分である。

→インスタンスのプロビジョニングされたストレージサイズを増やします。

理由: Cloud SQLでは、読み取りと書き込みのIOPSはプロビジョニングされた永続ディスクストレージの量に比例してスケーリングされます。ディスクサイズを増やすことが、利用可能なIOPSを増やす直接的な方法です。

重要なCloud SQLデータベースに、迅速なロールバック機能を備えたリスクの高いスキーマ変更をデプロイする必要がある。

→本番 (青) インスタンスのリードレプリカを作成します。レプリカをスタンドアロンインスタンス (緑) に昇格させ、スキーマ変更を適用し検証します。その後、アプリケーションのトラフィックを緑インスタンスにリダイレクトします。ロールバックのために青インスタンスは稼働させ続けます。

理由: このパターンにより、稼働中のシステムに影響を与えることなく、本番規模のデータコピーで変更を完全にテストできます。トラフィックは即座に切り替え可能であり、ロールバックはトラフィックを青インスタンスに戻すのと同じくらい簡単です。

本番環境に影響を与えることなく、データベースの災害復旧計画を四半期ごとにテストする必要がある。

→最近の本番バックアップから復元して一時的なテストインスタンスを作成します。このテストインスタンスに対して、シミュレートされたフェイルオーバーやアプリケーションの再接続テストを含む、文書化されたDR手順を実行します。

理由: 復元されたバックアップでのテストは、本番環境の停止を引き起こすリスクなしに、RTO/RPOと復旧手順を検証するための現実的な環境を提供します。

Cloud Runサービスが、パブリックインターネットを介さずに、Cloud SQLインスタンスに安全に接続する必要がある。

→Cloud SQLをプライベートIPで構成します。同じVPCにServerless VPC Accessコネクタを作成し、Cloud Runサービスがそれを経由してトラフィックをルーティングするように構成します。

理由: これは、サーバーレスコンピューティングをVPCネイティブなリソースに接続するための標準的で安全なパターンです。コネクタはサーバーレス環境とVPCを橋渡しし、すべてのトラフィックをGoogleのプライベートネットワーク上に維持します。

大規模でアクティブに書き込まれているCloud Spannerテーブルに、ダウンタイムなしで新しい非NULL可能カラムを追加する。

→1. カラムをNULL可能として追加します。 2. アプリケーションコードを更新して新しいカラムに書き込みます。 3. Dataflowを使用して既存の行をバッチでバックフィルします。 4. バックフィル後、カラムをNOT NULLに変更します。

理由: この複数ステップのプロセスは、大規模テーブル向けの標準的なオンラインスキーマ変更パターンです。テーブルを長期間ロックしたり、単一のトランザクションで大規模かつパフォーマンスに影響を与えるバックフィル操作を引き起こしたりすることを回避します。