MonotaRO が基幹データベースを Amazon Aurora Global Database に移行し、マルチリージョン DR とフルマネージド運用を実現

このブログ記事は、AWS ソリューションアーキテクトの多田慎也が執筆し、株式会社MonotaRO が監修しています。

はじめに

株式会社MonotaRO （モノタロウ）は、工具、部品、消耗品をはじめとする間接資材のインターネット通販を展開し、連結売上高 3,338 億円（2025 年 12 月期）、登録ユーザー数 1,100 万以上、取扱商品点数 2,800 万点以上を誇る事業者向け EC プラットフォームです。同社はこのたび、事業の根幹を支える基幹データベースをオンプレミスの MySQL から Amazon Aurora MySQL（以下、Aurora MySQL）へ移行し、Amazon Aurora Global Database（以下、Aurora Global Database）によるマルチリージョン DR 構成とフルマネージド運用を実現しました。本ブログでは、移行の背景と課題、選定理由、移行アプローチ、そして得られた成果についてご紹介します。

背景と課題

MonotaRO の基幹データベースは、日々の受発注処理をはじめとする事業のコアシステムとして、大量のクエリを処理しています。同社はクラウド活用を推進してきましたが、基幹データベースがオンプレミスに残っていること、そしてその基盤となる MySQL 環境そのものに、複数の領域で課題を抱えていました。

オンプレミスの基幹データベースがクラウド移行のボトルネックに

基幹アプリケーションやバッチ処理は、基幹データベースに対して大量のクエリを発行しています。アプリケーションとデータベースの間にネットワーク遅延が入ると処理時間が大きく伸びるため、データベースがオンプレミスにある限り、関連するアプリケーション群もオンプレミスに残らざるを得ない状況でした。これにより、クラウドネイティブな開発基盤への移行が制約されていました。

さらに、基幹データベースは事業の広範な領域と密結合しており、ひとたび障害が発生すると、基幹業務のドメイン同士にとどまらず、EC サイトや周辺業務にまで影響が波及する構造でした。この「基幹データベースがオンプレにあるためにアプリもクラウドに移せない」「密結合ゆえに障害影響が広い」という課題は、多くの企業が直面する共通の課題です。

レプリケーション遅延の変動

オンプレミス環境では、プライマリとリードレプリカ間の論理レプリケーション遅延が処理内容によって変動し、状況によっては十数分規模に達することもありました。この遅延により、データ鮮度が求められる処理ではリードレプリカではなくプライマリを参照せざるを得ないケースが生じ、プライマリへの負荷増大を招く要因にもなっていました。

MySQL 保守期限への対応

基幹データベースは旧バージョンの MySQL で稼働しており、保守期限が迫っていました。セキュリティパッチの提供終了リスクへの対処が急務となっていました。

18 台レプリカのセルフマネージド運用負荷

参照負荷に対応するため 18 台のリードレプリカを運用していましたが、すべてセルフマネージドでした。スケールアップ/ダウン作業やメンテナンス対応など、多くの時間が割かれていました。

マネージドなマルチリージョン DR の不在

従来も障害時の復旧手段は備えていましたが、いずれも手動運用を前提としたセルフマネージドな構成であり、マネージドかつ自動化されたマルチリージョン DR は実現できていませんでした。事業の成長に伴い、リージョン障害にも耐えうる DR を、運用負荷を抑えたマネージドな形で整備し、事業継続性をさらに強化することが求められていました。

こうした課題に対し、Aurora の I/O 性能やストレージレベルレプリケーション機能の向上、大阪リージョンの活用によるレイテンシー面の改善、これまでの MySQL 移行で培った移行の練度といった追い風もあり、Aurora への移行が有力な選択肢として本格的に検討されました。

Aurora MySQL 選定の理由

MonotaRO が Aurora MySQL を選定した理由は、以下の 4 点に集約されます。

ストレージレベルレプリケーションによる遅延の根本解消

Aurora はストレージレベルでレプリケーションを行うため、従来の論理レプリケーションで発生していた変動の大きい遅延を根本的に解消できます。リーダー（Reader）は通常ミリ秒オーダーの遅延でライター（Writer）と同期されます。

MySQL 8.0 互換によるアプリケーション改修の最小化と EOSL 解消

Aurora MySQL は MySQL 8.0 互換であり、既存アプリケーションからの接続方法や SQL 構文の互換性が高いため、アプリケーション改修を最小限に抑えながらバージョンアップを実現できます。これにより、保守期限の問題もクラウド移行と同時に解決されます。

フルマネージドによる運用負荷削減と TCO 最適化

Aurora のマネージドサービスとしての特性により、18 台のセルフマネージドレプリカの運用負荷を大幅に削減できます。リージョン内でのインスタンス障害時の自動フェイルオーバー、自動バックアップ、パッチ適用など、従来手動で行っていた運用作業が自動化されます。さらに、ハードウェアの保守・更改やデータセンター運用が不要になり、必要な性能に応じてキャパシティを柔軟に調整できるため、運用工数まで含めた総所有コスト（TCO）の最適化にもつながります。

Aurora Global Database によるリージョンレベルの DR

