イベント駆動型アーキテクチャ (EDA) により、企業は、起きていることすべてをリアルタイムで認識する力を高めることができます。

事業運営が大規模なデジタル・フットプリントを残す現代の企業では、ビジネス・イベントにより企業は適応力を高め、機会や脅威が発生したときに対応できるようになります。サプライチェーンを最適化し、顧客が喜ぶパーソナライズされたエクスペリエンスを提供し、品質問題を積極的に特定し、顧客離れを未然に防ぐことができます。

その結果、イベント駆動型に移行している組織は、競合他社との差別化を深め、最終的には売上高と純利益に影響を与えることができます。

企業は通常、いくつかの成熟段階を経て、EDAを確立していきます。

第 1 段階—戦術およびプロジェクトベース

まず、その可能性は個々のチームが提供する戦術的なプロジェクトで実証されます。多くの場合、オープン・テクノロジーとして、またさまざまなコア・システムやアプリケーションからイベントにアクセスするための事実上の標準として、Apache Kafkaを使用しています。このアプローチにより、新しい応答性の高いアプリケーションを構築することができます。

第 2 段階—より広範な導入

IT組織全体でアウェアネスが向上すると、複数のチームにわたる既存および新規のイベント駆動型プロジェクトの両方に対応するイベント・バックボーンを作成するための標準化された方法への移行が進みます。このアプローチにより運用効率が向上し、重要なオペレーションをサポートするのに十分な回復力とで拡張性を備えたソリューションを構築できます。

第 3 段階—共有と管理

導入件数の増加に伴い、イベントの共有と公開の管理を改善する必要性が高まります。チームは、他の人が作業した内容を再利用したり革新したりできるように、イベントへの可視性とアクセスを高めることを望みます。イベントの重要度は、イベントを記述、宣伝、検出するための設備として、アプリケーション・プログラミング・インターフェース（API）と同等にまで高まっています。セルフサービスへのアクセスは、承認のボトルネックを防ぐために提供されるとともに、設備が使用状況を適切に管理するために提供されます。

第 4 段階 – 変革的なビジネス戦略

より幅広いユーザーがイベントストリームにアクセスし、処理できるようになり、ビジネス上の文脈でその重要性を理解できるようになります。イベントのトピックを組み合わせてパターンや集計を特定し、傾向を分析して異常を検知することができます。イベント・トリガーを使用すると、ワークフローや意思決定を自動化でき、企業は通知を生成できるため、状況が検知されると同様迅速に適切な措置を講じることができます。

IBM は、このイベント主導型の導入ジャーニーのどの段階にあっても構成可能な一連の機能を作成しました。最高のオープンソース・テクノロジーをベースに構築された各機能は拡張性を重視し、接続、分析、処理などの柔軟性とエコシステム全体との互換性を考慮して設計されています。ゼロから始める場合でも、次のステップに進みたいと考えている場合でも、IBMは既存のものを拡張して価値を高めるお手伝いをします。

イベント・バックボーンは、ビジネス・イベントを必要な場所で効率的に利用できるようにするイベント駆動型企業の中核です。IBMは、企業全体にわたってイベントを管理できるようにするApache Kafka上に構築されたEvent Streams機能を提供しています。Kafkaベースのインフラストラクチャーがすでにデプロイされている場合、Event Streamsはハイブリッド・ブローカー環境の一部としてイベントとシームレスに相互運用できます。

Kubernetesベースのコンテナ・オーケストレーション・プラットフォームの一部として演算子を使用することで、コードとしてのインフラストラクチャのデプロイメントを可能にし、Apache Kafkaデプロイメントの多くのコンポーネントを一貫性のある反復可能な方法で構築および操作します。Kafkaクラスターは、完全な暗号化とアクセス制御により、需要に応じて自動的に拡張できます。柔軟でカスタマイズ可能なKafka構成は、シンプルなユーザー・インターフェイスを使用することで自動化できます。

