移行工数とコストを抑えた、Cloud SQL への MySQL 移行 [DeNA インフラ SRE]

はじめに

こんにちは、 IT 基盤部の izawa です。主に高い可用性が求められる大規模プロダクトのインフラを担当しています。

この記事では、以前 IaaS (MySQL on GCE) で運用していたデータベースを Google Cloud のマネージドサービスである Cloud SQL に移行した際の経験をご紹介します。マネージドサービスへのデータベース移行を検討されているインフラエンジニアの方々にとって、本記事が具体的なイメージを深める一助となれば幸いです。

本記事では、マネージドサービスを活用することで移行工数を抑えつつ安全に移行できたこと、マネージド移行の懸念点であるコストを抑えながら実現できた工夫、そして移行作業の全体像と具体的なポイントについてお伝えします。

移行の背景と課題

これまで私たちが運用していたデータベースは、IaaS 上に構築された MySQL 5.7 でした。長期運用されている既存プロダクトであり、周辺エコシステムの依存先を改修するには大きな工数が必要だったことから、バージョンアップに踏み切れずにいました。この構成には、以下のような複数の課題がありました。

IaaS 運用が抱えていた課題

MySQL 5.7 はすでに EOL（End of Life）を迎えており、バージョンアップが急務だった。
冗長化などに利用していた周辺管理ツールが新しい MySQL バージョンに追従できておらず、バージョンアップに大きな工数がかかると予想された。
そもそも IaaS での運用自体、日々の運用負荷が高かった。

MySQL 5.7 の EOL はセキュリティやサポートの観点から見過ごせず、バージョンアップは避けられない状況でした。ところが、冗長化などに利用していた周辺管理ツールが新しい MySQL バージョンに追従できておらず、バージョンアップに大きな工数がかかる見込みでした。加えて、日々の運用業務を省力化したいという強いニーズもありました。

これらを踏まえ、IaaS 運用を続けることには限界を感じ、マネージドサービスへの移行を真剣に検討し始めました。

C4A の登場によるコスト面の転換

マネージドサービスへの移行にあたって最大の懸念は、一般にコストが大幅に増加するのではないかという点でした。この懸念が、移行に踏み切れない最大のボトルネックだったのです。

状況を変えたのが、Google Cloud の新しいマシンファミリーである C4A ファミリーの GA（General Availability）です。C4A ファミリーは、より少ないインスタンスで高いパフォーマンスを発揮できるため、これを活用すればコスト増を抑えながらマネージドサービスのメリットを享受できるのではないかと考えました。

ただし、これはあくまで期待であり、C4A ファミリーを採用した Cloud SQL が本番のワークロードに耐え、コスト増も許容範囲に収まるのかは、実際に検証してみなければ分かりません。そこで移行を最終的に決定する前に、これらの懸念が実際に解消できるかを事前に検証することにしました。

Cloud SQL 導入の事前検証

Cloud SQL への移行を最終判断するにあたり、前述の懸念が実際に解消できるかを確かめるため、性能・機能・コストの観点で徹底した事前検証を行いました。

負荷検証の実施

まず確認すべきは、コスト効率の良い目標スペックの Cloud SQL インスタンスが、本番環境に近いワークロードに耐えうるかという点です。具体的には、既存の IaaS 環境ではプライマリ 1 台とレプリカ 2 台の計 3 台（n2d-highmem-4、ストレージは Local SSD）で MySQL のレプリケーション構成を組んでいました。これをコスト抑制のため Cloud SQL の db-c4a-highmem-4 × 1 台へ集約できるか、つまり 3 台分の負荷を 1 台で処理できるかを検証しました。

この負荷検証は以下の手順で実施しました。

本番環境に近いデータ量の準備: 負荷検証の精度を高めるため、移行元となる本番環境のデータベースと同程度のデータ量のレコードを事前に作成し、より現実に即した状況で性能を評価しました。
IaaS環境のベースライン負荷測定: 既存の IaaS 環境（MySQL on GCE）において、直近 1 年間でもっとも高負荷だったタイミングの 1 台あたりのメトリクス（CPU 使用率、IOPS、スループットなど）を再現できるよう sysbench の oltp_read_write シナリオのパラメーターを調整し、このときのパフォーマンスをベースラインとして記録しました。
Cloud SQL 環境への負荷と評価: 移行後は本番の冗長構成 3 台分の負荷を Cloud SQL 1 台で引き受けるため、ベースラインの 3 倍を目標負荷に設定しました。この負荷を db-c4a-highmem-4 × 1 台にかけ、CPU 使用率・IOPS・スループットなどを記録しながら安定して処理できるかを確認しました。

