複雑になったマイクロサービスを どう管理するか Kazushi Hirai

⾃⼰紹介 l LINE Fukuoka 株式会社 l 2016年⼊社 l 開発1室 Dev K team Manager l Server-side Engineer l 2 kids l Interests/Hobbies l Exercising / Marathon l Twitter: @hkazushi0627 ฏҪ Ұ࢙ ,";64)*)*3"*

LINE STORE Products LINE STORE Stickershop Themeshop Auto Suggest Recommendation OA

History 2012 スタンプショップ リリース 2013 LINE STOREリリース 2014 LINE着せかえ LINEクリエイターズスタンプ 2017 年賀キャンペーン開始 LINE公式アカウントからの おすすめスタンプ⾃動配信 2018 LINE絵⽂字 2019 LINEスタンプ プレミアム 2020 メッセージスタンプ LINEスタンプ プレミアム デラックスコース 2021 LINEスタンプ プレミアム 台湾、インドネシア LINEアニメーション絵⽂字 2011 LINEリリース 2022 LINEスタンプ プレミアム LINE Music LINEMO バンドル l サーバサイドエンジニア︓10⼈未満 ? l エンジニアのチーム数︓2 (プロダクトチーム) l マイクロサービスのコンポーネント数︓3 ? サービスローンチ当初のマイクロサービスとチームの構成

History 2012 スタンプショップ リリース 2013 LINE STOREリリース 2014 LINE着せかえ LINEクリエイターズスタンプ 2017 年賀キャンペーン開始 LINE公式アカウントからの おすすめスタンプ⾃動配信 2018 LINE絵⽂字 2019 LINEスタンプ プレミアム 2020 メッセージスタンプ LINEスタンプ プレミアム デラックスコース 2021 LINEスタンプ プレミアム 台湾、インドネシア LINEアニメーション絵⽂字 2011 LINEリリース 2022 LINEスタンプ プレミアム LINE Music LINEMO バンドル 2023 現在のマイクロサービスとチームの構成 l サーバサイドエンジニア︓30⼈以上 l エンジニアのチーム数︓6以上 (プロダクトチーム、フィーチャーチーム、SRE) l マイクロサービスのコンポーネント数︓80以上 l プロダクトや機能の拡⼤、アーキテクチャ改善 l モノレポで管理 l 複数コンポーネントのコードベースを単⼀のリポジトリで管理 2023 現在

l マイクロサービスやコードベースの学習が困難 l リポジトリ上のコンポーネントが多すぎる l それぞれのコンポーネントが、どのプロダクト、どの機能を担当するのか不明確 l 各コンポーネントの担当者が不明確 l コンポーネントについて質問したい時、何か変更を⾏ってソースレビューしてほしいとき、だれが適切なのか不明確 Problems チームの新メンバー チームの既存メンバー l 担当したコンポーネントは限られるため、新メンバーと同様の問題を抱える l 実はマイクロサービスの全体像を知っている⼈はだれもいない これらの問題をどう解決して、複雑になったマイクロサービスをどう管理していくか︖

l コンポーネントを論理的にグルーピングする l グループ = コンポーネントドメイン l ハイレベルな図を扱うことで、複雑ではなくなり、全体把握の学習コストが下がる Solution: Component Domain コンポーネントドメインの導⼊ ハイレベルアーキテクチャ図 Storeドメイン︓コンポーネント図

l GitHubであれば、コードオーナーを設定できる l ドメイン単位で階層化することで、コードオーナーも設定しやすい l プルリクエスト作成時に、コードオーナーが⾃動でReviewersに設定される Component Domain – Code Base store/ + store-server + store-cms + store-decaton shop/ … subscription/ … リポジトリの構成 /store/ @kazushi-hirai @xxx @yyy /shop/ @aaa @bbb /subscription/ @ccc @ddd … .github/CODEOWNERS GitHub: Pull Request コードベース上はどうドメインを表現する︖ 課題 リポジトリのトップレベルをドメイン単位にして、配下にドメインに含まれるコンポーネントを配置する 各ドメイン、コンポーネントの担当者はどう表現する︖ 課題

l プロダクトや機能、もしくはコンポーネントの責務 l ストレージやキャッシュレイヤーはドメインごとに閉じる l ストレージやキャッシュの障害の影響範囲は、ドメイン内のコンポーネントのみ l ドメインの開発を、プロダクト・フィーチャーチームにまるごとアサインできる l 担当ドメインの開発に集中できる l ストレージやキャッシュの担当ドメインが明確に定義され、内部、外部の依存関係も明確 l 明確な定義により、⽇々の開発だけでなく、緊急時の対応も円滑に⾏える Component Domain – How to define LINE STOREのWebアプリケーション部分が責務 ストレージやキャッシュへのアクセスは、Storeドメイン内のコンポーネントのみ それ以外は公開されたAPI経由で、アクセスする LINE STORE Devが開発担当 どういう単位で、コンポーネントをドメインごとにグルーピングする︖ 課題

l アーキテクチャのリファクタリングを⾏う l 別ドメインからは公開API経由でデータにアクセスするようにする l データベースをドメイン毎に分割する Component Domain - Refactoring 複数のドメインから同⼀のストレージにアクセスしている場合は、どうする︖ 課題 公開API経由でデータにアクセス データベースを分割 xxxドメインのコンポーネントが、yyyドメインのストレージにアクセス

発表の流れ l コンポーネントドメインを導⼊して、マイクロサービスをグルーピングする l コードベース上で、ドメインを表現する、担当者を明確にする l ドメインはプロダクト、機能、責務で分割する l データはドメインに閉じることで、耐障害性や開発効率が向上する l 正しいドメイン構成にするために、アーキテクチャのリファクタリングが 必要なケースもある まとめ

THANK YOU!