はじめに
本記事は AWS Summit 2025 Day2(2025/6/26)において KDDI の 鎌田氏 が講演された「Oracle から Aurora へ：クラウドネイティブで切り拓くビジネス DX 基盤刷新とビジネス貢献」のレポートです。
公式セッション紹介
KDDI はビジネス DX 創出の加速に向け、密結合だった基幹システムを疎結合化し、通信・金融など異業種データを横断かつリアルタイムに活用できるデータ照会基盤 『JOINT』 を AWS に構築しました。しかし、数年の運用で Oracle DB の運用負荷とコストが課題となり、 Aurora 移行を決断、DB コスト 50% 削減と性能向上を実現しました。本セッションでは、DB 移行の中で直面した技術課題や実践した工夫をお話ししながら、クラウドネイティブで切り拓いたビジネス貢献についてお伝えします。
（引用：Oracle から Aurora へ：クラウドネイティブで切り拓くビジネス DX 基盤刷新とビジネス貢献）
発表動画
Oracle から Aurora へ：クラウドネイティブで切り拓くビジネス DX 基盤刷新とビジネス貢献
※要登録
概要／おすすめポイント
Oracle DatabaseからAurora(PostgreSQL互換)への移行について、課題と対応について事例をあげて説明されており、非常に納得感の高いセッションとなっていました。特に、OracleからPostgreSQLにデータベースエンジンの変更を行っていますが、具体的に #1機能変化品質、#2検証品質、#3移行品質、と三つの観点でそれぞれ品質に関しての取り組みの実事例をあげられていたため、それぞれどうしようか、と悩んでいる人に参考になる内容だったと考えてます。
セッション内容の紹介
※画像は基本的にセッション動画が出典となります
- Agenda
- ビジネス戦略とシステム戦略
- データ照会基盤の課題とモダンアーキテクチャーへの移行
- さらなる改革へ ～クラウドネイティブの真価～
- まとめ
本レポートでは「データ照会基盤の課題とモダンアーキテクチャーへの移行」をメインで紹介していきます。
ビジネス戦略とシステム戦略
KDDIとして持っている既存のITアセットを「データ照会基盤」としてプラットフォーム化することで、多種多様な顧客に提供していく、という流れを説明されてました。
今回のお話は Stage② の部分でのデータベースのリアーキテクトをメインでお話されていましたが、Stage①のシステム構造のモダナイゼーションが完了している、という点が大きいと感じました。
- Stage①のシステム構成イメージ
- Stage②のシステム構成イメージ
データ照会基盤のリアーキテクチャ
Stage①でクラウド化を行った際のシステム構成は次のような形とのことです。
この段階ですでに Fargate を利用したAPI提供などは実施されていることが確認できます。
一方で、Oracle DBの部分はいわゆる従来型のアーキテクチャ、EC2上のOracle DBとして構築されており、またデータ連携部分もGoldenGateやバッチなどで連携されていることがわかります。
この構成がリアーキテクチャを行うことで、Oracle DB部分をAuroraサーバーレスに、そしてデータ連携部分を GoldenGate HUBやS3連携に集約されています。
リアーキテクチャにおける品質確保
リアーキテクチャにおける品質確保については、次の3点を重要視して確保されたとのことでした。
- 機能変化品質：機能差分のチェック・確認
- 検証品質：API、DBデータ、連携データの差分確認
- 移行品質：DB並行運用、APIカナリアリリース
いずれも、上位のAPIが Fargate などを活用したマイクロサービス化が実施されていたため、比較や並行運用などが実施しやすかったものと理解しました。
それぞれどのような観点で実施されていたのかを紹介します。
1．機能変化品質：機能差分のチェック・確認
Aurora for PostgreSQLへの変更も、単にSCT（Schema Conversion Tool）を通してSQL改修を行うのではなく、そのSQLで実現したいこと（たくさんのテーブルからデータを取得したいのか、少数のテーブルからUniqueでとってきたいのか、など）をベースにアプリケーションとしてのレスポンスを追求した、とのことです。
2．検証品質：API、DBデータ、連携データの差分確認
APIレイヤ、DBデータレイヤ、連携データレイヤでそれぞれ突合をおこない、また本番環境のトランザクションログベースでのシナリオを実施することで差分確認を徹底的に実施されたとのことでした。
マイクロサービス化が既に行われていたので、API側の比較とかがやりやすかったのもあるのかなと感じました。
3．移行品質：DB並行運用、APIカナリアリリース
移行においてはDBの並行運用をおこないデータ整合性を確認したうえで、APIの段階的切り替え（カナリアリリース）を実施して無停止で移行をやり切ったとのことです。
並行運用を実施したことで、移行でよくあるアプリケーションの凍結期間などを設けることなくリリースを行うことができたそうです。
こちらも、既にマイクロサービス化が行われていたので一部を切替、という判断ができたのだととらえています。
リアーキテクチャの成果
リアーキテクチャを実施されたシステムとしての成果として、次図をあげられていました。
やはり運用コスト半分で処理能力2倍というのはインパクト大きいですね。
システムをクラウドに移行する、モダナイズを行う、そしてリアーキテクチャを行う、というお手本のような流れできちんと成果を出されているところが素晴らしいと感じました。
もう一つ大きな成果として挙げられていたのはチームのモチベーション向上でした。
特に大規模のOracle DBを運用する場合、メンテナンスやパッチ適用、バージョン管理など、インフラ周りで実施しないといけない点が多く、また、それらがそれなりに高度な知識を要求される、ということもありなかなか難しい形になることが多いです。
一方で、クラウドのフルマネージドのサービスを利用する場合には比較的メンテナンスなどは大きな選択を行うだけなので、比較的維持ではない箇所に注力できる、というところは配置されているエンジニアのモチベーションに影響する、というのはよく理解できる話でした。
別途紹介しますが、裏側を紹介したKDDIさんのblogで、コスト削減意識がメンバー全員に芽生えた、と紹介されていたのが印象的でした。
さらなる構造改革に向けて
今後は可用性の向上を目指していく、ということで次のスライドが説明されていました。
アプリケーション側はコンテナからTypeScript, Lambdaに変更することでスケーリングを向上させ、DBは東阪でBlue/Greenを実現していく計画とのことです。
まとめ
OracleのAWSマイグレーション自体は 住信SBI銀行の事例 が広く知られていますが、それも含めてAWS Summitという場で具体的に発表されたことはなかったと記憶しています。
昨年のAWS Summitでは KDDI 系列の auコマース＆ライフ 様が 脱Oracle Exadata というテーマで発表されてましたが、Oracleからの脱却も検討したが最終的には RDS for Oracle への移行を選択されていました。
今回の発表は、Oracle から PostgreSQL(Aurora) への具体的な品質確保の内容をSQLなどのレイヤも含めて発表されていたので、とても興味深いものとなりました。
また、本発表の舞台裏という事でプロジェクトメンバの方が 大規模データ照会基盤のモダン化-DB移行の舞台裏- として解説されており、Oracleに最適化されたSQLをどのようにPostgreSQLへ最適化したか、という示唆に富む内容となってます。引き続き紹介していきたい、という形で締めくくられていますので、今後のアップデートも注目ですね。
十分に入念な準備・品質確保を行うことで移行時の障害をゼロに、というのは本当に素晴らしい成果だと思います。逆に、Oracle からの移行、というのはこれだけ大変だ、というのが改めてわかりますね。
Oracle@AWSもGAされたことで、AWSへのOracleマイグレーションは様々な形をとれるようになりました（別枠でOracleマイグレーションジャーニーのセッションもありました）。
今後もキャッチアップ継続していきたいと考えてます。