Aurora Global Database を採用することで、大阪リージョンをプライマリ、東京リージョンをセカンダリとするマルチリージョン構成を実現し、リージョンレベルの障害にも対応可能な DR 構成を構築できます。セカンダリリージョンへのレプリケーションは専用のストレージレベル基盤を通じて行われ、通常 1 秒未満の遅延で同期されます。リージョンレベルの切り替えは、スイッチオーバー（計画的な切り替え）や手動フェイルオーバーにより、迅速かつ制御された形で実施できます。

移行アプローチと技術的ポイント

PoC による性能・信頼性の検証

MonotaRO の開発チームが主導し、約 4 ヶ月間の PoC（Proof of Concept）を実施しました。インフラストラクチャ観点での性能検証やフェイルオーバー動作の確認に加え、アプリケーションの動作検証も行い、本番ワークロードに耐えうることを確認した上で、Aurora MySQL の採用を正式に決定しています。

中継機を用いたレプリケーションでのデータ移行

MySQL のレプリケーションは隣接するメジャーバージョン間でのみサポートされるため、MySQL 5.6 から複数のメジャーバージョンをまたいで Aurora MySQL 3 系（MySQL 8.0 互換）へ直接レプリケーションすることはできません。そこで、MySQL 5.7 の中継用インスタンス（中継機）を挟み、「MySQL 5.6 →（中継機）MySQL 5.7 → Aurora MySQL 3 系」の順でバージョンを 1 段ずつ引き上げながらレプリケーションすることで、オンプレミスから Aurora へ安定してデータを同期しました（図 1）。

(図1: 中継機を用いた段階的レプリケーションによるデータ移行)

参照系から更新系への段階的な切り替え

移行はビッグバン的に一度で切り替えるのではなく、段階的なアプローチを採用しました。まず影響範囲の小さい参照系（Read）のアプリケーションから先に新しいデータベースのリーダーへ接続を切り替え、最後に更新系（Write）のアプリケーションを切り替えました。小さな単位で少しずつ切り替えることで、各段階で動作を検証しながら問題の早期発見と切り戻しを可能にし、ミッションクリティカルなシステムの移行リスクを最小化しました。

AWS Countdown Premium の活用

さらに MonotaRO は、こうした移行を確実に進めるため AWS Countdown Premium を活用しました。同社には過去にオンプレミスから Aurora へのデータベース移行経験がありましたが、今回は過去に対応したことのない規模であり、かつミッションクリティカルなシステムであることから、AWS の専門家による支援を組み合わせる判断をしました。

MonotaRO が AWS Countdown Premium の活用を通じて得た価値は、以下の通りです。

• 専門家レビューによるリスクの事前特定: リソースレビューを通じて、現時点では顕在化していないものの、将来のスケールや運用の中で課題となり得る設計上のポイントを洗い出し、先回りして対処
• インフラメトリクスの立ち合いレビュー: 移行前後のメトリクスを専門家がリアルタイムで確認し、開発チームと専門家の直接コミュニケーションにより、開発チームの安心感を醸成
• 包括的な視点でのアドバイス: データベースだけでなく、データベースに関連するネットワークや運用面も考慮した総合的なアドバイスを提供

以上のように、開発チーム主導の PoC による検証、参照系から更新系への段階的な切り替え、中継機を用いた安定したデータ移行、そして AWS Countdown Premium による専門家支援を組み合わせた結果、移行は計画メンテナンスの範囲内で実施され、予期しないサービス影響を出すことなく完了しました。

構成と成果

最終構成

移行後の構成は、Aurora Global Database を中核としたマルチリージョン構成です（図 2 参照）。

• プライマリリージョン: 大阪リージョン
• セカンダリリージョン: 東京リージョン

(図2: Aurora Global Database 構成図 )

定量成果

※1 本表のレプリケーション遅延は Aurora クラスター内のリーダー参照における値で、通常ミリ秒オーダー（多くの場合 100 ミリ秒未満）です。一方、Aurora Global Database によるクロスリージョンのレプリケーションは通常 1 秒未満です。なお、Aurora から下流のオンプレミス連携先へのデータ連携は、従来と同様の方式で行われます。

※2 リージョン内フェイルオーバーは、障害の自動検知と自動フェイルオーバーによって実行されます。一般的な復旧時間は 60 秒未満（多くの場合 30 秒未満）であり、本記事では保守的に「1 分未満」と記載しています。

障害時の可用性向上と機会損失の削減

今回の移行で最も大きな効果は、基幹データベース障害時の事業影響（機会損失）を大幅に削減できる点です。

• ライター（Writer）のダウン（AZ 障害）時の RTO は、従来の手動切り替えで約 2 時間を要していたところ、Aurora 化により自動フェイルオーバーで1 分未満に短縮されました。障害からの復旧時間が大幅に短縮されることで、ダウンタイムに伴う機会損失を削減できます。
• リージョン障害時にも、Aurora Global Database のセカンダリリージョンへの昇格により、マネージドなクロスリージョン DR を実現しました。従来は手動運用を前提としたセルフマネージドな復旧構成であったのに対し、マネージド化・自動化されたことで運用負荷を抑えつつ、プライマリリージョンの復旧を待たずにサイトの注文受付を再開できます。

