一般的に推奨される利用方法

このページでは、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 インスタンスをスケーリングしてメモリのサイズを増やします。インスタンスのメモリサイズを変更するには、インスタンスを再起動する必要があります。インスタンスがすでに CPU の最大数に達している場合は、データベースを複数のインスタンスにシャーディングする必要があります。Google Cloud コンソールで両方の指標をモニタリングする方法については、指標をご覧ください。

データアーキテクチャ

ベストプラクティス	詳細
大規模なインスタンスを、可能な限り小規模なインスタンスに分割します。	可能であれば、大規模なインスタンスを 1 つ使用するより、小規模な Cloud SQL インスタンスを多数使用することをおすすめします。大規模なモノリシックインスタンスを管理する場合、小規模なインスタンスグループでは生じない問題に直面します。
あまりに多くのデータベースやデータベーステーブルを使用しないでください。	データベースの数は 500 未満にしておきます。インスタンスのテーブル数は 50,000 未満、または、コア数 32 コア以上、メモリ 200 G 以上の最小ハードウェア要求を満たしている場合は 500,000 未満に維持します。各データベースのテーブル数は 50,000 テーブル未満にしておきます。データベースまたはデータベーステーブルが多すぎると、データベースのアップグレード時間に影響するおそれがあります。
テーブルに主キーまたは一意のキーがあることを確認してください。	Cloud SQL は行ベースのレプリケーションを使用します。これは、主キーまたは一意のキーを持つテーブルで最も効果的です。

アプリケーションの実装

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

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

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

バックアップとリカバリ

ベストプラクティス	詳細
適切な Cloud SQL 機能を使用してデータを保護してください。	バックアップ、ポイントインタイムリカバリ、エクスポートは、データの冗長性を確保して保護するための手段です。これらは異なるシナリオでそれぞれ機能し、堅牢なデータ保護戦略でお互いを補います。バックアップは簡単で、インスタンスのデータをバックアップ作成時の状態に復元する手段を提供します。ただし、バックアップにはいくつかの制限があります。インスタンスを削除すると、バックアップも削除されます。単一のデータベースまたはテーブルをバックアップすることはできません。また、インスタンスが配置されているリージョンを使用できない場合、使用可能なリージョンにあるバックアップからそのインスタンスを復元することはできません。ポイントインタイムリカバリにより、インスタンスを特定のポイントインタイムに復旧できます。たとえば、エラーによってデータが失われた場合、エラーが発生する前の状態にデータベースを復旧できます。ポイントインタイムリカバリは、常に新しいインスタンスを作成します。既存のインスタンスには、ポイントインタイムを実行できません。データの再作成に使用できる外部ファイルが Cloud Storage に作成されるため、エクスポートは作成するのに時間がかかります。インスタンスを削除しても、エクスポートは影響を受けません。また、選択するエクスポート形式に応じて、単一のデータベースまたはテーブルだけをエクスポートすることもできます。
トランザクション（バイナリ）ログの保持を考慮してインスタンスのサイズを調整します。	データベースに対する書き込みが多いと、大量のトランザクション（バイナリ）ログが生成され、かなりのディスクスペースを消費する可能性があり、ストレージの自動増量が有効になっているインスタンスではディスクが増大する原因になります。インスタンスのストレージサイズは、トランザクションログの保持を考慮して調整することをおすすめします。
インスタンスとバックアップを誤って削除しないように保護します。	Google Cloud コンソールや Terraform を使用して作成した Cloud SQL インスタンスを使用すると、デフォルトで誤削除を防止できます。 Cloud SQL のエクスポート機能を使用してデータをエクスポートすると、さらに保護を強化できます。Cloud Scheduler と REST API を使用して、エクスポートの管理を自動化します。より高度なシナリオでは、Cloud Scheduler を Cloud Functions で自動化します。

ベストプラクティス

詳細

適切な Cloud SQL 機能を使用してデータを保護してください。

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

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

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

データの再作成に使用できる外部ファイルが Cloud Storage に作成されるため、エクスポートは作成するのに時間がかかります。インスタンスを削除しても、エクスポートは影響を受けません。また、選択するエクスポート形式に応じて、単一のデータベースまたはテーブルだけをエクスポートすることもできます。

トランザクション（バイナリ）ログの保持を考慮してインスタンスのサイズを調整します。

データベースに対する書き込みが多いと、大量のトランザクション（バイナリ）ログが生成され、かなりのディスクスペースを消費する可能性があり、ストレージの自動増量が有効になっているインスタンスではディスクが増大する原因になります。インスタンスのストレージサイズは、トランザクションログの保持を考慮して調整することをおすすめします。

インスタンスとバックアップを誤って削除しないように保護します。

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

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

次のステップ

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