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

by Red Frasco

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

⾃⼰紹介. 2 ◆ 経歴: エンジニア12年（バックエンド4年 + インフラ8年） ◆ 出⾝: ⾹川県 ◆ 好きな⾷べ物: うどん猪熊朔也⼤東建託パートナーズいい部屋ネット事業部インフラエンジニア

Slide 3

Slide 3 text

⼤東建託パートナーズについて ◆ 本社: 東京都港区港南⼆丁⽬16番1号品川イーストワンタワー ◆ 設⽴年⽉: 1994年7⽉ ◆ 事業内容: • アパート、マンションの管理 • アパート、マンションオーナ様のサポート • ⼊居者様のサポート • ⼊居者様斡旋 ü いい部屋ネットの運営 ü いい部屋ネットフランチャイズの展開 3 ⼤東建託パートナーズ管理⼤東建託リーシング仲介⼤東建託建築⼤東建託グループ組織関係図いい部屋ネット

Slide 4

Slide 4 text

いい部屋ネットとは賃貸物件をお探しの⽅向けの不動産ポータルサイト PC、スマホ、ネイティブアプリから利⽤可能 4

Slide 5

Slide 5 text

本セッションの前提 5 本セッションでは、いい部屋ネット(Web)にフォーカスします ※実際には、物件情報⼊⼒・変換を担うバックエンドシステム群も存在します物件情報の作成物件情報の変換物件情報の表⽰外部システム群担当者物件管理システム ETL パイプライン外部システム群 File I/F File I/F カスタマーいい部屋ネット家探し DB Upsert 本セッションのスコープ⼿作業バックエンドシステム群はスコープ外

Slide 6

Slide 6 text

いい部屋ネット(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 データパイプラインの再構築物件管理システムの再構築

Slide 7

Slide 7 text

いい部屋ネット(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 への移⾏

Slide 8

Slide 8 text

Step 0. スモールスタートいい部屋ネット、AWS への完全移⾏ 8

Slide 9

Slide 9 text

移⾏前のいい部屋ネットの状況（〜2020年） • ビジネススピードが上がりづらい開発環境 ü 技術負債で思うように開発が進まず、リリースのサイクルが⻑期化 ü 特定のエンジニアしかメンテナンスできず、属⼈化が深刻 • コストは右肩上がり、しかし安定性は低下 ü 繁忙期のたびにリソースを “増やして解決” ⇨ インフラ費が膨張 ü 障害によるダウンタイムが頻発し、カスタマー体験を毀損 • 課題＝伸びしろ ü ⼭積みの改善ポイント ⇨ 成果を出せる余地が⼤きい ü どうにかするために模索が始まった 9 問い合わせ数の成⻑が頭打ち “強く、⽌まらないサービス” への刷新が急務でした

Slide 10

Slide 10 text

スモールスタートで道を切り拓く 10 “問い合わせ数” を KPI として設定ビジネスが本当に伸びるのか︖を先に確かめることにしました課題が⼭積み KPIを1つに絞るまずは検証してみる ü ビジネス／システム両⾯の改善項⽬が多すぎる ü 優先順位がつけられない ü まずは「問い合わせ数」を伸ばせるか検証することにした ü 数値で成否を計測することができる ü ⼩さく勝って、次の投資判断を加速させる “実験場” でもあった ü 成功すれば、⼤規模投資（AWS移⾏）の説得材料になる 1 2 3

Slide 11

Slide 11 text

スモールスタートをどのように設計したか 11 問い合わせ数に直結する３画⾯のみを対象とし、⾼速にUIを改修してどこまで改善できるかの"⼩さな検証"を⾏うこととした《検証ポイント》問い合わせ数 +??% 検証ポイント問い合わせ数の変化期間 3ヶ⽉対象範囲スマホ版 × ⼀覧・詳細・フォームアプローチ UIのみに絞って⾼速に改修（前提: 既存アプリ・インフラを最⼤限活⽤）物件⼀覧物件詳細お問合せフォーム完了

Slide 12

Slide 12 text

12 コアコンセプト: 細かく⾼速に検証していくホームラン狙いの開発スタイル何度も打席に⽴つ開発スタイル 1発のホームランを狙うのではなく、何度も打席に⽴つことを意識⽬標時間〜⻑い検討＆開発⽬標時間不確実性効果の不確実性イチかバチかの⼀発勝負⽬標効果を超えられるか︖︖︖ 効果効果細かいチャレンジを続けていく（何度も打席に⽴つ）効果影響を⾒ながら細かく⽅向転換

Slide 13

Slide 13 text

13 リリース回数・速度を上げるため、⾃動リリースの仕組みを最初に導⼊ (チーム体制やPJ管理ツールといった開発プロセスも同時に⾒直し) 13

Slide 14

Slide 14 text

参考) 当時の検証ロードマップ 14 優先順位 1群の例 • ボタン／テキスト類の変更 • ⾊味の変更 • パーツUIデザイン変更／⼊替 • 上記に伴うヘッダ／フッタのデザイン変更優先順位 2群の例 • 問い合わせフォームの刷新 • 詳細ページ内物件レコメンドの実装 • 画像ギャラリーの実装 • 新問い合わせフォーム (レコメンド物件の準備なども含む） AWS 移⾏検討緊急事態宣⾔と同時にスタート 😭

Slide 15

Slide 15 text

参考）物件詳細のUI⽐較（BEFORE/AFTER) 15

Slide 16

Slide 16 text

参考）物件詳細のUI⽐較（BEFORE/AFTER) 16 フォームの最適化（EFO）を中⼼にUI改修を実施

