Upgrade to Pro — share decks privately, control downloads, hide ads and more …

これってSRE?いい部屋ネットを1,760%成長させた開発とインフラのコラボレーション

Avatar for Red Frasco Red Frasco
February 03, 2026

 これってSRE?いい部屋ネットを1,760%成長させた開発とインフラのコラボレーション

2026/1/31 に開催された SRE Kaigi 2026(https://2026.srekaigi.net/) のショートセッションの登壇資料です

Avatar for Red Frasco

Red Frasco

February 03, 2026
Tweet

More Decks by Red Frasco

Other Decks in Technology

Transcript

  1. 自己紹介 猪熊 朔也 ( いのくま さくや ) / @sinocloudon -

    株式会社 Red Frasco - インフラ/SRE ◆経歴 - 金融系 SIer, リクルート(SUUMO), 金融系スタートアップ, 現職 ◆その他コメント - うどんが好きです - ラーメン二郎が好きです - うどん脳 をプロフィールアイコンにすることが多いです 2
  2. “開発が攻めることができる土台” とは? 一言で言うと… 1. ビジネスを止めない移行プロセス • 既存案件と基盤移行を両立し、サイトを成長させながら移行する • ストラングラーパターンによる段階移行により、両立を実現 •

    1発ねらいではなく打席数を増やす(その上で、チーム全員で打率を上げる) 2. ビジネスを加速させる基盤 • 高速かつ安全にリリースできる基盤 • Blue/Green Deployment による無停止リリース基盤 • インフラがボトルネックにならないような仕組み • IaC による自動デプロイによってインフラの属人性を下げる • Feature環境自動生成や潤沢な開発・STG環境により、開発の速度を落とさない 11
  3. [基盤整備] Blue/Green デプロイによる無停止リリース • リリースのダウンタイムを許容しない • リリースすればするほど、ダウンタイムが蓄積される構造から脱却する • 無停止リリース基盤を構築する •

    リリースすればするほど、ビジネスが伸びる構造に変える • CircleCI を用いたBlue/Green デプロイを導入し、4年で2,000回リリース 14 以降はすべて 無停止リリース
  4. [基盤整備] インフラをボトルネックにしないための仕組み • インフラ起因でリリースまでのリードタイムを伸ばしたくない 例:インフラの作業待ちによるリリース後ろ倒し 開発環境が足りないため、開発作業に待ちが発生 • IaCはビジネスを支える上で必要不可欠な生存戦略 • デプロイまで自動化することで属人性を排除

    • 変更頻度が多いものは開発者がリリースできるようにする 例:コンテナの CPU/メモリを変更する、WAF の IP ブロックリストを更新する • Feature環境の自動生成や複数の開発、ステージング環境の構築 • 開発の流れを止めないように十分な環境を提供する • 夜間停止・削除、スポットの活用などによってコストとのバランスを取る 15
  5. “開発が攻めることができる土台” とは? まとめると… 1. ビジネスを止めない移行プロセス • 既存案件と基盤移行を両立し、サイトを成長させながら移行する • ストラングラーパターンによる段階移行により、両立を実現 •

    1発ねらいではなく打席数を増やす(その上で、チーム全員で打率を上げる) 2. ビジネスを加速させる基盤 • 高速かつ安全にリリースできる基盤 • Blue/Green Deployment による無停止リリース基盤 • インフラがボトルネックにならないような仕組み • IaC による自動デプロイによってインフラの属人性を下げる • Feature環境自動生成や潤沢な開発・STG環境により、開発の速度を落とさない 17
  6. “筋肉質なインフラ”とは? 1. あらゆる無駄を徹底的に削ぎ落とす • 使用されていないDBオブジェクト • 余剰なサーバーリソース • 呼ばれていないアプリケーションロジック •

    使用されていない機能(または使用率が極めて低い機能) 2. コストを下げながらリソース効率を高める • 最新世代のインフラに移行して、スループットやコスパを上げる • コストモニタリングをとおして可能な限りコストを削減し続ける • SQLチューニングの実施 • キャッシュの最適化 19
  7. 基盤移行によってインフラをより筋肉質にする 20 移行前 移行後 C D N 移 行 D

    B 移 行 • 右肩上がりで増えるコスト • 繁忙期に合わせて年間契約 • サイトの成長がコスト増に直結 (特に画像配信) • コスト削減の余地が不透明 • CDN製品の料金体系が複雑 • 料金が下がるかどうかわからない • 右肩上がりで増えるコスト • ライセンス制約によりコスト増を 避けられない • 鳴り止まないスロークエリ • サイトの成長に伴い、DBボトル ネックが顕在化 • バージョンアップはおろか再起動 すらできず、打つ手なし状態 • コストを 1/10 に削減 • 配信量を 1/3 に削減 • 画像配信処理を最適化 • レスポンスを100ms以下に改善 • キャッシュ制御を最適化 • コストを 1/8 に削減 • DBオブジェクトを断捨離 • 1,000以上のオブジェクトを削除 • スループット2倍以上 • クエリチューニング • クエリキャッシュ最適化
  8. 基盤移行によってインフラをより筋肉質にする 21 移行前 移行後 C D N 移 行 D

    B 移 行 • 右肩上がりで増えるコスト • 繁忙期に合わせて年間契約 • サイトの成長がコスト増に直結 (特に画像配信) • コスト削減の余地が不透明 • CDN製品の料金体系が複雑 • 料金が下がるかどうかわからない • 右肩上がりで増えるコスト • ライセンス制約によりコスト増を 避けられない • 鳴り止まないスロークエリ • サイトの成長に伴い、DBボトル ネックが顕在化 • バージョンアップはおろか再起動 すらできず、打つ手なし状態 • コストを 1/10 に削減 • 配信量を 1/3 に削減 • 画像配信処理を最適化 • レスポンスを100ms以下に改善 • キャッシュ制御を最適化 • コストを 1/8 に削減 • DBオブジェクトを断捨離 • 1,000以上のオブジェクトを削除 • スループット2倍以上 • クエリチューニング • クエリキャッシュ最適化 フロントエンドTMと協力して Lambda@Edgeを開発・デプロイ フロントエンドTM主体で キャッシュ設計の見直し バックエンドTM主体で不 要オブジェクトの精査 バックエンドTMと協力して 負荷テストとチューニングを 繰り返し実施
  9. “筋肉質なインフラ”を実現できた理由 チームで課題解決に挑むスタンス・文化 • 開発・インフラの境界を設けない • 作業依頼ベースでインフラタスクを進めない • 「Product SRE」や「Embedded SRE」のような動き方

    • 関係者全員でよりよいものを作ることが成果につながる • 周りとよく会話し、インフラ単独で進めない • 関係者全員で協力しなければ圧倒的な成果は得られない 22 常にこれらのスタンスを貫いてチームで成果を出す
  10. まとめ これまでの取り組みを2つの軸で振り返り 1. 開発が攻めることができる土台作り=基盤・仕組みの話 • 段階移行により大規模な移行の最中であってもビジネスは止めない • 高速かつ安全にリリースできる基盤を整備。インフラ起因のボトルネックを できる限り排除する 2.

    筋肉質なインフラを作る=スタンス・文化の話 • 従来の作業依頼から脱却。他チームとの境界をつくらない • インフラだけで達成できないことがたくさんある。チームで成果を出す 24 あらゆる課題にチーム全員で挑んだことで ビジネス成長につながる基礎を作ることができた
  11. システムの全体像 27 物件情報の作成 物件情報の変換 物件情報の表示 外部システム群 担当者 物件管理 システム ETL

    パイプライン 外部システム群 File I/F File I/F カスタマー いい部屋ネット 家探し DB Upsert 手作業