Cloud SQL for MySQL インスタンスの設定に関するベスト プラクティス

Cloud SQL for MySQL は、Google Cloud Platform 上の MySQL リレーショナル データベースの設定、維持、運用、管理を容易にするフルマネージド データベース サービスです。Cloud SQL for MySQL インスタンスを作成する準備ができたら、UI コンソール、gcloud CLI、Terraform、REST API など、いくつかのオプションがあります。それぞれのパスについて詳しくは、こちらのドキュメントをご覧ください。この記事では、設定に関するさまざまなベスト プラクティスを説明するため、UI を使用して説明を進めます。

安全なパスワードを選択する

これは、インスタンスとともに作成されるデフォルトの「root」@”% データベース ユーザーのパスワードです。root ユーザーを管理ユーザーとして残す場合は、ここで安全なパスワードを選択してください。「root」ではなく、あまり一般的でない管理者ユーザーを使用することをおすすめします。確認しました詳しくは「データベース ユーザーの管理」できます。

インスタンス レベルのパスワード ポリシーを作成する

パスワード ポリシー機能を使用すると、データベースのセキュリティを強化できます。パスワードの長さ、複雑さ、有効期限、再利用の制限に関するポリシーを構成できます。詳しくは、MySQL インスタンスの強化をご覧ください。

パフォーマンス向上のために 8.0 を検討する

Cloud SQL MySQL は複数の 8.0 マイナー バージョンをサポートしており、現在のデフォルトは v8.0.26 です。さまざまなマシンタイプでのベンチマーク テストでは、5.7 および 5.6 バージョンよりもデフォルト バージョン 8.0 の方がクエリ スループットに優れています。  

本番環境インスタンスを最新の一般提供バージョンに移行しないでください

Oracle と Cloud SQL はさまざまなテストを実施していますが、MySQL の更新リリースは、複雑な現実のシナリオで十分に検証されていません。そのため、本番環境インスタンスは安定版のままにし、開発インスタンスとステージング インスタンスを使用して Cloud SQL for MySQL の最新のマイナー バージョン アップグレードをテストすることをおすすめします。

本番環境インスタンスに複数のゾーンを構成する

Cloud SQL for MySQL は高可用性ソリューションとして、セカンダリ　ゾーンへの自動フェイルオーバーによってリージョンの可用性を提供します。可用性を最大限に高めるには、本番環境インスタンスのマルチゾーン オプションを構成して、日次バックアップとポイントインタイム リカバリが自動的に行われるようにします（詳しくは「バックアップ スケジュール」セクションをご覧ください）。

現在の CPU/メモリ使用量を評価し、十分な情報に基づいて移行を決定する

既存のインスタンスを Cloud SQL に移行する場合、現在のワークロードで適切な VM サイズを選択できます。

• CPU: 通常のワークロード条件での CPU 使用率はどのくらいですか？ピーク ワークロードへの対応インスタンスは CPU の制約を受けるか、I/O の制約を受けるか。ユーザーまたはシステムの CPU 使用率が比較的高い場合は、CPU の制約を受けるワークロードを示しています。I/O の割合が比較的高い場合は、I/O の制約を受けるワークロードを示しています。
• メモリ: 同様に、インスタンスの通常のメモリ使用量とピーク時の使用量は何でしょうか？

参考までに、Cloud SQL for MySQL の 1 個の vCPU は最大 6.5 GB のメモリをサポートできます。

CPU とメモリ用に 20 ～ 50% の追加スペースを計画する

通常は安定したインスタンスであっても、CPU とメモリに 20% 以上の余裕を持たせ、予期せぬスパイクを吸収するようにします。これは、ビジネスの成長には特に重要です。さらに 50% の増額も検討してください。

Cloud SQL を使用すると、マシンタイプを簡単にアップグレードできます。ただし、アップグレードに伴いダウンタイムが発生します。

SSD を使用してデータベースのパフォーマンスを向上させる

