BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース ビジネスプロセス、長期実行サービス、マイクロサービス

ビジネスプロセス、長期実行サービス、マイクロサービス

原文(投稿日:2018/06/28)へのリンク

ここ数年、ドメインイベントに関する議論は増えているが、コマンドについても同じように議論すべきではないか – Martin Schimak氏は、ロンドンのSkills Matterで先日開催されたDDD eXchange 2018の講演でこのように述べて、マイクロサービスにおけるイベントとコマンド、長期実行(long-running)サービスを取り上げるとともに、プロセスマネージャおよび同類のツールがコアビジネスロジックを運用する上でいかに有効であるかを説明した。

オーストラリアの独立系コンサルタントであるSchimak氏は、イベントの最大のメリットとして、すでに起きたことを表す事実である、という点をあげている。分散システムを扱う機会がますます増加する中で、システム内で発生した事象をローカルに保証することにより、システムの最終的な一貫性に信頼を加えることが可能になる。サービスの分離や、過去の事実を確認する上でもイベントは有効である。

イベントを使用することによるメリットはすべて、イベント駆動アーキテクチャが普及する理由のひとつになっており、サービス統合をイベントにのみ依存する設計も見られるようになった。これは簡素化としては合理的かも知れないが、いくつかの危険を生み出す可能性もある、とSchimak氏は指摘する。一例として、支払(Payment)、在庫(Inventory)、および出荷(Shipment)サービスと発注(order placed)支払(patment received)引当(goods fetched)出荷(goods shipped)の各イベントで構成された、簡単な注文プロセスを考えてみる。ユーザ課金の前に在庫を引き当てる、という比較的簡単な変更であっても、メッセージのフローが変わるため、関連するすべてのサービスの修正が必要になる。Shimak氏はこれを、サービス間の最適でない(suboptimal)結合によるものだ、と指摘する。

イベントは事実に過ぎないため、それ自体でアクションを起動することはない。イベントを待っている側で、どのイベントを受信した場合に何が起こるべきかを決めるような、何らかの形式でのポリシが必要だ。純粋なイベントベースシステムでは、このポリシは常にイベントを使用するサービス側にある。コマンドベースのアプローチでは、このポリシはイベント発行サービスに位置する場合もあるが、いずれのサービスも適切ではない場面も少なくない、とShimak氏は主張する。第3の選択肢として氏があげるのは、特定のイベントを受信して次のステップを決定するメディエータ(mediator)を追加することだ。

先程の例に注文(Order)サービスを追加すれば、このサービスが関連するイベントを受信してコマンドを送信することで、顧客が注文した時と、その後の注文が完了した時のプロセスのコーディネーションが可能になる。先程の例と同じ変更をしても、今回は注文サービスだけを変更すればよい。このプロセスで実行されるロジックは、ビジネスのコアドメインに属するビジネスロジックに共通するものだ、とSchimak氏は指摘する。

コマンドは将来的に何かを起こすことを意図したものである、と指摘した上でSchimak氏は、コマンドの実行形式として次の2つを定義する。

  • アトミックなトランザクションの実行 – 一般的にはモデルの変更を目的とする。発注(place order)コマンドがその例で、注文(order)の生成と発注イベントの発行とを伴う。
  • 複合的かつ長期的な実行 – よりビジネスレベルの結果を目的とするもので、場合によっては達成までに複数のステップを必要とする。前項と同じ発注コマンドであっても、最終的な結果が注文完了(order fulfiled)イベントまたは注文キャンセル(order cancelled)イベントの場合は、こちらの例になる。

支払要求のシナリオでは、価値のあるビジネス結果を達成するために努力すべきである。そのために支払サービスは、支払受領あるいは支払キャンセルといったイベントを発行する。しかしSchimak氏の経験では、クレジットカードへの請求失敗などの一時的な問題が発生して、その対処をクライアントに任せる場合が少なくない。これはつまり、明らかに支払処理の関心事であるポリシ上の問題の対処を、クライアントに強制していることになる – おそらくは再試行が、場合によっては別のクレジットカードで行われるはずだ。もしクライアントが注文サービスならば、注文処理の中で支払も行うことになり、結果として支払ドメインの知識が支払サービス以外にも拡散することになる。同時にこれは、注文サービスのサイズや複雑性も増加させる。

私たちの問題をクライアントに委譲することで、クライアントはエラー対処を余儀なくされます。クライアントが神のサービスになるのです。

そうではなく、支払サービスを支払に関する内部的なすべての問題に対処する長期実行サービスにして、最終的な結果 – 支払受領あるいは支払キャンセル – のみを発行するようにするべきだ。これはビジネス全体を集中的に管理するコーディネータを作るという意味ではなく、それぞれのコンテキスト境界を相互に保護する上で適切なAPI設計を行なうということだ、とSchimak氏は強調する。

長期実行サービスを開発する場合、共通ツールとなるのがプロセスマネージャだ。プロセスマネージャの一般的な要件は、時間とタイムアウトの管理、リトライ、プロセスがフェールした場合の補償などである。これらは自分自身で実装することも可能だが、Schimak氏はAxonメッセージングとSagaマネジメント、あるいはLagomをおもに使用している、さらに氏は、ビジネスプロセス実行エンジンの使用を検討するように勧めるが、ツールは軽量で、単一サービス内で利用可能なものを使用すべきだ、と強調している。オープンソースのプロセスエンジンフレームワークとしてはActivitiCamundaZeebee(同じくCamundaを基盤とする)などがある。サーバレスの世界ではAWSStep Functionsを開発しており、他のクラウドベンダも同じ方向に進んでいる。

長期実行サービルとビジネスプロセスエンジンに関してSchimak氏自身は、Zalandoの注文履行プロセスでCamundaを数年間使用した経験を持つ他、CamundaのBernd Rücker氏と共同で、“Events, Flows and Long-Running Services: A Modern Approach to Workflow Automation”、“Know the Flow! Microservices and Event Choreographies”という2つの記事をInfoQで執筆している。

 
 

この記事を評価

採用ステージ
スタイル
 
 

この記事に星をつける

おすすめ度
スタイル

BT