投稿したこちらの雑記の付属的な文章です。
本文の本番環境での記載はマイクロサービスについて出てきますが、その時に考えた事をこちらに記載します。本文の内容とはマイクロサービスについて考えたことを分離させるためです。
こちらも自分が考えたことの記事なので、技術的な記載ではなく単なる読み物として読んでいただけたらと思います。
マイクロサービス化
マイクロサービス化の利点
マイクロサービス化の利点としては、影響範囲を小さく閉じ込めることです。
複数のシステムが複雑に相互にAPI連携していると考えた際に、大きな単位でシステムを相互連携させていると、Aシステムでの変更がAシステム内のどのAPIに影響を及ぼすのか調査し、影響されたAPIの改修が発生します。この影響範囲が複雑で調査のコストが大きいです。
マイクロサービス化とは、このAPIをAシステムの機能と考えずに、Aシステムとその他システムの共通機能として考え、そのAPIが提供する機能を別の小さなシステム(マイクロサービス)として分離することです。
これをシステム全体に適用するとシステムは多数のマイクロサービスの組み合わせとして表現されることになります(=マイクロサービスアーキテクチャ)。そのためAPIの仕様を変更する改修は他の多数のマイクロサービスに影響しますが、その変更は呼び出しているマイクロサービス内で吸収されるので、影響範囲の特定は容易になります。
マイクロサービスアーキテクチャのデメリットとしては、サービスをマイクロサービスの組み合わせとして作成するので、システム全体の処理フローが追いづらくなります。
企業基幹システムでのマイクロサービス化
私の意見としては、企業の基幹システムの多くはマイクロサービスアーキテクチャの採用は難しいのではと考えています。
基幹システムは明確に問題領域(=ドメイン)が区切られており、その問題領域ごとにシステム(生産管理システム、人事管理システムなど)を作ります。そのためシステム間の主な連携箇所はシステムの入口と出口になり、データフローは基本的にシステム内に閉じるため、既に影響範囲は適切な範囲に閉じ込められています。
特に生産管理などのイベント管理系のシステムではフローが追いづらいデメリットが顕著になります。イベント管理系のシステムではイベントを登録、さらにそのイベントに対する後続イベントを登録その連続体で状態遷移を保存します。イベント登録を1つずつマイクロサービス化し分離すれば、イベントの連続体がそれぞれのマイクロサービスに分断されるため、どこまで後続イベントが登録されたのか、つまり状態の把握が困難になります。これは致命的でしょう。
基幹システムでも人事管理システムのようなマスタ的なシステムの場合は、他システムに提供するデータが多く、システムのデータ連携箇所はシステム内の様々な箇所で行われるため、マイクロサービス化するのも検討に入るのだと思います。
自社サービス企業でのマイクロサービス化
自社サービス企業の場合は、マイクロサービスアーキテクチャ採用の利点が大きいと思います。
自社サービス企業は、何らかのサービスをユーザに影響しますが、既存サービスの機能追加などが多く発生することが多いはずです。これら機能をマイクロサービスとして分離していれば、新規機能の開発時はマイクロサービスを追加する形になり、既存マイクロサービスへの影響はなくなります。影響範囲の閉じ込めの利点が大きく現れています。
また自社サービス企業でも最初からマイクロサービスアーキテクチャを採用するのかは検討が必要だと思います。大規模なサービスに拡張することが決定しているなら最初から適用しても良いのかもしれませんが、小さな規模のサービスの場合、共通的に利用されるマイクロサービスが少なくなり、インターフェイス分だけ無駄に作成することになります。
どのような機能に追加されるのか不明な場合は、段階的にマイクロサービス化していくのが現実的に感じます。最初はメール送信機能のような共通的に利用するであろう機能のみをマイクロサービスとして作成します。自社の新サービスの立ち上げ時に共通的に利用する機能や、データ連携が必要な箇所をマイクロサービスとして徐々に分離し共通的に利用する。この共通的に利用する機能をマイクロサービス化を繰り返せば、無駄のないマイクロサービス化が出来るのではないでしょうか。
バックエンドエンジニア目線のマイクロサービスアーキテクチャ
マイクロサービス化は共通機能を切り出し、影響範囲を小さくする事が出来ます。全体に適用したマイクロサービスアーキテクチャでは機能修正の影響はマイクロサービス内で閉じ込められ、機能拡張の影響は波及しないため機能拡張もしやすいと考えています。
筆者はバックエンド担当なのですが、これはSOLID原則の「O(OPEN-CLOSED原則)」をシステムアーキテクチャに適用したものに感じます。基幹システムに利点が薄いのは、基幹システムは機能に”拡張”は発生しにくく、自社サービスは機能の”拡張”が発生しやすいからです。
コメント