Cloud SQL for MySQL には経済性に優れたストレージ オプションとして HDD が用意されていますが、高パフォーマンスのデータベースが必要な場合は SSD オプションを選択します。この I/O パフォーマンスの比較をご覧ください。

ストレージ容量に関して、パフォーマンスと費用のバランスを取るよう計画を立てる

ディスクの IOPS とスループットは永続ディスクのサイズと相関します。容量が大きいほど、インスタンスの上限内で IOPS とスループットが高くなります。

SSD の場合、ゾーン構成とリージョン構成がパフォーマンスに影響します。詳細については、ゾーン SSD とリージョン SSD のパフォーマンス データをご覧ください。複数のゾーンの可用性を選択した場合は、リージョン SSD のパフォーマンス データをご確認ください。読み取り IOPS と書き込み IOPS はどちらも 1 GB あたり 30、スループットは 0.48 MB/GB です。リージョン SSD でも、インスタンスあたりの書き込み IOPS と書き込みスループットが小さくなる点を除き、パフォーマンス データはほぼ同じです。

Cloud SQL インスタンスでサポートされる最大ストレージ サイズは 64 TB です。

ストレージの自動増量を有効にして、ディスク容量の拡大をモニタリングする

Cloud SQL には、インスタンスのディスク容量（OOD）が不足しないように、ストレージの自動増量機能があります。この機能を有効にすると、ストレージが 30 秒ごとに確認され、必要に応じてストレージの容量が段階的に増加します。

この機能は OOD を防ぎますが、容量の増加は永続的であり、後でインスタンスをダウンサイズすることはできません。最初にディスクサイズに関するアラートを設定して、ストレージ容量の管理と計画を行えるようにしてください。

暗号化オプションをよく理解する

Cloud SQL はデフォルトで保存データを暗号化します。ただし、ニーズに合う場合は、Google が所有し管理するデフォルトの鍵の代わりに顧客管理の暗号鍵（CMEK）を使用することもできます。

プライベート IP とパブリック IP のトレードオフを評価する

プライベート IP とパブリック IP は、ネットワーク内のデバイスで使用されるアドレスの種類を指します。プライベート IP は、パブリック IP に比べてネットワーク セキュリティに優れ、ネットワーク レイテンシを低く抑えることができます。ただし、プライベート IP を設定するには追加の API と IAM 構成が必要で、実際にはパブリック IP が必要になる場合があります。パブリック IP を使用する必要があることがわかっているものの、セキュリティを強化したい場合は、承認済みネットワークを必須にするか、Cloud SQL Auth Proxy を使用できます。

安全な接続のための Cloud SQL Auth プロキシを検討する

Cloud SQL Auth Proxy を使用すると、SSL や承認済みネットワークを構成する代わりに、Cloud SQL インスタンスに安全にアクセスできます。アプリケーションは Auth Proxy クライアントと通信します。Auth プロキシ クライアントはローカル環境で実行され、安全なトンネルを使用して Cloud SQL インスタンス上のプロキシ サーバーと通信します。

バックアップとポイントインタイム リカバリを有効にして、保持ポリシーを確認する

定期的なデータ バックアップと検証可能なデータ復旧は、健全なデータベース管理に不可欠です。これらの手法は、データの破損や意図しないデータ操作などの状況で非常に役立ちます。いずれの場合も高可用性では軽減できません。

Cloud SQL は自動バックアップ、バックアップ検証、ポイントインタイム リカバリ（PITR）に対応しています。これらはデフォルトで有効になっており、複数のゾーンを持つインスタンスで必須です。自動バックアップは毎日行われ、デフォルトの保持ポリシーはバックアップの 7 コピーと 7 日間のバイナリログです（PITR で必須）。保持ポリシーは [詳細オプション] セクションで調整できます。

