マイクロサービスのオーケストレーションとAPI
時はコロナ禍でニューノーマルが叫ばれる2020年ですが
「1つのアプリケーションを、ビジネス機能に沿った複数の小さいサービスの疎に結合された集合体として構成する」
というマイクロサービスの考え方は2014年にマーチン・ファウラー氏らが提唱してから早6年が経ちました。
既に先進的な企業はマイクロサービスアーキテクチャを実践・実現しているものと思われますが、今回はこのマイクロサービスベースのアーキテクチャを考える際に一つの課題となる「マイクロサービス間の呼び出し誰が管理(オーケストレーション)するのか？」に対するアイデアについてご紹介したいと思います。
「マイクロ」サービスの単位
マイクロサービスの概要を知るには、マーチン・ファウラー氏のサイトに記載がありますが、日本語のWikipediaにも簡潔な記載があります。
この中でマイクロサービスの特性には、以下が含まれているとあります。
- サービスのコンポーネント化 — コンポーネントは独立して交換・更新可能なソフトウェアの単位である。
- 分散統治 — 各サービスは独立したチーム、開発言語、ツールでアプローチする。
- 分散データ管理 — 概念モデルに関する分散だけでなく、データストレージも分散(サービス間で独立)する。
- サービスのコンポーネント化 — コンポーネントは独立して交換・更新可能なソフトウェアの単位である。
個々のマイクロサービスはそれ単体で、まさに極小(マイクロ)なサービスとして単体でデプロイし稼働が可能な単位である事を意味します。
マイクロサービス間の通信
では単体で稼働しているマイクロサービス同士の通信はどの様にして行えば良いでしょうか？
マイクロサービスでは以下の特性も挙げられています。
- スマートエンドポイントとダムパイプ — メッセージ通信は軽量かつシンプルであること。エンドポイントに高い機能を持たせ、通信はダムパイプ（メッセージのルータとしてのみ動作する単純な機構）であること。
これにはシンプルかつ特定のテクノロジーに依存しない汎用的なプロトコルを利用して通信することが求められるため、マイクロサービスではHTTP (用途にによってはgRPCなどが考えられますが) ベースにしたAPIを持つことで互いのサービスと通信します。
誰がマイクロサービスをサービスにするのか？
ここでふとした疑問が生まれます。
数あるマイクロサービスを組み合わせてビジネス上意味のあるサービスとして提供するには、各マイクロサービスを
- 正しい呼び出し順序で呼び出し
- それぞれのマイクロサービス間のデータモデルのギャップを埋め
- 途中で起きる想定外の挙動に対して適切なハンドリングなどを行う
必要があります。
例えばECサイトで商品を購入するケースで考えてみると、ECサイトで商品を購入する際には
- 支払い処理を行うマイクロサービス
- 在庫引き当てを行うマイクロサービス
- 配送依頼を行うマイクロサービス
を順序良く呼び出し、全てのサービスが成功していることを確実にする必要がありますが、これは誰の責務で行うのが正しいでしょうか？
支払い処理を行うマイクロサービスが在庫と配送を呼ぶ？
3つのサービスを呼び出すだけの新たなマイクロサービスを作る？
などを考えていくと、思っているよりも個々のマイクロサービスの間に落ちる責務は意外に多く、何も考えずにその数を増やせばあっという間にその関連は複雑怪奇になります。
他にもマイクロサービスの数があまりに多くなってくるとDeathStar (スターウォーズの超巨大戦艦で、デカすぎて?設計に不備があって弱点を一撃で爆破された)の様になってしまうので、包括的な管理が必要になるといった話がありますが、これはインフラストラクチャの問題だけではなく、ビジネスプロセスに関しても同じことが言えます。
ではどのように解決すれば良いでしょうか？
色々なアプローチがあると思いますが、1つの解決方法として、各マイクロサービスのオーケストレーションを管理することだけにフォーカスした「オーケストレーションレイヤー」をアーキテクチャの中に設けるというアプローチがあります。
例えばMuleSoftでは、各システムやマイクロサービスのオーケストレーションを主な責務とする「Process API」レイヤーを設けたアプローチを推進することで、マイクロサービスのデススター化を解決しようとしています。
- System APIs — 既存のレガシーシステムのWebAPI化や、ラッピングによる抽象化、マイクロサービスに対するAPI Gatewayの役割により、サービス全体にガバナンスを提供する
- Process APIs — 単数または複数のSystem APIsをオーケーストレートし、ビジネス上意味のあるプロセスにまとまったAPIとして提供する
- Experience APIs — ProcessAPIsを各APIコンシューマ毎に最適化したエンドポイントとして提供する(BFFに近い)
実際にNetflixでも各マイクロサービスの呼び出しのみを管理する専用の「オーケストレーションサービス」を用いることで、この問題を解決しているとのことです。(記事中ではこのサービスがSPOFなのでどうにかしたい、という文脈ですが)
このマイクロサービスをオーケストレーションするレイヤーはメッセージの送受信、ルーティング、変換、タイミング制御に特化し、自身が永続的なデータソースとならないといった特性を持っているため、MuleSoftをはじめとするGUIによる補助のあるAPIオーケストレーションツールとの相性も非常に良いと思います。
個々のマイクロサービスについてはコアのエンジニアが独立したチームで開発を行い、それらをオーケストレーションする部分にAPIオーケストレーション製品を導入するというコンビネーションは、特にB2B企業などがマイクロサービスを導入する際に非常に現実的かつ有効なパターンなのではないかと思います。
