５年間のDB技術選定・運用を振り返る Aurora MySQL, RDS MySQL, RDS PostgreSQL が混在した理由と今後の展望

2025/11/13 に開催された アーキテクチャConference 2025 プレイベント(https://findy-tools.connpass.com/event/373033/) の登壇資料です。

Transcript

1. ５年間のDB技術選定・運用を 振り返る Aurora MySQL, RDS MySQL, RDS PostgreSQL が混在した理由と 今後の展望 2025/11/10 アーキテクチャ Conference 2025 プレイベント
2. 自己紹介 猪熊 朔也 ( いのくま さくや ) / @sinocloudon - 株式会社 Red Frasco - インフラ/SRE ◆経歴 - 金融系 SIer, リクルート(SUUMO), 金融系スタートアップ, 現職 ◆その他コメント - うどんが好きです - ラーメン二郎が好きです - うどん脳 をプロフィールアイコンにすることが多いです 2
4. 4 前提
5. 本セッションの前提 • Red Frasco は、不動産業界に特化した技術組織です • マーケティングから開発までクライアント様の集客を全面的に支援 • 今回の LT は、いい部屋ネット (https://www.eheya.net/)におけ る取り組みを題材としています 5
6. 本セッションの前提 • いい部屋ネットは、約4年間かけて AWS へ完全移行しました • AWS Summit Japan 2025 のアーカイブ動画もご覧ください • https://youtu.be/YyxYLggVcUA?si=GlPX2QS6muB05Jaj 6
7. 7 基盤の全体構成
8. 8 カスタマー向け いい部屋ネット (コンテナベース) クライアント向け 物件管理システム (EC2+RDSベース) ETLパイプライン (サーバレス) 基盤の全体構成 フロントチーム バックエンドチーム 業務システムチーム
9. 9 カスタマー向け いい部屋ネット (コンテナベース) クライアント向け 物件管理システム (EC2+RDSベース) ETLパイプライン (サーバレス) 基盤の全体構成 フロントチーム バックエンドチーム 業務システムチーム 特性の異なる3つのシステムが存在
10. システムの全体像 10 物件情報の作成 物件情報の変換 物件情報の表示 外部 システム群 担当者 物件管理 システム ETL パイプライン 外部 システム群 File I/F カスタマー いい部屋ネット 手作業 DB Upsert File I/F
11. 11 本題
12. 時系列でみるDB技術選定の変遷 12 2021 2022 2023 2024 2025 ポータル サイト ETL パイプ ライン 業務 システム SQL Server (オンプレ) RDS MySQL 5.x RDS MySQL 8.x RDS PostgreSQL 17.x Oracle Database(オンプレ) RDS PostgreSQL 16.x RDS PostgreSQL 17.x Aurora MySQL 3.x (MySQL 8.x互換)
13. 時系列でみるDBの変遷 13 2021 2022 2023 2024 2025 ポータル サイト ETL パイプ ライン 業務 システム SQL Server (オンプレ) RDS MySQL 5.x RDS MySQL 8.x RDS PostgreSQL 17.x Oracle Database(オンプレ) RDS PostgreSQL 16.x RDS PostgreSQL 17.x Aurora MySQL 3.x (MySQL 8.x互換) １ 2 3 4 4つのDB技術選定について1つずつ振り返り
14. 1. ETLパイプラインの DB を SQL Server から RDS MySQL に移行 14 ✓ RDS MySQL に移行することにした ✓ スケジュール制約があり、かつ開発メンバーが慣れていたため ✓ オンプレミスからAWSへ急いで移行する案件だった(開発期間が3ヶ月程度) ✓ 現行仕様書がなく、リバースエンジニアリング必須 ✓ MySQLを使ったシステム開発の経験があるメンバーが多かったため、MySQLを選択 ✓ 1日2回動作すればよいため、性能要件のハードルは低い [よかったこと ] ✓ スケジュール遅延なく移行できた。目立ったトラブルもなし [もうちょっと ] ✓ 最初から PostgreSQL を選択していれば、DBエンジンを統一できた ✓ 自分たちの手癖で本来あるべきアーキテクチャを歪めてしまったかも [まなんだこと ] ✓ 自分たちの能力を過信せず、スケジュール責任を果たすことは重要 ✓ 当時に戻って、PostgreSQL を選択する勇気を持つ自信はない… ✓ 起きるかどうかわからない未来(Oracle移行)は考えても仕方がない ✓ その時に考える。早すぎる最適化や必要以上な将来要件の考慮はしない 判断結果 当時の状況 振り返り 1 2 3
15. 2. 物件管理システムの DB に Aurora MySQL (MySQL 8.x 互換) を選定 15 ✓ Aurora MySQLを選定した ✓ ETLパイプラインの知見が活用でき、RDS MySQL より高機能だったため ✓ 不動産会社様が日常的に使用する業務システムのため、一定水準の堅牢性を求めていた ✓ 今後リリースされるであろう新機能の恩恵を享受することで、運用負荷やダウンタイムを 軽減しやすくしたかった ✓ ETLパイプラインと同様のバッチ処理があったため、先行知見を有効活用したかった [よかったこと ] ✓ 2022年の re:Invent で RDS の BG デプロイが発表。本番リリース後、実際に BG デプロ イを使ってバージョンアップすることができた [もうちょっと ] ✓ 知見の共有はあまりできなかった ✓ DBに関する課題(主にSQLチューニング)はシステム固有の話が多く、むずかしい ✓ データの増加や要件追加によるパフォーマンス問題に現在も向き合っており、リリース前 にもっとできたことがあったかも [まなんだこと ] ✓ システムごとに愚直に最適化する以外に有効な手段はない(＝銀の弾丸はない) 判断結果 1 当時の状況 2 振り返り 3
16. 3. ポータルサイトの DB を Oracle から RDS PostgreSQL に移行 16 ✓ RDS PostgreSQL に移行することにした ✓ Oracle との互換性が高く、Aurora PostgreSQL と比べて性能懸念もなかったため ✓ 1年以内に確実に移行を完遂したかった (年度をまたぐと、Oracleの費用がもう1年分追加でかかることになるため) ✓ Oracle との互換性が高く、移行難易度が最も低いDBを選定する必要があった ✓ Aurora PostgreSQL 前提で進めていたが、途中で性能問題が発覚した [よかったこと ] ✓ 年度内に移行達成。1ヶ月くらい余裕をもって移行できた ✓ 徹底的なパフォーマンスチューニングにより、移行前よりスループット向上 [もうちょっと ] ✓ 当初とりあえず Aurora を選択したが、物件データ更新処理で性能問題が発覚して手戻り ✓ パフォーマンスチューニングが大変だったため、もっと前もって着手していればよかった ✓ チューニング後に再度性能検証したら、Aurora PostgreSQL の方がさらに早かったかも [まなんだこと ] ✓ 特定の技術や製品を盲信しない。実際に計測して比較検討すべし(自戒を込めて) 判断結果 1 当時の状況 2 振り返り 3
17. 4. ETLパイプラインの DB を RDS MySQL から RDS PostgreSQL に移行 17 ✓ RDS PostgreSQL に移行することにした ✓ ポータルサイトと同じ PostgreSQL にすることで、開発や運用をしやすくするため ✓ 本番相当のデータを使って、ETLパイプラインをテストできる環境がなかった ✓ 本番データを同期する仕組みが、ETLパイプラインにも必要だった ✓ ポータルサイト側にはすでにデータ同期の仕組みが存在 ✓ 物件管理システムより、ポータルサイト都合で改修が発生することの方が多かった [よかったこと ] ✓ DBエンジンの差異がなくなり、データ同期など開発や運用を効率化する仕組みを共 有することができた ✓ 遠回りはしたが、Oracle 移行で得られた知見を活かし、スムーズにDB移行できた [もうちょっと ] ✓ 結局 PostgreSQL になったので、最初から…(以下略) [まなんだこと ] ✓ ETLパイプラインは入力元(物件管理システム)よりも出力先(ポータルサイト)の一部 であるという捉え方をした方が、我々にとっては都合がよい 判断結果 1 当時の状況 2 振り返り 3
18. 5年間のDB選定・運用全体をふりかえって 18 • 遠い将来を見据えて技術選定することの難しさ • 不確定要素だらけの中で、どうやって・どこに正しさを見出すのか？ • 運用をしていく中で、統一・集約すべきものと分離すべきものがみえてくる • 正解は1つではなく、システムの特性やその時の状況などコンテキスト次第 • 課題を解決できていることが最も重要 • 技術選定のミスがあったとしても、課題が解決していればビジネスとして大きな失敗には なりづらい • われわれの環境においては、Aurora だけでなく RDS も積極的に検討する • 高性能、高可用性はもちろん大切だが、コスト(ビジネス)とのバランスを考慮 • どちらを選んでも運用面での機能についてはそこまで大きな差がない(困らない)
19. 19 おわりに
20. Red Frasco における技術・アーキテクチャ選定の考え方 20 課題ベースで適用技術や アーキテクチャを決める ✓ 課題を抽出して整理する ✓ 課題を解決するための技術・アーキテクチャを選択 1 むやみに標準化しない 2 聖域を作らない 3 ✓ 課題やシステム特性に応じて最適な技術や アーキテクチャを選択 ✓ 価値のある技術や仕組みに絞って横展開(例：監視基盤) ✓変えるべきものは変える(脱・現行踏襲) ✓時間はかかったとしても、課題解決を優先
21. 再掲：システムの全体像(技術スタックあり) 21 物件情報の作成 物件情報の変換 物件情報の表示 外部 システム群 担当者 物件管理 システム ETL パイプライン 外部 システム群 File I/F カスタマー いい部屋ネット 手作業 DB Upsert File I/F
22. 全体のまとめ・今後の展望 • 引き続き、課題に対して最適な技術やアーキテクチャを検討 • DBに関して言えば、RDBMSに限らずさまざまなデータストアを視野に • 引き出しを多く持つことが大切で、日々の情報収集を怠らないこと • さまざまな技術・アーキテクチャが混在しても滞りなく運用 • 技術が統一されていなくてもつつがなく運用を回せるような仕組みを考えていく • その時は正解じゃなかったとしても、自分の腕で正解にしていく(精神論) 22 みなさんはどうやって技術選定していますか？ カンファレンスにてぜひ意見交換させてください！
23. END OF PRESENTATION ご清聴ありがとうございました