データベース フラグは、my.cnf ファイルに向かうサーバー構成です。構成可能な db フラグのリストがありますが、一部のマネージド フラグは構成できません。データベース フラグを確認して、インスタンス作成時に適切な値に構成することをおすすめします。一部の db フラグは動的ではなく、変更するとインスタンスの再起動がトリガーされるため。

character_set_server を確認する

Cloud SQL for MySQL インスタンスで、デフォルトの character_set_server は、v5.6 と v5.7 では utf8、v8.0 では utf8mb4 です。character_set_server は、character_set_server、character_set_server、character_set_server、character_set_server を同じ値に設定します。character_set_system には、v8.0 ではデフォルトで utf8mb3 が使用されます。

インスタンスを移行する際に、現在の構成で別の文字セット（latin1 など）を使用している場合は、新しいインスタンスで character_set_server を明示的に設定してください。

time_zone を確認する

タイムゾーンのデフォルトは system_time_zone（UTC）です。別の time_zone を使用する場合は、default_time_zone で設定します。このフラグには、タイムゾーン オフセット（例: +08:00時間）とタイムゾーン名（例: America/Los_Angeles）の 2 つの形式があります。タイムゾーン名でタイムゾーンを定義すると、自動的に夏時間が適用されます（該当する場合）。default_time_zone フラグは動的ではなく、変更するには db インスタンスの再起動が必要です。

低速クエリログを有効にする

デフォルトでは、slow_query_log は OFF に設定されています。低速のクエリログを有効にして、アプリケーションに適したしきい値を slow_query_log に設定することを強くおすすめします。低速のクエリログは、分析と最適化のために長時間実行クエリをキャプチャするのに役立ちます。この情報は、個々のクエリだけでなく、サーバー スループット全体や予期しないワークロードの事後分析にも役立ちます。

innodb_buffer_pool_size を確認する

これが InnoDB のパフォーマンスを高めるうえで最も効果的な構成です。メモリにバッファリングできるデータが多いほど、サーバーのパフォーマンスは向上します。同時に、グローバル バッファとスレッドごとの動的バッファ用に十分なメモリが予約されている必要があります。

Cloud SQL では、innodb_buffer_pool_size フラグのデフォルトの最小許容値と最大許容値は、ドキュメント で説明されているように、インスタンスのメモリによって異なります。

優れた innodb_buffer_pool_size には、すべてのデータが含まれている必要はなく、頻繁にアクセスされるデータのみが含まれている必要があります。バッファプールの効率を反映するステータス変数は Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests です。Innodb_buffer_pool_read_requests は論理読み取りリクエストの数で、Innodb_buffer_pool_reads は、バッファプールで処理されず、ディスクから読み取る必要がある論理読み取りの数です。データが完全にバッファプールに入った理想的なケースでは、Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests の比率はほぼ 0 になります。これらの変数をモニタリングすると、InnoDB バッファプールの効率を把握できます。innodb_buffer_pool_size が最大許容値で、バッファプールの効率が良くなく、アプリケーションでクエリのパフォーマンスの問題が発生している場合は、インスタンスをアップグレードしてメモリを大きくすることを検討してください。

この変数は MySQL v5.7 と v8.0 では動的になりますが、v5.6 では変更するとインスタンスの再起動が必要になります。

innodb_log_file_size を確認します。

8.0.30 より前では、innodb_log_file_size と innodb_log_files_in_group は動的ではなく、innodb_log_file_size を変更するにはクリーン シャットダウンが必要でした。8.0.30 では、innodb_log_file_size と innodb_log_files_in_group に代わる innodb_redo_log_capacity が導入されました。  

Cloud SQL for MySQL インスタンスは、innodb_log_file_size=512 MB、innodb_log_files_in_group=2（または innodb_redo_log_capacity=1 GB）と構成されています。これにより、InnoDB はディスクと同期せずにバッファプールでより多くの変更を保持できるため、サーバーのパフォーマンスが向上します。REDO ログファイルのサイズが大きいという欠点は、クラッシュからの復旧時間が長くなることです。この決定を行うには、インスタンスの HA の要件と設定に応じて、パフォーマンスと可用性のバランスを取る必要があります。

