こんにちは、IT 基盤部の西崎です。主に DeNA がグローバルに展開するゲームのインフラ管理を担当しています。今回は自分の所属する IT 基盤部第二グループで MySQL を 8.4 以降どのように動かし続けるかについて検討したことを紹介します。

結論としては Aurora などのマネージドサービスへの移行を選択しており、他の選択肢で実際に導入検証ができた部分も少ないのですが、変わり続けるデータベース情勢の中での調査検討の一事例として見て頂ければ幸いです。¹

MySQL の大規模環境をどう安定運用するか

DeNA はオンプレ時代から 15年以上に渡って MySQL を大規模に運用してきました。その間には MySQL のバージョンアップだけでなくクラウド化やマネージドサービスの出現、そして分散 SQL（NewSQL）の台頭など、さまざまな状況の変化がありました。

DeNA もクラウド化の波に乗って IaaS 上での運用や Amazon Aurora などのマネージドサービスを利用し始めたほか、新規サービスの検証も積極的に行い、その成果は本ブログでも発表してきました。その時々の状況に合わせて、MySQL をいかに大規模に安定運用するか という点は常に私たちの重要な問いでした。

このような努力の暫定的な結果として、検討開始時点で私たちのチームでは以下のどちらかの方法で MySQL 環境を運用していました。

• IaaS 上に MySQL クラスターを構築する
• マネージドサービスを利用する
  • Amazon Aurora（Serverless v2 を含む）

しかし状況は変化し続けており、2025年には国内外で新しい選択肢による実例が少しずつ増えていました。そしてこのタイミングで MySQL 8.4 以降をどのように動かすか？という点で方針を策定する必要があったというのが今回の内容です。

出発点：MySQL 8.4 では MHA が動かない

私たちの一番の出発点はこの点です。DeNA の MySQL 環境で長らく頼ってきた MHA は MySQL 8.4 以降に対応していません。

MHA は DeNA で開発され、2011年に発表された Perl 製の OSS ツールです。詳細は他に譲りますが、MySQL のレプリケーション構成において Source インスタンスが故障した場合でも、最小のダウンタイムとデータロスでレプリケーション構成を復旧させることができる HA 機能（High Availability/高可用性）を提供しています。

私のチームの環境でも、MySQL を IaaS 上で利用する時は必ず MHA を利用していました。しかし MHA が動かない以上、その対応を念頭に置いて MySQL 8.4 以降の構成を考える必要があります。そして MySQL 8.0 も 2026年4月に EoL（Amazon Aurora の EoL は 2028年4月）を迎えるため、対応方針を決める必要がありました。

アプリケーション側からの要望

MySQL バージョンを上げることで利用できる機能も多くあるため、できるだけ早期にバージョンを上げたいという要望はアプリケーションチームからも受けていました。自分がこの検討をした段階ではアプリケーション側で MySQL 8.4 に対応するための修正も並行して行われていましたが、MHA も含めてインフラ側の方針を決める必要がある状態でした。今回はこのインフラ側の検討について紹介します。実際にバージョンアップを行なう際に直面した課題も別の機会に紹介できればと思います。

MySQL 8.4 以降の選択肢

MySQL 8.4 以降の構成を検討するため、私たちのチームでは以下の選択肢を検討しました。

1. MHA をメンテして MySQL 8.4 以降に対応させる
2. Orchestrator を利用する
3. Vitess を利用する
4. TiDB を利用する
5. グループレプリケーションを利用した構成に変更する
6. MySQL と互換性のあるクラウドのマネージドサービス（AWS の Amazon Aurora, Google Cloud の Cloud SQL）を利用する

検討の基準は「信頼性・透明性があること（開発組織、今後の開発、ソフトウェアの挙動に対する信頼性）」、「システムの複雑性を上げないこと（新しい依存関係をできるだけ増やさないこと）」、「既存の大規模環境を現実的に移行できること」です。

たとえば Google Cloud の Cloud Spanner は私たちのチームでも運用実績がありますが、 MySQL との互換性はなく、データベースとしての仕組みも大きく違う部分があり、既存の大規模 MySQL 環境の移行は難しいことをすでに知っていたため、この時点で選択肢からは外しています。

選択肢 1. MHA を使い続ける

この選択肢のメリットは明白で、これまで通りの IaaS 構成と運用を維持できることです。反面、新しい機能や運用負荷の低減ができる訳ではなく、何より Perl 製の歴史ある大型ツールである MHA をメンテし続けるという大きなエンジニアリングコストが伴います。

• メリット
  • IaaS 上の MySQL 構成を維持できる
  • これまでの運用手順や蓄積したナレッジを利用できる
