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

このページでは、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 コンソールで両方の指標をモニタリングする方法について、詳細は指標をご覧ください。

データ アーキテクチャ

ベスト プラクティス 詳細
大規模なインスタンスを、可能な限り小規模なインスタンスに分割します。 可能であれば、大規模なインスタンスを 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 Run 関数を使用して自動化します。

次のステップ

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