長年運用している大規模システムに対していきなりマイクロサービス化を試みても恐らく成功しないでしょう。実際に食べログはかつてうまくいきませんでした。 大規模な変更に取り掛かる前に、モダンなシステム基盤を導入して変更容易性を高める、不要なコードを定量・削減してリファクタリングが必要な母数を減らすといった、足場を固めるステップからはじめるのが成功への道筋だと考えています。 食べログの過去の失敗と、再出発して成功しつつあるマイクロサービス化戦略を紹介したいと思います。

1. © Kakaku.com Inc. All Rights Reserved. 1
足場固めからやるマイクロサービス
株式会社カカクコム
食べログシステム本部 技術部 マイクロサービス化チーム
栗山友樹
2022年07月27日(水)

2. © Kakaku.com Inc. All Rights Reserved. 2
栗山 友樹 (Qiita@weakboson)
マイクロサービス化チームリーダー兼テックリード
食べログではサービス開発、DevOpsを経て2019年からマイクロサービス
化チーム
マイクロサービス化チームの最近の活動
• 食べログのレストラン検索を支える Debezium と Apache Kafka – Qiita
(Change Data Capture によるデータ同期改善)
• 食べログの内製Pub/Subメッセージング基盤をApache Kafkaにリプレ
イスした話 – Qiita
• 分散トレーシング導入
• 本番コード実行カバレッジの BigQuery + Tableau による可視化

3. © Kakaku.com Inc. All Rights Reserved. 3
目次 1. 食べログについて
2. 食べログマイクロサービス化の変遷
3. 大規模なレガシーシステムを段階的
に改善する取り組み
4. マイクロサービス基盤カタログ
5. 冒険者と武器屋型モデル

4. © Kakaku.com Inc. All Rights Reserved. 4
1. 食べログについて
日本最大級のレストラン検索・予約サイト
• 約8800万 MAU (2022年3月)
• レストランの口コミ、写真
• レストランのネット予約
• 飲食店DX (予約台帳、食べログオーダー、食べログ仕入)
• お取り寄せEC (食べログモール)

5. © Kakaku.com Inc. All Rights Reserved. 5
2. 食べログマイクロサービス化の変遷
• マイクロサービス化に振り回され期 – before 2019
• サービスのAPI化・システムの分割を目的としてしまった(あるある)
• ある程度成功したが、結果的に大きな失敗もあった
• 「分散されたモノリス」アンチパターンになった
• マイクロサービス化は手段と悟り期 – after 2019
• サービスのAPI化・システムの分割は手段と再認識した
• 現状課題の可視化・分析
• PoC と PDCA を繰り返して、失敗は小さく早めに済ませるようにした

6. © Kakaku.com Inc. All Rights Reserved. 6
「分散されたモノリス」アンチパターン
サービス間の過度な密結合が引き起こす問題は、コードの重複が起こす問題よりも悪質です。
分散されたモノリスになってしまうマイクロサービス - InfoQ
①ある機能が複数のリポジトリをまたいで成立している
• ドメイン境界が正しく切り分けられていないことで、
複数リポジトリのメンテナンスが必要になってしまった
②共有DBのメンテナンスが煩雑
• 過渡期限定の予定が長期化…
• テーブルの所有権が不明瞭で、ALTERで障害を起こ
すリスク
共有ライブラリの”機能α”をDBを共有するAPIとして切
り出したのだが、サブシステム業務Aは共有ライブラリ
からAPIに切り替えができず、分散されたモノリスに
なってしまった。
具体的に起こった課題

7. © Kakaku.com Inc. All Rights Reserved. 7
改善の過渡期は非常に長いので、レガシーなシス
テム基盤のままアプリケーション改善をはじめる
と、過渡期が苦しくなり失敗しやすい。
ビジネス案件の成功が至上命題である開発チームにとって、ビ
ジネスインパクトのない改善に、主体性を持って取り組むのは
難しいです。
食べログの大規模なエンジニア組織を段階的に改善していく取り組み - Qiita

