Knative と Zeebe を使用して CloudEvents をオーケストレーション ¶

公開日: 2020-10-14 , 改訂日: 2024-01-17

Knative と Zeebe を使用して CloudEvents をオーケストレーション¶

作成者: マウリシオ・サラティーノ (サラボーイ)、Camunda のシニアソフトウェアエンジニアおよび LearnK8s 講師

数週間前、Knative Meetup (動画、スライド) ですでに CloudEvents を使用しているアプリケーションを理解、強化、オーケストレーションするために、クラウドネイティブワークフローエンジン Zeebe をどのように活用できるかについて発表しました。

これらのツールが、分散アプリケーションの動作をより深く理解するのに役立つ方法についてもう少し詳しく説明したいと思います。

デモアプリケーション、インストール手順、アプリケーションとツールの動作を示す動画は GitHub で見ることができます。

私が構築したアプリケーションは、CloudEvents を使用して通信し、アプリケーションの標準的な（ハッピーパス）フローである「コンサートチケットの購入」を実行する 4 つのマイクロサービスで構成されています。各サービスは、他のサービスとメッセージを交換するために Knative Eventing を使用する Knative Service として実行されます。

Knative Application

このアプリケーションは Knative Eventing に大きく依存しています。すべてのサービスがイベントをブローカーに送信し、関心のあるイベントに Knative トリガー（サブスクリプション）を登録するためです。

Web サイトでチケットを購入したいユーザーごとに、アプリケーションから次のイベントが送信されます。

Application Events

このクラウドネイティブアプリケーションは WebSocket を使用することに注意してください。これは、スケーリングを検討すると複雑さが増します。

OpenTracing などのトレーシングや中央集中型ロギングシステムを使用していても、イベント駆動のアプリケーションで何が起こっているのかを把握するのは非常に厄介です。たとえば、同時にチケットを購入しようとしている顧客が 10 人だけいるとします。各顧客のプロセス内のどこにいるか、または潜在的なボトルネックがどこであるかを理解することは困難です。

この時点までは、ただ通常の Knative アプリケーションに過ぎず、CloudEvents をネイティブにサポートする Knative Eventing を使用しているため、次のセクションで説明するとおり、エコシステムにさらに多くのツールを統合できます。

可視化 / 理解¶

アプリケーションコードまたはセットアップ内部の何も変更せずに、イベントストリームにタップして顧客ジャーニーにとって意味のあるイベントをマッピングし、Zeebe と Camunda Operate を使用して可視化できます。

Knative and Zeebe

アプリケーションで送信されるイベントを使用してステータスをレポートするワークフローモデルを作成することから簡単に開始できます。次のモデルに示すように

Workflow model v1

このシンプルなワークフローモデルはアプリケーションイベントを待機し、各イベントが到着するとフローを先へ進めます。はい、お分かりのように、これは **CloudEvents** と連携して動作します。

チケットの購入のためにキューに参加する顧客ごとに、それらを追跡するための新しいワークフローインスタンスが作成されます。このようなインスタンスを活用することで、個々の顧客を追跡し、特定の時点で各顧客がどこに位置しているのかを迅速に把握できます。

workflow model instances

Zeebe には Camunda Operate が付属しており、これによりこの情報をほぼリアルタイムで確認できます。ワークフローの実行とそれに関連付けられたデータの監査証跡を詳細に把握できます。

Operate UI

装飾 / 強化¶

ワークフローエンジンの力を備えたので、その機能の一部を活用してアプリケーションを装飾または強化できます。強化されたバージョンのワークフローモデルは次のようになります

Workflow model v2

現在、顧客が **支払い送信** 状態に達すると、顧客がすでに予約したことを意味し、モデルは **支払い送信** CloudEvent が到着するのを待機します。

timers

