運用して分かってきた、マイクロサービスという選択

はじめに

NE株式会社のロカルコ事業部ではふるさと納税支援事業を展開しており、マイクロサービスアーキテクチャを採用しています。
一般的にマイクロサービスは、大規模なシステムを小さなサービスに分割することで、拡張性や柔軟性を高めることができると言われています。
しかし、私たちが開発しているプロダクトは大規模なものではありません。(むしろとても小さいものです)
そんな私たちのチーム(エンジニア3人)で運用してみて分かった、マイクロサービスのメリット・デメリットについて書こうと思います。

前提

• マイクロサービス自体の詳しい説明には触れません
• マイクロサービスを導入した背景は触れません
• 少人数で小さな規模のマイクロサービスを運用しています
• 全てのサービスでRubyを採用しています

ふるさと納税支援事業とマイクロサービス

ふるさと納税支援事業とは

弊社のふるさと納税支援事業は、本来各自治体が行っているふるさと納税の運営業務をまるごと代行するもので、まだまだ新しい事業です。
上図からもわかるように、ふるさと納税支援事業は、自治体と寄附者と返礼品事業者の3者間の仲介業務を行っています。ステークホルダーが多いだけではなく、業務内容も多岐に渡ります。(寄附管理、返礼品管理、出荷指示、お礼状の発送、etc...)

弊社のEC一元管理サービスであるNEXT ENGINEとふるさと納税ポータルサイトを連携し、各ステークホルダーに対して必要な運営業務を効率化するためのアプリケーションを私たちは開発しています。(ここでは「ふるさと納税業務アプリ」とします)

マイクロサービスアーキテクチャ

ふるさと納税業務アプリを簡単に表すと、上図のように8つのサービスに分割されています。
前述したように様々なステークホルダーが存在するため、それぞれに合わせたサービスを作成しています。

• ポータルサイトからの寄附情報の取り込み
• EC一元管理サービスであるNEXT ENGINEとの連携
• 返礼品事業者への出荷依頼
• 配送業者への集荷依頼
• 寄附者へ送付するお礼状や料金関連の操作

ぱっと表せるだけでも、これらのように提供対象も目的も異なる複数の業務が混在します。これらの業務を各サービスに分割し、それぞれで責務が明確になっています。(Decompose by business capabilityパターンが近いと思います)

メリット/デメリット

私たちが実現したい機能や様々な前提条件のもと運用してみて感じたメリットとデメリットです。

メリット

1. サービスごとのコードの見通しが良い

   • 業務ごとにサービスが分かれているため、どの機能のコードがどこにあるかがわかりやすい。いわゆる「勘所をつかみやすい」状態
   • 極論、他のサービスのナレッジが無い状態でも自分の担当サービスが理解できていれば開発できる

2. 言語のバージョンアップのハードルが低い

   • 純粋に一つ一つのサービスが小さくなるため、バージョンアップしやすい
   • 8つのマイクロサービス全てで、ほぼ最新のRubyとRoRにできている

3. 速く&&多くデプロイできる

   • デプロイ単位が小さく、アプリケーション全体で見た影響範囲も把握しやすいため「サクッと修正してデプロイ！」がしやすい
   • ほぼ毎営業日で何かしらのリリースができている

デメリット

1. サービス間のやり取りの煩雑さ

   • (少人数で運用していることが要因ではあるが)サービスを跨いでのエンドポイントの呼び出し元と呼び出し先の修正を一人で実装する必要がある。自分で投げたボールを自分で取りに行く。
   • サービスを跨いだ修正の場合、モノリスなものと比べて修正箇所が多くなってしまう。

2. IDEの定義ジャンプが使えない

   • サービスを跨いだコードジャンプができないのはちょっと辛いことがある

総括

私個人としては、組織人数やプロダクトの規模の割にはマイクロサービスのメリットを享受できている感覚です。
例えば、業務ごとにサービスを分割するという目的だと、マイクロサービスではなくモジュラモノリスなどで十分でしょう。ですが、それだとバージョンアップのハードルは高く、デプロイ頻度は低いプロダクトだったかもしれません。(ただし、それはテストや静的解析でカバーできるものかもしれない。)
私たちの事業の特性上、カスタマーサクセスチームとの密な連携も必要になります。DevOpsの文脈で考えたときにも、速くたくさんデプロイできていることはマイクロサービスを採用していることが奏功していると感じます。

しかし、開発メンバーの人数が少ないため複数のサービスを横断して担当する必要があり、理想的なマイクロサービスの運用ができているかというとそんなこともなく、マイクロサービスを採用しているが故の課題もあリます。

結局のところ、組織や事業ドメイン次第でどのアーキテクチャも最適に成り得ます。
誰かの何かの参考になったら嬉しいです。