Slide 17

Slide 17 text

スモールスタートで確証を得た 17 検証の結果、開始3ヶ⽉でお問い合わせ数は⼤きく改善それと同時に課題も浮き彫りになった GOOD ☺ BAD 😭 • 問い合わせ数 200%︕ • 課題＝伸びしろ説は正しそうだ • 本格的な AWS 移⾏の決断につながった • リリースごとに数⼗秒〜1分程度のダウンタイムが発⽣ • CDN がうまく使えておらず、レスポンスが遅い • 改修範囲が想像よりも広い画⾯ごとの改修に適していない作り

Slide 18

Slide 18 text

Step 1. ビジネスを⽌めない移⾏プロセスの構築いい部屋ネット、AWS への完全移⾏ 18

Slide 19

Slide 19 text

AWS 移⾏を決めたときの状況 • なぜ後発組が有利か︖ ü 先⾏事例やベストプラクティスが充実しており、標準構成を⼀気に導⼊できる ü 既存アカウントがないので、制約がなくフラットに移⾏⽅針を検討できる • 移⾏をはじめるにあたって、主に下記2点について検討した ü 🛡 Landing Zone︓セキュリティ & ガバナンスを満たすマルチアカウント基盤 (AWS Control Tower) ü 🚀 Migration Strategy︓アプリを段階的に移⾏する戦略(ストラングラーパターン) 19 当時、AWS アカウントは持っていなかった検討を進めるうちに、後発組こそ有利に進められることに気づいた

Slide 20

Slide 20 text

Landing Zone に基づいたアカウント構成 20 マルチアカウント運⽤に必要な構成要素を最初から考慮することで、途中の構成変更などの⼿戻りリスクをおさえる Payer (管理アカウント) Infra Core いい部屋ネット ETL パイプライン物件管理システムアカウント OU IdP CI/CD Audit Log 開発 STG 本番開発 STG 本番開発 STG 本番ネットワーク

Slide 21

Slide 21 text

Landing Zone に基づいたアカウント構成 21 マルチアカウント運⽤に必要な構成要素を最初から考慮することで、途中の構成変更などの⼿戻りリスクをおさえる Payer (管理アカウント) Infra Core いい部屋ネット ETL パイプライン物件管理システム監査⽤ Control Tower ⾃動⽣成将来を⾒越したOU構成開発・本番アカウントの分離アカウント OU IdP CI/CD Audit Log 開発 STG 本番開発 STG 本番開発 STG 本番ネットワークドメイン、専⽤線、TGW集約外部向けのIAM集約 IaC による⾃動デプロイ基盤

Slide 22

Slide 22 text

