マイクロサービスインタラクション内のタスクフローの監視と管理

キーポイント：

• コンポーネント間の相互作用は、開発者、オペレーター、およびビジネスアナリストが理解するのが難しい予期しない動作につながる可能性があります。
• ビジネスの持続可能性を確保するには、システムで発生するすべての相互作用を確認する必要があります。
• : , -; , ; , ; (process mining), ; , .
• , , , .

2018年、私は大手インターネット会社の建築家に会いました。彼は、このアーキテクチャスタイルを「マイクロサービス」とは呼んでいませんが、すべての正しいガイドラインに従い、機能をさまざまな領域内の小さなチャンクに分割していると私に言いました。次に、これらのサービスがどのように相互作用して、サービスの境界を超えるビジネスロジックをサポートするかについて説明しました。これは、理論が実践される場所だからです。彼は、彼らのサービスはバスで公開されたイベントを使用して相互作用すると述べました-このアプローチは「振り付け」と呼ばれ ます（これについては以下で詳しく説明します）。同社は、これが結束を減らすという観点から最適であると考えています。しかし、彼らは問題に直面しました。システムで何が起こっているのかを理解することは困難であり、それを変更することはさらに困難です。 「」 これは、マイクロサービスのプレゼンテーションで見られる振り付けのダンスではありません。これは、制御できないポゴジャンプです。「



これはすべて、他のクライアントが私に言ったことと調和しています。たとえば、 CreditSenseのJoshWolf：「私たちが置き換えるシステムは、理解するためにいくつかのコードベースの分析を必要とする複雑なピアツーピアの振り付けを使用します。」





簡単な例を使用して、この状況を理解しましょう。注文処理アプリケーションを作成しているとしましょう。イベント駆動型アーキテクチャを使用することを選択し、たとえば、イベントバスとしてApacheKafkaを選択しました。誰かが注文すると、チェックアウトサービスは、支払いサービスによってピックアップされるイベントを生成します。この支払いサービスはお金を受け取り、在庫サービスによってピックアップされるイベントを生成します。





イベントの振り付けストリーム。



このアプローチの利点は、システムに新しいコンポーネントを簡単に追加できることです。顧客にメールを送信する通知サービスを作成するとします。システムの他の部分に触れることなく、新しいサービスを追加して適切なイベントにサブスクライブするだけです。また、GDPR（EUデータ保護規制）の要件を満たすインタラクション設定と通知の複雑さを一元管理できるようになりました 。





このスタイルのアーキテクチャは、オーケストレーターが他のコンポーネントに何をすべきかを指示する必要がないため、コレオグラフィーと呼ばれます。ここで、各コンポーネントは、他のコンポーネントが反応できるイベントを生成します。このスタイルは、通知サービスの概要に当てはまるように、コンポーネント間の結合を減らし、システムの設計と変更を容易にすることになっています。

イベントの流れにおける透明性の喪失

このアーキテクチャの議論に参加するときに最も頻繁に出てくる質問に焦点を当てたいと思います。「イベントの流れの透明性（そしておそらく制御）を失うことを回避する方法は？」で ある研究、（私は仕事）Camundaはmicroservicesの使用について尋ねました。回答者の92％は少なくともそれらを検討しており、64％はすでに何らかの形でそれらを使用しています。これはもはや誇大広告ではありません。しかし、その調査では、問題についても質問し、懸念事項を明確に確認しました。ほとんどの場合、複数のサービスに関連するビジネスプロセスのエンドツーエンドの透明性が失われていると言われました。





複数のデータベーストリガーに基づくアーキテクチャを覚えていますか？何らかのアクションに応答して何が正確に発生するのか、そしてなぜこれが発生するのかがわからないアーキテクチャ。このような比較は明らかに不適切ですが、リアクティブマイクロサービスに関連する問題によってこれを思い出すことがあります。

透明性の確保

そのような状況で何ができるでしょうか？次のアプローチは透明性を取り戻すのに役立ちますが、それぞれに長所と短所があります。

