“後発優位”で挑んだ 「いい部屋ネット」再構築： 4年間のAWS移行で実現した成果とその舞台裏

2025/6/25,26 に開催された AWS Summit Japan 2025 の登壇資料です。
株式会社Red Frascoは「いい部屋ネット」のAWS移行プロジェクトに開発協力会社として参画し、その事例が AWS Summit Japan 2025で紹介されました。
本プロジェクトに従事した弊社所属の猪熊朔也が、大東建託パートナーズ株式会社の一員として登壇し、技術的知見を共有いたしました。

参考URL：https://aws.amazon.com/jp/summits/japan/

Transcript

1. AWS Summit Japan 2025 “後発優位”で挑んだ 「いい部屋ネット」再構築： 4年間のAWS移行で実現した成果とその舞台裏 1
2. 自己紹介. 2 ◆ 経歴: エンジニア12年 （バックエンド4年 + インフラ8年） ◆ 出身: 香川県 ◆ 好きな食べ物: うどん 猪熊 朔也 大東建託パートナーズ いい部屋ネット事業部 インフラエンジニア
3. 大東建託パートナーズについて ◆ 本社: 東京都港区港南二丁目16番1号 品川イーストワンタワー ◆ 設立年月: 1994年7月 ◆ 事業内容: • アパート、マンションの管理 • アパート、マンション オーナ様のサポート • 入居者様のサポート • 入居者様斡旋 ✓ いい部屋ネットの運営 ✓ いい部屋ネットフランチャイズの展開 3 大東建託パートナーズ 管理 大東建託リーシング 仲介 大東建託 建築 大東建託グループ 組織関係図 いい部屋ネット
4. いい部屋ネットとは 賃貸物件をお探しの方向けの不動産ポータルサイト PC、スマホ、ネイティブアプリから利用可能 4
5. 本セッションの前提 5 本セッションでは、いい部屋ネット(Web)にフォーカスします ※実際には、物件情報入力・変換を担うバックエンドシステム群も存在します 物件情報の作成 物件情報の変換 物件情報の表示 外部システム群 担当者 物件管理 システム ETL パイプライン 外部システム群 File I/F File I/F カスタマー いい部屋ネット 家探し DB Upsert 本セッションの スコープ 手作業 バックエンドシステム群は スコープ外
6. いい部屋ネット(Web)完全移行までの道のり 6 ４年間かけて、アマゾン ウェブ サービス (AWS) へ完全移行しました 本日はそれぞれ下記のようにStepに分けて説明していきます 2020.04 新体制始動 2021.04 AWS移行開始 2022.01 AWS移行 初回リリース 2022.11 CDN移行 2023.10 iOSリニューアル 2024.11 DB移行 画面リニューアル （詳細 / 一覧 / TOP） BGデプロイ導入 画面の段階的移行 2024.10 Androidリニューアル 2020 2021 2022 2023 2024 2025 データパイプラインの再構築 物件管理システムの再構築 Step.0 スモールスタート Step.1 移行プロセスの開始 Step.2 アプリケーション アーキテクチャの刷新 Step.3 クラウドネイティブ アーキテクチャへの 刷新 Step.4 Oracle から Amazon RDS for PostgreSQL への移行
7. Step 0. スモールスタート いい部屋ネット、AWS への完全移行 7
8. 移行前のいい部屋ネットの状況（〜2020年） • ビジネススピードが上がりづらい開発環境 ✓ 技術負債で思うように開発が進まず、リリースのサイクルが長期化 ✓ 特定のエンジニアしかメンテナンスできず、属人化が深刻 • コストは右肩上がり、しかし安定性は低下 ✓ 繁忙期のたびにリソースを “増やして解決” ⇨ インフラ費が膨張 ✓ 障害によるダウンタイムが頻発し、カスタマー体験を毀損 • 課題＝伸びしろ ✓ 山積みの改善ポイント ⇨ 成果を出せる余地が大きい ✓ どうにかするために模索が始まった 8 問い合わせ数の成⻑が頭打ち “強く、止まらないサービス” への刷新が急務でした
9. スモールスタートで道を切り拓く 9 “問い合わせ数” を KPI として設定 ビジネスが本当に伸びるのか？を先に確かめることにしました 課題が山積み KPIを1つに絞る まずは検証してみる ✓ ビジネス／システム両面の改善項目が多すぎる ✓ 優先順位がつけられない ✓ まずは「問い合わせ数」 を伸ばせるか検証することにした ✓ 数値で成否を計測することができる ✓ 小さく勝って、次の投資判断を加速させる “実験場” でもあった ✓ 成功すれば、大規模投資（AWS移行）の説得材料になる 1 2 3
10. スモールスタートをどのように設計したか 10 問い合わせ数に直結する３画面のみを対象とし、 高速にUIを改修してどこまで改善できるかの"小さな検証"を行うこととした 《検証ポイント》 問い合わせ数 +??% 検証ポイント 問い合わせ数の変化 期間 3ヶ月 対象範囲 スマホ版 × 一覧・詳細・フォーム アプローチ UIのみに絞って高速に改修 （前提: 既存アプリ・インフラを最大限活用） 物件一覧 物件詳細 お問合せ フォーム 完了
11. 11 コアコンセプト: 細かく高速に検証していく ホームラン狙いの開発スタイル 何度も打席に立つ開発スタイル 1発のホームランを狙うのではなく、何度も打席に立つことを意識 目標 時間 〜 長い検討＆開発 目標 時間 不確実性 効果の 不確実性 イチかバチかの一発勝負 目標効果を超えられるか？？？ 効果 効果 細かいチャレンジを 続けていく（何度も打席に立つ） 効果影響を見ながら 細かく方向転換
12. 12 リリース回数・速度を上げるため、自動リリースの仕組みを最初に導入 (チーム体制やPJ管理ツールといった開発プロセスも同時に見直し) 12
13. 参考) 当時の検証ロードマップ 13 優先順位 1群の例 • ボタン／テキスト類の変更 • 色味の変更 • パーツUIデザイン変更／入替 • 上記に伴うヘッダ／フッタのデザイン変更 優先順位 2群の例 • 問い合わせフォームの刷新 • 詳細ページ内物件レコメンドの実装 • 画像ギャラリーの実装 • 新問い合わせフォーム (レコメンド物件の準備なども含む） AWS 移行検討 緊急事態宣言と同時にスタート
14. 参考）物件詳細のUI比較（BEFORE/AFTER) 14 フォームの最適化（EFO）を中心にUI改修を実施
15. スモールスタートで確証を得た 15 検証の結果、開始3ヶ月でお問い合わせ数は大きく改善 それと同時に課題も浮き彫りになった GOOD BAD • 問い合わせ数 200%！ • 課題＝伸びしろ説は正しそうだ • 本格的な AWS 移行の決断につながった • リリースごとに数十秒〜1分程度のダウン タイムが発生 • CDN がうまく使えておらず、レスポンス が遅い • 改修範囲が想像よりも広い 画面ごとの改修に適していない作り
16. Step 1. ビジネスを止めない移行プロセスの構築 いい部屋ネット、AWS への完全移行 16
17. AWS 移行を決めたときの状況 • なぜ後発組が有利か？ ✓ 先行事例やベストプラクティスが充実しており、標準構成を一気に導入できる ✓ 既存アカウントがないので、制約がなくフラットに移行方針を検討できる • 移行をはじめるにあたって、主に下記2点について検討した ✓ Landing Zone：セキュリティ & ガバナンスを満たすマルチアカウント基盤 (AWS Control Tower) ✓ Migration Strategy：アプリを段階的に移行する戦略(ストラングラーパターン) 17 当時、AWS アカウントは持っていなかった 検討を進めるうちに、後発組こそ有利に進められることに気づいた
18. Landing Zone に基づいたアカウント構成 18 マルチアカウント運用に必要な構成要素を最初から考慮することで、 途中の構成変更などの手戻りリスクをおさえる Payer (管理アカウント) Infra Core いい部屋ネット ETL パイプライン 物件管理 システム 監査用 AWS Control Tower 自動生成 将来を見越したOU構成 開発・本番アカウントの分離 アカウント OU IdP CI/CD Audit Log 開発 STG 本番 開発 STG 本番 開発 STG 本番 ネット ワーク ドメイン、専用線、TGW集約 外部向けのIAM集約 IaC による自動デプロイ基盤
19. AWS Control Tower によるマルチアカウント管理・統制 19 AWS Control Tower の機能をフル活用 運用負荷を抑えながら、一定水準のセキュリティ・ガバナンスを維持 ✓ ボタン１つでアカウント構築が可能 ✓ Amazon EventBridge と連携し、デフォルトVPCなど不要リソース自動削除 ✓ AWS IAM Identity Center でシングルサインオン環境を構築 ✓ チームや役割に応じてアクセスユーザーと権限を一元管理 ✓ デフォルトで監査ログを取得(Audit, Log Archive) ✓ デフォルトでガードレールが設定される ✓ AWS CloudFormation StackSets を利用して共通インフラリソース配布 アカウント作成 アクセス権限管理 アカウント管理・統制
20. AWS への移行戦略 20 ビジネスを改善しながら移行することが必須だと考え、 移行戦略としてストラングラーパターンを採用 改善を止めたくない 移行のために改善を止めると 成長機会が失われてしまう 移行も進めていきたい 改善に終わりはないので 移行と同時並行するしかない ストラングラーパターンによる移行 段階的に移行できる戦略を策定
21. • 既存システムを段階的に移行する方式 • 提唱者である Martin Fowler 氏が熱帯雨林の旅行中 に見た、つる植物から発想 • 一般的に以下のような流れで移行する ✓ 新旧システムの前段にファサードを配置し、 リクエストを振り分けられるようにする ✓ 段階的に新システムにリクエストを振り分ける ✓ 新システムへの切り替えが完了したら、 旧システムを廃止する 21 参考）ストラングラーパターンとは 既存の大樹にからみついて、徐々に成長する植物 https://martinfowler.com/bliki/StranglerFigApplication.html
22. ストラングラーパターンの実践 22 いい部屋ネットでは、下記のようにパターンを適用していった 専用線の敷設 (AWS Direct Connect) リバースプロキシ導入 画面ごとに移行 ✓ セキュリティやオンプレミスのネットワーク安定性を考慮し、 まずは AWS から既存 DB を参照するために専用線を敷設 ✓ AWS Transit Gateway も併用して安定的な通信経路を確立 ✓ オンプレミスと AWS の振り分けをするため (ファサード) ✓ ページ単位で移行するには、Application Load Balancer（ALB）より 細やかな制御が必要になるため導入 ✓ 改善を実施する画面(機能)ごとに AWS へ振り分けていく ✓ 不要になったリソース(サーバ、テーブル、ドメインなど)は、 順次オンプレミス側から消していく 1 2 3
23. ストラングラーパターンの変遷 23 1 移行初期 オンプレミスが主 2 移行中期 AWSを主に逆転 3 最終形 オンプレミス撤去 オンプレミス AWS オンプレミス AWS オンプレミス AWS CDN Web サーバー 旧アプリ DB リバース プロキシ 新アプリ Web サーバー 旧アプリ DB リバース プロキシ 新アプリ CDN Web サーバー 旧アプリ DB リバース プロキシ 新アプリ CDN DB 撤去 専用線接続 専用線接続
24. 移行プロセスの振り返り • 構築初期から5年以上経過した今でも困っていない ✓ Landing Zone のおかげで、アカウント構成の見直しをすることなく運用できている （ベストプラクティス・先行事例の偉大さに感謝） ✓ AWS Control Tower によって、ガバナンスを効かせながら運用できている • ビジネスの改善を止めずに移行も同時に進めることができた ✓ ストラングラーパターンを採用することで、"いいとこどり" ができた ✓ スモールスタート時に大切にした「細かく改善」という考え方は、AWS 移行でも活かせた 24 ベストプラクティスや先行事例を取り入れながら移行プロセスを構築 移行もビジネスの改善も両方をやりながら移行することに成功
25. Step 2. アプリケーションアーキテクチャの刷新 いい部屋ネット、AWSへの完全移行 25
26. • リリースするたびに数十秒〜1分程度の ダウンタイムが発生 • CDNがうまく使えておらずレスポンスが遅い • 改修範囲が想像よりも広い →画面ごとの改修に適していない作りだった • ネイティブアプリ（Android・iOS）の リニューアルも行う • 現行DB（Oracle）の移行も行う 26 アプリケーションの刷新に必要な要件とは(1/2) ①スモールスタートで気づいた課題 ②未来の要件 ①現在直面している課題の解決 と ②未来の要件を満たすこと この2つが重要であると考え、要件を整理した ①の整理: ✓ 高頻度リリースに耐えられる ✓ CDN のフル活用ができる ✓ 画面ごとに疎になるような作り ②の整理: ✓ Web とネイティブアプリで基盤を共通化 ✓ DB に依存しすぎない作り ＋
27. 27 アプリケーションの刷新に必要な要件とは(2/2) 刷新で実現したいこと 解決策 高頻度リリースに耐えられる Blue/Green Deployment CDN のフル活用 画面ごとに疎になるような作り Next.js による画面ごとの最適化 自由度が高いリバースプロキシ層の追加 ネイティブアプリとの基盤共通化 GraphQL による表現層とデータ層の分離 DB(Oracle) に依存しすぎない作り 利用テーブルの最適化、ストアドなどのDB 依存機能の廃止、など
28. 28 アプリケーションアーキテクチャの全体像 Amazon CloudFront ELB Amazon ECS Nginx (リバースプロキシ) Amazon ElastiCache (Redis) Amazon ECS Next.js Amazon ECS GraphQL Oracle DB AWS WAF オンプレミス 大きく3つの層に分けてアーキテクチャを再構築 Web(プレゼンテーション層) 自由なリバースプロキシと 画面単位で最適化された アプリケーション 本質的には iOS/Android と 同じ1つのプレゼンテーション層 CDNとWAF パフォーマンスの最大化 柔軟なアクセス制御 抽象化されたデータ層 Web もネイティブアプリも 同一の（標準化された） データ構造で通信
29. Green環境 Blue環境 アプリケーションアーキテクチャの全体像（詳細） 29 CloudFront ELB AWS WAF Amazon ElastiCache (Redis) Oracle DB オンプレミス Proxy ECS リバースプロキシ Front ECS API ECS Nginx Next.js Apollo GraphQL Proxy ECS リバースプロキシ Front ECS API ECS Nginx Next.js Apollo GraphQL • Blue/Green Deployment により、 無停止で環境切り替え • 切り戻しも容易かつ高速にできるため、 安心してリリースができる • Nginxをリバースプロキシとして導入することで 柔軟なページ・アセット管理ができる • 画面単位の移行や、Amazon S3 にホストされた コンテンツへのリバースプロキシが簡単にできる • iOS/Android は GraphQL に直接アクセスする （Web と同じデータを利用） • CDN だけでなく ElastiCache に クエリキャッシュを導入 • 多段キャッシュによりアーキテクチャ全体で パフォーマンスを追求
30. 30 アーキテクチャの刷新でどうなったか？ 解決策 結果 Blue/Green Deployment 2,000回/4年 の無停止リリース実現 Next.js による画面毎の最適化 & 自由度が高いリバプロ層の追加 大半のページが2桁msの爆速レスポンス GraphQL によるプレゼンテーション層と データ層の分離 ネイティブアプリ刷新にかかる工数が激減 Android は6ヶ月で実現
31. 参考）Blue / Green Deployment とリリース回数 31 実行順や並列処理といった工夫により 15分以内に完結するように CircleCI でのワークフローも最適化 2020年〜2025年2月までの集計 以降はすべて 無停止リリース
32. 参考）大半のページが爆速レスポンス 32 Next.js でページごとにキャッシュを個別最適化し、 CDNを経由する場合は~10ms、経由しない場合でも平均~80msでレスポンス CDNヒット時の爆速レスポンス
33. 補足) GraphQL と REST の比較@いい部屋ネット 33 GraphQL の例 REST API の例 ✓ コンポーネントごとに必要な項目を宣言してクエリを構築 するのでムダがない (Colocating Fragments) ✓ 不動産のような項目が多いサイトと相性がよかった ✓ エンドポイントを機能ごとに複数作る ✓ 過不足ある取得（多すぎたり少なすぎたり） ✓ バージョン管理が大変 <RoomPage /> query RoomQuery { room { ...RoomFragment } } <Room /> ...以下省略 <<複数のエンドポイント>> • 物件詳細 /v1/rooms/:id/ • 周辺環境 /v1/facilities/?lat=xx,lng=yy • レコメンド /v1/recommend/?room_id=...
34. 補足) GraphQL の光と闇 • 多段クエリを解決するときのパフォーマンス問題（N+1問題） ✓ DataLoader + Amazon ElastiCache(クエリキャッシュ) を導入しないと実用に耐えなかった • セキュリティ対応に苦労した ✓ 定義したクエリ以外で実行できない仕組みを独自に実装する必要があった。 用意された機能 (PersistedQuery) では自分たちのやりたいことと微妙にマッチしなかった • そもそもスキーマ設計やグラフ構造の設計が難しすぎる ✓ 物件に紐づく項目数や関連が多く、議論が尽きない ✓ 項目数だけでも数百〜数千にのぼり、命名１つとっても苦労する （例:敷引償却金の英語表現） 34 GraphQL による恩恵は大きかったが、同時に取り扱いも難しかった すべてを語り尽くせないため、今回は割愛 恩恵が大きいからといって、安易におすすめはできない
35. アプリケーションアーキテクチャ刷新の振り返り • 課題を整理することではじめて最適な技術・アーキテクチャがみえてくる ✓ アプローチが逆だったら失敗していたかもしれない ✓ 技術選定が失敗しても課題が解決していればビジネスとして大きな失敗にはなりづらい • その上で、聖域を作らず、変えるべきものは変えるスタンスを貫く ✓ リアーキテクチャによる課題解決を優先し、現行仕様の変更をいとわない（脱・現行踏襲） ✓ 時間はかかるが、こうした姿勢がアーキテクチャ刷新の成功につながったと考えている 35 AWS 移行や特定の技術を目的にせず、 課題ベースでアーキテクチャを再構築したことがよい判断だった
36. Step 3. クラウドネイティブアーキテクチャへの刷新 いい部屋ネット、AWS への完全移行 36
37. （再掲）いい部屋ネット完全移行までの道のり 37 ４年間かけて AWS へ完全に移行しました 本日はそれぞれ下記のように Step に分けて説明していきます 2020.04 新体制始動 2021.04 AWS移行開始 2022.01 AWS移行 初回リリース 2022.11 CDN移行 2023.10 iOSリニューアル 2024.11 DB移行 画面リニューアル （詳細 / 一覧 / TOP） BGデプロイ導入 画面の段階的移行 2024.10 Androidリニューアル 2020 2021 2022 2023 2024 2025 データパイプラインの再構築 物件管理システムの再構築 今回は CDN をクラウドネイティブアーキテクチャに刷新した事例を紹介
38. • 年間契約のため、繁忙期にあわせて契約量を 高く設定せざるをえない • サイトが成長すればするほどコストが増加 • 料金・サービス体系が複雑 • 配信量の80%が画像配信 • Akamai の Image & Video Manager (※)を停 止しても料金が下がるかどうかわからない ✓ 単価や割引オプションなどが複雑に絡んだ料金 ✓ 費用構造がわからないので試算もできない ※アクセス元のデバイスやブラウザーに応じて、 最適な形式にリアルタイムに画像を変換する機能 38 移行のキッカケ：Akamai のコストが下げられない 右肩上がりで増えるコスト コストが削減できるかわからない 当時の Akamai のコストは、年間数千万レベル規模にまで拡大 さらにコストが右肩上がりで増え続けていた 4月 5月 6月 7月 8月 9 月 10月 11月 12月 1月 2月 3月 配信量 契約量
39. • 試算した結果、かなりのコスト削減効果が見 込めることがわかった • Akamai のプロパティをすべて CloudFront に移行できる • Akamai の画像配信機能を Lambda@Edge で代替できる • Lambda@Edge によるリアルタイム画像変換 の先行事例がすでに存在 39 Amazon CloudFront への移行を決断 大幅なコスト削減 移行ハードルの低さ 大幅なコスト削減が見込めたため、Amazon CloudFront への移行を決断 Akamai から移行する上での致命的なハードルもないことがわかった
40. Akamai を使用した移行前の CDN アーキテクチャ 40 他社システム いい部屋ネット 利用ユーザー www.eheya.net Akamai いい部屋ネット オリジン サイトコンテンツ Aシステム 物件画像 Bシステム 物件画像 Cシステム 物件画像 コスト削減＋配信量・配信仕様の最適化を実施 すべてのアクセスが Akamai を経由するため、 サイトのトラフィック増がコスト増加に直結 • 実画像は複数の他社システムにも分散しており、 HTTPで都度取得しなければならない • 画像配信量が全体の80%を占めるほど肥大化 HTTP Next.js のキャッシュ機能を 有効活用できていなかった
41. Amazon CloudFront への移行計画 41 物件画像用とサイト用に分けて、順次 Amazon CloudFront に移行 配信量の大きい物件画像用 CDN から移行に着手 他社システム いい部屋ネット 利用ユーザー www.eheya.net Akamai いい部屋ネット オリジン サイトコンテンツ Aシステム 物件画像 Bシステム 物件画像 Cシステム 物件画像 すべてのアクセスが Akamai を経由するため、 サイトのトラフィック増がコスト増加に直結 • 実画像は複数の他社システムにも分散しており、 HTTPで都度取得しなければならない • 画像配信量が全体の80%を占めるほど肥大化 HTTP Next.js のキャッシュ機能を 有効活用できていなかった ② サイトCDN移行 ① 物件画像 CDN 移行
42. アーキテクチャ刷新①：物件画像 CDN 編 42 CDN 乗り換えに際して、物件画像配信に必要な要件を整理した CloudFront と Lambda@Edge で実現できそうなことが分かった 刷新で実現したいこと CDN 移行後の運用コストが 増えないようにしたい エッジコンピューティングのような 運用負荷が小さい仕組みを前提とする 実画像がさまざまな場所に分散していても 安定した画像配信を実現したい HTTPによるフェッチ前提で、 安定した画像配信の仕組みを導入する 画像を最大限圧縮して効率的に配信したい 元画像をWebP または AVIF に変換する サムネイル生成など細かい機能も追加する 移行方針・解決策
43. 物件画像配信 CDN by Lambda@Edge 43 Users CloudFront 変換画像格納S3 Viewer Request Lambda@Edge Origin Request Viewer Response Origin Response Lambda@Edge 画像オリジン群 オリジン画像 取得＆変換 変換画像を保存 HTTP Server HTTP Server HTTP Server Accept ヘッダまたはリクエストパラメーターを元に URI を再編成 再編成された URI をキャッシュキー＆画像変換処理パラメーターとして使用する • 変換画像が存在する場合、そのままレスポンスを返す • 変換画像が存在しない場合、オリジン画像を取得・変換してレスポンスを返す • 画像変換処理は、sharp を利用して実装 変換画像のキャッシュ層として利用 画像オリジン側に問題が発生しても、 変換画像があればオリジンの影響を受けずに画像配信できる ※400万オブジェクト・合計7TBの画像が常時保管 これらを非常に小さなコードベースで実現できた
44. 44 参考）画像最適化によるサイズの違い 物件画像20枚の物件詳細 フォーマットごとのサイズの違い 加工なし 1.18MB AVIF 419.55KB (削減率 65.3%) WebP 409.29KB (削減率 66.1%) 元のサイズの半分以下！
45. アーキテクチャ刷新②：サイト CDN 編 45 キャッシュ管理を Next.js に一任することで、 画面ごとにきめ細やかなキャッシュコントロールを実現 Amazon CloudFront ECS オリジン ページ単位に Cache-Controlヘッダを付与 CDNの「土管化」 Amazon CloudFront に余計な設定を入れない ・オリジンの Cache-Control ヘッダに従ってキャッシュ ・開発者が CDN コンソール上でキャッシュ設定を変更することはほぼない （3年以上運用しているが、設定変更は2〜3回程度）
46. 参考）Next.js に一任するためのキャッシュポリシー 46 「最小 TTL を 0 秒」にし、「最大 TTL を限りなく大きい値」にすることで、 実質的に Next.js が付与した Cache-Control ヘッダーが適用されるようにした (Honor Origin Cache Control) Amazon CloudFront ( Cache Control 編) - AWS Black Belt Online Seminar https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_AmazonCloudFront-CacheControl_0430_v1.pdf
47. CDN アーキテクチャ刷新の効果 47 インフラコストだけでなく、配信量も大幅に削減することに成功 エッジコンピューティングのおかげでほぼノーメンテナンスで安定運用 ✓ Akamai 利用時の 1/10 以下 ✓ 年間数千万のコストが年間数百万になった (桁が1つ落ちた) ✓ キャッシュ設定を Next.js に一任し、画面単位でキャッシュ制御 ✓ 大半の画面が 10ms~100ms で返却できる世界を実現 ✓ Lambda@Edge による物件画像 CDN を独自に構築したことで、 Akamai 利用時の 1/3 以下 まで配信料を最適化 ✓ 10TB/月の割引プランが利用できないレベルまで配信量を削減 コスト レスポンス 配信量
48. CDN アーキテクチャ刷新の振り返り 48 AWS の機能を最大限活用したアーキテクチャに刷新したことで、 課題の解消に加えて、費用対効果の高い CDN 基盤を実現できた • 独自の物件画像 CDN を構築した結果、既存 CDN よりも費用対効果がよいものができた • エッジコンピューティングの利便性を痛感 ✓ ローコードで開発・運用 ✓ 処理の安定性も問題なし ✓ キャパシティプランニングもほぼ不要 • CDN を透過的に適用することが重要 ✓ アプリケーションにキャッシュ設定をよせる ことが1つの最適解だと考えている • 開発者が Amazon CloudFront を保守する 必要がほぼないので快適 • オリジンシールドや AWS WAF によって、 オリジンの負荷が軽減 物件画像 CDN の振り返り サイト CDN の振り返り
49. Step 4. Oracle から Amazon RDS for PostgreSQL への移行 いい部屋ネット、AWS への完全移行 49
50. Oracle DB の AWS 移行 50 AWS 移行が進むにつれて DB の負荷が無視できないレベルにまで増加 インフラコストも年々増加する一方だったため、Oracle の移行を決めた ✓ AWS 移行が進んでサイトが大きくなるにつれ、DB ボトルネックが顕在化 ✓ SQL チューニングを実施してもスロークエリアラートが常態化 ✓ 年間数千万のコストがかかっていた ✓ 保守費用が、毎年必ず10%程度あがる ✓ いい部屋ネット含め複数のシステムが参照しており、長時間停止できない ✓ 古いバージョンを使い続けており、サポートやモニタリングツールも 有効活用できない 右肩上がりのコスト 打つ手がない 鳴り止まない スロークエリアラート
51. 移行先として RDS for PostgreSQL を選択 51 当初 Amazon Aurora PostgreSQL 前提だったが、性能問題が発覚 性能比較をした結果、RDS for PostgreSQL を選択した • Oracle との互換性を考慮して PostgreSQL を選択 • 事前の移行アセスメントでも 大きな問題は検出されなかった • Aurora PostgreSQL で物件更新バッチ を動かしたところ、既存 DB より遅く なった • RDS for PostgreSQL では性能問題は起 きなかった • 運用上の懸念がなく、コストメリットも あったため RDS for PostgreSQL を選 択 なぜ PostgreSQL を選択したか？ なぜ RDS for PostgreSQL を選択したか？
52. 52 参考）PostgreSQLへ移行するときの作業 実験段階では43個の SQLファイルの修正のみで動いた 参考）DDLの修正項目は6項目のみ 個別対応したカラムも数える程度だった
53. Oracle → RDS for PostgreSQL 移行までの道のり 53 画面移行をしながら数年かけて、不要な DB オブジェクトを削除 徹底した現新比較とパフォーマンスチューニングを実施 • ストアド×100 全削除 • シノニム×1,000 削除 • テーブル×500 削除 • 監査ログを仕込んで、 ひたすら確認 ※テーブル構成見直しなどの リファクタリングを含む 不要オブジェクト削除 • 物件データ更新処理を 並行稼働 • 差分があれば内容を 確認して対処 • OK になるまで繰り返す 現新比較 • 毎日負荷テストを実施 • 非効率なクエリの チューニング • OK になるまで繰り返す クエリチューニング RDS for PostgreSQL Oracle DB
54. Oracle → RDS for PostgreSQL 移行による成果 54 インフラコスト削減だけでなく、サイト全体のパフォーマンスも向上 移行前よりも2倍以上捌けるデータベースにパワーアップした ✓ Oracle 利用時の 1/8 以下 ✓ 年間数千万のコストが、年間数百万になった(桁が1つ落ちた) ✓ 移行前と比べて、2倍以上のスループットを達成 ※ 移行に伴うクエリのチューニングによるもの ✓ 繁忙期のトラフィックであっても余裕で捌ける ✓ ストアド、シノニム、インデックス、テーブルなど 合計1,000以上の DB オブジェクト群を断捨離 ✓ DB 移行の際も聖域を作らず 脱・現行踏襲 で臨んだことで、 上記のような成果を得られた（ただし、腕力が必要） コスト 性能 その他
55. Oracle → RDS for PostgreSQL 移行の振り返り • DB については、先行事例やベストプラクティスにとらわれすぎない ✓ データ量やシステム特性など状況は千差万別 ✓ セオリーが自分たちにも当てはまるかどうかはわからない • 聖域を作らず、削除すべきものは削除する ✓ 移行時に不要な DB オブジェクトを精査し、可能な限り削除していく ✓ こうした移行時にしかできないチャンスが巡ってきたと思って取り組むことが大事（精神論） 55 DB 移行に銀の弾丸はない 製品選定や現新比較、性能検証などを1つ1つ愚直に進めるしかない
56. 参考）リリース前後の GraphQL TTFB 推移 56 Oracleの世界 RDS for PostgreSQL の世界
57. 移行全体をふりかえって いい部屋ネット、AWSへの完全移行 57
58. Step ごとのまとめ(おさらい) 58 スモールスタート ✓ 3ヶ月でお問い合わせ数 200% 達成 ✓ 効果の確証と同時にシステム課題も把握できた STEP 0 ビジネスを止めない 移行プロセスの構築 ✓ ガバナンスの効いたマルチアカウント基盤を構築 ✓ ビジネスを伸ばしながら移行するプロセスを確立 STEP 1 アプリケーション アーキテクチャの刷新 ✓ 課題からアーキテクチャを策定(Next.js + GraphQL) ✓ 4年で2,000回リリース、無停止リリースの実現 STEP 2 クラウドネイティブ アーキテクチャへの刷新 ✓ Amazon CloudFront への移行でコストは1/10 に削減 ✓ Next.js と組み合わせて爆速レスポンスを実現 STEP 3 Oracle から Amazon RDS for PostgreSQL への移行 ✓ RDS for PostgreSQL への移行でコストは 1/8 に削減 ✓ レスポンスの TTFB が改善＆安定化 ✓ DB移行に銀の弾丸なし STEP 4
59. 移行4年間の総括・学び • スモールスタート ✓ 小さくはじめる、細かく進めることでビジネスを止めずに移行できた • ビジネスを伸ばすための移行 ✓ 移行を目的化しない ✓ 目の前の課題を1つずつ対処した結果が、4年間でのAWS完全移行 • 後発優位性 ✓ 他社先行事例や蓄積されたベストプラクティスを最大限活用する ✓ 後発はデメリットではなく、むしろメリットである 59 ビジネスを伸ばすための移行が、非連続な成⻑につながった 小さくはじめる・細かく進める・後発の強みをフル活用
60. 60 最後に… KPI（問い合わせ数）が5年間で どう変化したかご紹介します
61. お問い合わせ数 最大 1,760% 2025年3月時点
62. おわりに 62
63. 今回紹介したトピックはほんの一部です • さまざまな媒体をとおして、今後も取り組みを発信したい • 今回紹介しきれなかった話がたくさんあります ✓ GraphQL導入時の詳細 ✓ RDS for PostgreSQL移行の詳細 ✓ iOS / Android リニューアル ✓ ETLパイプラインのAWS移行 ✓ 物件管理システム再構築 ✓ etc… 63
64. 今後の展望 • いい部屋ネット(Web)に、ぜひアクセスして使ってみてください • 今後もさらなる成長をめざして頑張ります 64