Apache Kafkaは、マイクロサービスを基盤とするシステム内でのメッセージやイベントの配信によく使用される、スケーラビリティの高い分散ストリーミングプラットフォームである。これらのイベントは、複数のマイクロサービスに分散したビジネスプロセスの一部の場合もある。複雑なビジネスプロセスの処理には、ワークフローエンジンが使用できるが、Kafkaとマッチするためには、kafkaと同程度のスケーラビリティを提供できることが必要となる。Zeebeは、このようなスケーラビリティ要件を満たすべく、設計と開発が進められているワークフローエンジンである。アムステルダムで行われた合同ミーティングではKai Waehner氏が、Kafkaの特徴と、イベント駆動型アーキテクチャ(EDA)への適合性について説明した。また、Bernd Rücker氏は、ワークフローエンジンであるZeebeと、それをKafkaと併用する方法について述べた。
ConfluentのテクノロジエバンジェリストであるWaehner氏は、現在Kafkaが広く採用されている理由として、統合されるアプリケーションやマイクロサービス、モバイルアプリやIoTデバイスの数が増え続けていることと、それに伴って、ますます多くのデータが提供されるようになっていることを挙げた。我々は以前よりも多くのメッセージを、以前よりも高速に、時にはリアルタイムのユースケースで処理しなければならない。この取り組みは何年も前に、ポイント・ツー・ポイント統合の構築によって始まったが、その方法はスケーラビリティに乏しく、メンテナンスも困難だった。10年ほど前から、統合手段としてエンタープライズサービスバス(ESB)が使用されるようになり、さらに今日では、すべてのアプリケーションを接続する、Kafkaなどのメッセージストリーミングプラットフォームに置き換えられている。
EDAは新しい考え方ではない。その概念は、少なくとも10～20年前には存在していた。新しいのは、データを処理する方法だ。データベースに格納したデータを他のサービスが読み取って処理する、という方法ではなく、現在ではデータが流れて、継続的な処理が行われる。イベントストリーミングプラットフォームの重要な差別化要因は、SQLやNoSQLデータベースのような静的ストアを使用しないことだ。その代わりに、イベントやその他のメッセージが保存される。これはアプリケーションの構築方法にも影響する。現在では、イベントがパブリッシュされ、他のアプリケーションによってコンシュームされている。
Kafkaには3つの概念がある、とWaehner氏は指摘する。メッセージング、データ保存、データ処理である。それは他の多くのブローカのようなメッセージングブローカであり、望む限りデータを保存できるストレージシステムであり、最終的に実行可能なデータ処理だ。Kafkaとデータベースに共通する重要な機能は、次の２つである。
- メッセージの厳密な順序付け。これは多くのユースケースにおいて非常に重要である。
- 永続性。メッセージはすべてディスクに保存されるので、クラッシュしてもデータを失うことはない。
Kafkaでもうひとつ重要な点は、分散を前提に設計され、障害を考慮して構築されていることだ。その中心をなすのは、レプリケーション、フォールトトレランス、パーティショニング、エラスティックスケーリングなどの概念である。
Waehner氏の見解によると、多くの開発者は、Kafkaを単なるメッセージングプラットフォームとして見なしている。それに対して氏は、さらに２つのコンポーネントが含まれていることを指摘する。
- Kafka Connect – Kafkaのコア上に構築された統合フレームワーク。コネクタの例には、多数のデータベースとメッセージングシステムが含まれる。
- Kafka Streams – ストリーム処理を目的とする。Waehner氏はこれを、最も簡単なデータ処理の方法だと考えている。
Waehner氏は、Kafkaをコアビジネスアプリケーション構築に使用する事例がますます増えていることから、Kafkaがビジネスとして成立していることを指摘し、自身の講演の結論とした。ビジネスの分析は依然として重要だが、それはごく一部に過ぎない。氏が目の当たりにするもうひとつのトレンドは、顧客の大部分がハイブリッドであるということだ。新たなシステムはクラウド内に構築されるが、オンプレミスにもシステムが残っており、それらすべてが相互に通信する必要がある。
Bernd Rücker氏
Camundaの共同創設者でデベロッパ・アドボケートのRücker氏は、ここ数年間、氏の顧客の間にマイクロサービス採用の明らかなトレンドがあることを実感している。さらに氏は、一部のユーザがイベント駆動型のアプローチの導入を始めて、現在では全面的に採用している、という点にも注目している。
イベント通知パターンを使用したシステムが、ビジネスのさまざまな部分を担当するマイクロサービスで構築されているのだ。これらのサービスは、発生した事象を他のサービスに通知するために、イベントを発行する。ビジネス機能を実現する上で、いくつかのサービスが関与して、相互にイベントを送信する場合もある。Rücker氏はこれを"ピアツーピアのイベントチェーン"と呼び、その問題点のひとつとして、ビジネスの観点から全体的な流れを把握することが困難である点を指摘する。さらに氏は、イベント通知パターンは場合によっては有用だが、より大規模なフローを見失う危険性を伴うという点について指摘した、Martin Fowler氏の記事にも言及している。
イベントの流れを把握するためのアプローチのひとつは、モニタリングとトレースを活用することだ。Rücker氏はInfoQの記事で、これをどのように行うことができるか、実例を挙げて説明している。氏が推奨するのはプロセス追跡の方法である。ワークフローをモデル化し、全イベントを監視するワークフローエンジンを使用することで、各イベントフローが正しく機能していることをビジネスの観点から確認すると同時に、障害発生時には通知を代理で受け取ることが可能になる。
プロセストラッキングは何も変更する必要がなく、適用が簡単だ、とRücker氏は述べている。単にワークフローエンジンを、Kafkaインフラストラクチャに接続すればよい。同時にこれは、例えばプロセス終了に時間がかかり過ぎている場合にタイムアウトや警告を追加するなど、潜在的な障害に対処するための最初のステップにもなる。プレゼンテーションでは、Vodafoneが既存ミドルウェアのリプレースを実施するにあたって、最初にトラッキングを導入し、その後すべてのタスクをステップバイステップでオーケストレーションに置き換えていった実例が紹介された。
ピアツーピアのイベントチェーンでの潜在的な問題は、ワークフローを変更する必要がある時だ。このような場合には、いくつかのサービスに、自身のイベントサブスクリプションを変更する必要性が発生する可能性がある。さらにはチーム間やサービスのデプロイメントの調整，あるいは実行中のワークフローとシステム内のアクティブなイベントに関する考慮も必要になる。ビジネスプロセスが確実に遂行されるようにするために、Rücker氏は、エンドツーエンドの責任をひとつのサービスとして抽出する方法を好んで採用している。メリットは、企業にとって非常に重要なことの責任をひとつのサービスが負うことと、タスクのシーケンスを制御する単一ポイントが存在することだ。さらには、ワークフローを制御するためのコマンドも使用できるようになる。何かをするように指示するという意味において、コマンドはオーケストレーションに他ならない。しかしRücker氏は、オーケストレーションはマイクロサービスの内部であって、すべてのサービスが使う中核的インフラストラクチャメカニズムではない、と指摘する。さらに氏は、ひとつのサービスがワークフローを担当することにより、実行中の要求の状態や、成功した要求の数などを確認する単一のポイントが存在する、という点も指摘している。
Camundaは現在、水平スケーラビリティを備えたマイクロサービス用のワークフローエンジンであるZeebeの開発に取り組んでいる。これは、Kafkaと組み合わせることで、低レイテンシかつ高スループットのユースケースに適している。現在はまだ開発者向けプレビューの状態だが、毎秒10～20万のワークフローインスタンスを実行中のパイロットユーザがある。Rücker氏によると、実運用対応バージョンは2019年7月に予定されている。
プレゼンテーションで使用されたWahner氏のスライドとRücker氏のスライドは、いずれも公開されている。
InfoQとのインタビューの中で、Rücker氏は、企業にとって非常に重要な受注処理がコアドメインで処理されないというのは奇妙な話であって、イベントの監視によって処理の滞りを検出可能であるべきだ、と述べている。注処理サービスは、注文発生時にイベントを発行して、他のサービスが支払い処理や顧客への商品配達を行ってくれることを単に期待するのではなく、注文の履行という観点での考慮が必要である、というのが氏の考えだ。
我々はイベントストリームをよく話題にするが、レコードあるいはメッセージストリームを語ることが重要だ、とRücker氏は考えている。Kafka APIで使用されている用語はイベントではなく、レコードなのだ。Kafkaはイベントやコマンドなど、さまざまな種類のメッセージに使用することができる、として氏は、Gregor Hohpe氏とBobby Woolf氏によって著されたセミナブックである"Enterprise Integration Patterns"を紹介している。同署ではCommandやDocument、Eventといったメッセージが解説されている。