広告システムの生産性向上への試み〜100以上のマイクロサービスのモノレポ化〜

広告配信システムはマイクロサービスアーキテクチャを採用し、100以上ものマイクロサービスで構築されています。

サービス提供開始から5年が経ち、様々な機能追加、機能改修が行われ、保守するソースコードレポジトリは100に上ります。

次第に、機能改修、共通ロジックの抽出、依存ライブラリバージョンアップ、セキュリティパッチの適用などを行う際、複数のレポジトリにまたがって変更を行う必要があり、開発スピードが大きく低下していました。

これらの問題を解決するためにモノレポに移行しました。

今回はどのようにモノレポ移行したのかを説明し、開発フローの改善への取り組みについて説明します。

https://developer.abema.io/2021/sessions/QXlcQUxHjJ/?utm_medium=social&utm_source=slideshare

Transcript

1. View Slide

2. 自己紹介
   宮下 優希
   2017年に新卒入社。

   2020年に株式会社AbemaTV 広告本部に移動。

   現在はバックエンドエンジニアとして広告配信システム
   に従事。

   

   趣味: /TFT/アニメ/漫画/

   

   View Slide

3. 広告配信システム
   •CMチャンス時に適切な広告を選択し配信する
   

   View Slide

4. アーキテクチャ
   DMP
   VOD
   リニア
   GKE
   トランス
   コーダ 広告入稿シ
   ステム
   Batch
   Tracking
   Server
   DMP
   配信システ
   ム
   GKE
   トランス
   コーダ
   広告入稿シ
   ステム
   Tracking
   Server
   保証型広告配信システム
   非保証型広告配信システム
   

   View Slide

5. アーキテクチャ
   •主要コンポーネントはGKE上で動作
   •コンポーネント間の通信には主にGRPCを採用
   •プログラミング言語は主にGolang, Scala を採用
   

   View Slide

6. マイクロサービス × マルチレポ
   y proto
   D component E component F component
   x proto
   A component B component C component
   

   View Slide

7. リポジトリの数
   

   View Slide

8. リポジトリの数
   モノレポ導入
   

   View Slide

9. 開発体制
   ● 広告局では2チームに分かれ、合計10人ほどのメンバーで開発を行なっている
   ● 100以上のリポジトリを管理
   

   View Slide

10. 課題
    開発から5年が経ち、システムの老朽化や技術的負債が溜まってきており、開発生産性の向
    上、リアーキテクチャなどを行いたい
    しかし、これらを実施するには以下の課題があった
    •マイクロサービス × マルチレポにおける開発フローの複雑性
    •リファクタリングしづらい構成
    •外部パッケージ、CI/CD、ツールなどのメンテナンスがしづらい構成
    

    View Slide

11. 開発ワークフローの複雑性
    GRPC/protobuf の変更を伴う改修を行うには、複数のリポジトリにまたがり改修、その都
    度レビューを行わなければならなかった
    1. proto修正
    2. レビュー
    3. 依存コンポーネント修正
    4. レビュー
    5. マージ&リリース
    Coder
    Reviewer
    

    View Slide

12. リファクタリング
    共通パッケージは別リポジトリで管理
    ● 改修を行うにはタグ打ちを行う必要があった
    ● 依存しているコンポーネントへの影響を把握しづらく改修が難しい状態だった
    shared package
    A component B component C component
    

    View Slide

13. メンテナンス性
    A repository
    CI設定ファイル
    go.mod
    その他設定ファイル
    モジュール管理ファイル・設定ファイルなど、100以上リポジトリに分散しており、メンテナンス
    しづらい状態であった
    B repository
    CI設定ファイル
    go.mod
    その他設定ファイル
    C repository
    CI設定ファイル
    go.mod
    その他設定ファイル
    

    View Slide

14. 課題を解決するためモノレポ化を検討
    •マイクロサービス × マルチレポにおける開発フローの複雑性
    •リファクタリングしづらい構成
    •外部パッケージ、CI/CD、ツールなどのメンテナンスがしづらい構成
    モノレポ化を検討
    

    View Slide

15. なぜモノレポ化なのか
    Istio
    ● マイクロサービスアーキテクチャは、スケールするほど、どのコンポーネントでも必要な
    可観測性、トラフィック制御、セキュリティ管理が難しくなる
    ● これらをコードの変更することなく実現してくれる
    リポジトリに対しても同じことが言えるのではないか？
    → 各コンポーネントで必要なコードを共通化し、アプリケーションコードに専念できるように
    

    View Slide

16. モノレポの導入
    •新規非保証型広告配信システム開発プロジェクトにおいてモノレポを導入
    •開発フローが大きく変わるため、メンバーには大きな抵抗感があった
    → チームでどのようなリポジトリアーキテクチャにするのか議論を行なった
    

    View Slide

17. 依存関係管理について
    シングルモジュール化を行い、依存関係を簡潔化
    懸念: 特定のコンポーネントで特定のバージョンのパッケージを利用したい場合はどうする
    のか？
    → 基本依存するパッケージは同じバージョンを使う方針に
    ● なるべく最新バージョンのパッケージを使うように
    ● 全てのコンポーネントのリリースを行うワークフロー用意し、依存モジュールのバー
    ジョンアップを支援
    

    View Slide

