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

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

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

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

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

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

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

Transcript

2. 自己紹介 宮下 優希 2017年に新卒入社。
 2020年に株式会社AbemaTV 広告本部に移動。
 現在はバックエンドエンジニアとして広告配信システム に従事。
 
 趣味: /TFT/アニメ/漫画/

3. 広告配信システム •CMチャンス時に適切な広告を選択し配信する
4. アーキテクチャ DMP VOD リニア GKE トランス コーダ 広告入稿シ ステム Batch Tracking Server DMP 配信システ ム GKE トランス コーダ 広告入稿シ ステム Tracking Server 保証型広告配信システム 非保証型広告配信システム
5. アーキテクチャ •主要コンポーネントはGKE上で動作 •コンポーネント間の通信には主にGRPCを採用 •プログラミング言語は主にGolang, Scala を採用
6. マイクロサービス × マルチレポ y proto D component E component F component x proto A component B component C component
7. リポジトリの数
8. リポジトリの数 モノレポ導入
9. 開発体制 • 広告局では2チームに分かれ、合計10人ほどのメンバーで開発を行なっている • 100以上のリポジトリを管理
10. 課題 開発から5年が経ち、システムの老朽化や技術的負債が溜まってきており、開発生産性の向 上、リアーキテクチャなどを行いたい しかし、これらを実施するには以下の課題があった •マイクロサービス × マルチレポにおける開発フローの複雑性 •リファクタリングしづらい構成 •外部パッケージ、CI/CD、ツールなどのメンテナンスがしづらい構成
11. 開発ワークフローの複雑性 GRPC/protobuf の変更を伴う改修を行うには、複数のリポジトリにまたがり改修、その都 度レビューを行わなければならなかった 1. proto修正 2. レビュー 3. 依存コンポーネント修正 4. レビュー 5. マージ&リリース Coder Reviewer
12. リファクタリング 共通パッケージは別リポジトリで管理 • 改修を行うにはタグ打ちを行う必要があった • 依存しているコンポーネントへの影響を把握しづらく改修が難しい状態だった shared package A component B component C component
13. メンテナンス性 A repository CI設定ファイル go.mod その他設定ファイル モジュール管理ファイル・設定ファイルなど、100以上リポジトリに分散しており、メンテナンス しづらい状態であった B repository CI設定ファイル go.mod その他設定ファイル C repository CI設定ファイル go.mod その他設定ファイル
14. 課題を解決するためモノレポ化を検討 •マイクロサービス × マルチレポにおける開発フローの複雑性 •リファクタリングしづらい構成 •外部パッケージ、CI/CD、ツールなどのメンテナンスがしづらい構成 モノレポ化を検討
15. なぜモノレポ化なのか Istio • マイクロサービスアーキテクチャは、スケールするほど、どのコンポーネントでも必要な 可観測性、トラフィック制御、セキュリティ管理が難しくなる • これらをコードの変更することなく実現してくれる リポジトリに対しても同じことが言えるのではないか？ → 各コンポーネントで必要なコードを共通化し、アプリケーションコードに専念できるように
16. モノレポの導入 •新規非保証型広告配信システム開発プロジェクトにおいてモノレポを導入 •開発フローが大きく変わるため、メンバーには大きな抵抗感があった → チームでどのようなリポジトリアーキテクチャにするのか議論を行なった
17. 依存関係管理について シングルモジュール化を行い、依存関係を簡潔化 懸念: 特定のコンポーネントで特定のバージョンのパッケージを利用したい場合はどうする のか？ → 基本依存するパッケージは同じバージョンを使う方針に • なるべく最新バージョンのパッケージを使うように • 全てのコンポーネントのリリースを行うワークフロー用意し、依存モジュールのバー ジョンアップを支援
18. ディレクトリ構成について モノレポに固執しない構成に • components 以下に今までのリポジトリ単位だっ たコードを配置 • モノレポから切り離すことも考慮
19. ビルドツールの選定 モノレポ導入当初 Bazel を使用 • どれほどビルドに時間がかかるか把握できなかった • 差分ビルドを行うために導入 • Go, Docker イメージのビルドのみに使っていた 結果: 各ツールを使いビルドするよう変更 • Bazel のビルドと各ツールのビルド時間にそれほど差がなかった • Goのビルドが通るがBazelのビルドが通らないことが時折発生 • メインの言語はGoのみでBazelの機能を活かしきれていなかった
20. CI/CDについて CI • Github Actions を採用 • 設定ファイルのテンプレート化 • 変更があったディレクトリごと実行するワークフローを分け、必要なCIのみ実行する ように CD • ArgoCDを採用 • GitOpsを採用 • Kubernetesのマニフェストを変更することでデプロイできるワークフローを用意
21. ブランチ戦略 feature ブランチによる長期開発との相性が悪い 長期開発を行なってしまうと feature ブランチと master ブランチに差分が発生してしまい、 デグレなどが起きてしまう → トランクベースの開発を行う必要がある フィーチャートグルを用いた開発、作業を細かく分割しマージ頻度を高める必要がある
22. モノレポ設計 • ルートにgo.modを配置し、シングルモジュール化 • ディレクトリ構成 ◦ 基本シンプルな構成に、コンポーネントごとにディレクトリに分割 ◦ メトリクス、ロギング、コンフィグなどのみ共通パッケージ化 • DB, protobuf などのスキーマの管理方法 ◦ 共通で使う構造体は使い回せるように • terraformやkubernetesのマニフェストなども全てモノレポ化 • CI/CD ◦ 全体または一部のコンポーネントをタグ打ちリリースできるように
23. 既存コンポーネントのモノレポ化 チームでのベストプラクティスが定まり既存コンポーネントのモノレポ化に着手 • git subtree コマンドを用いて、コミット履歴を保持したままモノレポ化 • import 文などを修正し、ビルドできるように • CI/CD 周りを整備し、リリース コアコンポーネントからモノレポ化を行い4ヶ月ほどで基本的な開発が行えるように
24. モノレポ化によって得たメリット 意図したメリット • 開発ワークフローの改善 • リファクタリングしやすい構成 • 外部パッケージ、ツール、CI/CDのメンテナンス性の向上 意図しないメリット • コードオーナー意識の拡大 • Issue を活用する新しい文化の誕生
25. 開発ワークフローの改善 GRPC/protobuf の変更を伴う改修を行う場合でも、1つのプルリクエストで改修を行えるよ うになった 1. proto, アプリケーション コードを含めた修正 2. レビュー 3. マージ&リリース Coder Reviewer
26. 変更のリードタイム 変更のリードタイム(中央値)
27. リファクタリングしやすい構成 • 共通ロジックなど見つけた場合、共通パッケージに移植することで簡単に無駄なコード を減らせるようになった • 共通パッケージを変更した場合、全ビルドができ影響範囲など把握できるようになった shared package A component B component C component
28. メンテナンス性の向上 今までパッケージ、ツール、CI/CDの設定が各リポジトリに分散されていたためメンテナンスし づらい状態にあった → go.modの統一、またはツール、CI/CDの設定ファイルをテンプレート化することによって メンテナンス性が向上し、アプリケーション開発に専念できるようになった
29. コードオーナー意識の拡大 Ownership 当事者意識の範囲を広げる モノレポ化によってメンバーの担当領域を超えて コードの改修を行いやすくなり コードオーナー意識を拡大することができた
30. Issue を活用する新しい文化の誕生 • リポジトリが乱立している状態であったため、Issue を上手く活用できていなかった • モノレポ化を行い Issue の活用がしやすくなったため、メンバーからIssueを活用しよう と声が上がった → コードやコミット、プルリクを参照しながら、Issue 上で議論を行う文化が誕生
31. 今後の展望 • モノレポ化は手法の一つでしかない チームがベストパフォーマンスを発揮できる手法は模索していかないといけない • 技術的負債の解決やリアーキテクチャを行いプロダクトをより成長させたい
32. まとめ •5年が経ちシステムに老朽化がちらつき始め、改革する必要があった •チームがベストパフォーマンスを発揮できる開発手法を模索した •モノレポ化を行うことで開発生産性を向上することができた