1. 分散トレース（ZipkinやJaegerなど）。
2. データレイクまたは分析ツール（Elasticなど）。
3. プロセスマイニングの制御と分析（例：ProM）。
4. タスクフロー自動化（Camundaなど）を使用した追跡。

これらのアプローチはすべて、実行中のシステムを監視し、その中のデータフローを調べる必要があることに注意してください。有用な情報を抽出できる静的分析ツールを知りません。

分散トレース

このアプローチは、異なるシステムおよびサービス間のコールスタックを監視します。このために、一意の識別子が使用され、通常は特定のヘッダーに追加されます（たとえば、HTTPまたはメッセージヘッダー）。システム内の全員がこれらのヘッダーを理解しているか、少なくとも中継している場合は、サービス間の要求の交換を追跡できます。





通常、分散トレースは、要求がシステム内でどのように流れているかを理解し、障害が発生している場所を見つけ、パフォーマンス低下の原因を調査するために使用されます。このアプローチの利点には、ツールキットの成熟度とそれに伴う生きたエコシステムが含まれます。したがって、通常は（おそらく積極的に）アプリケーションやコンテナに指示する必要がある場合でも、分散トレースの使用を開始するのは比較的簡単です。



では、このアプローチを使用して、ビジネスプロセスがイベントを生成する方法を理解してみませんか？通常、これには2つの理由があります。

• . , , . . , -.
• . , , 90 % . Three Pillars with Zero Answers — towards a New Scorecard for Observability. .

したがって、それ自体では、トレースは私たちにはほとんど適していません。同様のアプローチに目を向けることは論理的ですが、私たちの特定のタスクを考慮に入れます。これは通常、トレースではなく、すでに遭遇した可能性のある重要なビジネスイベントまたはテーマイベントを収集することを意味します。多くの場合、ソリューションは、すべてのイベントをリッスンしてデータベースに保存するサービスを作成することになります。これにより、システムの負荷が増大する可能性があります。今日、多くの人がこれにElasticを使用しています。





これは、比較的簡単に実装できる強力なメカニズムです。そして、それは私たちのイベント主導のクライアントのほとんどによってすでに実装されています。実装の主な障害は、通常、大規模な組織の誰がそのようなツールを管理するかという問題になります。これは、ツールを一元的に管理する必要があるためです。このメカニズムを操作するための独自のユーザーインターフェイスを簡単に作成できるため、特定のクエリに関連する情報をすばやく見つけることができます。





イベント監視インターフェイスの例。



欠点には、イベントのリストを操作しやすくするグラフがないことが含まれます。ただし、イベントをBPMNなどのレンダラーに投影するなどして、インフラストラクチャに追加できます。 bpmn.ioのような小さなフレームワークを使用すると、Kibanaプラグインにパッケージ化できる単純なHTMLページ（例）として表示される図に情報を追加 できます。





このモデルは、ビジネスプロセス管理モジュールでは実行できません。ログに記録されたイベントを視覚化するために使用される単なる図です。この観点から、表示の詳細を選択する際に一定の自由があります。また、全体像に特に関心がある場合は、さまざまなマイクロサービスからのイベントを1つの図に表示するモデルを作成できます。このような図は、個々のサービスに変更を加えることを妨げるものではないため、会社の柔軟性に影響を与えることはありません。ただし、オペレーティングシステムの現在の状態と比較して、図が陳腐化するリスクがあります。

プロセスマイニングツール

前のアプローチでは、レンダリングに使用するダイアグラムを明示的にモデル化する必要がありました。しかし、イベントの流れの性質を事前に知ることができない場合は、最初にそれを調査する必要があります。



これは、プロセスを監視および分析するためのツールを使用して実行できます。完全な図を作成してグラフィカルに表示できるため、特にシステムのボトルネックや潜在的な最適化に関連する詳細を調べることができます。