8. © Kakaku.com Inc. All Rights Reserved. 8
マイクロサービス化は手段であって、
高凝集・疎結合で、少人数で自律的に開発・運用できるシステ
ムへのリファクタリングが目的。
ということで、現在はシステムの分割は一休み、積極的には推進してませ
ん。
では、何をしているのか？

9. © Kakaku.com Inc. All Rights Reserved.
大規模なレガシーシステムを段階的に改善する取り組み
食べログの大規模なレガシーシステムを段階的に改善していく取り組み - Qiita

10. © Kakaku.com Inc. All Rights Reserved.
STEP 1 - システムの変更容易性と変更安全性を高める
当時の姿 (As Is) 目指す姿 (To Be) 手段 (How) 遂行チーム
VMベースでインフラ変更
に弱いプラットフォーム
インフラ変更に強いイ
ミュータブルなインフラ
Kubernetes +
GitOps
SREチーム
5分ごとにしか収集されな
いメトリクス監視
秒単位で収集できるメト
リクス監視
Prometheus +
Thanos, NewRelic
SREチーム
レガシーな基盤技術 分散システムを運用でき
るモダンな基盤技術
マイクロサービス基盤
Apache Kafka,
Change Data
Capture, 分散ト
レーシング,
GraphQL
マイクロサービス化
チーム
などなど、課題解決のための技術スタックは似ているが、チームのスコープを決
めて集中して課題解決していく。

11. © Kakaku.com Inc. All Rights Reserved.
4. マイクロサービス基盤カタログ
書籍「マイクロサービスアーキテクチャ」や他社事例、現状の課題から食べロ
グに必要なシステム基盤をカタログ化する。

12. © Kakaku.com Inc. All Rights Reserved.
マイクロサービス基盤カタログ
小さく検証・運用をはじめて、うまくいったら導入を拡大していく。

13. © Kakaku.com Inc. All Rights Reserved.
マイクロサービス基盤の事例: データ同期基盤 before
当時の状況 目標
処理間隔 15分 リアルタイム
全件更新所要時間 16日 8時間
• 検索エンジンの仕様を変更するのが怖い
• 企画の要望に応えづらい
レガシーでパフォーマンスが悪い

14. © Kakaku.com Inc. All Rights Reserved.
マイクロサービス基盤の事例: データ同期基盤 after
当時の状況 目標 変更後 改善率
処理間隔 15分 リアルタイム リアルタイム
全件更新所要時間 16日 8時間 3.5時間 約110倍
• 検索エンジンの仕様変更がしやすくなる
• 企画の要望に応えやすくなる
モダンな基盤に刷新してパフォーマンスを暴上げ

15. © Kakaku.com Inc. All Rights Reserved. 15
システム基盤の改善からはじめると、過渡期にも
メリットが得られて嬉しい。
検索インデックス同期の改善は、開発チームがよくぼやいてい
たので、技術部から持ちかけて合同で進めました。
ビジネスインパクトのある基盤技術を提供すると、開発チーム
も主体性を持って、改善に取り組みやすくなります。

16. © Kakaku.com Inc. All Rights Reserved. 16
5. 冒険者と武器屋型モデル
食べログの大規模なエンジニア組織を段階的に改善していく取り組み - Qiita
技術部 (武器屋)
• SREチーム
• マイクロサービス化チーム
• Developer Productivityチーム
• Data Scientistチーム
基盤技術 (武器)
• Kubernetes
• Change Data Capture
• Pub/Subメッセージング
• 自動テスト基盤
開発エンジニア (冒険者)
• ウェブ開発部
• 飲食店システム開発部
事業開発を担う部門と技術開発を担う部門が、互いに主体性を持ちながら協調的に取り組む組織設計

17. © Kakaku.com Inc. All Rights Reserved.
締め - 足場固めからやるマイクロサービスとは？
「システム全体をモダンなインフラ基盤に刷新
することで、変更安全性と変更容易性を高め
る」ことからはじめるシステム改善