一般に、redo ログファイルには、1 時間分の書き込みアクティビティを保持するのに十分な大きさにすることをおすすめします。これを測る方法の 1 つは、Innodb_os_log_written を 1 日にわたって確認し、Innodb_os_log_written × Innodb_os_log_written が、実測ピーク時に十分大きい値となるようにします。

innodb_log_buffer_size を確認します

MySQL v5.6 と v5.7 では、innodb_log_buffer_size は動的ではなく、変更するにはインスタンスの再起動が必要になります。そのため、初期化時に設定することをおすすめします。

innodb_log_buffer_size がトランザクション全体を格納するのに十分な大きさである場合、トランザクションの実行中に追加のディスクへのフラッシュは行われません。デフォルトでは、innodb_log_buffer_size が 16 MB に設定されています。これは通常、これで十分です。ただし、大規模なトランザクションでより大きなバッファが必要かどうかを把握するには、大規模なトランザクションを発行するときに Innodb_log_waits ステータス変数をモニタリングします。innodb_log_buffer_size が小さすぎてフラッシュを待機する必要がある場合、Innodb_log_waits が 1 増加します。

必要に応じて動的変数を調整する

table_open_cache、thread_cache_size などのパフォーマンス関連の db フラグは動的です。最初は適切なサイズにして、必要に応じて測定値を設定し、調整することをおすすめします。

table_open_cache は開いているテーブルの数を表します。十分なキャッシュがあると、テーブルを開く時間が短くなり、クエリのパフォーマンスが向上します。ステータス変数 Opened_tables は、開かれたテーブルの数を示します。Opened_tables が増加し続ける場合は、able_open_cache の増加を検討してください。

thread_cache_size は、クライアントの接続解除後にスレッドを再利用するためにスレッドをキャッシュに保存するために使用します。インスタンスで多数の同時接続が想定される場合は、サイズを大きくします。ステータス変数 Threads_created と Connections の比率は、スレッド キャッシュの効率を示します。比率は低いほど良いです。

スレッドごとのメモリフラグは控え目にする

クエリのパフォーマンスに影響するスレッドごとのメモリバッファ（tmp_table_size、tmp_table_size、tmp_table_size、tmp_table_size など）がある。これらの変数には、グローバル スコープとセッション スコープの両方があります。グローバル スコープでは、すべての新しい接続にスレッドごとの値が設定されますが、セッション スコープは、現在のセッションの後続のクエリに対して有効になります。このような設定に使用するメモリが大きいほど、クエリのパフォーマンスが向上します。ただし、これらは動的で、スレッドごとに 1 つ以上割り当てるため、メモリ不足（OOM）のシナリオにつながる可能性があります。

グローバル値には控えめな数を使用し、特定のセッションに大きな数を予約して、制御された方法でパフォーマンスを改善することをおすすめします。

performance_schema を検討する

MySQL v8.0.26 より前のバージョンでは、performance_schema はデフォルトで OFF になっており、有効にするには再起動が必要です。performance_schema を使用すると、さまざまな計測が可能になり、サーバー オペレーションを分析するための豊富なデータセットが提供されますが、パフォーマンスとメモリのどちらも費用がかかります。デフォルトのインストルメンテーションでは、パフォーマンスが約 5% 低下しますが、インストルメンテーションが追加されるにつれて増加します。メモリ消費量が 1 GB 以上に増加することもあるため、ワークロードで計測手法をベンチマークします。このメモリ使用量は、memory_summary_global_by_event_name テーブルで確認できます。

Cloud SQL インスタンスを作成した後、1 つのデータベース ユーザー 'root’@’%’ が使用可能になります。追加のデータベース ユーザーの作成が必要になる可能性があります。

必要なオペレーションへのユーザー アクセスを制限する

ユーザーのアクセスは常に必要最小限のものにしてください。

