このページは Cloud Translation API によって翻訳されました。

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

MySQL | PostgreSQL | SQL Server

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

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

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

ベストプラクティス	詳細
オペレーションガイドラインを参照し、その手順に沿ってご使用のインスタンスが Cloud SQL SLA の対象であることを確認してください。
中断更新がいつ発生するかを制御するため、プライマリインスタンスのメンテナンスの時間枠を構成してください。	メンテナンスの時間枠をご覧ください。
読み取り負荷の高いワークロードについては、リードレプリカを追加してプライマリインスタンスからトラフィックをオフロードしてください。	必要に応じて、HAProxy などのロードバランサを使用して、レプリカへのトラフィックを管理できます。
インスタンスを定期的に削除して再作成する場合は、新しいインスタンス ID が使用可能になる確率を高めるため、インスタンス ID にタイムスタンプを使用してください。
前のオペレーションが完了する前に管理オペレーションを開始しないでください。	Cloud SQL インスタンスは、前のオペレーションが完了するまで、新しいオペレーションリクエストを受け付けません。準備が整う前に新しいオペレーションを開始しようとすると、オペレーションリクエストは失敗します。こうしたオペレーションには、インスタンスの再起動も含まれます。 Google Cloud Console のインスタンスステータスには、オペレーションが実行されているかどうかは反映されません。緑色のチェックマークは、インスタンスが `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 関数を使用して自動化します。

ベストプラクティス

詳細

適切な 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 オペレーションでは、多数のログ先行書き込み（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 インデックスを削除して、バキュームオペレーションを高速化すると便利な場合があります。

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