一般的なベスト プラクティス

このページでは、Cloud SQL のパフォーマンス、耐久性、可用性を高めるためのおすすめの方法を示します。

Cloud SQL インスタンスで問題が発生した場合は、トラブルシューティングの際に次の点を確認してください。

インスタンスの構成と管理

ベスト プラクティス 詳細
オペレーション ガイドラインを参照し、その手順に沿ってご使用のインスタンスが Cloud SQL SLA の対象であることを確認してください。
中断更新がいつ発生するかを制御するため、プライマリ インスタンスのメンテナンスの時間枠を構成してください。 メンテナンスの時間枠をご覧ください。
読み取り負荷の高いワークロードについては、リードレプリカを追加してプライマリ インスタンスからトラフィックをオフロードしてください。 必要に応じて、HAProxy などのロードバランサを使用して、レプリカへのトラフィックを管理できます。
インスタンスを定期的に削除して再作成する場合は、新しいインスタンス ID が使用可能になる確率を高めるため、インスタンス ID にタイムスタンプを使用してください。
前のオペレーションが完了する前に管理オペレーションを開始しないでください。

Cloud SQL インスタンスは、前のオペレーションが完了するまで、新しいオペレーション リクエストを受け付けません。準備が整う前に新しいオペレーションを開始しようとすると、オペレーション リクエストは失敗します。こうしたオペレーションには、インスタンスの再起動も含まれます。

Google Cloud コンソールのインスタンス ステータスには、オペレーションが実行されているかどうかは反映されません。緑色のチェックマークは、インスタンスが RUNNABLE 状態にあることのみを示します。オペレーションが実行中かどうかを確認するには、[オペレーション] タブに移動して、最新のオペレーションのステータスをチェックします。
重要なデータベースのメンテナンスに対応するストレージを構成します。

インスタンス設定のストレージの自動増量を有効にするが無効になっているか、ストレージの自動増量の上限が有効になっている場合、Cloud SQL が実行する可能性のある重要なデータベース メンテナンス オペレーションに対応できるよう、少なくとも 20% の空き容量を確保します。

利用可能なディスク容量が 20% を下回った場合にアラートを受信するには、ディスク使用率指標に対して指標ベースのアラート ポリシーを作成し、しきい値を上回る条件とし、値を 0.8 に設定します。詳細については、指標ベースのアラート ポリシーを作成するをご覧ください。
CPU の過剰使用を防ぎます。

使用可能な CPU のうちインスタンスが使用している割合は、Google Cloud コンソールのインスタンスの詳細ページで確認できます。詳細については、指標をご覧ください。また、指標しきい値のアラート ポリシーを作成するを使用して、CPU 使用率をモニタリングし、指定したしきい値でアラートを受信することもできます。

過剰な使用を回避するためには、インスタンスの CPU 数を増やします。CPU 数を変更するには、インスタンスの再起動が必要です。インスタンスがすでに CPU の最大数に達している場合は、データベースを複数のインスタンスにシャーディングする必要があります。
メモリ不足を回避します。

メモリ不足の兆候を調べる際は、主に使用量指標を使用してください。メモリ不足のエラーを回避するには、この指標を 90% 未満に保つことをおすすめします。

また、総使用量指標を使用すると、データベース コンテナが使用しているメモリやオペレーティング システムのキャッシュが割り当てたメモリなどを含め、Cloud SQL インスタンスで使用されている使用可能なメモリの割合を確認できます。

これら 2 つの指標の差を観察することで、プロセスによって使用されているメモリの量と、オペレーティング システムのキャッシュで使用されているメモリの量を把握できます。このキャッシュ内のメモリは再利用できます。

メモリ不足の問題を予測するには、両方の指標を確認してまとめて解釈します。指標が高い場合は、インスタンスのメモリが不足している場合があります。要因としては、カスタム構成によるもの、ワークロードに対してインスタンスのサイズが小さすぎる場合、またはこれらの要因の組み合わせの可能性があります。

Cloud SQL インスタンスをスケーリングしてメモリのサイズを増やします。インスタンスのメモリサイズを変更するには、インスタンスを再起動する必要があります。インスタンスがすでに最大メモリサイズに達している場合は、データベースを複数のインスタンス間でシャーディングする必要があります。Google Cloud コンソールで両方の指標をモニタリングする方法については、指標をご覧ください。
インスタンスに最適なトランザクション ID があることを確認してください。