MySQL CLI でユーザーを作成する場合は、権限を明示的に付与する必要があります。

Cloud コンソールからユーザーを作成する場合、そのユーザーには ‘root’@’%’ ユーザーと同じ権限が付与されます。MySQL v5.6 および v5.7 では、デフォルトの権限には、付与オプションのある SUPER 権限と FILE 権限を除くすべての権限が含まれます。v8.0 では、ユーザーは動的な権限を持ち、SUPER 権限と FILE 権限は引き続き制限されていますが、ユーザーはさらに多くの管理者ロールを使用できます（たとえば、APPLICATION_PASSWORD_ADMIN、APPLICATION_PASSWORD_ADMIN、APPLICATION_PASSWORD_ADMIN、APPLICATION_PASSWORD_ADMIN、APPLICATION_PASSWORD_ADMIN）。MySQL CLI を介して不要な権限を取り消す必要があります。v8.0 インスタンスでは、partial_revokes 変数は有効になっています。

'root'@'%' を特定の管理者ユーザーに置き換えることを検討する

‘root’@’%’ ユーザーはデフォルトかつ最も使用されているスーパー ユーザーであるため、ハッカーに狙われることがよくあります。セキュリティ向上のため、‘root’@’%’ ユーザーと同じ権限セットを持つ独自の管理者ユーザーを作成して、‘root’@’%’ と置き換えることをおすすめします。

データベース オペレーションとシステム リソースのさまざまな側面をモニタリングして追跡することは非常に重要です。インスタンスの運用の健全性を経時的に確認、分析できるため、リソース プランニングに役立ちます。

• Cloud コンソールの概要ページには、主要な指標のリストが表示されます。
• Cloud Monitoring には追加の指標が用意されています。データベース インスタンスについて、選択した指標を含むダッシュボードを作成できます。Cloud コンソールの左上にあるナビゲーション メニューで、[オペレーション] を選択します。-->Cloud Monitoring にアクセスします。
• Cloud SQL で Query Insights を使用してクエリのパフォーマンス分析を行います。概要セクションには、データベース、ユーザー、またはクライアント アドレスごとにスライスされた CPU 負荷が表示されます。CPU 使用率も分類され、I/O 待機とロック待機が表示されます。また、クエリ ダイジェスト別に上位のクエリも一覧表示されます。クエリ ダイジェストごとに、平均実行時間、クエリ数、スキャンされて返された平均行数を確認できます。これらの指標は、ホットスポットや最適化すべきクエリを特定するのに非常に役立ちます。
• 独自に開発したモニタリング ツールやサードパーティ製ツールで上記を補完することもできます。主な目的は、サーバーとクエリの両方の最適化とトラブルシューティングに影響を与える可能性があるデータベース オペレーションを理解することです。

適切なアラートは、サーバーの健全性を保つうえで重要です。CPU の飽和によるメモリ不足（OOM）やシステムの停止などのサービスの中断を防ぐことができます。

Cloud Monitoring を使用している場合は、指標ベースのアラートを作成できます。詳細については、ドキュメントをご覧ください。

他のモニタリング ツールを使用する場合は、アラートを構成します。

読み取りをスケーリングするには、リードレプリカの追加を検討してください。HAProxy、ProxySQL、その他のロードバランサを使用して、複数のリードレプリカ間で読み取りを分散できます。

Cloud SQL はチェーン レプリケーションもサポートしています。これについては、カスケード レプリカをご覧ください。  

リードレプリカは、プライマリ インスタンスと同じ MySQL バージョンで作成されます。作成後、レプリカをプライマリにアップグレードすることもできます。

高可用性ソリューションは、同じリージョン内のセカンダリ ゾーンでデータの冗長性を提供します。障害が発生すると、1 つのリージョンが使用できなくなる場合があります。クロスリージョン リードレプリカは、必要に応じてプライマリ インスタンスに昇格できるため、障害復旧計画における強力なリソースとなります。詳しくはドキュメントをご覧ください