DeNAがCloud SQLへMySQL移行　3台構成を1台に集約した判断材料

編集: グリットアーツ編集部

公開日：2026年10月11日

3行解説

ニュースの概要

DeNAのIT基盤部は2026年8月7日、IaaS上で運用していたMySQL 5.7を、Google CloudのマネージドサービスであるCloud SQLへ移行した取り組みを公開しました。対象は長期運用の既存プロダクトで、従来はMySQL on GCEでプライマリ1台とレプリカ2台の構成でした。記事では、EOL対応、運用負荷の軽減、コスト増の抑制を目的に、性能検証、ダウンタイム検証、DMSの機能確認、月額試算を行った流れが説明されています。

何が新しいのか

この事例の新しさは、単に「Cloud SQLへ移した」ことではなく、IaaSの3台分の負荷をCloud SQL 1台で受けられるかを、かなり具体的に確かめている点です。既存環境の直近1年で最も高負荷だったタイミングを基準にし、sysbenchのoltp_read_writeでベースラインの3倍負荷を再現しています。さらに、CPUだけでなくIOPS、スループット、コネクション数、スレッド数も見て判断しています。

また、Cloud SQL Enterprise Plusのニアゼロダウンタイムを使い、スケールアップ/ダウン時の停止時間も実測しています。結果は約1秒、連続スケールダウン時でも約40秒でした。マネージド化は便利でも停止時間が読めないと採用しにくいですが、この事例はその不安を数値で潰している点が実務的です。加えて、費用はIaaS比で約1.4倍に収まったと示され、コスト面の壁も具体的に評価されています。

グリットアーツ編集部の分析

注目すべきは、Cloud SQLの採用可否を「運用が楽になるか」だけで決めていないことです。DeNAは、db-c4a-highmem-4×1台で本番の冗長構成3台分を受けられるかを検証し、さらにHA構成の月額を試算しています。これは、マネージド化で減るのが日々の保守負荷で、増えるのがCompute中心の課金だと見極めたうえでの判断です。日本企業でも、DB移行は性能より先に「費用が読めるか」「切り戻しができるか」が止まりやすいので、PoCの設計がそのまま導入難易度を左右するとみられます。

日本の現場で考えると

日本の本番環境でこの手の移行を考えるなら、まず権限と切り替え手順を先に固める必要があります。今回のようにDMSではmysql.userを含むシステムDBが移らず、ターゲット側はレプリカ扱いで書き込みできません。つまり、アプリ接続用ユーザーやGRANTを事前に用意しないと、切り替え直後に接続障害が起きやすくなります。

向いているのは、EOL対応が急務で、かつ短時間の停止やスケール変更時の数秒〜数十秒の揺れを許容できる業務です。一方で、連続スケールダウンを頻繁に行う運用や、停止時間をほぼゼロにしたい基幹系では、事前の切り戻し設計まで含めて慎重に見るべきです。既存の冗長化ツールが新バージョンに追従できない場合は、移行後の運用設計も見直し対象になります。

導入・検討時に確認したいこと

• 本番に近いデータ量と負荷を再現できるか。CPUだけでなくIOPS、スループット、コネクション数も見る。
• Cloud SQLのエディションやマシンファミリーを変えたとき、必要な性能と費用のバランスが取れるか。
• DMS利用時に、ユーザー作成や権限付与をどこまで事前準備する必要があるか。
• スケールアップ/ダウン時の停止時間が、業務要件の許容範囲に入るか。
• HA構成やストレージ設定を含めた月額が、IaaS運用と比べて許容できるか。

現時点で分かっていないこと

記事からは、移行対象の具体的な業務要件や、ピーク時の実トラフィックの詳細までは分かりません。また、Cloud SQL移行後の長期運用で、障害対応や保守工数がどれだけ減ったかも明示されていません。将来のスケール方針や、同じ構成が他のワークロードにもそのまま当てはまるかは、別途検証が必要です。

MySQLやデータベースの移行では、性能だけでなく権限移行や切り替え手順がつまずきやすいポイントです。自社環境での検証観点を整理したい場合は、運用前提から見直すことが重要です。

出典: DeNA Engineering