見出し画像

モノレポによるマイクロサービスの開発運用

MODE Japan

English version:

執筆者：Yuta Shimakawa, Software Engineer at MODE

2023/3/9にFindyさん主催のイベント「"良い開発者体験"にむけた国内/海外のアーキテクチャLT会 AWS編」に参加し、「モノレポによるマイクロサービスアーキテクチャの開発運用」と言うタイトルでライトニングトークをさせて頂きました。本記事では改めてスライドの内容をブログ形式でご紹介します。

スライドはこちら。

MODEのバックエンドアーキテクチャ

MODEの提供するプロダクトの背後では多様な機能を提供するサービスが動作しています。公開系のシステムとしてはWEB APIゲートウェイサーバーやMQTTサーバー、バルクデータダウンロードサーバーなどがある一方で、インターナルなバックエンドには時系列データベースサービス、ビデオ処理サービス、データストリームサービス、データ外部連携サービスなど異なる目的のシステムが多く存在します。

モノレポによるマイクロサービスのコードベース管理

テーマの中にあるモノレポとはマイクロサービスのバージョン管理ツールによるコードベース管理の手法の一つです。単一のソースコードリポジトリによってマイクロサービスの全サービスを管理するような方法はモノレポ（mono-repo）と一般的に呼ばれます（逆の方法、すなわち、各サービス毎にソースコードリポジトリを分けるような方法をポリレポ（poly-repo)と呼んだりすることもあるようです）上述のようにMODEのバックエンドシステムは、マイクロサービスはモノレポによって単一のリポジトリで管理されています。

モノレポのメリット

モノレポを採用する際のメリットには以下のようなものがあると筆者は考えます。

サービスの一覧性を高くしやすい

ポリレポでマイクロサービスを管理する場合、外部ツールや外部ドキュメント、またはネーミングルールによる強制などで管理するような方法が考えられますが、モノレポの場合、全て同一リポジトリで管理されているので、ファイルツリーの運用やドキュメンテーションによって何がどういう目的なのかと言うことが割と明瞭に管理できると思います。

開発に必要なサービス一式を立ち上げやすい

ローカル環境での開発時に、複数のサービスが必要になるケースがあると思います。もちろん、規模によっては開発・サンドボックス環境の依存サービスを使う方が効率的になることも考えられますが、ローカルで立ち上げることが必要な場面や環境も多くあります。そのような場合に、同一リポジトリに全てのコードが存在することは大きなメリットになります。

共通ライブラリの運用がしやすい

また、特に単一または少数の言語でバックエンドマイクロサービスを開発している場合は、ライブラリの運用が楽になります。

複数のサービスやライブラリのコードを同一目的で変更しやすい

特に、複数のライブラリやサービス（このような機会は別の問題もあることが多いので必ずしも多く行われるわけではないですが）を同一の目的で変更したい場合などには、モノレポの場合だと同一ブランチで全ての変更を管理することが可能なため、楽になると思います。

ハード/ソフトな共通化がしやすい（設定、デプロイ、規約など）

上記のようなメリットの他にも、設定の共通化・共有やデプロイ方法の共通化、開発規約の制約などの共通化もしやすいと言うメリットも挙げられます。

もちろん、これらのメリットは相対的な話であるのと、規模によっては上記のようなメリットが活かせなくなるような場面も出てくるかと思いますが、MODEのように、小規模なチームで多様なサービスを開発運用している現状はメリットを多く得られていると感じています。

モノレポのデメリット

一方、モノレポを採用する場合のデメリットもあります。

一つは、CICDパイプラインに一般解が存在しない点です。Jenkins, GitHub Actions, CircleCIなどの様々なCICDツールでよく使われるような、テンプレート的なフローをそのまま採用するのが難しいことが多くなると思います。仮に、全てのPRでビルド・テストを全サービスに対して実施したり、デプロイメントの単位が全サービス対象になってしまう、と言うようなナイーブな方法をとってしまうと、CICDパイプラインの実行が鈍重になってしまいますし、リリースタイミングにも制約が多くついてしまうと思います。このような問題をいかに回避するかと言うのが課題となります。

もう一つは、モノレポと言う性質上、単一リポジトリに関わる人数が多くなりがちです。その結果、工夫をしないとソースコードのコンフリクトや一貫性の維持が困難になるなどの問題も多くなってくると思われます。

CICDパイプラインの工夫

MODEでは上述のようなCICDパイプラインを効率的に行うために以下のような構造にしています。

  • PRやブランチに対しての自動ビルド・テストは関連のないものが動作しないようにGitHub Actionsのワークフローの制約をかけており、無駄なビルド・テストが発生しないようにしている。

  • デプロイメントは下図のようにGitHub ActionsとAWS CodePipelineを主に組み合わせて行っている。

  • デプロイメントフローにおいては、サービス*環境毎にGitHub ActionsのワークフローとAWS CodePiplineを分けており、サービス毎に独立したデプロイをできるようにしている。

  • masterへのマージについては、サービス毎のワークフローではサービスに関連するコードに変更が合ったのみにデプロイメントが実行されるように制約をかけており、無駄なサービスデプロイが発生しないようにしている。

  • ステージング・本番環境へのリリースの際には、人の手でタイミングを制御するために、git tagを利用して、デプロイワークフローの実行をトリガーするようにしている。

モノレポ管理の工夫

モノレポに関わる人的・組織的な規模の増加に対しての工夫としては以下のような二つのアプローチを実施しています。

  • リポジトリのブランチ運用ルールはなるべくシンプルにする。また、長期的にブランチがオープンしたままだとコンフリクトのリスクが増加するため、なるべく高頻度にメインブランチにマージできるようにする。そのためにフィーチャートグルの仕組みなどの実装上の工夫も行う。

  • モノレポと言っても本当に全てのソースコードを入れるわけではない。MODEでは、ゲートウェイと呼んでいるエッジデバイス上で動作するソフトウェアやモバイルアプリのコードは統一するメリットが大きくないので、別リポジトリにて管理している。

この問題は人的・組織的な規模や構造の変化に伴って深刻度や性質が異なってくるため、絶対的な正解はなく、定期的に見直しが必要になるものだと考えています。

余談 - モノレポはどの程度採用されているのか

モノレポがどの程度利用されているのだろう？と思い、イベントの際にTwitterの投票機能でアンケートをしてみたところ、やはり現状だとポリレポの方が多数派でした。一方、筆者は自身はMODE以前に働いていた職場（日本企業）ではマイクロサービスを採用していても、モノレポを採用している現場はなく、モノレポ vs ポリレポのような議論をあまり目にしたこともなかったので、40%程度はモノレポを採用していると言う回答には意外と多いな、と言う印象を受けました。

なお、弊社のCEOによれば、シリコンバレーのテックスタートアップの界隈ではよくモノレポ vs ポリレポの議論があるらしく、創業メンバーの出身企業でどんな方法をとっていたか、と言うのに大きく影響されるそうです。

まとめ・所管

MODEに入る以前は、私個人としてはモノレポには縁がなかったので、入社当時には少し運用のしずらさや、懐疑的に思うことも多かったのが正直なところです。この部分はデメリットであげたようなこと。

ただし、ある程度仕組みを整えた結果、メリットをより実感することができるようになってきました。特に言語がある程度統一されている場合、よりメリットが大きくなるのではないかなと思います（弊社の場合、バックエンドマイクロサービスは全てGoで実装しています）。

最後に、モノレポをはじめとしたマイクロサービスの運用やバックエンドの開発に興味のあるエンジニアの方は絶賛募集中ですので、ご興味のある方はお気軽に話を聞きにきてください。