00:03
はい、みなさんこんにちは。エンジニアをやりつつ、今はですね、 ジェネラティブアーティストを目指している、 きーずことくわはらです。
じゃあ本日もやっていきましょう。 keethのエンジニア雑談チャンネルです。この番組では、ウェブ業界に関することや、 エンジニアについての雑談などの情報を発信していきたいと思います。
今回はですね、まあこっちのチャンネルではずっと、 朝活配信をしていたんですけども、考えることが一つあってですね、
あのモノレポ開発についてちょっと考える機会があってですね、 まあ去年、一昨年かな、なんかモノレポのワードをちょいちょい耳にするようになって、
僕はフロントエンドエンジニアなので、あれですね、あのPMPMとかのワードをですね、 よく聞くようになったなと思ってて、まあその評価もしたりと思ったんですけど、
改めてこのあれですね、モノレポ開発のメリットとかデメリットをちゃんと僕は理解しなかったりとか、 プロジェクトで実はモノレポをやったことがほぼほぼないんですよね。
なんか入ったプロジェクトでたまたまやってたっていうのはありますけど、 自分でスタートの時からモノレポでやるみたいな考えたこと、アーキテクトをしたこともなかったので、
ちょっとその辺改めて自分でも勉強しつつでもなんか改善で言いますか、 自分の中で答えを見つけたかったなというのが正直あるので、今日はその辺の話がしたいんですけど、
お話がしたいんですけど、まだ今からそのモノレポについての勉強をしたかったので今からするんですけど、 ちなみに勉強すると言いながらまあ行動を書くわけじゃないですけど、とある記事ですね、
サークルCIさんのブログがあって、そのブログをちょっと読んでいきつつ、 あの自分の考えを述べていこうかなと思ってます。
はい、なのでいつも通りの朝活と同じような流れになるかもしれないですけど、 ご了承いただければ幸いです。
じゃあいきたいと思います。 モノレポ開発のメリット、バーさせてメリットという記事です。
まずモノレポなんですけど、モノレポとはアプリケーションやマイクロサービスの全コードを 単一なモノリシックなリポジトリ、普通はGitですね、に保存するパターンを指しています。
一般的には様々なアプリコンポーネントのコードをサブフォルダに分割して、 新機能だったりバグ修正にはGitワークフローを使ったりします。
GitHubじゃなくてGitワークフローなんですね。
モノリシックなアーキテクチャでアプリケーションやシステムを開発するのであれば、 大抵はこうしたアプローチを自然と採用することになります。
通常このようなモノレポでは、コードから実行可能なアプリケーションを生成する ビルドパイプラインも一つだけになります。
そうだね、確かにモノレポなんだから、それはビルドパイプライン一つだけになりますよね。
この手法はメンテナンスはしやすいんですけど、全体的な開発速度が落ちると。
修正に手間がかかるバグが少しあるだけで、リリース候補版というのを 本番環境にデプログできなくなってしまう。
この記事ではモノレポとポリレポの違いを説明して、 モノレポのメリットとデメリットを比較してから、
モノレポが皆さんの開発チームにとって適切な手段化を判断する際の ポイントをお伝えしますということでした。
マイクロサービス開発でもモノレポとポリレポです。
マイクロサービスアーキテクチャの普及につれて、 コードを多数のリポジトリに分割するいわゆるポリレポですね。
チームが増えてきましたよと。
各マイクロサービスの開発チームはそれぞれ独立していて、 それぞれの課題に合ったツールとプログラミング言語と使用します。
例えば人工知能、AIというのを開発する開発者はPythonを使用する一方で、 APIの実装を担当する開発者はJavaや.NETを使用しているという具合です。
03:02
やばいですね。まあまあ、それ仕方ないか。 普通にマイクロサービスごとによってアーキテクチャが違ったりするのは当然だと思うんで。
とはいえ、できれば統一している方がいいと思いつつですね。
あと、APIの実装をJavaとか.NETで使用するってどうなんでしょうね。
僕らがウェブ開発者だったり、僕がウェブ業界にしかいないから特に違和感はありますけど、 何でもいいですけど。
ポリレポのメリットは明白ですね。
チームが一つだけであり、その規模が小さいのであれば、 マイクロサービスを迅速に実装して担当者が別々にデプロイを行うことで、 ソフトウェア開発のスピードを大きく高められますと。
しかしリポジトリの分割にはリスクもあります。
複数のリポジトリを各担当チームがバラバラにメンタルするので、 システムに関する知識が分散してしまいますよと。
その結果、システム全体をビルドしデプロイする方法を知っている人が誰もいないみたいな状態でありかねません。
いわゆるそういう、ブリッジエンジニアじゃなくて、いわゆる結合屋さんが必要になってきますけど、
そういうのは大体職人になってしまって、人以上になる傾向があるなと思いました。
マイクロサービスの開発ではポリレポが当然の選択肢に思えますけど、
しかしモノレポの問題点というのは、ビルドとデプロイのパイプラインを統一し、 自動化することでほぼ解決できますと。
モノレポならではのメリットやよくある誤解を詳しく見て、 皆さんのチームに適切かどうか考えてみましょうと。
どっちのペインを取るかっていうところですよね、要は。
チーム開発しますからね。
モノレポのメリットはというんですけど、ざーっと一覧化します。
次のメリットですけど、まず一つ目は見やすいと。
担当のマイクロサービスで他のマイクロサービスを呼び出す場合、 該当するコードを見て仕組みを把握できます。
バグが発生した場合も原因が自分の担当範囲にあるのか、 他のチームのマイクロサービスにあるのかを突き止められますと。
単純にこれだけだったら、 ポリレポでもできなかった気はしますし、
情報とアクセスのパイプとかをしっかり組んでおけば 全然見れるんじゃないかなと思ったりしますけど、
モノレポのほうが見やすいですよね、情報が集約されてますからね。
続いて、コードを共有できるというのがメリットですと。
複数のチームで様々なマイクロサービスを開発していると、 コードが重複したり、エンジニアリングの間接コストが増えがちですと。
リポジトリを大変使わせて共通モデル、共有ライブラリ、 ヘルパーコードを全てまとめておけば、
マイクロサービスが多くたとしても、 これらを使い回せるようになりますよと。
それもそうだよね。
エディターとかIDを使っておけば、 コードジャンプでそのまま全然使えたりしますし、
検索できますからね。同じリポジトリでありますから。
続いて、コラボレーションがしやすいというところですね。
モノレポならチーム間に障壁とかサイロが生じることがないので、 連携性の高いマイクロサービスを設計・メンテナンスしやすくなりますと。
ないと断言できるかは難しいですけど、 比較的少なくなると思いますので、
コラボしやすいのもそうだと思いますね。
共通言語みたいなもんですね、ソースコードが。
なのでその場でパッと会話しやすくなったりするのも 確かに強いかもしれないです。
コンテキストが一致してますからね。
続いて、標準化が容易になりますと。
モノレポはポリレポに比べてチーム間での コードやツールの標準化というのは簡単ですと。
ブランチポリシーを適用することでメインブランチの簡素化だったり、 特定のブランチへのアクセス制限、
06:01
もしくは命名ガイドライン適用だったりでコードレビューの配置だったり、 ベストプラクティスの実践を強制できるからになりますと。
完了済みの成果物に開発中のコードが 混じってしまうこともありません。
状況を把握しやすいというところもメリットになりますと。
状況を把握しやすいが次のメリットですね。
標準化のところはまさしくそうですよね。
さっきと同様ですけどコンテキストと一致してますし、 同じリポジトリ内で動いていくんだから、
ルールとかも適用を皆さんに共有しやすいし、 それを徹底しやすいとなりますよね。
で、ついて状況を把握しやすいが次のメリットですけど、 モノレポではコード全体を一目で把握できます。
ポリレポに比べてリポジトリ全体の状態の確認だったり、 全ブランチの調査、変更の追跡というのは大幅に簡単になりますよと。
それもそうだよね。
で、リリースを管理しやすいというのが次です。
モノレポならシステム全体をデプロイする方が 分からなくなることはまあないけど、
ビルドパイプラインが1本ですからね。
ビルドとデプロイのパイプラインを自動化すれば、 一部のチームだけがデプロイ方法を知っているという状況も避けられますよね。
で、続いてリファクタリングが容易というのがラストのメリットです。
モノレポでは全てのマイクロサービスに直接アクセスできるため、 コードリファクタリングしやすくなります。
コードの構造変更も行えます。
ソースコードを移動する際もリポジトリ間ではなくて、 フォルダやサブフォルダ間で移動すれば容易で手間がかかりません。
それもそうだよね。
じゃあ続いてモノレポのデメリットに入っていきたいと思いますが、
モノレポのデメリットは、上手すぎるようなメリットがある一方で、 モノレポのデメリットがいくつか存在します。
共通のコードを変更すると、 かつ多くのアプリケーションコンポーネントに影響を及ぶにします。
つまり影響範囲がデケェよって言ってます。
あとソースの競合によりマージしにくい場合もあります。
そうですよね。 コンフリクトオンパレードになる確率は高いかなと思ってます。
あとデプロイプロセスが複雑化する可能性もあって、 ソース管理システムのスケーリングも必要ですね。
1個1個のサービスにおけるデプロイパイプラインとしては、 本当はシンプルかもしれないですけど、
それぞれ全部が1本に集約されているので、 それぞれ同士にちゃんと動くようにやるとなると、
複雑化するってのは確かにそうかもしれないですね。
とはいえ状況サイトとなっていれば、 こうしたデメリットよりもモノレポを導入するメリットの方が上回りますよね。
それはそうですね。
プロジェクト単位とか、僕らみたいなクライアントワークをするプロジェクトでも、
フロントからバックからアプリからとか、 全部丸っとお願いされている場合は、
ある種モノレポでやってみるっていうのが 一つの手かもしれないですね。
あとはどこかでコンテナ管理したりとか、 そのコンテナを分けるとかすれば、
もうちょっとその辺がうまいこといけたりするとなるので、 なんかいけそうな気はしますけどね。
やったことないだけちょっと面白そうな気はしました。
だいぶ前にGoogleがワンブランチで全部、 全サービスを作ってるみたいな噂を聞いたことがあって、
それすげえだと思ってましたけどね。
あれと近いような感覚な気はしますけどね。
モノレポに関する誤解の話は次に続きますね。
マイクロサービスアーキテクチャでアプリを 開発している現場では、
モノレポについていくつかの誤解が見受けられます。
例えば、プログラミング言語だったり、 ツールを複数使用している場合、
ビルドプロセスを統一しづらいので、 モノレポは適さないみたいな意見があります。
しかし、この問題はコンテナを使用することで 解消できません。やっぱりそうか。
各マイクロサービスをコンテナイメージ内で ビルドしてから、それぞれの個々のユニットとして
09:03
デプロイすればよい。
マイクロサービスをコンテナ化すれば、 個別のテストも可能になるし、
ビルドステージを多数のリポジトリに分散させることなく、 モノレポで管理もできるようになります。
ビルドターゲットはコンテナのことしか 違いはありませんというところで、
要はスコープ切れれば別に何でもよくないって話ですよね。
全部それぞれの最適解のまま、 アーキテクチャが違っても
一つの管理でいけるようになりますよと。
モノレポを導入するとコードの密接化が起きてしまう みたいな声も聞かれますけども、
必ずしもそうなるわけじゃないよと。
ただしコード同士が複雑に絡めないことのないようには 判断の注意が必要だと。
ここは結局エンジニアの腕の見せ所とかありますよね。
マイクロサービスを開発する場合は サービス間に依存関係が生じないように、
それぞれの独立性を維持しなければならないよと。
チームでマイクロサービス開発のベストプラクティスと ガイドライン守ればモノレポでも実現可能ですよと。
マイクロサービスはコンポーネントに似ています。
どちらのアイディアも大きなシステムを個別に デプロイする可能な結びつきの
緩い単位まで分化する点は同じですと。
そりゃそうだよね。
ただしコンポーネントとの違い。
マイクロサービスでは個々の単位がプロセスの境界を超え、
一般にはREST APIを使用して互いに通信をしますと。
モノレポではマイクロサービスアーキテクチャの パターンが崩れやすいのは事実ですと。
しかしモノレポを導入するだけでコードの密結構が 消失してしまうということはありませんということですね。
結局設計次第ですよね、そこら辺はね。
マイクロサービスの更新は個別に行うべきだけど、
モノレポではそれが不可能だと思われがちだというのも 次の誤解ですねと。
しかしローリングアップデートではなく、
ブルーグリーンデプロイだったりカナリアデプロイなどの 高度なデプロイ戦略を採用すればこうしたもので解決できます。
前のバージョンと並行して新しいバージョンをデプロイするので、
新しいバージョンのマイクロサービスが 期待通りに動作するか確認もできますし、
バグが見つかってもすぐにトラフィックを 前バージョンへリダイレクトすることも可能ですよと。
自動化したCI-CDパイプラインを導入しておけば、
これまでに述べたモノレポのデメリは 全て解消できますというので、
CI-CDパイプラインのところに、 別の記事のリンクがありますけど、
このブログがサークルCIさんなので、
案の定、このパイプラインのところのリンクも サークルCIのサービスのリンクでした。
続いて、それぞれの開発チームは 他のチームを邪魔されることなく独立して、
マイクロサービスの開発に取り組み、 コンテナイメージをビルドして
デプロイすることができるようになりますよと。
だからCI-CDパイプラインのメリットはそこにあります。
マイクロサービスをテスト環境でバリデーションして、 本番下にリリースしたり、
前のバージョンと新しいバージョンを 共存させたりすることも可能です。
コンテナ化を導入すれば、それぞれのマイクロサービスの デプロイやテストを独立して行えるので、
ツールやプログラミング言語の違いを 気にする必要もないですねと。
モダンなCI-CDツールであれば、 スケーリングも自動で行われたり、
複雑なデプロイの管理も簡単になりますと。
モノレポの規模が大きくなっても、
マイクロサービスのビルドをテスト、 さらにはデプロイまでは個別に行えます。
チームに最適な戦略はということですけど、
では皆さんのマイクロサービス開発は、
モノレポとポリレポのどちらが適正に 向かうでしょうかというんですけど、
一つ目のポイントは、 そもそもチームの文化を考えましょうと。
モノレポのメリットであるコラボレーションが、
盛んな開発者は皆さんのチームに 合っているんでしょうかと。
二つ目は決まりごとの徹底ですよね。
皆さんのチームで密接のコードを作らないような 体制を築けているでしょうか。
12:01
モノレポ内では、マイクロサービス間の 依存管理が生じなければなりませんと。
ただし、ブランチポリシーとか権限の制限を利用すれば、
この決まりごとは義務付けることができます。
また、本番環境へのマイクロサービスへの デプロイを行えるメンバーも制御できますと。
権限の設定を通じて、各サービスをデプロイ可能な チームメンバーを指定することもできます。
統一されたCACDパイプラインならば、 こうした仕様をすべて実装し、
モノレポが大型化しても、マイクロサービスを 個別にビルド、デストロイ、デプロイできますと。
パイプラインを自動化することで、
迅速にデプロイしながらも、 モノレポを簡単に管理できる仕組みが整えられます。
はい、というわけでまとめですけども、 モノレポには見やすさ、コラボレーションのしやすさ、
コードの共有のしやすさなど、 多くのメリットがありますよと。
しかし全てのチームに最適とまでは言い切れませんし、
皆さんのチームの弱みと強みというのに基づいて、 モノレポが本当に適切かどうかというのは、
ちゃんと判断しましょうということでした。
はい、モノレポを採用することに決めた場合ってですね、
統一されたCI-CDパイプラインとして、 サークル試合もあるし、
無料のトライアルもあるので、 見てみてくださいということでした。
はい、なるほどね、結構勉強になりましたし、 改めてモノレポ開発、
僕が持っていた認識とか知見と、 それほど大差はなかったんですけど、
改めて言語化されたり、
現代でもそうなのかなというところが見れたのは すごくありがたかったなと思います。
言ってもこの記事もですね、 ちょっと2021年の5月なんで、
古いっちゃ古いですけど、 もう2年前になってしまいますので、
本当の最新かというと最新ではないんですけど、
改めてでも思想的なところは あんま変わらないんだろうなって気はしました。
結局チームでどうしたいかというと、
チームがどういう動き、ムーブ、 文化をしているかというところを
しっかり確認していくっていうのが大事ですね。
とはいえ、やっぱりメリットは大きいので、
モノレポを試しに実際の開発にまで やってみたいなってちょっとありますね。
やってみたいけど、モノレポをやるための プロジェクトではないので、
プロジェクトに対して本当に最適な方でいける っていうふうに判断してモノレポを導入するのを
やっぱりどっかでやってみたいなと思いましたね。
はい、いかがだったでしょうか。
相互だったり共有化だったり、
コラボレーションっていうところが 本当に強いので、
やっぱりチーム開発っていうことを考えると、
モノレポはでも確かにやってみたい感は すごくありますよねっていうのは
ちょっと思いつつもですね、
まあ難しいところはあると思うんで、
しっかり皆さんでルールを徹底する っていうところで、
しかもヒューマンエラーは絶対起きると思うので、
そこを徹底して仕組みとかシステムで解決できる ような何かが入ってないと、
それはそれで難しいと思いますので、
この辺をね、考えていきたいと思いますけど、
以上モノレポの開発のメリットと デメリットというお話でした。
いや、とても勉強になりましたし、 参考になれば幸いです。
こんな感じでですね、今後も自分の考えとか 知見を伸びたいと思いますけど、
なかなか僕がですね、勉強したいとか、
トゥードゥに入れてるモノで なかなか勉強できなかったモノ、
かつアサカツじゃないモノでテーマをピックアップして、
勉強したいモノっていうのをまたこうやって 配信でやっていこうかなと思ったりしています。
やっぱ僕目で読むよりも音読するほうが 全然頭に入りますね。
僕はなんか耳から勉強するタイプっぽいので。
アサカツとは別でこうやってテーマに絞った タイトルの配信も今後やっていきたいなと思いますので、
興味があれば聞いてみてください。
じゃあ今日の配信は、
今回のモノレポ開発のメリットとデメリットは これで終了したいと思います。
15:00
いつも聞いてくださり、本当にありがとうございます。
では次回の主力でお会いしましょう。
バイバイ。