ベースラインの基準としたタイミングの CPU 使用率は、下図のとおりです。

IaaS環境の1年間で最も高負荷だったタイミングのCPU使用率 — 直近1年間で最もCPU使用率が高くなったタイミング。この値をベースラインの基準とした

さらに、この 3 倍という負荷は安全側の見積もりです。ベースラインには過去 1 年で最も高負荷だった瞬間の 1 台あたりの値を採用しており、定常時には下図のとおり各台の CPU 使用率に十分な余裕があります。滅多に発生しないこのピーク値を基準に 3 倍しているため、実運用の負荷に対してはかなり余裕を持った見積もりになっています。

IaaS環境の定常負荷時の CPU 使用率 — 定常負荷時は各台のCPU使用率に余裕があり、3倍という負荷設定が安全側であることを示している

負荷は sysbench の oltp_read_write シナリオで生成しました。まず既存の IaaS 環境のホスト名を指定してベースラインを測定し、次に Cloud SQL インスタンスのホスト名を指定して評価を行っています。実際にベースラインの 3 倍の負荷をかけた際の Cloud SQL 1 台の CPU 使用率の推移が以下です。

ベースライン3倍の負荷をかけたCloud SQLのCPU使用率の推移 — ベースライン3倍の負荷でもCPU使用率には余裕があり、安定して処理できている

なお、判断にあたっては CPU 使用率だけでなく、コネクション数やスレッド数、IOPS の上限に対する余裕など複数のメトリクスを確認しています。本記事ではわかりやすさのために CPU 使用率のグラフのみを掲載していますが、いずれの指標も実用上問題のない水準に収まっていることを確認しました。この結果から、db-c4a-highmem-4 × 1 台でも本番の冗長構成 3 台分の負荷を十分に処理できることを確認でき、コストと性能のバランスに対する確信を持つことができました。

スケーリング時のダウンタイム検証

次に、突発的な負荷上昇時にはスペックを変更して対応するため、その際にどれだけダウンタイムが生じるのかを事前に把握しておきたいと考えていました。そこで、今回採用した Enterprise Plus エディションのニアゼロダウンタイムによって、スケーリング時のダウンタイムがどこまで抑えられるのかを計測しました。

そこで、インスタンスのスペック変更（スケールアップ/ダウン）を実際に実行し、mysqladmin ping を 0.5 秒間隔で実行する簡易的なシェルスクリプトで疎通状況を監視して、ダウンタイムをミリ秒単位で記録しました。結果として、どちらの操作も約 1 秒程度のダウンタイムで完了することを確認できました。ただし、公式ドキュメントに記載のとおり、3 時間以内に連続でスケールダウンを実施すると、ニアゼロダウンタイムではなく通常のフェイルオーバーにフォールバックします。このケースは公式では 60 秒ほどのダウンタイムが想定されていますが、今回実測したところ約 40 秒で復旧することを確認しました。スペック変更自体は、全体として約 5 分程度で完了しました。

DMS の機能検証と移行方針

データ移行には、Google Cloud の Database Migration Service (DMS) を利用する方針としました。DMS は、ソースデータベースからのデータダンプ、継続的なレプリケーション、そしてレプリカ昇格という一連のプロセスを安全かつマネージドで実行できるサービスです。手動でのデータ同期作業に伴うリスクを排除し、ダウンタイムを最小限に抑えながら移行できる見込みが立ったため、本番移行に先立って主要な機能と制約を検証しました。

検証を通じて把握した重要な制約が、DMS で一度レプリケーションを設定すると、Cloud SQL 上のターゲットインスタンスはリードレプリカとして扱われ、ユーザー作成や権限付与を含む書き込み処理が一切できなくなるという点です。

この書き込み制約に加え、DMS は mysql.user などを含む mysql システムデータベースを移行対象としないため、アプリケーションが接続に使うユーザーとその権限（GRANT）は移行先に引き継がれません。そこで、これらはレプリケーション開始前に作成しておき、昇格後に追加の設定が必要にならないようにしました。実際の移行でも、昇格後は接続先を切り替えるだけで済み、権限の再付与などの追加対応は発生しませんでした。

コスト試算

マネージドサービスへの移行でもっとも懸念していたのがコストです。そこで移行前に、IaaS 構成と Cloud SQL 構成の月額費用を試算し、増加が許容範囲に収まるかを確認しました。