Google Cloud コンソールの Metrics Explorer ページで、Resource Type を Cloud SQL Database として、Metric を Percentage of instance's transaction IDs consumed として設定すると、インスタンスのトランザクション ID の使用率を表示できます。詳細については、Metrics Explorer でグラフを作成するをご覧ください。

データベース インスタンスのチューニングとモニタリングは、バキュームに関する問題の軽減または回避に役立ちます。インスタンスのトランザクション ID の使用率をモニタリングし、インスタンスのワークロードに応じて autovacuum パラメータを有効にして調整します。詳しくは、トランザクション ID（TXID）のラップアラウンド保護を解消するをご覧ください。

データ アーキテクチャ

ベスト プラクティス 詳細
大規模なインスタンスを、可能な限り小規模なインスタンスに分割します。 可能であれば、大規模なインスタンスを 1 つ使用するより、小規模な Cloud SQL インスタンスを多数使用することをおすすめします。大規模なモノリシック インスタンスを管理する場合、小規模なインスタンス グループでは生じない問題に直面します。
あまりに多くのデータベース テーブルを使用しないでください。

インスタンスのテーブル数を常に 10,000 個未満にします。データベース テーブルが多すぎると、データベースのアップグレードに時間がかかる可能性があります。

アプリケーションの実装

ベスト プラクティス 詳細
接続プーリングや指数バックオフなどの適切な接続管理方法を使用してください。 これらの手法は、アプリケーションのリソース使用を効率化して Cloud SQL の接続上限内に収めるのに役立ちます。詳細とコードサンプルについては、データベース接続の管理をご覧ください。
メンテナンスの時間枠内でいつでも発生する可能性があるメンテナンス更新に対するアプリケーションのレスポンスをテストしてください。 セルフサービス メンテナンスを試して、メンテナンス更新をシミュレートします。メンテナンス中は、インスタンスが一時的に使用できなくなり、既存の接続が切断されます。メンテナンス ロールアウトをテストすることで、アプリケーションによる定期メンテナンスの処理方法や、システムを迅速に復旧する方法を確認できます。
いつでも発生する可能性があるフェイルオーバーに対するアプリケーションのレスポンスをテストしてください。 Google Cloud コンソール、gcloud CLI、または API を使用すると、手動でフェイルオーバーを開始できます。フェイルオーバーの開始をご覧ください。
大規模なトランザクションは回避します。 トランザクションのサイズを小さくして、短時間で終わるようにしてください。大規模なデータベース更新が必要な場合は、1 つの大規模なトランザクションではなく、複数の小規模なトランザクションを使用してください。
Cloud SQL Auth Proxy を使用している場合は、必ず最新のバージョンを使用してください。 Cloud SQL Auth Proxy の最新状態の維持をご覧ください。

データのインポートとエクスポート

ベスト プラクティス 詳細
サーバーレス エクスポートを使用します。 サーバーレス エクスポートでは、エクスポート オペレーションを一時インスタンスにオフロードします。これにより、プライマリ インスタンスはクエリの実行を継続し、通常のパフォーマンスでオペレーションを実行できます。データのエクスポートが完了すると、一時インスタンスは自動的に削除されます。
小規模なインスタンスのインポートを高速化してください。 小規模なインスタンスでは、一時的にインスタンスの CPU と RAM を追加して、大規模なデータセットをインポートする際のパフォーマンスを強化できます。
Cloud SQL にインポートするデータをエクスポートする場合は、適切な手順を使用してください。 外部管理データベース サーバーからデータをエクスポートするをご覧ください。

バックアップとリカバリ

ベスト プラクティス 詳細
適切な Cloud SQL 機能を使用してデータを保護してください。

バックアップ、ポイントインタイム リカバリ、エクスポートは、データの冗長性を確保して保護するための手段です。これらは異なるシナリオでそれぞれ機能し、堅牢なデータ保護戦略でお互いを補います。

バックアップは簡単で、インスタンスのデータをバックアップ作成時の状態に復元する手段を提供します。ただし、バックアップにはいくつかの制限があります。インスタンスを削除すると、バックアップも削除されます。単一のデータベースまたはテーブルをバックアップすることはできません。また、インスタンスが配置されているリージョンを使用できない場合、使用可能なリージョンにあるバックアップからそのインスタンスを復元することはできません。

