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