18. ディレクトリ構成について
    モノレポに固執しない構成に
    ● components 以下に今までのリポジトリ単位だっ
    たコードを配置
    ● モノレポから切り離すことも考慮
    

    View Slide

19. ビルドツールの選定
    モノレポ導入当初 Bazel を使用
    ● どれほどビルドに時間がかかるか把握できなかった
    ● 差分ビルドを行うために導入
    ● Go, Docker イメージのビルドのみに使っていた
    結果: 各ツールを使いビルドするよう変更
    ● Bazel のビルドと各ツールのビルド時間にそれほど差がなかった
    ● Goのビルドが通るがBazelのビルドが通らないことが時折発生
    ● メインの言語はGoのみでBazelの機能を活かしきれていなかった
    

    View Slide

20. CI/CDについて
    CI
    ● Github Actions を採用
    ● 設定ファイルのテンプレート化
    ● 変更があったディレクトリごと実行するワークフローを分け、必要なCIのみ実行する
    ように
    CD
    ● ArgoCDを採用
    ● GitOpsを採用
    ● Kubernetesのマニフェストを変更することでデプロイできるワークフローを用意
    

    View Slide

21. ブランチ戦略
    feature ブランチによる長期開発との相性が悪い
    長期開発を行なってしまうと feature ブランチと master ブランチに差分が発生してしまい、
    デグレなどが起きてしまう
    → トランクベースの開発を行う必要がある
    フィーチャートグルを用いた開発、作業を細かく分割しマージ頻度を高める必要がある
    

    View Slide

22. モノレポ設計
    ● ルートにgo.modを配置し、シングルモジュール化
    ● ディレクトリ構成
    ○ 基本シンプルな構成に、コンポーネントごとにディレクトリに分割
    ○ メトリクス、ロギング、コンフィグなどのみ共通パッケージ化
    ● DB, protobuf などのスキーマの管理方法
    ○ 共通で使う構造体は使い回せるように
    ● terraformやkubernetesのマニフェストなども全てモノレポ化
    ● CI/CD
    ○ 全体または一部のコンポーネントをタグ打ちリリースできるように
    

    View Slide

23. 既存コンポーネントのモノレポ化
    チームでのベストプラクティスが定まり既存コンポーネントのモノレポ化に着手
    ● git subtree コマンドを用いて、コミット履歴を保持したままモノレポ化
    ● import 文などを修正し、ビルドできるように
    ● CI/CD 周りを整備し、リリース
    コアコンポーネントからモノレポ化を行い4ヶ月ほどで基本的な開発が行えるように
    

    View Slide

24. モノレポ化によって得たメリット
    意図したメリット
    ● 開発ワークフローの改善
    ● リファクタリングしやすい構成
    ● 外部パッケージ、ツール、CI/CDのメンテナンス性の向上
    意図しないメリット
    ● コードオーナー意識の拡大
    ● Issue を活用する新しい文化の誕生
    

    View Slide

25. 開発ワークフローの改善
    GRPC/protobuf の変更を伴う改修を行う場合でも、1つのプルリクエストで改修を行えるよ
    うになった
    1. proto, アプリケーション
    コードを含めた修正
    2. レビュー
    3. マージ&リリース
    Coder
    Reviewer
    

    View Slide

26. 変更のリードタイム
    変更のリードタイム(中央値)
    

    View Slide

27. リファクタリングしやすい構成
    ● 共通ロジックなど見つけた場合、共通パッケージに移植することで簡単に無駄なコード
    を減らせるようになった
    ● 共通パッケージを変更した場合、全ビルドができ影響範囲など把握できるようになった
    shared package
    A component B component C component
    

    View Slide

28. メンテナンス性の向上
    今までパッケージ、ツール、CI/CDの設定が各リポジトリに分散されていたためメンテナンスし
    づらい状態にあった
    → go.modの統一、またはツール、CI/CDの設定ファイルをテンプレート化することによって
    メンテナンス性が向上し、アプリケーション開発に専念できるようになった
    

    View Slide

29. コードオーナー意識の拡大
    Ownership
    当事者意識の範囲を広げる
    モノレポ化によってメンバーの担当領域を超えて
    コードの改修を行いやすくなり
    コードオーナー意識を拡大することができた
    

    View Slide

30. Issue を活用する新しい文化の誕生
    ● リポジトリが乱立している状態であったため、Issue を上手く活用できていなかった
    ● モノレポ化を行い Issue の活用がしやすくなったため、メンバーからIssueを活用しよう
    と声が上がった
    → コードやコミット、プルリクを参照しながら、Issue 上で議論を行う文化が誕生
    

    View Slide

31. 今後の展望
    ● モノレポ化は手法の一つでしかない
    チームがベストパフォーマンスを発揮できる手法は模索していかないといけない
    ● 技術的負債の解決やリアーキテクチャを行いプロダクトをより成長させたい
    

    View Slide

32. まとめ
    •5年が経ちシステムに老朽化がちらつき始め、改革する必要があった
    •チームがベストパフォーマンスを発揮できる開発手法を模索した
    •モノレポ化を行うことで開発生産性を向上することができた
    

    View Slide

33. View Slide