私たちの問題に対する完璧な解決策のように聞こえます。残念ながら、このようなツールはレガシーアーキテクチャのプロセスを調査するために最も頻繁に使用されるため、ログの分析に重点を置き、イベントのライブストリームを平凡に処理します。もう1つの欠点は、それらが純粋に科学的なツールであり、使用が難しい（ProMなど）か、非常に重い（Celonisなど）ことです。私の経験では、これらのタイプのツールを一般的なマイクロサービスの取り組みで使用することは実用的ではありません。





いずれにせよ、プロセス探索とデータ分析は、イベントストリームとビジネスプロセスの可視性を提供するための興味深い可能性をもたらします。同様の機能を備えたテクノロジーが間もなく登場することを願っていますが、より軽量で、開発者にとって使いやすく、実装が簡単です。

タスクフローの自動化による追跡

もう1つの興味深いアプローチは、タスクフローをモデル化し、制御モジュールを介してそれらを展開および実行することです。このモデルは、イベントを追跡するだけで、積極的に何もしないという意味で特別です。つまり、何も管理せず、登録するだけです。これについては、Apache KafkaとオープンソースのZeebeワークフローモジュールを使用 して、 Kafka Summit San Francisco2018で 説明しました。





この機会は特に興味深いものです。制御モジュールの分野には多くの革新があり、コンパクトで開発が容易で、高度にスケーラブルなツールの出現につながります。これについては、 イベント、フロー、および長時間実行サービス：ワークフロー自動化への最新のアプローチで説明しました。明らかな欠点には、タスクフローの予備モデリングの必要性が含まれます。ただし、一方で、このモデルは、イベントモニタリングとは対照的に、プロセス制御モジュールを使用して実行できます。基本的に、インバウンドイベントのプロセスインスタンスを開始するか、イベントをインスタンスにマップします。また、現実がモデルと一致するかどうかを確認することもできます。



さらに、このアプローチは、タスクフロー自動化プラットフォームによって提供されるツールチェーン全体を活用します。システムの実際の状態を確認したり、SLAを追跡したり、プロセスインスタンスの障害を検出したり、履歴監査データの徹底的な分析を実行したりできます。





タスクフローの監視の例。



このアプローチをクライアントでテストしたところ、セットアップは簡単でした。バスからイベントを受信する汎用コンポーネントをまとめて、タスクフロー制御モジュールと照合しました。イベントを調整できなかった場合は、小さな決定テーブルを使用して、それを無視できるかどうか、またはイベントが後で調査する必要のあるインシデントにつながるかどうかを判断しました。また、マイクロサービス内で使用されるタスクフロー制御モジュールを改善して ビジネスロジックを実行し、全体像の一部となる特定のイベント（たとえば、プロセスインスタンスの開始、完了、またはある段階の完了）を生成するようにしました。



これはすべてイベント監視に似ていますが、ビジネスプロセスに重点が置かれています。トレースとは異なり、このアプローチはすべてのビジネスイベントをキャプチャし、さまざまな利害関係者に適したさまざまな形式で全体像を表示します。

ビジネスの見通し

監視用のビジネスプロセスが利用できるため、コンテキストを理解できます。特定のインスタンスについて、それがどのように、いつ、どのような状態で終了したかを確認できます。これは、このプロセスがたどらなかった（そして他の人がたどることが多い）パスと、特定の決定につながったイベントまたはデータを理解できることを意味します。また、近い将来に何が起こるかを理解することができます。他のタイプの監視ではこれは許可されていません。今日、ビジネスとITの間の一貫性の問題について議論することは一般的ではありませんが、専門家以外の人もビジネスプロセスと、イベントがさまざまなマイクロサービスをどのように通過するかを理解することが不可欠です。

追跡から管理まで

プロセス追跡は、運用の監視、レポート、KPI、および透過性を提供するための優れたツールです。これらはすべて、会社の柔軟性を維持する上で重要な要素です。しかし、現在のプロジェクトでは、追跡はマイクロサービスエコシステムのより深い管理とオーケストレーションに向けた最初のステップにすぎません。



たとえば、エンドツーエンドのプロセスのタイムアウトを監視することから始めることができます。タイムアウトが発生すると、アクションが自動的に実行されます。以下の例では、14日後に遅延についてクライアントに通知しますが、それでも待機します。そして21日後に注文をキャンセルします。





