イベントバスが必要なケースをよくある5つの用途で紹介
オリジナル記事
Do You Need an Event Bus? A Quick Overview of Five Common Uses
Lyric Hartley
1月23日·所要時間7分
イベントは、メッセージとも呼ばれ、異なるシステム間で情報を伝達するための優れた手段です。Apache Kafkaは、こうした通信を大規模に処理するように設計されています。 これが業界標準になっている1つの理由は、入力データをすべて最適に活用する効率的な方法を提供していることです。
英語などの言語の価値が高まるのは、多くの人がその言語を話すからであるように、こうしたメッセージは最も一般的なシステムで「理解」される一方で、そうでないメッセージに関して「教える」には多大な努力が必要です。
このブログ記事は公開されており、お互いのことを知らなくても情報を共有できるように、Kafkaはイベントやメッセージを関係者に配信する手段となります。そして、話し言葉と同じように、その言葉を話す人が増えれば増えるほど、その価値は高まっていきます。同様に、異種システムがイベントを交換できるKafkaのような共有イベントバスがあれば、さらに強力になります。
Herokuのアーキテクトとしてトップクラスのお客様をサポートしていると、人とその会社を窮地に追い込むパターンや、きわめて簡単に変更を行うパターンを目にします。この記事では、標準規格に準拠したイベントバスによって実現する（数多くの）パターンのうち、5つのパターンについて手短に紹介します。それぞれのパターンの目的は異なりますが、実装は基本的に同じであるため、簡単で保守性と汎用性の高いものになっています。
これは、イベント駆動型アーキテクチャについて説明するシリーズの記事です。このシリーズの他の記事では、Herokuのコンピューティングを使用してフローを拡張する方法、Work.com組織の複数組織における可視性、および組織間のデータ同期について説明しています。
こうしたパターンの中心となるのが、HerokuとApache Kafkaのコネクターです。どちらもよく知らないという方は、記事の最後にある資料をご覧ください。（また、Heroku Enterpriseのお客様は、Customer Solutions Architectureチームにこれらのトピックに関する詳細なガイダンスをリクエストできます）。
今回の記事では、以下の5つのパターンを取り上げています。
パターン#1：変更を管理する場合（Change Data Capture）
パターン#2：連携する場合（統合）
パターン#3：すぐに把握する必要がある場合（リアルタイム処理とインサイト）
パターン#4：後で必要となる可能性がある場合（データのアーカイブ、バッチ処理）
パターン#5：組織のスケーリングが必要な場合（スケーラビリティ）
パターン#1：変更を管理する場合（Change Data Capture）
データが変更されない場合（おかしなことですが）、この問題はスキップしても構いませんが、変更されてもわからない理由を理解する必要があります。このパターンでは、基本的なユースケースとして、Salesforce組織で何かが変更され、他の多くのサービスで変更内容を把握する必要がある場合を想定しています。サービスが何であるか、または誰が所有しているかを把握していなくても、変更を反映させることができます（言うまでもなく、セキュリティを考慮することが重要です）。
たとえば、オンラインストアを運営していて、地域のあるSalesforce組織で在庫が更新されたときに、サイトの検索、レコメンドグラフデータベース、CDNを更新する必要があるとします。Lightning Webコンポーネントは、共有されたKafkaイベントバスから直接更新することもできるので、Salesforce組織内で動作しているアプリであっても、変更後すぐに更新できます。
在庫切れの商品の購入を勧めるような真似は避けたいので、このパターンではタイミングを考慮することが重要になります。また、ロールアウトの同期を維持しながら、品目をパージする機能を備えているかどうかを確認することもおすすめします。オンラインショッピング時に品目は在庫としてあるのに、購入しようとすると消えてしまうような問題を経験したことがありませんか。より適切に処理するには、在庫切れのマークをつけて、順番待ちリストを提供することです。お客様に時間を無駄にしたと感じさせず、他のサイトに流れさせて販売機会を失うこともありません。
最終的に、次のようなアーキテクチャになると考えられます。
詳細情報
Apache Kafka on Herokuによる複数のSalesforce組織の同期化（ウェブセミナー）（英語）
https://devcenter.heroku.com/ja/articles/heroku-data-connectors
CDNアドオン（英語）
Fastly + Kafka + Elasticsearch（英語）
パターン#2：連携する場合（統合）
ピーナッツバターとゼリー、コーヒーとドーナツ、あるいはコピーとペーストのように、多くのテクノロジーは相性が良いものです。Apache Kafkaの真の強みは、サービス間やクラウド間でデータを共有すると同時に、各システムの切り離しが可能であることです。これも、標準規格に準拠したオープンソースのソリューションを使用することのメリットです。Apache Kafkaには常に新しいコネクターやツールが開発されており、そのまま利用することも、既存のものを利用して独自に開発することもできます。エコシステムは製品よりも強力です。
イベントを共有バスに送信することで、新しいサービスを追加したいときには、これを共有バスに接続するだけですぐに動作するようになります。この図ではPrivateLink経由でKafkaに接続していますが、これにより、AWS VPC内の別のIPであるかのように安全にアクセスすることができます。また、MuleSoftも接続しており、他の多くのサービスやAPIに接続することができます。
詳細情報
Apache Kafka on Heroku向けPrivateLinkの作成
Mulesoftコネクター（英語）
MulesoftとHerokuのデータサービスとの接続（英語）
パターン#3：すぐに把握する必要がある場合（リアルタイム処理とインサイト）
一部には時間的制約がある変更もあるため、できる限り早急に把握しておく必要があります。たとえば、セキュリティ侵害、商品の出荷（配送）、サービスの停止など、今すぐに対応が必要な問題を考えてみましょう。
リアルタイムのイベントを分析し、通知やダッシュボードを提供するためのアーキテクチャは、以下の図のようになります。イベントがトピックに入ってくると、それを処理し、適切な措置を講じます。イベント数をカウントしてアクションをトリガする量でないか確認することもあれば、単にダッシュボードに集計結果を表示してモニタリングすることもあります。
Kafka Streamsは、このタイプのアプローチを実装する妥当な手段であり（以下のリンクを参照）、アーキテクチャは次のようになります。
詳細情報
小売でのリアルタイム利用（英語）
リアルタイムの他のサンプル（英語）
イベントストリームの管理（英語）
パターン#4：後で必要となる可能性がある場合（データのアーカイブ、バッチ処理）
それでは、今あるこのデータをどこに保存しますか？
多くの企業では、データを一定期間保存したり、オフサイトに保管したりする必要があります。どの企業も、お客様のことをもっと知りたい、データからインサイトを得たいと考えています。これは、そうした方（つまり、私たち全員）を対象としたパターンです。生のイベントをどこかに保存しておく理由は、処理以外にも、イベントを「再生」できるという点があります。バグのため、または新しい方法でデータを処理するために再生が必要となる場合があるかもしれません。どのようなユースケースであっても、このパターンは導入してよかったと思えるものです。
詳細情報
Apache KafkaとRedshiftを連携させるコネクターのサンプルアプリ（英語）
Apache KafkaとS3、Google Cloud Storageなどの連携（英語）
Apache Kafka、Redshift、Metabaseのサンプルアプリ（英語）
Kafkaイベントを再生する例（英語）
パターン#5：組織のスケーリングが必要な場合（スケーラビリティ）
これは大規模なものになりそうです。
サービスが分離されると、サービスは脆弱性が低くなり、俊敏性が高まります。組織の成長に伴って必ず低下するのがチームの「コラボレーションコスト」です。これは、自分のチームの仕事を終わらせるために他のチームと話すのに、どれだけの時間を費やしているのかを表しています。つまり、分離することでアプリケーションおよび組織の拡張が可能になります。大規模なモノリシックアプリは、徐々に分離したマイクロサービスに分割することができるうえ、このマイクロサービスは個別にスケーリングできます。また、ここで示したパターンでは、さまざまな地域にあるPrivate Spacesを利用してグローバルにスケーリングしています。Kafkaに送信される変更を取得し、他の地域にあるリモートのRedisキャッシュを更新しています。
詳細情報
Apache Kafkaを使用したイベント駆動型マイクロサービス
KafkaとRedisを連携させるコネクターのサンプル（英語）
まとめ
ご覧のように、こうしたパターンは、サービスの接続を行う小規模企業だけでなく、規模拡大に伴って、問題なくチームの動きを迅速化しようとする大規模企業にも、あるいはその中間の企業にも当てはまります。ピースがそろえば、他にもさまざまなユースケースが見えてきます。Kafkaは、より優れたアーキテクチャを実現するための入り口であり、基本的な準備が整えば、可能性は無限大です。
その他の有益なリソース
Apache Kafkaとは（英語）
Herokuのストリーミングデータコネクターのリリース（英語）
[すでにHeroku Enterpriseをご利用のお客様は、こちらで会議を設定することができます。Lyricが送ったとお伝えください。]
著者紹介：
Lyric Hartleyは、Herokuのカスタマーソリューションアーキテクトです。Herokuの大口顧客が抱える難題の解決と、必要なスケーリングの実現を支援する日々を過ごしています。いつでも新しくて難しい問題を解決することが大好きです。現在の職務に就く前は、Salesforceの開発チームに所属していました。Salesforceの仕組みを理解し、Salesforceの多くのチームがHerokuを使用してより迅速にイノベーションを実現できるよう支援しています。コンピューティングの未来に情熱を注いでおり、人々がすべてのビジネスに共通することではなく、自分のビジネスにとって重要なことに集中できるようにしたいと考えています。また、音楽とビールも大好きです。