AWS Control Tower によるマルチアカウント管理・統制 22 AWS Control Tower の機能をフル活⽤運⽤負荷を抑えながら、⼀定⽔準のセキュリティ・ガバナンスを維持 ü ボタン１つでアカウント構築が可能 ü Amazon EventBridge と連携し、デフォルトVPCなど不要リソース⾃動削除 ü AWS IAM Identity Center でシングルサインオン環境を構築 ü チームや役割に応じてアクセスユーザーと権限を⼀元管理 ü デフォルトで監査ログを取得(Audit, Log Archive) ü デフォルトでガードレールが設定される ü AWS CloudFormation StackSets を利⽤して共通インフラリソース配布アカウント作成アクセス権限管理アカウント管理・統制

Slide 23

Slide 23 text

AWS への移⾏戦略 23 ビジネスを改善しながら移⾏することが必須だと考え、移⾏戦略としてストラングラーパターンを採⽤改善を⽌めたくない移⾏のために改善を⽌めると成⻑機会が失われてしまう移⾏も進めていきたい改善に終わりはないので移⾏と同時並⾏するしかないストラングラーパターンによる移⾏段階的に移⾏できる戦略を策定

Slide 24

Slide 24 text

• 既存システムを段階的に移⾏する⽅式 • 提唱者である Martin Fowler ⽒が熱帯⾬林の旅⾏中に⾒た、つる植物から発想 • ⼀般的に以下のような流れで移⾏する ü 新旧システムの前段にファサードを配置し、リクエストを振り分けられるようにする ü 段階的に新システムにリクエストを振り分ける ü 新システムへの切り替えが完了したら、旧システムを廃⽌する 24 参考）ストラングラーパターンとは既存の⼤樹にからみついて、徐々に成⻑する植物 https://martinfowler.com/bliki/StranglerFigApplication.html

Slide 25

Slide 25 text

ストラングラーパターンの実践 25 いい部屋ネットでは、下記のようにパターンを適⽤していった専⽤線の敷設 (AWS Direct Connect) リバースプロキシ導⼊画⾯ごとに移⾏ ü セキュリティやオンプレミスのネットワーク安定性を考慮し、まずは AWS から既存 DB を参照するために専⽤線を敷設 ü AWS Transit Gateway も併⽤して安定的な通信経路を確⽴ ü オンプレミスと AWS の振り分けをするため (ファサード) ü ページ単位で移⾏するには、Application Load Balancer（ALB）より細やかな制御が必要になるため導⼊ ü 改善を実施する画⾯(機能)ごとに AWS へ振り分けていく ü 不要になったリソース(サーバ、テーブル、ドメインなど)は、順次オンプレミス側から消していく 1 2 3

Slide 26

Slide 26 text

ストラングラーパターンの変遷 26 1 移⾏初期オンプレミスが主オンプレミス AWS CDN Web サーバー旧アプリ DB リバースプロキシ新アプリ専⽤線接続

Slide 27

Slide 27 text

ストラングラーパターンの変遷 27 1 移⾏初期オンプレミスが主 2 移⾏中期 AWSを主に逆転オンプレミス AWS オンプレミス AWS CDN Web サーバー旧アプリ DB リバースプロキシ新アプリ Web サーバー旧アプリ DB リバースプロキシ新アプリ CDN 専⽤線接続専⽤線接続

Slide 28

Slide 28 text

ストラングラーパターンの変遷 28 1 移⾏初期オンプレミスが主 2 移⾏中期 AWSを主に逆転 3 最終形オンプレミス撤去オンプレミス AWS オンプレミス AWS オンプレミス AWS CDN Web サーバー旧アプリ DB リバースプロキシ新アプリ Web サーバー旧アプリ DB リバースプロキシ新アプリ CDN Web サーバー旧アプリ DB リバースプロキシ新アプリ CDN DB 撤去専⽤線接続専⽤線接続

Slide 29

Slide 29 text

移⾏プロセスの振り返り • 構築初期から5年以上経過した今でも困っていない ü Landing Zone のおかげで、アカウント構成の⾒直しをすることなく運⽤できている（ベストプラクティス・先⾏事例の偉⼤さに感謝） ü AWS Control Tower によって、ガバナンスを効かせながら運⽤できている • ビジネスの改善を⽌めずに移⾏も同時に進めることができた ü ストラングラーパターンを採⽤することで、"いいとこどり" ができた ü スモールスタート時に⼤切にした「細かく改善」という考え⽅は、AWS 移⾏でも活かせた 29 ベストプラクティスや先⾏事例を取り⼊れながら移⾏プロセスを構築移⾏もビジネスの改善も両⽅をやりながら移⾏することに成功

