ジャンプ先

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

MySQL は、独自の物理マシンや仮想マシンに手動でデプロイして自己管理することもできますが、MySQL の運用に関するさまざまな処理を扱う、クラウド サービス プロバイダからのマネージド サービスを利用する方法がさらに普及しています。

おすすめの方法

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

インスタンスの情報

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

これは、インスタンスで作成されるデフォルトの “root”@”%” データベース ユーザーのパスワードです。root ユーザーを管理者ユーザーとして維持する場合は、安全なパスワードを選択してください。セキュリティ上の懸念事項のために、”root” ではなく、あまり一般的でない管理者ユーザーを使用することをおすすめします。「データベース ユーザーを管理する」セクションをご覧ください。

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

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

パスワード ポリシーの設定方法を示した Cloud コンソールのスクリーンショット

データベースのバージョン

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

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

本番環境インスタンスを最新の GA バージョンにしない 

Oracle と Cloud SQL でのすべてのテスト作業が行われていますが、MySQL の更新リリースは、実際の複雑なシナリオでは十分に精査されていません。したがって、本番環境インスタンスを安定バージョンに維持し、開発インスタンスとステージング インスタンスを使用して Cloud SQL for MySQL の最新マイナー バージョン アップグレードをテストすることをおすすめします。

高可用性

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

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

高可用性の設定を示す Cloud Console のスクリーンショット

マシンタイプ

現在の 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 は 1 GB あたり 30 回、スループットは 1 GB あたり 0.48 MB です。リージョン SSD を使用すると、インスタンスあたりの書き込み IOPS と書き込みスループットが低下する点を除き、パフォーマンス データはほぼ同じです。

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

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

Cloud SQL にはストレージの自動増量機能が備わっているため、インスタンスのディスク容量が不足する(OOD)のを防ぐことができます。この機能を有効にすると、ストレージは 30 秒ごとにチェックされ、必要に応じてストレージ容量が追加されます。

この機能は OOD を防ぐものですが、容量の増加は永続的なものです。後でインスタンスのサイズを小さくすることはできません。ストレージ容量を管理、計画できるように、まずディスクサイズに関するアラートを設定します。

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

Cloud SQL はデフォルトで保存データを暗号化します。ただし、必要に応じて、デフォルトの Google 管理の鍵ではなく顧客管理の暗号鍵(CMEK)を使用するオプションもあります。

ストレージ オプションを示す Cloud コンソールのスクリーンショット

接続を設定

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

プライベート IP とパブリック IP は、ネットワーク内のデバイスで使用されるアドレスのタイプです。プライベート IP は、パブリック IP よりもネットワーク セキュリティが向上し、ネットワーク レイテンシが短縮されます。 ただし、プライベート IP を設定するには、追加の API と IAM 構成が必要です。パブリック IP が必要になる場合があります。パブリック IP を使用する必要があるが、セキュリティを向上する必要がある場合は、承認済みネットワークを必須にするか、Cloud SQL Auth プロキシを使用します。 

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

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

バックアップのスケジュールと保持を設定する

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

健全なデータベース管理には、定期的なデータ バックアップと検証可能なデータ復旧が不可欠です。これらの手法は、高可用性によって緩和することができない、データの破損や意図しないデータ オペレーションなどの状況において非常に有用です。

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

データ保護オプションを示す Cloud コンソールのスクリーンショット

データベース フラグを構成する

データベース フラグは、my.cnf ファイルに入るサーバー構成です。構成可能な db フラグのリストがあります。特定のマネージド フラグは構成できません。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_clientcharacter_set_connectioncharacter_set_databasecharacter_set_results を同じ値に設定します。character_set_system には、v8.0 ではデフォルトで utf8mb3 が使用されます。

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

タイムゾーンを確認する

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

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

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

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 の比率はほぼゼロになります。これらの変数をモニタリングすることで、InnoDB のバッファプールの効率を把握できます。innodb_buffer_pool_size が最大許容値で、バッファプールの効率が悪く、アプリケーションにクエリのパフォーマンスの問題がある場合は、より大きいメモリにするよう、インスタンスのアップグレードを検討してください。

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

innodb_log_file_size を確認する

8.0.30 より前では、innodb_log_file_sizeinnodb_log_files_in_group は動的ではなく、innodb_log_file_size の変更にはクリーンなシャットダウンが必要でした。8.0.30 では、innodb_log_file_sizeinnodb_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_write を 1 日にわたって確認し、innodb_log_file_size × innodb_log_files_in_group が、実測ピーク時に十分大きい値となるようにします。

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

table_open_cache は、開いているテーブルの数を表します。キャッシュが十分にあると、テーブルを開く時間を短縮できるため、クエリのパフォーマンスが向上します。ステータス変数 Opened_tables は、開いているテーブルの数を表します。Opened_tables が継続的に増加している場合は、table_open_cache を増やすことを検討してください。

thread_cache_size は、クライアントとの接続が解除された後、スレッドをキャッシュして再利用するためのものです。インスタンスで多数の新しい同時接続が予想される場合は、より大きなサイズを設定します。ステータス変数 Threads_created と接続の比率は、スレッド キャッシュの効率性を示しています。比率が低いほど効果的です。

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

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

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

performance_schema を検討する

MySQL v8.0.26 より前では、performance_schema はデフォルトでオフになっていますが、オンにするには再起動する必要があります。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_ADMINCONNECTION_ADMINROLE_ADMINSET_USER_IDXA_RECOVER_ADMIN)。不要な権限は、MySQL CLI を介して取り消す必要があります。v8.0 インスタンスでは、partial_revokes 変数が有効になっています。

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

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

モニタリングを設定する

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

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

アラートの設定

適切なアラートは、サーバーの状態を左右する重要な要素です。これにより、メモリ不足(OOM)や CPU 飽和によるシステム ストールなどのサービス中断を防ぐことができます。

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

他のモニタリング ツールを使用する場合は、必ずアラートを構成してください。

レプリカを構成する

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

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

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

災害復旧計画

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

Cloud SQL での高可用性設定のためのアーキテクチャ
リードレプリカはネイティブの非同期レプリケーションを使用するため、パフォーマンスをモニタリングし、調整してレプリケーションに対応できるようにしてください。

Google Cloud は、オンプレミスのデータセンターの廃止から SaaS アプリケーションの実行、基幹業務システムの移行まで、お客様のビジネスニーズに合わせて構築されたマネージド MySQL データベースを提供します。