ポイントインタイム リカバリにより、インスタンスを特定のポイントインタイムに復旧できます。たとえば、エラーによってデータが失われた場合、エラーが発生する前の状態にデータベースを復旧できます。ポイントインタイム リカバリは、常に新しいインスタンスを作成します。既存のインスタンスには、ポイントインタイムを実行できません。

データの再作成に使用できる外部ファイルが Cloud Storage に作成されるため、エクスポートは作成するのに時間がかかります。インスタンスを削除しても、エクスポートは影響を受けません。また、選択するエクスポート形式に応じて、単一のデータベースまたはテーブルだけをエクスポートすることもできます。
トランザクション（バイナリ）ログの保持を考慮してインスタンスのサイズを調整します。 データベースに対する書き込みが多いと、大量のトランザクション（バイナリ）ログが生成され、かなりのディスク スペースを消費する可能性があり、ストレージの自動増量が有効になっているインスタンスではディスクが増大する原因になります。インスタンスのストレージ サイズは、トランザクション ログの保持を考慮して調整することをおすすめします。
インスタンスとバックアップを誤って削除しないように保護します。

Google Cloud コンソールや Terraform で作成した Cloud SQL インスタンスを使用すると、デフォルトで誤削除を防止できます。

保護を強化するため、Cloud SQL のエクスポート機能を使用してデータをエクスポートします。Cloud Scheduler と REST API を使用して、エクスポートの管理を自動化します。より高度なシナリオでは、Cloud Scheduler と Cloud Run 関数を使用して自動化します。

チューニングとモニタリング

データベース インスタンスのチューニングとモニタリングは、バキュームに関する問題の軽減または回避に役立ちます。

VACUUM オペレーションには、異なるロックレベルの異なるバリアントがあります（標準 VACUUM と VACUUM FULL）。VACUUM FULL オプションでは、より多くのディスク スペースを再利用できますが、テーブルが排他的にロックされ、実行速度が低下します。代わりに、本番環境のデータベース オペレーションと並行して実行できる標準形式の VACUUM を使用します。VACUUM オペレーションを使用すると、SELECT, INSERT, UPDATE, and DELETE などのコマンドは引き続き正常に機能します。バキューム中は、ALTER TABLE などのコマンドでテーブルの定義を変更することはできません。

VACUUM オペレーションの完了に要する時間の短縮に役立ついくつかの推奨事項を以下に示します。

  • システムメモリと maintenance_work_mem を増やします。これにより、各イテレーションでより多くのタプルがバッチ処理され、作業の完了が限界まで早くなります。なお、自動バキュームの実行時は、このメモリを最大 autovacuum_max_workers の回数分割り当てできるため、デフォルト値は大きくしすぎないようにしてください。
  • VACUUM オペレーションでは、多数の write-ahead log（WAL）のレコードが生成されます。このインスタンスにレプリカが構成されていないなど、WAL のレコード数を減らすことができる場合、オペレーションはより迅速に完了します。
  • タプルが凍結されていないためにテーブルが 上限の 20 億トランザクション ID に達していた場合は、シングルユーザー モードで行われる作業量を減らしてみてください。選択肢の 1 つは、vacuum_freeze_min_age=1,000,000,000 を設定（デフォルト値の 50,000,000 から許容される最大値に変更）することです。この新しい値により、フリーズするタプルの数が最大 2 倍削減されます。
  • PostgreSQL バージョン 12.0 以降では、インデックス エントリをクリーンアップせずにクリーンアップと VACUUM オペレーションがサポートされます。インデックスをクリーンアップするには完全なインデックス スキャンが必要であることから、複数のインデックスが存在する場合、合計時間はインデックスのサイズによって異なるため、これは非常に重要です。
  • インデックスが大きいほど、インデックス スキャンにかなりの時間がかかるため、テーブルデータを素早くクリーンアップして、フリーズするために INDEX_CLEANUP OFF することをおすすめします。12.0 より前のバージョンの PostgreSQL では、インデックスの数を調整する必要があります。つまり、クリティカルでないインデックスがある場合は、NON-CRITICAL インデックスを削除して、バキューム オペレーションを高速化するとよい場合があります。

次のステップ

データベース エンジンによる一般的なプラクティスの詳細については、以下をご覧ください。