Slide 30

Slide 30 text

Step 2. アプリケーションアーキテクチャの刷新いい部屋ネット、AWSへの完全移⾏ 30

Slide 31

Slide 31 text

• リリースするたびに数⼗秒〜1分程度のダウンタイムが発⽣ • CDNがうまく使えておらずレスポンスが遅い • 改修範囲が想像よりも広い →画⾯ごとの改修に適していない作りだった • ネイティブアプリ（Android・iOS）のリニューアルも⾏う • 現⾏DB（Oracle）の移⾏も⾏う 31 アプリケーションの刷新に必要な要件とは(1/2) ①スモールスタートで気づいた課題 ②未来の要件 ①現在直⾯している課題の解決と ②未来の要件を満たすことこの2つが重要であると考え、要件を整理した＋

Slide 32

Slide 32 text

• リリースするたびに数⼗秒〜1分程度のダウンタイムが発⽣ • CDNがうまく使えておらずレスポンスが遅い • 改修範囲が想像よりも広い →画⾯ごとの改修に適していない作りだった • ネイティブアプリ（Android・iOS）のリニューアルも⾏う • 現⾏DB（Oracle）の移⾏も⾏う 32 アプリケーションの刷新に必要な要件とは(1/2) ①スモールスタートで気づいた課題 ②未来の要件 ①現在直⾯している課題の解決と ②未来の要件を満たすことこの2つが重要であると考え、要件を整理した ①の整理: ü ⾼頻度リリースに耐えられる ü CDN のフル活⽤ができる ü 画⾯ごとに疎になるような作り ②の整理: ü Web とネイティブアプリで基盤を共通化 ü DB に依存しすぎない作り＋

Slide 33

Slide 33 text

33 アプリケーションの刷新に必要な要件とは(2/2) 刷新で実現したいこと解決策⾼頻度リリースに耐えられる Blue/Green Deployment CDN のフル活⽤画⾯ごとに疎になるような作り Next.js による画⾯ごとの最適化⾃由度が⾼いリバースプロキシ層の追加ネイティブアプリとの基盤共通化 GraphQL による表現層とデータ層の分離 DB(Oracle) に依存しすぎない作り利⽤テーブルの最適化、ストアドなどのDB 依存機能の廃⽌、など

Slide 34

Slide 34 text

34 アプリケーションアーキテクチャの全体像 Amazon CloudFront ALB Nginx (リバースプロキシ) Amazon ElastiCache (Redis) Next.js GraphQL Oracle DB AWS WAF オンプレミス

Slide 35

Slide 35 text

35 アプリケーションアーキテクチャの全体像 Amazon CloudFront ALB Nginx (リバースプロキシ) Amazon ElastiCache (Redis) Next.js GraphQL Oracle DB AWS WAF オンプレミス Web(プレゼンテーション層) ⾃由なリバースプロキシと画⾯単位で最適化されたアプリケーション本質的には iOS/Android と同じ1つのプレゼンテーション層 CDNとWAF パフォーマンスの最⼤化柔軟なアクセス制御抽象化されたデータ層 Web もネイティブアプリも同⼀の（=標準化された）データ構造で通信⼤きく3つの層に分けてアーキテクチャを再構築

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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 にクエリキャッシュを導⼊ • 多段キャッシュによりアーキテクチャ全体でパフォーマンスを追求

Slide 38

Slide 38 text

38 アーキテクチャの刷新でどうなったか︖ 解決策結果 Blue/Green Deployment 2,000回/4年の無停⽌リリース実現 Next.js による画⾯毎の最適化 & ⾃由度が⾼いリバプロ層の追加⼤半のページが2桁msの爆速レスポンス GraphQL によるプレゼンテーション層とデータ層の分離ネイティブアプリ刷新にかかる⼯数が激減 Android は6ヶ⽉で実現

Slide 39

Slide 39 text

