マイクロサービスアーキテクチャのトレードオフとコンポーネント増加について〜Yahoo!ニュース〜

2025年12月1日に開催された「LINEヤフー Developer Meetup #1 in Tokyo 紀尾井町LT忘年会2025」での発表資料です。

1. マイクロサービスアーキテクチャの トレードオフとコンポーネント増加について 〜Yahoo!ニュース〜 2025/12/01 後藤 拓実
2. 自己紹介 後藤 拓実 2012年にヤフー株式会社に新卒で入社。社内向けツールの開発後、 Yahoo!ニュースのコメント機能の運用・開発を担当しつつ、2017年頃よ りニュース全体の技術刷新のテックリードとしてグランドデザインの策定 を行い、2022年頃にNEWSWEB SREの立ち上げを行う。記事入稿システ ムチームのリーダーを経て、2025年4月よりYahoo!ニュース開発部長。 2025年10月よりニュース領域アーキテクト。 システムや組織などの構造と、それらが生み出す影響やトレードオフを考 えるのが好き。
3. 話すこと • コンポーネント（デプロイ単位）が多い。 • どうしてこうなったのかを考えた。 • 役に立つ知見というよりは事例紹介的な内容
4. Yahoo!ニュースにおける マイクロサービス
5. 全社視点とニュース視点 • 全社視点 ◦ トップページ, 天気, ニュース... と巨大なドメインの中に「ニュース」がある。 • ニュース視点 ◦ さらにその中にサブドメインと、それに対応するチームが存在 ▪ フロント: NewsWeb、NewsApp ▪ サブドメイン: コメント、エキスパート、トピックス、記事・媒体等 • 規模感 ◦ Yahoo!ニュース領域だけで 100以上のデプロイ単位（コンポーネント） が存在。 ※例外的にWebのみサブドメインを管掌する各チームが共同開発している
6. 歴史的経緯に基づくMSA • 戦略的設計ではなく歴史的経緯 ◦ 意図的な設計戦略に基づいたMSAではない。結果としてMSAで説明できる形になった ◦ ニュースの各領域が増える際に、既存システムへの追加改修ではなくチーム・システムが増 えるようなタイミングが幾度かあった • 組織とシステムの相関 ◦ 組織構造がシステム構造に反映されている。 ◦ 5年前頃の技術刷新のタイミングでWebのみ統合をして共同開発の形にした
7. サブドメインを管掌するチームの特徴 各チームの独立性 • 各チーム（コメント、トピックス、記事、etc.）が独立したバックログを持つ。 ◦ 実体としては約8個の開発チームが存在 • 各チームがサブドメインに対応するシステムを管掌する ◦ 例外もあり、複数管掌したり分割して管掌するチームも存在する • 設計・マネジメント・技術選定に裁量（自由）がある ◦ 言語など全社で決められている部分もある • 職能横断型（エンジニア、デザイナー、企画が1チーム）。
8. 現状の構造のメリット • 認知コストの低減 ◦ 各チームはドメインに従った領域（システムと責務）を管掌するため、 担当範囲に集中できる。 • 意思決定のスピード ◦ ステークホルダーが明確（コメントならコメントユーザー等）なため、 コミュニケーションや優先順位付けの負担が減る。 • 施策実行の速度 ◦ 必要な職能がチーム内に揃っているため、立案から実施までがスムーズ。 • 挑戦のしやすさ ◦ チームごとに自由度が高く、領域ごとの改善が進みやすい。
9. 現状の構造のデメリット • 全体最適の難しさ ◦ ニュース全体での優先順位に基づいた施策実施が難しい（チームごとに事情や忙しさが異なる）。 ◦ チーム毎の管掌領域があるため、稼働状況関係なくどのチームがやるか決まったり、決まらなかったり。 • 人員数変化に弱い ◦ チーム機能維持に最低人数が必要となり、人員変化への弾力性が弱い。一方で機能が増えても新チームを簡 単には作れない。 • サイロ化しやすい ◦ 隣のチームが「別組織」のような感覚になりやすい。独自の文化・マネジメントスタイルにより、チーム間 異動の学習コストが高い。 • 全体視点を持ちづらい ◦ メンバーにとって「管掌システム＝世界」になりやすく、ニュース全体を意識できる人が育ちづらい。
10. 問題意識：コンポーネント数が多い
11. 問題の焦点 コンポーネント数が非常に増えてしまっている • 1つのサービス領域（ニュース）で100以上のデプロイ単位が存在。 • これにより保守コストが増大している。 • フレームワークやライブラリの定期的なアップデート追従や脆弱性対応等
12. なぜ増えたのか（要因分析） 現状のMSAの状態を踏まえると、単に「分けすぎた」のではなく、歴史的・構造的な理由がありそう。 • 過去の開発スタイルの名残 ◦ 新規施策を「プロジェクト」として切り出し、新規システムとして開発する文化があった。 • 既存機能への当てはまりにくさ ◦ 既に機能単位でシステムが細分化されているため、既存の機能に当てはまらない新機能は「新規デプ ロイ単位」として増やすしか選択肢がない。 • 「中心となる部分」の不在 ◦ 「ニュースバックエンド」と呼べるコアシステムが存在しないため、機能を増やすときに分けざるを 得ない。 • リスク回避としての分割 ◦ 「障害時の影響範囲を限定的にできる」というメリットが、分割することへの抵抗感を下げている。
13. 新たな変数の登場：生成AI 生成AIの登場により、従来よりも低コストで柔軟な機能開発が可能になった。 技術的容易さが招く複雑性 • 既存の枠組みに収まらないコンポーネントを安易に増やす誘惑が強まっている。 • これまで以上にシステムが断片化しやすい土壌ができつつある。
14. 所感 - 問題（コンポーネント増加）に対して表面的にはコンポーネントの統廃合が まず手段として出てくる - 深堀ると、コアとなるシステムがないことや、コミュニケーションコスト回 避やリスク回避という原因も見えてくるため、こういった部分にも対処が必 要そうということが分かる（分かってきた） - 今のメリデメを踏まえつつどうアプローチしていくかはよく考えたい
15. 終