• デメリット
  • 大きなエンジニアリングコストがかかる
    • MySQL のバージョンアップによる MHA のバグを踏んだ話 でも紹介したように、MHA は MySQL の実装に直接的に依存している部分が多く、最終的には MySQL の各バージョンに追従する必要がある
    • データベースの可用性と整合性というサービス提供の根幹に関わる機能のため、さまざまなバージョン、設定値、状況を横断して正常動作を担保する必要がある
  • その割に新機能や運用改善が期待できるわけではない

MHA の運用方針について何らかの結論が出たわけではありませんが、この時点ではメンテナンスコスト（と得られる効果のバランス）の見通しが立たず、時間も限られていたため他の選択肢を検討せざるを得ない状態でした。

選択肢 2. Orchestrator

Orchestrator は MHA と同様に障害時のフェイルオーバーなどの機能を持つ OSS です。Booking.com や GitHub での利用実績があり信頼性はあると考えましたが、この調査をしていた時点でメンテが止まっていたため候補から外しました。

Orchestrator は HA 機能の他にもトポロジー（MySQL 構成）の自動検出と表示機能などがありますが、 開発者によるメンテナンス停止 が発表された後、 Percona によるフォーク は存在したものの Percona 社内向けの管理に限ったものでした。2026年4月に ProxySQL によるメンテナンスの引き継ぎ が発表されたため今後も使われていく可能性はありますが、引き続き状況を注視する必要がありそうです。特に我々のように HA 機能だけを求めるのであれば、後述するグループレプリケーションの方が MySQL の公式プラグインとして開発されており安定性・機能・管理面で優位性があると考えています。

選択肢 3. Vitess

Vitess は YouTube で開発・利用された後、Planetscale という会社を中心に開発されているツールです。現在 CNCF の Graduated Project としてホストされています。MySQL クラスターとクライアントの間に VTGate や VTTablet などのコンポーネントを介し、MySQL シャードの管理やリクエストのルーティングを行う構成です。現在は Kubernetes 上で運用する方が一般的ですが、今回は VM 上の MySQL 構成に対して利用することを想定していました。

IaaS 上の MySQL をベースに構成できることは非常に興味深いですが、HA 構成のためのレイヤーが増えてしまうことになり、既存環境の移行にはハードルが高いと考えて候補から外しました。今回はアプリケーション側でシャーディングに対応したロジックやトランザクション管理をすでに実装・運用しているため、HA 機能のために利用するには仕組みが複雑（Vitess の強みである複数シャードの自動管理やリクエストのルーティングのメリットを直接的に活かせない）で、レイテンシや運用負荷も上がってしまうデメリットに見合わないという判断です。新規構築であったり、Vitess Operator for Kubernetes を利用しやすい環境であれば、より具体的に検証したいと個人的には考えています。

• メリット
  • IaaS 上の MySQL 構成を維持できる
  • YouTube などでの実績があり、CNCF で管理されている OSS である
• デメリット
  • HA 構成のために利用するには仕組みが複雑であり、検討点や管理対象が多い
  • VTGate を介するため HOP 数が増えてレイテンシの悪化が見込まれる
    • https://vitess.io/docs/25.0/overview/architecture/

選択肢 4. TiDB

TiDB は PingCAP 社によって開発されている分散 SQL OSS です。OLTP に加えて OLAP も効率的に処理できる HTAP 向けに拡張された分散 SQL という理解ですが MySQL との互換性が高く、特に日本では MySQL 互換の分散 SQL としての実績や認知度が高い印象です。

マネージドサービスに加えてセルフマネージドの選択肢もありますが 、Vitess と同じく全体のアーキテクチャから大きく変わることになるため、今回のケースで HA 機能のために導入するには変更点が多いと判断して候補から外しました。また自分の調査よりも以前に調査・検証されたことがあり、現行のアプリケーションに必要な要件を満たさないことから導入が見送られていたという経緯もあります。その後の TiDB のアップデートで要件を満たせるようになった部分もあるようなので、今後機会があれば詳しく調査してみたいです。

• メリット
  • IaaS 上の MySQL 構成を維持できる
  • 日本国内でも多くの実績があり、OSS として公開されている
  • MySQL との互換性が高い分散 SQL である
• デメリット
  • HA 構成を目的にするには変更点が多い
  • 以前の検証で現行アプリケーションに必要な要件を満たさないことが判明していた

選択肢 5. グループレプリケーションを利用した構成

グループレプリケーションは MySQL の公式プラグインで、Spanner のように Paxos ベースのアルゴリズムによって同一クラスター内のレプリケーションや死活監視を行います。比較的新しいレプリケーション方式ですが、 Uber や Booking.com など、大規模な MySQL 環境での実績があります。詳細は後述しますが、最小限の変更で IaaS 上の構成と新たなメリットを期待できるため今回は特に有力な選択肢でした。