参考）Blue / Green Deployment とリリース回数 39 実⾏順や並列処理といった⼯夫により 15分以内に完結するように CircleCI でのワークフローも最適化 2020年〜2025年2⽉までの集計以降はすべて無停⽌リリース

Slide 40

Slide 40 text

参考）⼤半のページが爆速レスポンス 40 Next.js でページごとにキャッシュを個別最適化し、 CDNを経由する場合は~10ms、経由しない場合でも平均~80msでレスポンス CDNヒット時の爆速レスポンス

Slide 41

Slide 41 text

補⾜) GraphQL と REST の⽐較@いい部屋ネット 41 GraphQL の例 REST API の例 ü コンポーネントごとに必要な項⽬を宣⾔してクエリを構築するのでムダがない (Colocating Fragments) ü 不動産のような項⽬が多いサイトと相性がよかった ü エンドポイントを機能ごとに複数作る ü 過不⾜ある取得（多すぎたり少なすぎたり） ü バージョン管理が⼤変 query RoomQuery { room { ...RoomFragment } } ...以下省略 <<複数のエンドポイント>> • 物件詳細 /v1/rooms/:id/ • 周辺環境 /v1/facilities/?lat=xx,lng=yy • レコメンド /v1/recommend/?room_id=...

Slide 42

Slide 42 text

補⾜) GraphQL の光と闇 • 多段クエリを解決するときのパフォーマンス問題（N+1問題） ü DataLoader + Amazon ElastiCache(クエリキャッシュ) を導⼊しないと実⽤に耐えなかった • セキュリティ対応に苦労した ü 定義したクエリ以外で実⾏できない仕組みを独⾃に実装する必要があった。⽤意された機能 (PersistedQuery) では⾃分たちのやりたいことと微妙にマッチしなかった • そもそもスキーマ設計やグラフ構造の設計が難しすぎる ü 物件に紐づく項⽬数や関連が多く、議論が尽きない ü 項⽬数だけでも数百〜数千にのぼり、命名１つとっても苦労する（例:敷引償却⾦の英語表現） 42 GraphQL による恩恵は⼤きかったが、同時に取り扱いも難しかったすべてを語り尽くせないため、今回は割愛恩恵が⼤きいからといって、安易におすすめはできない

Slide 43

Slide 43 text

アプリケーションアーキテクチャ刷新の振り返り • 課題を整理することではじめて最適な技術・アーキテクチャがみえてくる ü アプローチが逆だったら失敗していたかもしれない ü 技術選定が失敗しても課題が解決していればビジネスとして⼤きな失敗にはなりづらい • その上で、聖域を作らず、変えるべきものは変えるスタンスを貫く ü リアーキテクチャによる課題解決を優先し、現⾏仕様の変更をいとわない（脱・現⾏踏襲） ü 時間はかかるが、こうした姿勢がアーキテクチャ刷新の成功につながったと考えている 43 AWS 移⾏や特定の技術を⽬的にせず、課題ベースでアーキテクチャを再構築したことがよい判断だった

Slide 44

Slide 44 text

Step 3. クラウドネイティブアーキテクチャへの刷新いい部屋ネット、AWS への完全移⾏ 44

Slide 45

Slide 45 text

（再掲）いい部屋ネット完全移⾏までの道のり 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 をクラウドネイティブアーキテクチャに刷新した事例を紹介

Slide 46

Slide 46 text

• 年間契約のため、繁忙期にあわせて契約量を⾼く設定せざるをえない • サイトが成⻑すればするほどコストが増加 • 料⾦・サービス体系が複雑 • 配信量の80%が画像配信 • Akamai の Image & Video Manager (※)を停⽌しても料⾦が下がるかどうかわからない ü 単価や割引オプションなどが複雑に絡んだ料⾦ ü 費⽤構造がわからないので試算もできない ※アクセス元のデバイスやブラウザーに応じて、最適な形式にリアルタイムに画像を変換する機能 46 移⾏のキッカケ︓Akamai のコストが下げられない右肩上がりで増えるコストコストが削減できるかわからない当時の Akamai のコストは、年間数千万レベル規模にまで拡⼤さらにコストが右肩上がりで増え続けていた 4⽉ 5⽉ 6⽉ 7⽉ 8⽉ 9 ⽉ 10⽉ 11⽉ 12⽉ 1⽉ 2⽉ 3⽉配信量契約量