上記のように、**支払い送信** 状態に 2 つのタイマー境界イベントが関連付けられています。破線のついた下部のイベントは非割り込みイベントで、実際の流れを中断せず、ファイアアンドフォーゲット方式でのみトリガーされます。これにより支払いリマインダーが送信され、繰り返しのタイマーとして構成できるため、一定時間ごとにトリガーされます（プレゼンテーションでは 10 秒に設定されました）。

Websockets push notification

上記の画像は、ワークフローエンジンによって生成され、Web サイトバックエンドにルーティングされ、WebSockets を使用して顧客のブラウザにある Web サイトフロントエンドに転送された通知をフロントエンドに表示しています。

実線の入った上部は割り込みイベントで、モデルの通常の流れを破棄し、タイマーから定義されたステップ（この場合は **予約期限切れ**）のみに進むことになります。このシナリオでは、割り込みタイマーはチケットの予約後にある一定時間後にトリガーされるように設定されます（プレゼンテーションでは 2 分に設定されました）。予約がタイムアウトすると、Web サイトは顧客を最初にリダイレクトします。

どちらのタイマーについても、完全なトレーサビリティが得られます（たとえば、いつ、どのくらいの頻度でトリガーされたかなど）。これらの詳細は**Operate**でグラフィカルに確認できます。

Workflow model v2 in Operate

非割り込みタイマーが数回トリガーされ、フロントエンドで支払いリマインダーを生成していることがわかります。フロントエンド通知を実装しなくても、これらのタイマーを使用して、顧客が実際に支払いを行うまでにかかる時間を測定して分類できます。これは、さまざまなカテゴリを分類するのに非常に役立ちます。たとえば、人々が支払い情報を提供するのに平均してどのくらいの時間がかかるかなどです。

これらのタイマーとCronjobs (Kubernetes の場合など)の大きな違いは、これらのタイマーは関連付けられている状態に文脈依存的であることです。つまり、Payment Sent の CloudEvent が受信されると、両方のタイマーが自動的にキャンセルされ、ガーベッジコレクションされます。この特定のシナリオでは、支払いの通知を送信するようにしていますが、支払いが送信された場合に予約がタイムアウトしないようにする必要もあります。ワークフローエンジンは、アプリケーションの一部として時間ベースのイベントを登録したいユーザーにとって、非常に一般的な要件を透過的に処理します。

オーケストレーション¶

上で示したモデルに示されているPayment ReminderとReservation Time Outの状態は、単にイベントをリッスンすることから、実際にワークフローモデルから CloudEvents をエミットする境界を超える時点を表します。現在ワークフローモデルは、クラウドネイティブアプリケーションが何をしているかを視覚化して理解するだけでなく、サービスと連携して制御しているだけです。

ワークフローエンジンを使用して CloudEvents をオーケストレーションすると、より複雑なシナリオに対処するためのさまざまな新しいツールを使用できます。

ワークフローモデルのバージョン 3 は、subprocess を使用して一連の状態を一緒にグループ化できるより複雑なダイアグラムを示しています。そうすることで、ワークフロー内のステージを簡単に特定し、タイマーやメッセージイベントなどのこれらのステージのイベントを登録できます。

Workflow Model V3

ワークフローは、Customer Buying Tickets ステージのいつでも CloudEvent Customer Abandoned Queue で反応できます。これにより、Customer Clean Up イベントがトリガーされ、データをキャッシュしているすべてのサービスから顧客セッションに関連するすべてのデータをガーベッジコレクションします。

次のスクリーンショットでは、Camunda Operate 内ですべてのワークフローのインスタンスの数が特定のステージにあることと、完了したワークフローの数をその完了した状態を示すことをすばやく視覚化できます。

Workflow Model V3 in Operate

ワークフローエンジンを使用するもう 1 つの利点は、フロー制御です。排他的ゲートウェイなどのフロー制御要素を使用すると、いくつかの高レベルの決定 (通常ビジネスロジックをエンコードする) をワークフローエンジンに委任できます。

Workfloe Model V4

