このページでは、Cloud SQL のパフォーマンス、耐久性、可用性を高めるためのベスト プラクティスを示します。
Cloud SQL インスタンスで問題が発生した場合は、トラブルシューティングの際に次の点を確認してください。
インスタンスの構成と管理
| ベスト プラクティス | 詳細 |
|---|---|
| オペレーション ガイドラインを参照し、その手順に沿ってご使用のインスタンスが Cloud SQL SLA の対象であることを確認してください。 | |
| 中断更新がいつ発生するかを制御するため、プライマリ インスタンスのメンテナンスの時間枠を構成してください。 | メンテナンスの時間枠をご覧ください。 |
| インスタンスを定期的に削除して再作成する場合は、新しいインスタンス ID が使用可能になる確率を高めるため、インスタンス ID にタイムスタンプを使用してください。 | |
| 前のオペレーションが完了する前に管理オペレーションを開始しないでください。 |
Cloud SQL インスタンスは、前のオペレーションが完了するまで、新しいオペレーション リクエストを受け付けません。準備が整う前に新しいオペレーションを開始しようとすると、オペレーション リクエストは失敗します。こうしたオペレーションには、インスタンスの再起動も含まれます。
Google Cloud コンソールのインスタンス ステータスには、オペレーションが実行されているかどうかは反映されません。緑色のチェックマークは、インスタンスが |
| 重要なデータベースのメンテナンスに対応するストレージを構成します。 |
インスタンス設定のストレージの自動増量を有効にするが無効になっているか、ストレージの自動増量の上限が有効になっている場合は、Cloud SQL が実行する可能性のある重要なデータベース メンテナンス オペレーションに対応できるよう、少なくとも 20% の空き容量を確保します。 利用可能なディスク容量が 20% を下回った場合にアラートを受信するには、ディスク使用率指標に対して指標ベースのアラート ポリシーを作成し、しきい値を超える位置、また値を 0.8 に設定します。詳細については、指標ベースのアラート ポリシーを作成するをご覧ください。 |
| CPU の過剰使用を防ぎます。 |
使用可能な CPU のうち、インスタンスが使用している割合は、Google Cloud コンソールのインスタンスの詳細ページで確認できます。詳細については、指標をご覧ください。また、指標しきい値のアラート ポリシーを作成するを使用して、CPU 使用率をモニタリングし、指定したしきい値でアラートを受信することもできます。 過剰な使用を回避するために、インスタンスの CPU 数を増やせます。CPU を変更するには、インスタンスの再起動が必要です。インスタンスがすでに CPU の最大数に達している場合は、データベースを複数のインスタンスにシャーディングする必要があります。 |
| メモリ不足を回避します。 |
メモリ不足の兆候を調べる際は、主に使用量指標を使用してください。メモリ不足のエラーを回避するには、この指標を 90% 未満に保つことをおすすめします。 また、総使用量指標を使用して、データベース コンテナが使用しているメモリやオペレーティング システムのキャッシュが割り当てたメモリなど、Cloud SQL インスタンスで使用されている使用可能なメモリの割合を確認することもできます。 2 つの指標の差を観察することで、プロセスによって使用されているメモリの量とオペレーティング システムのキャッシュで使用されているメモリの量を把握できます。このキャッシュ内のメモリは再利用できます。 メモリ不足の問題を予測するには、両方の指標を確認してまとめて解釈します。指標が高い場合は、インスタンスのメモリが不足している可能性があります。要因としては、カスタム構成、ワークロードに対してインスタンスのサイズが不足している、またはこれらの組み合わせの可能性があります。 Cloud SQL インスタンスをスケーリングしてメモリのサイズを増やします。インスタンスのメモリサイズを変更するには、インスタンスを再起動する必要があります。インスタンスがすでに最大メモリサイズになっている場合は、データベースを複数のインスタンス間でシャーディングする必要があります。Google Cloud コンソールで両方の指標をモニタリングする方法について、詳細は指標をご覧ください。 |
| Cloud SQL で最適に動作するよう SQL Server を設定してください。 | SQL Server の設定をご覧ください。 |
| テスト実行に合わせてインスタンスを最適に調整してください。 | 次の表は、テスト実行に適した構成値を示しています。
|
| SQL Server をデプロイする前に、I/O サブシステムの容量を決定してください。 | さまざまな I/O タイプとサイズをテストします。SQL Server の永続ディスク ストレージに発行される I/O のサイズは、IOPS とスループットに影響します。SQL Server のワークロードが IOPS の上限またはスループットの上限に達すると、ワークロードが制限されます。Cloud SQL で使用されているストレージ タイプは PD SSD で、高パフォーマンスのエンタープライズ レベルのワークロードに適しています。 次のように VM をカスタマイズして、パフォーマンスを最大化してください。
|
| インデックスの断片化やインデックスの欠落を防ぎます。 | データの変更頻度に応じて、インデックスを再編成するか、インデックスを再構築するようにスケジュールを設定します。また、断片化を減らすために適切なフィルファクタを設定します。SQL Server でインデックスの欠落をモニタリングします。これを防ぐことでパフォーマンスが向上する可能性があります。 |
| 統計情報を定期的に更新してください。 | 統計情報が古くなっている場合、SQL クエリ オプティマイザーによって最適ではないクエリプランが生成される可能性があります。特に、大量のデータが変更された後は、統計情報を更新するようにしてください。クエリストアを使用して、最適ではないクエリプランを持つ SQL Server をモニタリングし、トラブルシューティングします。 |
| データベース ファイルが不必要に大きくなるのを防ぎます。 |
さらに、Cloud SQL でストレージの自動増量を有効にする機能を有効にして、データベースとインスタンスの空き容量が不足している場合に Cloud SQL が保存容量を追加できるようにします。 |
データベースの整合性の問題を検出するには、少なくとも 1 週間に 1 度、DBCC CHECKDB を実行します。 |
DBCC CHECKDB は、データベース内のすべてのオブジェクトの整合性をチェックします。DBCC CHECKDB を毎週実行することで、データベースが破損していないことを確認できます。DBCC CHECKDB はリソースを大量に消費するオペレーションであり、インスタンスのパフォーマンスに影響する可能性があります。本番環境サーバーで DBCC CHECKDB を実行しないでください。本番環境サーバーで DBCC CHECKDB を実行する代わりに、次のいずれかのオプションを使用することをおすすめします。
データベースで
|
データ アーキテクチャ
| ベスト プラクティス | 詳細 |
|---|---|
| 大規模なインスタンスを、可能な限り小規模なインスタンスに分割します。 | 可能であれば、大規模なインスタンスを 1 つ使用するより、小規模な Cloud SQL インスタンスを多数使用することをおすすめします。大規模なモノリシック インスタンスを管理する場合、小規模なインスタンス グループでは生じない問題に直面します。 |
| あまりに多くのデータベース テーブルを使用しないでください。 |
インスタンスのテーブル数を常に 10,000 個未満にします。データベース テーブルが多すぎると、データベースのアップグレードに時間がかかる可能性があります。 |
| データベースの照合 |
SQL Server の新しいインスタンスのインストール、データベースのバックアップの復元、サーバーとクライアント データベースの接続のいずれにおいても、使用するデータのロケール要件、並べ替え順序、大文字と小文字の区別を理解しておくことが重要です。サーバー、データベース、列、または式に対して照合を選択すると、データに特定の特性が割り当てられます。これらの特性は、データベースでの多くのオペレーションの結果に影響します。たとえば、ORDER BY を使用してクエリを作成するときに、結果セットの並べ替え順序は、データベースに適用される照合順序や、COLLATE 句で指定される照合順序によって異なる場合があります。詳細については、データベース照合と Unicode のサポートをご覧ください。 |
| クエリの設計 | データベースまたはクエリのパフォーマンスを最適化するため、同じクエリ内で多数のテーブル（16 個以上）を使用していないことを確認します。 |
| クエリのモニタリング |
クエリは時間の経過とともに劣化する場合があります。アプリケーションとクエリのパフォーマンスを継続してモニタリングすることが重要です。劣化する理由の一つはハッシュ ベイルアウトです。 再帰的なハッシュ結合やハッシュ ベイルアウトはサーバーのパフォーマンスを低下させます。トレースにハッシュ警告イベントが多数含まれている場合は、結合されている列の統計情報を更新します。詳しくは、ハッシュ ベイルアウトをご覧ください。 |
アプリケーションの実装
| ベスト プラクティス | 詳細 |
|---|---|
| 接続プーリングや指数バックオフなどの適切な接続管理方法を使用してください。 | これらの手法は、アプリケーションのリソース使用を効率化して Cloud SQL の接続上限内に収めるのに役立ちます。詳細とコードサンプルについては、データベース接続の管理をご覧ください。 |
| メンテナンスの時間枠内でいつでも発生する可能性があるメンテナンス更新に対するアプリケーションのレスポンスをテストしてください。 | セルフサービス メンテナンスを試して、メンテナンス更新をシミュレートします。メンテナンス中は、インスタンスが一時的に使用できなくなり、既存の接続が切断されます。メンテナンス ロールアウトをテストすることで、アプリケーションによる定期メンテナンスの処理方法や、システムを迅速に復旧する方法を確認できます。 |
| いつでも発生する可能性があるフェイルオーバーに対するアプリケーションのレスポンスをテストしてください。 | 手動でフェイルオーバーを開始するには、Google Cloud コンソール、gcloud CLI、または API を使用できます。フェイルオーバーの開始をご覧ください。 |
| 大規模なトランザクションは回避します。 | トランザクションのサイズを小さくして、短時間で終わるようにしてください。大規模なデータベース更新が必要な場合は、1 つの大規模なトランザクションではなく、複数の小規模なトランザクションを使用してください。 |
| Cloud SQL Auth Proxy を使用している場合は、必ず最新のバージョンを使用してください。 | Cloud SQL Auth Proxy の最新状態の維持をご覧ください。 |
データのインポートとエクスポート
| ベスト プラクティス | 詳細 |
|---|---|
| 小規模なインスタンスのインポートを高速化してください。 | 小規模なインスタンスでは、一時的にインスタンスの CPU と RAM を追加して、大規模なデータセットをインポートする際のパフォーマンスを強化できます。 |
| Cloud SQL にインポートするデータをエクスポートする場合は、適切な手順を使用してください。 | 外部管理データベース サーバーからデータをエクスポートするをご覧ください。 |
バックアップとリカバリ
| ベスト プラクティス | 詳細 |
|---|---|
| 適切な Cloud SQL 機能を使用してデータを保護してください。 |
バックアップとエクスポートは、データの冗長性を確保して保護するための方法です。それらはそれぞれ異なるシナリオで機能し、堅牢なデータ保護戦略でお互いを補います。 バックアップは簡単で、インスタンスのデータをバックアップ作成時の状態に復元する手段を提供します。ただし、バックアップにはいくつかの制限があります。インスタンスを削除すると、バックアップも削除されます。単一のデータベースまたはテーブルをバックアップすることはできません。また、インスタンスが配置されているリージョンを使用できない場合、使用可能なリージョンにあるバックアップからそのインスタンスを復元することはできません。 データの再作成に使用できる外部ファイルが Cloud Storage に作成されるため、エクスポートは作成するのに時間がかかります。インスタンスを削除しても、エクスポートは影響を受けません。また、選択するエクスポート形式に応じて、単一のデータベースまたはテーブルだけをエクスポートすることもできます。 Enterprise または標準 SQL Server インスタンスでエクスポート バックアップ機能を使用する場合は、SQL Server によってすでにネイティブに圧縮されているバックアップを圧縮しようとするため、GZ アーカイブ ファイルの作成は避けてください。 |
| インスタンスとバックアップを誤って削除しないように保護します。 | Google Cloud コンソールや Terraform で作成した Cloud SQL インスタンスを使用すると、デフォルトで誤削除を防止できます。 保護を強化するため、Cloud SQL のエクスポート機能を使用してデータをエクスポートします。Cloud Scheduler と REST API を使用して、エクスポートの管理を自動化します。より高度なシナリオでは、Cloud Scheduler と Cloud Functions を使用して自動化します。 |
SQL Server の設定
Cloud SQL には SQL Server の一部の設定が推奨されています。以下のトピックでは、いくつかの推奨事項について説明します。
グローバル構成
| 設定 | 推奨事項 |
|---|---|
max worker threads
|
デフォルト値の 0 のままにします。この設定は、CPU の数に基づいて SQL Server で使用可能なスレッド数を定義します。この値は、起動時に SQL Server エンジンによって自動的に計算されます。 |
変更するデータベース設定
SQL Server データベースのパフォーマンスを最適化するには、次に示す SQL Server 設定をおすすめします。
| 設定 | 推奨事項 |
|---|---|
cost threshold for parallelism |
これは、SQL オプティマイザーが並列処理でクエリを実行する場合のしきい値です。デフォルト値の
|
max degree of parallelism (MAXDOP) |
並列処理によるデータベースの待機時間を短縮するには、使用可能な論理プロセッサの数に関する具体的な推奨事項に基づいて、この値を調整します。このオプションを 1 に設定すると、パフォーマンスが慎重に測定されます。 |
optimize for ad hoc workloads |
プランのキャッシュに、単回使用のプランを多数設定しないでください。単回使用のアドホック バッチを多く含むワークロードでプラン キャッシュの効率を向上させるには、このオプションを |
tempdb |
自動拡張が不要になるように、
プロセッサの数が 8 以下の場合は、論理プロセッサと同じファイル数を使用します。プロセッサ数が 8 を超える場合は、8 個のデータファイルを使用します。競合が解決しない場合は、競合が発生しなくなるまでファイルの数を増やします（4 の倍数になるように増やします）。 |
ワークロードによっては、次の設定も変更することをおすすめします。
| 設定 | 推奨事項 |
|---|---|
Close Cursor on Commit Enabled |
デフォルト値は off です。これは、トランザクションを commit してもカーソルは自動的にクローズしないことを意味します。 |
Default Cursor |
このオプションは、T-SQL コードで使用されるカーソルのスコープを制御します。この設定を変更する場合は、アプリケーション コードに悪影響がないかどうかを評価してください。 |
Page Verify |
このオプションを使用すると、SQL Server がディスクに書き込みを行う前にデータベース ページのチェックサムを計算し、ページヘッダーに格納できます。ページを再度読み込むと、チェックサムが再計算され、ページの整合性が検証されます。推奨値は checksum です。 |
Parameterization |
デフォルト値は simple です。SQL Server では、シンプルなパラメータ化により、クエリ内のリテラル値をパラメータに置換できます。Microsoft は、この値の変更方法やプランガイドで使用する方法に関するガイドラインを提供しています。 |
保持するデータベース設定
SQL Server データベースのパフォーマンスを最適化するには、次の SQL Server の設定のデフォルト値をそのまま使用します。
| 設定 | 保持するデフォルト値 |
|---|---|
Auto Close
|
False。この設定をオンにすると、接続を開始または終了します。また、接続のたびにプロシージャがフラッシュされます。アクセス頻度が高いデータベースでは、パフォーマンスが低下する可能性があります。 |
Auto Shrink
|
False。これをオンにすると、データベースとインデックスの断片化やその他のパフォーマンスの問題が発生する可能性があります。その他の問題の詳細については、SQL Server のブログをご覧ください。 |
Date Correlation Optimization Enabled
|
False。これを有効にすると、オプティマイザーが関連する 2 つのテーブル間の日付関係を検出し、最適化します。SQL Server でこれを追跡すると、パフォーマンスのオーバーヘッドが発生します。 |
Legacy Cardinality Estimation
|
False。この設定を有効にすると、SQL Server がカーディナリティを正確に計算できない場合があります。 |
Parameter Sniffing
|
ON。データベース テーブルからパラメータ スニッフィングを使用すると、再利用可能な実行計画を作成できます。テーブルのデータが均等に分散していない場合、結果として作成された実行計画でパフォーマンスの問題が発生する可能性があります。このようなデータの場合は、この設定を変更するのではなく、クエリストアの他のオプションを使用してください。 |
Query Optimizer Fixes
|
False。有効にすると、SQL Server カーディナリティ推定のパフォーマンスに影響する可能性があります。有効にする場合は、クエリ回帰がないことをテストで確認します。 |
Auto Create Statistics
|
True。このオプションを使用すると、SQL Server はクエリプランのカーディナリティの推測値を改善できる単一列の統計情報を作成できます。 |
Auto Update Statistics
|
True。このオプションを使用すると、SQL Server は、テーブルのカーディナリティに基づく再コンパイルのしきい値を使用して、古い統計情報を更新します。 |
Auto Update Statistics Asynchronously
|
False。このオプションを有効にすると、現在のクエリ実行に古い統計情報を使用し、将来のワークロードに役立つように統計情報を非同期で更新するように SQL クエリ オプティマイザーに指示します。
ただし、頻繁に実行されるクエリの応答時間が予想される場合や、統計情報の更新を待機している間にクライアント リクエストのタイムアウトが頻繁に発生する場合は、このオプションを有効にして |
Target Recovery Time (Seconds)
|
60。この設定は、ダーティページをバッファプールからディスクにフラッシュする頻度を増減させることにより、データベースの復旧時間の上限を設定します。トランザクションの多いワークロードで、この設定値が低いと、最大値に近いストレージ IOPS が発生したときにパフォーマンスのボトルネックになる可能性があります。 |
トレースフラグの設定
SQL Server のトレースフラグは、特定の特性の設定、SQL Server データベースの動作の変更、SQL Server の問題のデバッグに使用されます。
一部の SQL Server トレースフラグは Cloud SQL でサポートされており、データベース フラグで設定できます。推奨される設定は次のとおりです。
| トレースフラグ | 推奨 |
|---|---|
1204
|
Yes。ただし、デッドロックが頻発するほどワークロードの負荷が高いサーバーは除きます。デッドロックに関与しているロックのリソースとタイプ、現在影響を受けるコマンドを返します。 |
1222
|
Yes。ただし、デッドロックが頻発するほどワークロードの負荷が高いサーバーは除きます。 |
1224
|
No。これにより、メモリ使用量が増加し、データベースのメモリを圧迫する原因となります。 |
2528
|
No。オブジェクトの並列チェックがデフォルトで、これが推奨の設定です。並列度は、データベース エンジンによって自動的に計算されます。 |
3205
|
No。バックアップ用テープドライブは Cloud SQL for SQL Server の機能です。 |
3226
|
No。ただし、TLOG バックアップなど、頻繁なバックアップが必要な場合を除きます。 |
3625
|
No。root アカウントにはシステム管理者権限がないため、一部のエラー メッセージを表示できない場合があります。 |
4199
|
No。これはカーディナリティ推定に影響し、クエリの回帰につながる可能性があります。 |
4616
|
No。この制限により、アプリケーション ロールのセキュリティが低下します。アプリケーションの要件に基づいて検証する必要があります。 |
7806
|
Yes。データベース サーバーが応答しなくなった場合、診断用の接続を確立する際に専用管理者接続（DAC）が唯一の方法になることがあります。 |
次のステップ
データベース エンジンによる一般的なプラクティスの詳細については、以下をご覧ください。