Slide 47

Slide 47 text

• 試算した結果、かなりのコスト削減効果が⾒込めることがわかった • Akamai のプロパティをすべて CloudFront に移⾏できる • Akamai の画像配信機能を Lambda@Edge で代替できる • Lambda@Edge によるリアルタイム画像変換の先⾏事例がすでに存在 47 Amazon CloudFront への移⾏を決断⼤幅なコスト削減移⾏ハードルの低さ⼤幅なコスト削減が⾒込めたため、Amazon CloudFront への移⾏を決断 Akamai から移⾏する上での致命的なハードルもないことがわかった

Slide 48

Slide 48 text

Akamai を使⽤した移⾏前の CDN アーキテクチャ 48 他社システムいい部屋ネット利⽤ユーザー www.eheya.net Akamai いい部屋ネットオリジンサイトコンテンツ Aシステム物件画像 Bシステム物件画像 Cシステム物件画像 HTTP

Slide 49

Slide 49 text

Akamai を使⽤した移⾏前の CDN アーキテクチャ 49 他社システムいい部屋ネット利⽤ユーザー www.eheya.net Akamai いい部屋ネットオリジンサイトコンテンツ Aシステム物件画像 Bシステム物件画像 Cシステム物件画像コスト削減＋配信量・配信仕様の最適化を実施すべてのアクセスが Akamai を経由するため、サイトのトラフィック増がコスト増加に直結 • 実画像は複数の他社システムにも分散しており、 HTTPで都度取得しなければならない • 画像配信量が全体の80%を占めるほど肥⼤化 HTTP Next.js のキャッシュ機能を有効活⽤できていなかった

Slide 50

Slide 50 text

Amazon CloudFront への移⾏計画 50 物件画像⽤とサイト⽤に分けて、順次 Amazon CloudFront に移⾏配信量の⼤きい物件画像⽤ CDN から移⾏に着⼿他社システムいい部屋ネット利⽤ユーザー www.eheya.net Akamai いい部屋ネットオリジンサイトコンテンツ Aシステム物件画像 Bシステム物件画像 Cシステム物件画像すべてのアクセスが Akamai を経由するため、サイトのトラフィック増がコスト増加に直結 • 実画像は複数の他社システムにも分散しており、 HTTPで都度取得しなければならない • 画像配信量が全体の80%を占めるほど肥⼤化 HTTP Next.js のキャッシュ機能を有効活⽤できていなかった ② サイトCDN移⾏ ① 物件画像 CDN 移⾏

Slide 51

Slide 51 text

アーキテクチャ刷新①︓物件画像 CDN 編 51 CDN 乗り換えに際して、物件画像配信に必要な要件を整理した CloudFront と Lambda@Edge で実現できそうなことが分かった刷新で実現したいこと CDN 移⾏後の運⽤コストが増えないようにしたいエッジコンピューティングのような運⽤負荷が⼩さい仕組みを前提とする実画像がさまざまな場所に分散していても安定した画像配信を実現したい HTTPによるフェッチ前提で、安定した画像配信の仕組みを導⼊する画像を最⼤限圧縮して効率的に配信したい元画像をWebP または AVIF に変換するサムネイル⽣成など細かい機能も追加する移⾏⽅針・解決策

Slide 52

Slide 52 text

物件画像配信 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の画像が常時保管これらを⾮常に⼩さなコードベースで実現できた

Slide 53

Slide 53 text

53 参考）画像最適化によるサイズの違い物件画像20枚の物件詳細フォーマットごとのサイズの違い加⼯なし 1.18MB AVIF 419.55KB (削減率 65.3%) WebP 409.29KB (削減率 66.1%) 元のサイズの半分以下︕

Slide 54

Slide 54 text

アーキテクチャ刷新②︓サイト CDN 編 54 キャッシュ管理を Next.js に⼀任することで、画⾯ごとにきめ細やかなキャッシュコントロールを実現 Amazon CloudFront オリジンページ単位に Cache-Controlヘッダを付与 CDNの「⼟管化」 Amazon CloudFront に余計な設定を⼊れない・オリジンの Cache-Control ヘッダに従ってキャッシュ・開発者が CDN コンソール上でキャッシュ設定を変更することはほぼない（3年以上運⽤しているが、設定変更は2〜3回程度）