上記のモデルにあるように、排他的ゲートウェイは条件に基づいて 2 つの異なるパスから選択するために使用されています。この場合、条件は顧客が予約するチケットの数を評価しており、それに基づいてモデルは通常のクレジットカード支払いまたはより複雑な送金方法から選択しています。

アーキテクチャと次のステップ¶

アーキテクチャの観点から、ワークフローエンジンと Knative の統合は非常にシンプルです。これはCloudEventsとそのイベントを正しいワークフローにルーティングする責任を持つコンポーネントと、その逆に依存します。

Zeebe CloudEvents ルーターは、イベントを転送できるエンドポイントを公開し、同時にワークフローモデルからイベントをプッシュする場所を理解する役割を担っています。

Knative and Zeebe Detailed

上の図のように、Zeebe CloudEvents ルーターは単独ではありません。Zeebe Operatorは、リモートワークフローエンジンにプロビジョニングまたは接続する責任を負い、ワークフローの定義をデプロイして管理する機能があります。つまり、ワークフローモデルがクラウドイベントをエミットするか使用するかを解析して理解でき、その情報はKnative チャンネルを動的にプロビジョニングしてKnative トリガーを作成するために使用できます。各モデルについては、Knative のフロー (シーケンスと並列)で行われているように、

たとえば、ワークフローモデルのバージョン 1 の場合

Workflow Model V1

次の Knative トリガーが作成されます

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: router-queue-join-trigger
  namespace: default
spec:
  broker: default
  filter:
    attributes:
      type: Queue.CustomerJoined
  subscriber:
    uri: http://zeebe-cloud-events-router.default.svc.cluster.local/message

---
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: router-queue-exit-trigger
  namespace: default
spec:
  broker: default
  filter:
    attributes:
      type: Queue.CustomerExited
  subscriber:
    uri: http://zeebe-cloud-events-router.default.svc.cluster.local/message

---
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: router-tickets-reserved-trigger
  namespace: default
spec:
  broker: default
  filter:
    attributes:
      type: Tickets.Reserved
  subscriber:
    uri: http://zeebe-cloud-events-router.default.svc.cluster.local/message

---
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: router-tickets-payment-sent-trigger
  namespace: default
spec:
  broker: default
  filter:
    attributes:
      type: Tickets.PaymentSent
  subscriber:
    uri: http://zeebe-cloud-events-router.default.svc.cluster.local/message

---
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: router-tickets-payment-authorized-trigger
  namespace: default
spec:
  broker: default
  filter:
    attributes:
      type: Tickets.PaymentsAuthorized
  subscriber:
    uri: http://zeebe-cloud-events-router.default.svc.cluster.local/message

前に述べたように、さらなる統合により、メッセージングレイヤーでより高度なトポロジーに対処する必要があります。たとえば、ワークフローモデルを論理的にグループ化して、専用のKnativeチャンネルとZeebe CloudEventsルーターを使用できるようになります。今後のリリースでは、ZeebeオペレーターはKnativeとCloudEventsの統合の提供と管理のためにCloudEventsルーターを認識します。

まとめ¶

このブログ記事では、Zeebeのようなワークフローエンジンを使用してKnativeアプリケーションの上で実行できる驚くべき機能について説明します。提供される抽象化により、さまざまなクラウドプロバイダーに簡単に移動でき、サービスを変更することなく非常に堅牢なアプリケーションを構築できたため、Knativeを使用している間は個人的に非常に楽しく感じました。このデモをライブでご覧ください。{{< youtube msDDdqmyEFA >}}このブログ記事で紹介されているプロジェクトと統合は活発に開発されていますので、興味がある場合や関わりたい場合は、Twitterを介してご連絡ください。@salaboyまたは私たちのSlackチャネルに参加してください。zeebe-io.slack.com

このデモを独自のKubernetesクラスタで実行したい場合は、こちらで手順を確認できます。https://github.com/salaboy/orchestrating-cloud-events/リポジトリにスターを付けたい場合は、感謝します :)