今回の比較では、IaaS 側の本番の冗長構成 3 台とバックアップ用途 1 台の計 4 台（各 n2d-highmem-4 + Local SSD 1500 GiB）を、Cloud SQL の HA 構成 1 台へ集約する前提としました。

IaaS 構成（4 台合計）の内訳は次のとおりです。

項目	月額
n2d-highmem-4 × 4 台	約 $419
Local SSD 1500 GiB × 4 台	約 $302
合計	約 $721

Cloud SQL 構成（HA 1 台）の内訳は次のとおりです。¹

区分	項目	月額
Compute	vCPU・メモリ（HA）	約 $552
Storage	ディスク容量（1150 GiB）	約 $265
Storage	プロビジョニング IOPS（8000）	約 $200
Storage	スループット（140 MiB/s）	$0（無料枠内）
合計		約 $1,017

Cloud SQL の費用は IaaS 比で 約 1.4 倍にとどまり、当初懸念していた数倍規模の増加には至りませんでした。

比較対象とした Cloud SQL の構成は次のとおりです。

インスタンスは db-c4a-highmem-4（4 vCPU、32 GiB メモリ）で、エディションは Enterprise Plus です。
突発的な障害に備え、別ゾーンにスタンバイを持つ HA 構成を有効にしています。
ストレージは Hyperdisk Balanced を 1150 GiB でプロビジョニングし、8000 IOPS を割り当てています。
スループットは無料枠である 140 MiB/s に収め、データキャッシュは今回のワークロードでは不要と判断して無効にしています。

内訳を見ると、増加の主な要因は Compute です。HA 構成では vCPU とメモリが二重に課金されるうえ、CUD は Compute にのみ適用されストレージには効かないため、割引を適用しても Compute の比重が大きくなります。

一方でストレージ費用は減少しています。IaaS の Local SSD は 375 GiB 単位でしか構成できず、必要なデータ量に対して 1500 GiB（375 GiB × 4）を確保する必要がありました。これに対し Cloud SQL の Hyperdisk Balanced は 1 GiB 単位で容量を指定できるため、実データ量に見合った 1150 GiB へムダなく設定でき、その分の費用を抑えられました。

また、今回割り当てた 8000 IOPS は余裕を持たせた値です。無料枠の 3000 IOPS を超える分が課金対象となるため、実際の使用状況を見ながら適正値まで引き下げれば、内訳の IOPS 費用をさらに削減できる余地があります。

なお、ここで比較しているのは純粋なインフラ費用のみです。実際には周辺管理ツールの追従やバージョンアップ、バックアップ運用といった作業がマネージドサービス側に移るため、運用工数の削減効果も見込めます。これらを含めた総保有コスト（TCO）で見れば、費用対効果はさらに高まると考えています。

これらの事前検証により、性能・運用性・コストのいずれの懸念も解消できる見通しが立ちました。こうして私たちは Cloud SQL への移行を正式に決定しました。MySQL のバージョンアップと運用業務の省力化という課題を解決でき、その対価となるコスト増も許容範囲に収まる、バランスの取れた現実的な選択肢だと判断したのです。

移行の実施

事前検証によって Cloud SQL への移行が実現可能であることを確認した後、本番環境への移行に向けたインフラ構築とデータ移行作業を進めました。

移行全体の流れは以下のとおりです。インスタンス構築からレプリケーションまでの事前準備フェーズと、メンテナンス期間中に実施する切替フェーズの 2 段階で進めました。

Cloud SQL への移行全体のフロー図

移行環境の構築とデータ移行

インフラの構築には Terraform を採用しました。既存の他の Google Cloud リソースも Terraform で管理しているため、一貫性のある運用を目指したものです。MySQL の各種パラメーターに相当するデータベースフラグやディスク容量、インスタンスタイプといった設定を一括で管理でき、手動によるミスを防ぎ、変更履歴も明確に保てます。

構築で一点注意が必要なのは、Cloud SQL インスタンスを Terraform で作成すると、デフォルトの root ユーザーが自動的に削除されるという仕様です。このため、root ユーザーを明示的に定義する必要があり、そのパスワードは Secret Manager と連携して安全に管理しました。

# Cloud SQL インスタンスを作成すると root ユーザーは自動削除されるため、
# root ユーザーを明示的に定義し、パスワードは Secret Manager から取得する
data "google_secret_manager_secret_version" "db_password" {
  secret  = "db-root-password"
  version = "latest"
}

resource "google_sql_user" "root" {
  name     = "root"
  instance = google_sql_database_instance.this.name
  host     = "%"
  password = data.google_secret_manager_secret_version.db_password.secret_data
}