Slide 55

Slide 55 text

参考）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

Slide 56

Slide 56 text

CDN アーキテクチャ刷新の効果 56 インフラコストだけでなく、配信量も⼤幅に削減することに成功エッジコンピューティングのおかげでほぼノーメンテナンスで安定運⽤ ü Akamai 利⽤時の 1/10 以下 ü 年間数千万のコストが年間数百万になった (桁が1つ落ちた) ü キャッシュ設定を Next.js に⼀任し、画⾯単位でキャッシュ制御 ü ⼤半の画⾯が 10ms~100ms で返却できる世界を実現 ü Lambda@Edge による物件画像 CDN を独⾃に構築したことで、 Akamai 利⽤時の 1/3 以下まで配信料を最適化 ü 10TB/⽉の割引プランが利⽤できないレベルまで配信量を削減コストレスポンス配信量

Slide 57

Slide 57 text

CDN アーキテクチャ刷新の振り返り 57 AWS の機能を最⼤限活⽤したアーキテクチャに刷新したことで、課題の解消に加えて、費⽤対効果の⾼い CDN 基盤を実現できた • 独⾃の物件画像 CDN を構築した結果、既存 CDN よりも費⽤対効果がよいものができた • エッジコンピューティングの利便性を痛感 ü ローコードで開発・運⽤ ü 処理の安定性も問題なし ü キャパシティプランニングもほぼ不要 • CDN を透過的に適⽤することが重要 ü アプリケーションにキャッシュ設定をよせることが1つの最適解だと考えている • 開発者が Amazon CloudFront を保守する必要がほぼないので快適 • オリジンシールドや AWS WAF によって、オリジンの負荷が軽減物件画像 CDN の振り返りサイト CDN の振り返り

Slide 58

Slide 58 text

Step 4. Oracle から RDS PostgreSQL への移⾏いい部屋ネット、AWS への完全移⾏ 58

Slide 59

Slide 59 text

Oracle DB の AWS 移⾏ 59 AWS 移⾏が進むにつれて DB の負荷が無視できないレベルにまで増加インフラコストも年々増加する⼀⽅だったため、Oracle の移⾏を決めた ü AWS 移⾏が進んでサイトが⼤きくなるにつれ、DB ボトルネックが顕在化 ü SQL チューニングを実施してもスロークエリアラートが常態化 ü 年間数千万のコストがかかっていた ü 保守費⽤が、毎年必ず10%程度あがる ü いい部屋ネット含め複数のシステムが参照しており、⻑時間停⽌できない ü 古いバージョンを使い続けており、サポートやモニタリングツールも有効活⽤できない右肩上がりのコスト打つ⼿がない鳴り⽌まないスロークエリアラート

Slide 60

Slide 60 text

移⾏先として RDS PostgreSQL を選択 60 当初 Aurora PostgreSQL 前提だったが、性能問題が発覚性能⽐較をした結果、RDS PostgreSQL を選択した • Oracle との互換性を考慮して PostgreSQL を選択 • 事前の移⾏アセスメントでも⼤きな問題は検出されなかった • Aurora PostgreSQL で物件更新バッチを動かしたところ、既存 DB より遅くなった • RDS PostgreSQL では性能問題は起きなかった • 運⽤上の懸念がなく、コストメリットもあったため RDS PostgreSQL を選択なぜ PostgreSQL を選択したか︖ なぜ RDS PostgreSQL を選択したか︖

Slide 61

Slide 61 text

61 参考）PostgreSQLへ移⾏するときの作業実験段階では43個の SQLファイルの修正のみで動いた参考）DDLの修正項⽬は6項⽬のみ個別対応したカラムも数える程度だった

Slide 62

Slide 62 text

