“管理画面”をモノリスに作らずにサービスを分割しよう

はじめに

要約

新しくサービスを作ったり、管理画面を作り直したりするときに、サービスを分割するとよいのではないかという提案をします。
管理画面は事業サービスと比べて、適切な粒度に分解しやすく、分割するデメリットを吸収しやすいため、分割のメリットを享受しやすいと考えます。
事業サービスがモノリス or モジュラモノリスの場合、分割したサービスにはReact Router (Remix) でのアプリ開発が適していることを主張します。

言葉の説明

• 事業サービス
  • エンドユーザに提供したい実際のサービスです。
• 管理画面
  • エンドユーザが利用する設定画面などではなく、事業を運営する社内の従業員がアクセスしシステムに関連する業務を行う画面・システムを指します。
• 凝集度と結合度
  • 厳密な意味ではなくニュアンスとして使用しています。(適切な言葉が見当たらなかった。)関係のあるものがソースコード上、アーキテクチャ上まとまっていて、関係の薄いものが離れているとよいよね、というニュアンスです。

管理画面の特徴

“管理画面”の特徴を機能と非機能に分けて分析してみましょう。

管理画面の機能の特徴

Copilotに管理画面の機能の代表的なユースケースを聞いてみると、以下の6つを挙げてくれました。(項目のみ引用)

1. ユーザー管理
2. コンテンツ管理
3. 注文管理
4. レポート作成
5. システム設定
6. サポート管理

これらを見てみると、1.5.は情シス部門の人が使う機能、2はマーケ、3.6.はCS、4は管理部門向けのユースケースに見えます。

このように異なるユーザ向けのサービスが一つの管理画面というサービスに多くのケースで統合されているのは考えてみると不思議です。少なくともこの形がベストだというのは自明ではありません。

管理画面の非機能的な特徴

続いて非機能についてみてみます。

• SLA
  • 事業サービスと比べると低いSLAでよいことが多い。計画停止なども認められやすい
• 画面デザイン
  • 事業サービスと比べると厳密でなくても許される場面が多い
• 性能
  • 業務を行うための性能は求めらるが、シビアな事業サービスのようにミリ秒単位でのパフォーマンスチューニングが求められることは少ない。

このようにしてみると、事業サービスとは異なった技術選定・アーキテクチャ検討が必要であるor可能であることがわかります。

管理画面のサービス分割アーキテクチャ

提案の前提

事業サービスはモノリスクモジュラモノリスであることを想定しています。 (マイクロサービス化されているのであれば管差画面もすでにマイクロサービス化されているはずで、この議論の対象外となります。）

提案内容

管理画面の機能的な特徴から、異なるタイプのユーザ(異なる部署の従業員)が用いる機能が集約されていてアプリケーションとして凝縮度が下がりやすい、結合度が上がりやすい状態であるといえます。
そこでサービスを分割して小さくして開発しやすくしようというのがこの記事の主張になります。
共通で利用する機能としてユーザ管理・認証機能を用意し、それ以外は利用するユーザの属性ごとのサービスに分割します。
サービスを分割することで、分割されたサービスの複雑度が減り、開発が容易になります。一般にマイクロサービス化した場合は、(1)サービス間の複雑性が増すことや、(2)データソースへのアクセスの一貫性の維持が難しくなることが懸念されます。が、今回提案するアーキテクチャでは(1)サービス間の依存はないため複雑になりえません。また(2)についてもデータソースを分割したりしないため、データソース側でのトランザクションをそのまま用いることができ複雑なトランザクション管理などは不要です。

従来のマイクロサービスアーキテクチャのイメージ図は以下のように示されます。

この文章で主張しているサービス分割は以下のようなイメージです。

また、デプロイの粒度が細かくなることでデプロイ頻度があがることも考えられますが、管理画面は寸断や計画停止が比較的認められやすいので、導入のハードルは高くないと考えられます。

認証機能の実現方法

ユーザ管理・認証機能については(AWSであれば)Cognitoを使うことを想定しています。これは事業サービス側にCognitoを入れるということではなく、管理画面の各アプリ群のために導入します。事業サービスで使用している場合は別のユーザブールを用意します。(もちろんCognitoなどを利用せずに自前で実装してもよいですが、楽です)

汎用的な各アプリの実現方法

サービスを分割することで、そもそも管理画面のアプリを開発しなくても、Strapi (CMS)、Redash (BI)、Drizzle Studio (DB管理)などを導入してALBでCognitoによるアクセス制限しておくだけで機能要件を満たせることも多いのもメリットです。また、スコープが限定されることでノーコード・ローコードツールの活用も検討しやすくなります。既成のツールやノーコード・ローコードで実現しづらいところは小さい個別アプリを作って素早く改善していきます。

個別実装が必要なアプリの実現方法

各個別アプリの実装としては、(フレームワークとしての) React Router (Remix)がおすすめです。技術スタックとして単一言語 (TypeScript) でフルスタックな実装が可能で、シンプルなSoRなシステムを実装するのに適しています。
DBのCRUDや、AWSリソースへのアクセス・操作などをいい感じに設計することができます。
必要に応じて複雑な機能は (TypeScriptまたはほかの言語で実装した) LamdaやSQS、Batchなど呼び出します。

反論と批判

上記の内容について、批判と反論をCopilotに聞いてみました。

管理画面を分割することで、開発の効率化や柔軟性の向上が期待される一方で、統合性の低下や運用負荷の増加といったデメリットも存在します。最終的には、具体的なビジネスニーズや運用体制に応じて、分割のメリットとデメリットを慎重に評価し、最適なアーキテクチャを選択することが重要です。

確かにその通り、オーバーヘッド増加や運用負荷増はありうるので、その点は考慮して判断したいですね。