• メリット
  • 公式機能（プラグイン）のみで IaaS 上の MySQL 構成を維持できる
  • 既存の運用（トポロジ管理やインスタンス追加など）を公式機能に寄せる形で運用の簡素化と効率化が見込める
  • 複数インスタンスへの並列書き込み機能を利用することで新たなメリットも見込める
• デメリット
  • 大規模運用の公開実績が乏しいため、課題が見つかった場合の対応にコストがかかる

選択肢 6. マネージドサービス（Amazon Aurora, Cloud SQL）

パブリッククラウド上のマネージドサービスを利用する選択肢です。私たちのチームでは Aurora の利用実績が十分あったため、移行や運用自体に大きな懸念はありませんでした。ただし IaaS 上での構成は諦めることになり、運用の手間がなくなる一方で料金は上がります。

• メリット
  • 私たちの環境でも十分な実績がある
  • MySQL on IaaS よりもパフォーマンスや可用性に優れる面がある
  • マネージドサービスのため運用工数が少ない
• デメリット
  • MySQL on IaaS 構成よりも料金がかかる
  • マネージドサービスのため、透明性やポータビリティは MySQL on IaaS より劣る

MySQL 8.4 以降の状況まとめ

一度ここまでの調査内容をまとめてみます。

1. 単純な MySQL HA（可用性）機能として有力なのはグループレプリケーション

MySQL 8.4 で純粋な HA 機能のみを求める場合、選択肢は Orchestrator とグループレプリケーション（InnoDB Cluster も含めて）になります。しかし Orchestrator は一般に開かれた OSS としてのメンテナンスを再開したのが2026年4月であり、自分たちのケースで必要な機能を備えているか、今後も安定してメンテナンスされるかは注視しておく必要があります。

グループレプリケーションも（特に日本国内では）まだ利用実績が多いとは言えませんが、 2016年に GA した 公式のプラグインであること、バックアップやリストアなど関連する機能も公式でサポートされていることを考えると、将来的にこちらの方がメリットが多くなりそうです。Booking.com や Uber のように、長期間に渡って大規模に MySQL を利用してきた企業も採用しており、Orchestrator などの HA ツールから（少なくとも部分的に）移行しつつ併用しているように見えます。MySQL 側の変化も大きくなる中で MHA や Orchestrator のようなユーザ企業が OSS として管理するコストが上がっており、同時に HA 機能は MySQL 本体やマネージドサービスなどのサービス提供側に組み込まれつつある印象です。

今回の我々のケースでも、管理する対象や工数は低く抑えたい、シャーディングロジックやインスタンスの管理機能はあるが HA 構成（自動フェイルオーバー機能）だけ欲しい、というパターンなので、グループレプリケーションが最後の検討に残ることになりました。

2. 分散 SQL を含め、マネージドサービスが台頭している

国内外でパブリッククラウドでのマネージドサービスへの移行が相次いでいます。並行して分散 SQL の利用・移行も進んでいる印象です。

• Amazon RDS / Amazon Aurora / DSQL
• Google Cloud SQL / Spanner
• TiDB
• 実績は比較的少ないが Vitess も CNCF でホストされている

ここで共通しているのは運用負荷が低減できることです。今回の検討の出発点となった MHA を含めて、運用負荷の低減はデータベース運用の大きな課題です。自分のチームでもマネージド MySQL と 分散 SQL の両方を活用しており、その効果を実感しています。

特に日本では TiDB への移行事例が近年多く発表されており、大規模 MySQL を互換性高く分散 SQL に移行する有力な選択肢となっている印象です。直接 MySQL に対応していませんが、Spanner や Aurora DSQL のような分散 SQL もクラウド事業者が力を入れて開発しており、今後の大きなトレンドの１つになりそうです。ここで興味深いのが、MySQL や PostgreSQL などがソフトウェア全体ではなくデータベースエンジンやプロトコル互換性という部分的な形でこれらの製品に取り込まれていることです。Amazon Aurora や DSQL のようにデータベースエンジン自体が再利用されている例もありますが²、TiDB のようにプロトコル互換性のみで元の実装を利用していない場合もあります³。そもそもこれらの製品はアーキテクチャ自体が全く異なるため、単に互換性があるというだけでなく、それぞれ別の仕組みで動くものとして個別に理解する必要があります。

グループレプリケーション VS. マネージドサービス

調査の結果、最後に残った選択肢は「IaaS 上でグループレプリケーションを本格的に検証して利用する」と「マネージドサービスに全面的に移行する」でした。ここでグループレプリケーション（以下 GR）についてもう少し説明しておきます⁴。