Oracle → RDS PostgreSQL 移⾏までの道のり 62 画⾯移⾏をしながら数年かけて、不要な DB オブジェクトを削除徹底した現新⽐較とパフォーマンスチューニングを実施 • ストアド×100 全削除 • シノニム×1,000 削除 • テーブル×500 削除 • 監査ログを仕込んで、ひたすら確認 ※テーブル構成⾒直しなどのリファクタリングを含む不要オブジェクト削除 • 物件データ更新処理を並⾏稼働 • 差分があれば内容を確認して対処 • OK になるまで繰り返す現新⽐較 • 毎⽇負荷テストを実施 • ⾮効率なクエリのチューニング • OK になるまで繰り返すクエリチューニング RDS PostgreSQL Oracle DB

Slide 63

Slide 63 text

Oracle → RDS PostgreSQL 移⾏による成果 63 インフラコスト削減だけでなく、サイト全体のパフォーマンスも向上移⾏前よりも2倍以上捌けるデータベースにパワーアップした ü Oracle 利⽤時の 1/8 以下 ü 年間数千万のコストが、年間数百万になった(桁が1つ落ちた) ü 移⾏前と⽐べて、2倍以上のスループットを達成 ※ 移⾏に伴うクエリのチューニングによるもの ü 繁忙期のトラフィックであっても余裕で捌ける ü ストアド、シノニム、インデックス、テーブルなど合計1,000以上の DB オブジェクト群を断捨離 ü DB 移⾏の際も聖域を作らず脱・現⾏踏襲で臨んだことで、上記のような成果を得られた（ただし、腕⼒が必要）コスト性能その他

Slide 64

Slide 64 text

Oracle → RDS PostgreSQL 移⾏の振り返り • DB については、先⾏事例やベストプラクティスにとらわれすぎない ü データ量やシステム特性など状況は千差万別 ü セオリーが⾃分たちにも当てはまるかどうかはわからない • 聖域を作らず、削除すべきものは削除する ü 移⾏時に不要な DB オブジェクトを精査し、可能な限り削除していく ü こうした移⾏時にしかできないチャンスが巡ってきたと思って取り組むことが⼤事（精神論） 64 DB 移⾏に銀の弾丸は、ない製品選定や現新⽐較、性能検証などを1つ1つ愚直に進めるしかない

Slide 65

Slide 65 text

参考）リリース前後の GraphQL TTFB 推移 65 Oracleの世界 RDS PostgreSQL の世界

Slide 66

Slide 66 text

移⾏全体をふりかえっていい部屋ネット、AWSへの完全移⾏ 66

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

移⾏4年間の総括・学び • スモールスタート ü ⼩さくはじめる、細かく進めることでビジネスを⽌めずに移⾏できた • ビジネスを伸ばすための移⾏ ü 移⾏を⽬的化しない ü ⽬の前の課題を1つずつ対処した結果が、4年間でのAWS完全移⾏ • 後発優位性 ü 他社先⾏事例や蓄積されたベストプラクティスを最⼤限活⽤する ü 後発はデメリットではなく、むしろメリットである 68 ビジネスを伸ばすための移⾏が、⾮連続な成⻑につながった⼩さくはじめる・細かく進める・後発の強みをフル活⽤

Slide 69

Slide 69 text

69 最後に… KPI（問い合わせ数）が5年間でどう変化したかご紹介します

Slide 70

Slide 70 text

お問い合わせ数最⼤ 1,760% 2025年3⽉時点

Slide 71

Slide 71 text

おわりに 71

Slide 72

Slide 72 text

今回紹介したトピックはほんの⼀部です • さまざまな媒体をとおして、今後も取り組みを発信したい • 今回紹介しきれなかった話がたくさんあります ü GraphQL導⼊時の詳細 ü RDS PostgreSQL移⾏の詳細 ü iOS / Android リニューアル ü ETLパイプラインのAWS移⾏ ü 物件管理システム再構築 ü etc… 72 物件情報の作成物件情報の変換物件情報の表⽰外部システム群担当者物件管理システム ETL パイプライン外部システム群 File I/F File I/F カスタマーいい部屋ネット家探し DB upsert 本セッションのスコープ⼿作業バックエンドシステム群はスコープ外

Slide 73

Slide 73 text

今後の展望 • いい部屋ネット(Web)に、ぜひアクセスして使ってみてください • 今後もさらなる成⻑をめざして頑張ります 73