不思議なことに、ここで注文をキャンセルするためにチームを送ることは、しばしば物議を醸す方法で議論されるオーケストレーションです。

オーケストレーション

オーケストレーションは、一貫性をもたらしたり、個々のマイクロサービスの自律性を混乱させたりするため、避けるべきだとよく耳にします。もちろん、それは不十分に実装される可能性があります。しかし、マイクロサービスの原則と一致し、ビジネスに大きな価値をもたらす方法でオーケストレーションを実装することも可能です。これについては、InfoQ New York2018で詳しく話しました 。



私にとって、オーケストレーションとは、あるサービスが別のサービスに何かをするように指示できることを意味します。そしてそれがすべてです。これは密接な接続ではなく、別の種類の接続です。注文のある例を思い出してみましょう。キャッシュレジスターサービスでは、誰が処理するかわからないまま、注文を生成してイベントバスに入れることをお勧めします。注文サービスは、表示された注文に関するイベントをピックアップします。受信者はイベントについて学習し、それについて何かをすることにします。つまり、受信側に凝集が存在します。



支払いの場合、支払いが何のために受け取られたかを支払いサービスが知っているかどうかはかなり奇妙であるため、状況は異なります。しかし、彼は注文や注文などの適切なイベントに対応するためにこの知識が必要になります。また、新しい製品やサービスの支払いを受け取るたびに、サービスを変更する必要があることも意味します。多くのプロジェクトでは、この不快な接続は必要な支払いイベントを生成することによってバイパスされますが、送信者が誰かにそれについて何かをしてほしいので、これらはイベントではありません。これはチームです！注文サービスは、支払いサービスにお金を受け取るように命令します。この場合、送信者はどのコマンドを送信するかを知っており、そうします。つまり、送信者側に結束が存在します。



2つのサービス間のすべての相互作用が効果的であるためには、ある程度の結合を意味します。ただし、特定のタスクによっては、一方の側に接続を実装することをお勧めします。





注文サービスは、オーケストレーションやその他のサービスを担当し、注文処理の段階を追跡することもできます。このアプローチの利点については、上記の講演で詳しく説明しました。秘訣は、優れたアーキテクチャにはオーケストレーションと振り付けのバランスを取る必要があるということですが、これは必ずしも簡単ではありません。



ただし、この記事では、透明性に焦点を当てたいと思いました。また、タスクフローモジュールを使用したオーケストレーションには明らかな利点があります。モデルは、オーケストレーターが実行するための単なるコードではなく、フローの透過性を提供するために使用できます。

結論

実装に関係なく、ビジネスプロセスの透明性を確保することは非常に重要です。私はさまざまなアプローチを検討しましたが、実際のプロジェクトでは、通常、Elasticなどのツールを使用したある種のイベント監視、または制御モジュールを使用したプロセスの追跡にすべてが行き着きます。部分的には、選択は特定のケースと関係する人々の役割に依存するかもしれません。たとえば、ビジネスアナリストは、すべてのプロセスインスタンスから収集されたデータを必要な詳細度で理解する必要がありますが、運用担当者は、特定のプロセスをさまざまな詳細度で分析し、おそらくシステムレベルでインシデントを迅速に解決するためのツールを取得する必要があります。



プロジェクトが振り付けに大きく依存している場合は、プロセスの追跡によってオーケストレーションを追加できます。そして、これはあなたのビジネスプロセスを長期的に管理する上で非常に重要なステップだと思います。そうでなければ、「イベントとプロセスの数が増えるにつれて透明性が失われることに気付かずに、慎重に分離されたイベント駆動型システムを作成し、それによって今後数年間で問題を確実にすることができます」と マーティン・ファウラーは述べています。まったく新しいシステムに取り組んでいる場合は、最初からオーケストレーションと振り付けのバランスを見つけてください。



ただし、システムの実装の詳細に関係なく、相互作用するサービスを使用して実装されたビジネスプロセスのわかりやすい表示をビジネスに提供するようにしてください。