これには、アプリケーションからのイベント・データを期待どおりに検証し、データ品質を向上させ、エラーを削減するためのスキーマ・レジストリーが組み込まれています。イベント・スキーマは、共同作業するチーム間で合意された形式を確立することで統合の複雑さを軽減するのに役立ち、Event Streamsはイベント駆動型の導入が加速する中でスキーマの進化と適応性を可能にします。

Event Streamsは、複数のゾーンにまたがるクラスター間でイベントデータの複製をサポートすることで、インフラがサービスの可用性を失うことなくゾーンの障害を許容できるような、回復力と可用性の高いイベントバックボーンを確立します。災害復旧に関しては、Geoレプリケーションの主要な機能を使い、イベントデータの複製を作成してバックアップクラスターに送信することができます。ユーザーインターフェースを通し、数回のクリックでこれを構成できるようになります。

イベント・バックボーンの質は、アクセスできるイベント・データによって決まります。Event Streams は、イベントデータが生成または消費される主要なアプリケーション、システム、プラットフォームへの幅広いコネクタをサポートしています。コネクタ・カタログには、IBMとコミュニティがサポートする主要なコネクタの広範なリストが含まれています。

これらすべての機能をまとめているのが包括的な管理インターフェイスであり、これはKafka環境とそれに接続されたアプリケーションのスムーズな監視と運用を可能にします。これには、システム全体の正常性だけでなく、個々のイベント・ペイロード、スキーマ、公開率、消費率の詳細にドリルダウンする機能が含まれており、問題のあるイベント・データの特定と解決を支援します。

多くの組織では、イベントの利用が急速に拡大する段階に達しています。必ずしも互いのアクティビティを把握していない複数のチームによって、毎日新しいイベント ストリームが作成されています。重複に対する懸念だけでなく、その可視性を改善して効率と再利用性を高める方法についても懸念が生じ始めています。もちろん、再利用には独自の課題が伴います。アクセスはどのように制御されるのでしょうか？バックエンド・システムの負荷を避けるためにワークロードをどのように管理するのでしょうか？多くのチームに影響を与える重大な変更をどのように回避できるでしょうか？

これらの懸念に対処するため、多くの企業は、 API管理の一部として開発された優れたプラクティスを適用して、イベント・インターフェイスが適切に記述・バージョン管理され、アクセスが分離され、使用が適切に保護・管理されるように、イベント・インターフェイスをより正式に扱い始めています。

IBMは、既存のイベントをあらゆるユーザーが検出して利用できるようにするイベント・エンドポイント管理機能を提供し、APIなどのイベント・ソースを管理して企業全体で安全に再利用できるようにします。この機能は、IBMからEvent Streamsを管理できるだけでなく、すでに説明したオープン・アプローチに沿って、既存のKafkaベースのイベント駆動型アプリケーションやバックボーンにも対応可能です。

これにより、AsyncAPIのオープン スタンダードに基づく一貫したフレームワークでイベント・インターフェイスを記述できるようになります。つまり、これは人間が理解でき、コード生成ツールでサポートされ、API定義と一致するものであることを意味します。イベント・エンドポイント管理は、イベント・スキーマまたはサンプル・メッセージに基づいて有効なAsyncAPIドキュメントを生成します。

これは、他のユーザーが発見できるようにイベント・インターフェースを公開するためのカタログを提供します。これには、ライフサイクル管理、バージョン管理、ポリシーベースの制御の定義が含まれます。たとえば、ユーザーに有効な認証情報を提供することを要求するために、IDアクセス管理ソリューションと統合し、ロールベースのアクセスを実現します。

カタログのユーザーは、利用可能なイベントを見つけて、自分に関連するイベントを理解し、セルフサービス・アクセスに簡単に登録できます。使用状況分析により、イベント所有者はサブスクライバーを監視し、必要に応じてアクセスを取り消すことができます。これにより、再利用用のトピックを提供するチームがトピックをカタログに自分で配置でき、コンシューマーがアクセスを自分で管理できるため、Kafka管理者の負担が大幅に軽減されます。

