[PyCon APAC 2023]PantsではじめるPython Monorepo

PyCon APAC 2023 「Pants ではじめる Python Monorepo」発表資料

https://2023-apac.pycon.jp/timetable?id=PSZB3R

https://docs.google.com/presentation/d/e/2PACX-1vSXXZwB1H-2dXlrMe03ijQ9jrLyYI96do-dLW8LFJ3rB6GJmYXMfo6Xdr8vKpusT8Q921dVDyZdtfSE/pub?start=false&loop=false&delayms=3000&slide=id.g291c64a2df3_0_7

Transcript

1. PyCon APAC 2023 Koki Nishihara Pantsではじめる Python Monorepo 1
2. ⾃⼰紹介 Koki Nishihara (github@nishikoh) CADDi AI Team, Lead Engineer • MLOpsの推進 • Python Working Group Lead 好きなOSS • pydantic • Pants 2
3. Monorepo Contents Pants 概要と活用 1 2 Keywords monorepo, build tools, Python, Pants, CI/CD, 静的解析, チーム開発, 大規模 開発, 開発効率, 依存管理, コード共有, Docker, pex 話さないこと Bazel や Buck2、Moon、NX といった Pants 以外のビルドシステムの詳細 Monorepoとビルドツール 3
4. Monorepo 4
5. Polyrepo と Monorepo Polyrepo Monorepo repository project Monorepoは複数のプロジェクトを単一のrepositoryで管理する構成 5
6. Polyrepoの特徴 ✅ 各repoごとに技術選定や意思決定がしやすく、⾃由度が⾼い ✅ ⼩さいコードサイズによる認知負荷の低減 ✅ 短いビルドとテスト時間 ❌ 統⼀的な管理とrepo間の⼀貫性 ❌ コードや設定、CI/CDの共有 repo proj 6
7. Monorepoの特徴 ✅ ⼀貫性と集約的な管理 ✅ コードや設定、   CI/CDの再利⽤による⼯数削減 ✅ ⾼い可視性 ✅ Single source of truth ✅ Atomic commits repo proj ⚠ 技術選定や意思決定の影響範囲 ❌ ビルドやテストのパフォーマンス ❌ 学習コストと   認知負荷 7
8. 開発規模が拡⼤した際の懸念 • 依存管理の複雑化 • テストやビルド時間の増加 • 複数の開発者が関わることによるソースコードのコンフリクト • git cloneの時間 …etc 8
9. 開発規模が拡⼤した際の懸念 • 依存管理の複雑化 • テストやビルド時間の増加 • 複数の開発者が関わることによるソースコードのコンフリクト • git cloneの時間 …etc これらの課題はビルドツールを使うと改善できる 9
10. ビルドツールの機能 • ローカルキャッシュ • リモートキャッシュ • リモート実⾏ • 差分検知 • ツールの統⼀ ビルドツールが開発規模拡⼤した際のパフォーマンスや管理をサポート • ビルド‧パッケージング • 依存管理 • 依存の制約（禁⽌‧許可）管理 • タスクランナー ... etc 10
11. モノレポは全ての課題を解決する銀の弾丸ではないが、 うまく活⽤することで効率的な開発ができる 11
12. Pants 12
13. Pants PantsはPythonのサポートに⼒を⼊れているビルドツール1 依存関係リゾルバー、テストランナー、リンター、フォーマッタ、 REPL など、Python開発でよく使われる標準的なツールを 公式でサポートしており、Scalableな開発が可能 1 PantsはPython以外にGo、Java、Scala、Shellなどをサポートしている 13
14. Pants PantsでサポートしているPython開発ツールの例 pip, pytest, black, yapf, flake8, docformatter, pydocstyle, isort, pylint, bandit, autoflake, pyupgrade, ruff, mypy, setuptools, iPython … etc Docker, pex, AWS Lambda, Google Cloud Functions requirements.txt, pyproject.toml (PEP621, poetry) , Pipfile.lock 依存管理 packaging tools 14
15. Getting started Hello World! を出⼒するプログラム これをPantsで実⾏し、静的解析も実⾏してみる . ├── lib/ │ └── hello_world.py ├── main.py └── requirements.txt rich 15
16. Getting started [setup] Pantsの初期設定に必要なものは主に3つ 1. pantsバイナリ 2. pants.toml 3. 各ディレクトリごとのBUILDファイル 以下のコマンドでバイナリをインストール & setup 16
17. Getting started [ディレクトリ構成] pants.tomlと各ディレクトリのBUILDファイルを配置すると、 最終的に右のような構成になる . ├── lib/ │ └── hello_world.py ├── main.py └── requirements.txt . ├── BUILD ├── lib/ │ ├── BUILD │ └── hello_world.py ├── main.py ├── requirements.txt └── pants.toml 17
18. Getting started [pants.toml] pants.tomlにはlinterやformatterなどrepo全体に関する設定を記述 ここではblackとflake8のbackendを有効にしている 18
19. Getting started [BUILD] PantsにはBUILDファイルの⾃動⽣成機能がある 以下のコマンドで⾃動⽣成でき、ほとんどの場合、⽣成されたBUILDファ イルに⼿を加えずに作業を終えることができる $ pants tailor :: 19
20. Getting started [BUILD] BUILDにはどのファイルをPantsで管理するかや entorypoint などを記述 . ├── BUILD ├── lib/ │ ├── BUILD │ └── hello_world.py ├── main.py ├── requirements.txt └── pants.toml python_sources() python_requirements( name="requirements", source="requirements.txt" ) python_sources() 20
21. Getting started [BUILD] python_sources()でカレントディレクトリの*.pyをPantsに紐づける python_sources() python_requirements( name="requirements", source="requirements.txt" ) python_sources() . ├── BUILD ├── lib/ │ ├── BUILD │ └── hello_world.py ├── main.py ├── requirements.txt └── pants.toml 21
22. Getting started [BUILD] python_requirements()でファイルに依存するパッケージをPantsで管理 requirements.txt 以外に poetry や PEP621 対応のpyproject.toml でもOK python_sources() python_requirements( name="requirements", source="requirements.txt" ) . ├── BUILD ├── lib/ │ ├── BUILD │ └── hello_world.py ├── main.py ├── requirements.txt └── pants.toml 22
23. Getting started [run] setupが終わった今の状態で、右のコマンドを実⾏するとプログラムが起動 . ├── BUILD ├── lib/ │ ├── BUILD │ └── hello_world.py ├── main.py ├── requirements.txt └── pants.toml $ pants run main.py Hello World! 23
24. Getting started [lint] 以下のコマンドでlintを実⾏ . ├── BUILD ├── lib/ │ ├── BUILD │ └── hello_world.py ├── main.py ├── requirements.txt └── pants.toml # 単一のファイル $ pants lint lib/hello_world.py # ディレクトリ配下全て $ pants lint lib/:: # repo全体 $ pants lint :: 24
25. ここまでのまとめ - PantsはPythonの標準的な開発ツールをサポートしているユーザーフレ ンドリーなビルドシステム - pantsバイナリ、pants.toml、各BUILDファイルの3つが開発に必要 - pants tailor :: でBUILDの記述を⾃動化できる - 既存のディレクトリ構成をベースにPantsを使った開発ができる 25
26. monorepoで起こりそうな困りごと 😥 テストとビルド時間の増加 😥 Dockerfileに依存するPythonファイルを都度COPYするのが⼤変 😥 いつの間にか意図しない依存関係ができていた 😥 依存するパッケージのバージョンが合わないのでコードを共有できない 26
27. テストとビルド時間の削減 ローカル環境やCI環境でのテストが⻑いと時間とお⾦もかかり、 開発者体験も悪くなる Pantsでは以下の機能を提供しており、テスト時間の削減が期待できる - 差分実⾏ - リモートキャッシュ - shard分割による並列実⾏ 27
28. 差分実⾏ 変更によって影響を受けるファイルのみを対象に実⾏ Pantsのコマンド実⾏時にオプションを付与するだけで、差分実⾏できる。 以下のコマンドは指定されたorigin/mainから変更されたファイルとそのファ イルに依存しているものをテストする $ pants test --changed-since=origin/main --changed-dependees=transitive CADDiの環境では差分実⾏によりCIの時間がp90で1/10になった 28
29. リモートキャッシュ 異なる開発マシン間でキャッシュを共有 リモートキャッシュを参照することで⼀度実⾏済みのコードやテストの結果 を再利⽤でき、CI の待ち時間を短縮できる。 CADDiでは bazel-remote-cache を使ってGCSにキャッシュを保存。リモート キャッシュにfull hitするとテストの実⾏時間が1/12になった リモートキャッシュのsetup⽅法はCADDi Tech Blogを参照 29
30. shard分割による並列実⾏ テストを複数の shard（分割単位）に分けて実⾏ 30 $ pants test --shard=0/10 :: $ pants test --shard=1/10 :: … 770秒かかっていたテストを試しに1/10に分割すると58秒まで短縮 CI 環境で複数のマシンで並列分散実⾏すると、CIの待ち時間を短縮できる
31. PythonにおけるDocker Pythonはコンパイルして単⼀のバイナリを⽣成する⾔語仕様ではない モノレポはファイルの共有がしやすいが、 Dockerfileで都度依存するファイルをCOPYするのは⼤変 31 . ├── lib/ │ └── hello_world.py ├── main.py └── requirements.txt
32. pex pexファイルは、サードパーティのパッケージを含めた Python 仮想環境を zip 形式でパッケージングした実⾏ファイル。ポータビリティが⾼い 32 pexファイルでPythonプログラムを動かせる このpexファイルだけCOPYすると Dockerfileの記述をシンプルにできるのでは🤔
33. pex pexファイルは、サードパーティのパッケージを含めた Python 仮想環境を zip 形式でパッケージングした実⾏ファイル。ポータビリティが⾼い 33 pexファイルでPythonプログラムを動かせる このpexファイルだけCOPYすると Dockerfileの記述をシンプルにできるのでは🤔 ←これだけで pydanticが使える👍 pexをCOPY
34. Pantsとpex pexの構築に必要なパッケージとコードをPantsが⾃動的に検知してビルド どのサードパーティパッケージと⾃作のコードを含めるかは、 ほとんどの場合、明⽰的に指定する必要はなく簡単にpexファイルが作れる 34
35. PantsとpexとDocker Pantsが⾃動的に依存関係を検知してpexをビルド。そのpexをDockerfileに COPYすることでシンプルにコンテナイメージを構築できる Pythonではイメージサイズを⼩さくするためにキャッシュを無効化したり、 venvを使ったりするが、pexではシンプルにCOPYするだけで⼩さくできる2 35 2Docker build for Python tips: torchのようなGPUが関わるものはpexに含めずに、 Dockerfile内でインストールするとハマりにくい
36. 依存の禁⽌設定 公開する予定がないコードがいつの間にか参照されて使われるようになる と、バグの原因になったり、メンテナンスが⼤変 36 Pantsは依存の禁⽌‧許可の 設定ができる 右のコードはsandbox以外の何かが sandboxに依存するのを禁⽌する
37. Diamond DependenciesとOne-Version Rule Diamond Dependenciesはコードの依存するバージョンが衝突する状況 37 libaが使うlibbaseとlibbが使う libbaseのバージョンが違うとビルド や実⾏時にエラーを引き起こす 対策: One-Version Rule 任意のライブラリに対して 1 つの バージョンを使⽤することでビルドの 堅牢性を⾼め、失敗を防ぐ 引用: https://abseil.io/resources/swe-book/html/images/seag_2101.png
38. ここまでのまとめ - 差分検知やリモートキャッシュ、shard分割による実⾏で開発規模が⼤ きくなっても、テストやビルドの時間を短くできる - pexの活⽤でシンプルなDockerfileの記述 - 依存禁⽌の設定により、意図しない依存の防⽌ - Pantsでは各プロジェクトごとに依存管理できるが、全体管理にできる だけ集約するとDiamond Dependencies対策がしやすい 38
39. CADDi社内でのPants活⽤ 活⽤場⾯ • backendのWebAPI • 機械学習パイプライン • 社内向けPythonライブラリ 39 規模 • 依存するパッケージ数: 300以上 • プロジェクト数: 30以上 パッケージは全て⼀つのバージョンを 使っている(”One-Version Rule”) 300以上のパッケージを最新バージョン に更新するのも5分以内に完了する
40. Pants monorepoをやってみて ✅ あらゆる資産を再利⽤できるので新規開発のスタートが早くなった ✅ 将来的な開発効率向上に繋がる施策がしやすく、積み上がっている ❌ Pantsの学習コストは⼀定ある（必要なコストだと認識） ❌ 機械学習モデルをlfs管理しているが重い 40
41. 全体まとめ - モノレポにもトレードオフがあるが、上⼿く活⽤することで効率的 な開発ができる - PantsはPython開発における標準的なツールをサポートしているユー ザーフレンドリーなビルドツール - モノレポは複数のプロジェクトを管理できるのが強みだが、⼀つの プロジェクトだけ管理しても良い。試しに⼩さく始めてみるのがオス スメ - CADDi Tech BlogでPantsの活⽤事例を公開中 41
42. おすすめ書籍 Software Engineering at Google Build Systems and Build Philosophy の章は モノレポに関わる人にオススメ！ 42
44. 補⾜ 44 repo間の設定やCI/CDを共有する⽅法 - GitHub template repository, cookiecutterのようなテンプレート - テンプレートから⼀度作ったプロジェクトを更新するのが⼤変 なのでcopierやcruftを使う - GitHub organization内のworkflow共有 - nitpickのようなリモートファイルの参照