インフラを構築したのち、事前の検証で機能と制約を確認済みの DMS を用いてデータ移行を進め、ターゲットをリードレプリカとして継続的にレプリケーションさせながら本番切り替えに備えました。

本番環境への切り替えと最終確認

本番環境への切り替えは、サービスのメンテナンス期間中に実施しました。この期間はアプリケーションからの書き込みが発生しないため、切り替えに伴うユーザー影響のあるダウンタイムは発生せず、データ不整合の心配もありません。この前提のもと、以下の手順で慎重に作業を進めました。

サービスをメンテナンス状態にし、アプリケーションからの書き込みを停止する
レプリケーションが追いついたことを確認し、データの整合性チェックをする
DMS でリードレプリカを昇格させ、書き込み可能なインスタンスにする
アプリケーションの接続先を新インスタンスに切り替える
アプリケーションの動作確認を行い、問題がなければメンテナンスを終了する

なお、切り替えに問題があった場合に備え、移行元の IaaS 環境はしばらくの間、停止せずに残しておきました。メンテナンス期間中は新環境への書き込みがまだ発生していないため、上記の手順の途中で問題が見つかった場合でも、接続先のエンドポイントを旧環境へ戻すだけで速やかに切り戻せる状態を保っていました。

整合性チェックでは、まずレプリケーション自体が健全であることを確認しました。具体的には、レプリケーションスレッド（IO / SQL）が正常に動作していること、遅延が発生していないこと、移行元と移行先でバイナリログの適用位置が一致していることの 3 点です。

あわせて、移行元と移行先のデータの一致も確認しました。主要なテーブルについてレコード件数と各テーブルの最終レコードを比較しています。切り替えは書き込みが停止したメンテナンス期間中に実施しているため、各テーブルの最終レコードは固定されています。主キーの id は単調増加するので、件数と最終レコードがともに一致していれば、レプリケーションが最後の 1 件まで追いついていると判断できます。データの一致とレプリケーション状態の両面から確認したことで、切り替え前に移行先が完全に追いついていると判断できました。

なお、これらの確認は事前に用意したスクリプトで自動化し、迅速かつ正確に行えるようにしました。

この 2 段階のチェックには限界もあります。件数と最終レコードの比較は軽量で高速に行える一方、途中のレコードが書き換わったようなケースまでは検出できません。より厳密に検証するなら、テーブル全体のチェックサムを比較する方法もあります。今回はデータ同期を DMS がマネージドで担保しており、移行期間中もレプリケーションの状態を継続的に監視できていたことから、この方法で十分と判断しました。

おわりに

今回の MySQL を IaaS から Cloud SQL へ移行した経験を通じて、いくつかの重要な学びと成果が得られました。

まず、Database Migration Service (DMS) をはじめとする Google Cloud のマネージドサービスを積極的に活用したことで、データの移行作業を安全かつ最小限の工数で完了できました。複雑なデータ同期やレプリケーションの管理をサービス側に任せたことで、私たちはより本質的な検証や設計に集中できました。

また、マネージドサービスへの移行における最大の懸念点だったコスト面も、C4A ファミリーの採用という工夫によって大幅なコスト増加を抑えながら乗り越えられました。この経験から、現在のワークロードの特性や将来の予測をしっかりと分析すれば、マネージドサービスのメリットを享受しつつ、費用を大きく増やさずに運用を省力化できると実感しています。

この移行によって、データベースの運用負荷は大幅に軽減されました。これまで必要だったバックアップスクリプトの運用や、フェイルオーバー時の一部の手動対応が不要になり、さらにスペック調整なども容易に行えるようになったことで、運用にかかる手間は大きく減りました。その結果、インフラエンジニアはより戦略的な業務に時間を割けるようになりました。

今後は、さらに踏み込んだコスト最適化の取り組みを継続します。具体的には、IOPS の最適化や、Google Cloud の Query Insights を活用したボトルネッククエリの特定と改善などを進めていきます。さらに、今回移行したものには水平シャーディングされている系統も含んでおり、これらについては性能に余裕のある Cloud SQL の特性を活かして統合を検討しています。

これらの最適化を着実に進めることで、マネージド化のメリットを享受しながら、IaaS で運用していた頃よりもコストを抑えられる——そんな未来も見えてきています。

本記事でも触れた DMS のより詳細な機能や、今回は扱わなかった Backup Vault を使用した安全なバックアップの作成・管理についても、別の機会に記事としてご紹介できればと考えています。