イベント・エンドポイント管理は、消費者がイベント・プロデューサーやブローカーから切り離され、相互に分離され、データ形式の変更が管理されるようにするイベント・ゲートウェイを提供します。また、ポリシーベースの制御も強制し、これらをKafkaプロトコル自体に直接適用します。これは、エコシステムの一部であるKafka準拠の実装を管理できることを意味します。

イベントがさまざまな方法で再利用され、ユースケースがより洗練されるに従い、イベントをさらに改良したり、他のイベントと組み合わせたりする必要が生じることがよくあります。これは、対応すべき最も興味深いビジネス状況を識別するためです。イベントは、外部データで強化されるか、特定の期間に他のイベントと一緒に発生する場合に、より実行可能になる場合があります。

IBMは、ユーザーがイベントを操作してビジネス・コンテキストを理解できるようにするイベント処理機能を提供しています。幅広いユーザーがイベントを操作できるように設計されたローコード・ユーザー・インターフェースと、強力なオープンソース・イベント処理エンジンが含まれています。繰り返しになりますが、すでにデプロイされているKafkaベースのインフラストラクチャーでは、イベント処理は、環境内にある任意の Apache Kafka実装から取得されたイベントを処理できます。

イベント処理ランタイムは、イベント処理フローを実行するための、オープンで信頼性があり安全、かつスケーラブルな方法であるApache Flink上に構築されています。IBMイベント処理ランタイムは、Kubernetesオペレーターを使用して完全にサポート、デプロイ、および管理されます。これにより、共有実行環境として、またはアプリの一部としてのデプロイメントと管理が簡単になります。

ローコード・ツールを使用すると、ユーザーはイベント・ソースをイベントの処理方法を定義する一連のオペレーションに接続できます。複数のソースからのイベントを結合して、発生したさまざまなイベントから派生した状況を識別したり、イベントをフィルタリングして無関係なイベントをストリームから削除したり、イベントを集約してさまざまな期間における発生回数をカウントしたり、イベント内のフィールドを使用して新しい情報を導き出すための計算を実行したりできます。従来、この種のイベント処理には高度なスキルを持つプログラマーが必要でした。このツールを使用することで、ユーザーは安全で非破壊的な環境で、有用なシナリオを広範囲にプロトタイプ化できます。

イベントソースや宛先、処理操作をドラッグ・アンド・ドロップで配置し、それらを接続することで、直感的かつ視覚的にイベントを処理できるよう設計されています。各ステップでは生産性向上の支援や検証機能も備えています。「実行」をクリックするとエディターにアウトプットがすぐに表示され、再実行する前に処理を一時停止して編集できるため、ソリューションを迅速に反復することが可能です。結果は、エクスポートしたり、Kafkaに連続ストリームとして送信したりできます。

イベント処理により、多くのソリューションを作成およびデプロイできるため、コラボレーションが可能になり、複数のチーム メンバーがワークスペース内で共有およびコラボレーションできるようになります。ツールによって生成されたイベント処理ロジックは、GitHubなどのツールにエクスポートして、組織内の他のユーザーと共有できます。チュートリアルと状況に応じた支援により、新しいチームメンバーは簡単に状況を把握し、貢献を開始することができます。

Event Processingにソリューションを構成すると、オブザーバビリティーを実現してアクションを促進するために、そのアウトプットをさまざまな場所に送信できます。これには、Kafkaインプットを利用できるクラウドネイティブ・アプリケーション、オートメーション・プラットフォーム、ビジネス・ダッシュボードなどが含まれます。

IBM Event Automationは、完全に構成可能なイベント駆動型サービスであり、企業がプロセスのどの段階にいるかにかかわらず、施策の推進を後押しします。イベント・ストリーム、イベント・エンドポイント管理、イベント処理機能は、イベントの持つ可能性を解き放つイベント駆動型アーキテクチャの基盤作りを支援します。