マイクロサービスの利用検討

2020年07月20日

マイクロサービス（Microservices）は、個々に開発された複数の小さな（マイクロ）サービスを連携させて管理、運営をおこなっていくソフトウェアのアーキテクチャです。

マイクロサービスの利用には２つパターンが有ります。

①、遠隔手続き呼び出しRPC（Remote Procedure Call）です。

②、イベント駆動型（Event-Driven）です。

２つパターンのメリット・デメリットを紹介する前に、業務サービス間の関連関係を紹介します。良い設計には、メンテしやすい柔軟性を十分保つべきである。

業務サービス間には主に４つの重要関係があります。

RPC：
　　同期呼出である場合、サーバの回答がしばらく返してくれなければ、タイムアウトになり、処理失敗とする。特にサーバ側のトランザクション処理時間が長ければ、長いほど、失敗のケースが多く発生されます。

　　非同期呼出の場合、Callback関数をパラメータとして、サービスを呼出す時に設定し、サーバが処理終了後、Callback関数経由で結果をお知らせしてくれて、待つ必要がなくなります。

イベント駆動型：
　　サービスを待機し、クライアントからの請求を届く、イベントが発生する。
イベントをメッセージパイプに登録して、クライアントにご請求を預かりましたを応答します。その後、サーバ側がいろんな処理が終わった後、再度クライアントにお知らせします。

RPC：無理。メッセージキュー(MessageQueue)を利用しなければなりません。

イベント駆動型：同じく、メッセージキュー(MessageQueue)を利用しなければなりません。

PRC：すべてのAPI情報、呼出順等を知らなければ行けません。

イベント駆動型：先頭のイベントだけを発砲したら、その後は、処理結果しだいで、自動的に進めます。BPM（ビジネスプロセスマネジメント）と同じ仕組みです。

PRC：明確なロジック処理宛先が必要、P2Pで、サービスを呼出して、サービスの応答を待つ。

イベント駆動型：ロジック処理宛先を知らなくても、統一API代理として、API Gatewayに請求を送信するだけで、処理先の決定はAPIGatewayに任せます。
APIGatewayより、P2Pで送信指示もできるし、Broadcastで送信も可能です。

業務処理フローを見える化にはWork-Flowとして、世の中普及されていますが、時にデータ更新時のイベント発生状況を確認したい、要するにタイムマシンで、過去の時点に戻りたい時に、Event Sourcingという設計パターンが現れます。

Event Sourcingとは、データの更新されるとなるイベントを積み上げます。
現在を含めたある特定時点の状態を再現できます。
例えば、ある商品の3日前の在庫状況を再現したい場合は、3日前までのイベントを再試行すれば、出荷、入荷、返品、追加等すべての状態が完全に再現できます。

利用目的としては、データチエーンと同じ考え方で、異常発生した時に、発生元の状態を容易に究明ができます。

DDDドメイン駆動設計の重要概念は境界づけコンテキスト（Bounded Context）です。
各サブシステムは独立のドメインとして運行しています。各ドメインには独自のサービスだけでなく、DBも独立である。例えば、生産、販売、物流、顧客、アフターサービスはそれぞれ独立運用されます。

主要ポイントは、データの同期問題。

DDDの考え方は、ドメイン間のデータ同期には、全く同じクラス、同じDB構成で、バッチにより、同期させます。DBの共用では有りません。

数が多くほど、管理作業が増えていきます。devopts、dockerコンテナ化、サービスレジストリ・発見等メンテ管理の自動化発展により、マイクロサービスの利用がますます便利になります。

ケースバイケースですが、マイクロサービス一つには、DBテーブルが１０以内におすすめです。

マイクロサービスの呼出しパターンはRPCとイベント駆動の２つがあります。

イベント駆動にはもっと柔軟性が有り、おすすめです。

Event Sourcingとドメイン駆動設計はマイクロサービスの利用発展方法方向の一つです。

弊社提供している業務の概要紹介：

弊社はiot、bigdata関連ソリューションを提供しております。詳細技術文書は後続追加掲載させて頂きます。

弊社はintra-mart社のベンダーです。intra-martプラットフォーム関連ソリューションのご提供は、長年続けております。

業界初Intra-mart + IoT + BIGDATA + モバイル端末対応:
https://mbpsmartec.co.jp/si-service/