セキュリティ・運用面の向上

Aurora は AWS のマネージドサービスであり、ホスト OS への直接アクセスを前提としない運用となるため、実行環境に対する不正アクセスや改竄のリスクを低減できます。あわせて、パッチ適用やバックアップといった運用作業がマネージド化されることで、運用チームはより付加価値の高い業務に注力できるようになりました。

お客様の声

• 「当社はかねてより全社的なシステムのモダナイゼーションを進めてきましたが、その最大のボトルネックの１つであったオンプレの基幹データベースを Amazon Aurora 上へ移行させることができました。参照系から更新系へと段階的に切り替えることでリスクを下げ、業務影響を最小限にとどめながら安全にコントロールされた移行を実現できました。AWS様の的確なサポートにも大変助けられました。今回の移行は MySQL 8.0 へのバージョンアップを兼ねており、多数のリードレプリカに対するレプリケーション遅延の解消に加え、Instant DDL や Blue/Green Deployments によりスキーマ変更をかけにくいという長年の課題も解消。これによりデータ構造のリファクタリングが容易になりました。またクローン機能により検証用データベースも即時に用意できるようになり開発環境の自動化を加速できます。さらに CloudWatch Database Insights によるクエリパフォーマンスの可視化と改善サイクルを早くまわせる仕組みを導入準備中です。今後もモダナイゼーションを進めることでシステムの変更容易性を獲得し、当社の競争優位をさらに強固なものにしてまいります。」 — 株式会社MonotaRO 常務執行役 ソフトウェア本部長 普川氏
• 「オンプレミス環境の稼働メトリクスや全クエリを生成 AI も活用して事前に分析し、移行後に問題となり得る箇所を洗い出したうえで、参照系から更新系へと段階的に切り替えていきました。ミッションクリティカルなシステムでありながら、計画メンテナンスの範囲内で移行を完了できています。現在は、稼働状況をもとに Amazon Bedrock で改善案を生成し、プルリクエストとして開発チームへ提案する仕組みに加え、今後のバージョンアップに備えて現行バージョンと次期バージョンの挙動を突き合わせ、同様にプルリクエストとして提案する仕組みの構築を進めており、Aurora への移行はその土台となりました。」 — 株式会社MonotaRO ソフトウェア本部 コアシステムエンジニアリング部門 基幹モダナイゼーショングループ 石田氏（本プロジェクト PM）
• 「オンプレミスでは、データベース運用の多くが手作業であること、レプリケーション遅延が各システムに影響すること、データベースがオンプレミスにあるためアプリケーションもクラウドへ移せないことなど、長年にわたり様々な課題がありました。Aurora MySQL への移行でその多くに解決の見通しが立ち、システム設計と運用の自由度が大きく広がりました。」 — 株式会社MonotaRO ソフトウェア本部 プラットフォームエンジニアリング部門 サービスインフラグループ 中島氏（インフラ担当）

今後の展望

MonotaRO は以前からクラウド活用やモダナイゼーションを進めてきましたが、基幹データベースはオンプレミスに残り、関連するアプリケーション群のクラウド移行を妨げる要因となっていました。今回の移行によってこの制約が解消され、モダナイゼーションをさらに加速できる状態になりました。

• 基幹システムのモダナイゼーション加速: これまで基幹データベースがオンプレミスに存在していたことで制約されていた関連アプリケーション群のクラウド移行が可能になりました。今後はクラウドネイティブ化（コンテナ基盤への移行）を進め、開発者が新サービス開発や事業成長に直結する業務により集中できる環境の実現を目指します。
• リーダーへの読み取り振り分けによる負荷分散: レプリケーション遅延が解消されたことで、これまでデータ鮮度の都合でライター（Writer）に向けざるを得なかった読み取り処理も、リーダー（Reader）へ振り分けられるようになります。ライターの負荷を軽減し、読み取りのスケールアウトを進める土台が整いました。
• メンテナンス運用の最適化: Aurora MySQL の Blue/Green Deployments を活用することで、メジャーバージョンアップやスキーマ変更といった計画メンテナンスを、ダウンタイムを最小化して実施できます。Blue/Green Deployments では、本番環境の複製（グリーン環境）で事前に変更を検証したうえで、通常 1 分未満・データ損失なしで切り替えが可能です。
• 継続的な運用改善: Aurora が提供する CloudWatch Database Insights や Enhanced Monitoring などの機能を活用し、継続的な運用改善に取り組んでいます。

まとめ

MonotaRO は、基幹データベースをオンプレミス MySQL から Aurora Global Database に移行し、レプリケーション遅延の根本解消、マルチリージョン DR の実現、18 台のセルフマネージドレプリカからフルマネージド運用への転換を達成しました。加えて、障害時の RTO 短縮により、障害時の事業影響（機会損失）を大幅に削減できる見込みです。この移行は、単なるデータベースの載せ替えではなく、クラウドネイティブな開発基盤への移行を加速させる重要な一歩です。