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