グループレプリケーションについて

GR は従来の非同期・準同期レプリケーションとは異なる、新しい MySQL のレプリケーション方式です。従来のように Source から Replica に一方向のレプリケーションを行うのではなく、クラスター全体が１つの「グループ」として互いを認知しており、レプリケーションもこの中で自動的に行われます。

GR のグループ内では特定のインスタンスが故障した場合に検知され、自動的にインスタンスの切り離しやフェイルオーバー（新規プライマリインスタンスの選出）が行われます。新規メンバーが参加した場合のデータリカバリも、物理バックアップを利用したクローンプラグインと binlog 転送によるデータ復旧を組み合わせて自動で行うことが可能です。GR は公式機能である上に HA 機能がビルトインされているため、今回のケースでは有力な選択肢でした。IaaS 上の構成をこれまで通りに利用できる他、新規インスタンス構築の手順も簡略化できる点が魅力的です。

マルチプライマリモードの可能性

GR にはマルチプライマリモードもあり、この場合はグループ内のすべてのインスタンスで書き込みが可能になります。書き込みリクエストは該当インスタンス上でパース・データ取得・書き込み値の計算が行われ、binlog として発行された後に他のインスタンスでも適用されます。この間には他のインスタンスとの検証フェーズも存在しており、データ衝突があった場合はエラーとなるためインスタンス間でデータ整合性が崩れる心配もありません。ただし頻繁なデータ衝突があると性能が大きく劣化するため、同時書き込みを実施する場合は接続先インスタンスを適切に制御する必要があります。

他にも制限事項や注意点がありますが、同一クラスターで複数インスタンスに同時書き込みができるのは大きなメリットです。インスタンス故障時も書き込み先さえ変えればデータ更新ができるためダウンタイムがほぼゼロになる他、書き込み処理の部分的な分散によるグループ内でのスケールができる可能性もあります⁵。我々の環境では MyDNS を用いて DB クエリの向き先を柔軟に管理しているため⁶、グループ内で書き込むインスタンスを瞬時に変えることや、書き込み先のインスタンスをデータ衝突なく管理することも現実的に考えられました。実際に利用するにはさらなる検証を行う必要がありますが、公式プラグインでこのような機能を想定できるのは魅力的です⁷。

このように GR を利用すれば工数を抑えつつ、新しいメリットもある形で IaaS 上の構成を維持できる可能性が出てきました。マネージドサービスも便利ですが、料金の上昇や製品ごとに異なる扱いが必要であったり、クラウド事業者間のポータビリティを失うなどのデメリットもあります。我々のような事業者にとって、自前で運用できる選択肢を持っておくことも重要な点です。

分散 SQL ではないマネージドサービスを選んだ理由

しかし今回選んだのは Aurora や Cloud SQL のようなマネージドサービスでした。初期構築や運用のコストが低く、それと比較して料金の上昇も許容範囲内だったからです。

一方でシャーディングを始めとする複数クラスタ管理手法は当面使えるため、変化とコストの大きい分散 SQL よりも実績のあるソリューションが適していたという面もあります。ゲームの場合はストレージ量の増加幅も運用年数に応じて下がっていく場合が多く、Aurora や Cloud SQL をシャーディングすれば長期間の運用にも基本的には耐えることができます。

• マネージドサービス（Amazon Aurora, Cloud SQL）を選んだ理由
  • すでに本番運用中であり、チーム内での実績がある
  • 構築・運用コストが低い
    • GR など新しい仕組みの検証・構築には一定の工数がかかる
    • 分散 SQL よりも変更が少ない
  • 使用料金の上昇が許容範囲内
    • Cloud SQL への移行ブログ でも具体的に紹介
    • データ量が多く EC2 では i3en 系を使う必要があった環境では、Aurora に移行してむしろ料金が下がったケースもあった

ちなみに私たちのグループでは分散 SQL を利用している環境もあります。今回の検討はこれまで IaaS 上で MySQL を利用してきた環境についてのものとご理解ください。

最後に

DeNA の大規模環境で MySQL 8.4 への移行方針をどう考えたかを紹介しました。最近のデータベースはグループレプリケーションや分散 SQL など、分散処理を前提とした仕組みが多く出てきており、とてもダイナミックで面白いと感じています。並行してマネージドサービスが台頭しつつあり、MySQL や PostgreSQL も単なるソフトウェアを超えてプロトコルやデータベースエンジンとして部分的に使われるなど、より流動的な状況になっている印象です。それだけに十分な情報収集と思考の価値がある領域ではないでしょうか。

この検討も変わり続ける状況の中での一時点のものであり、決して最終結論ではありません。IT 基盤部ではこれからもさまざまな技術に対して、調査と検証を実施します。