先日、あるウェビナーを主催する機会を得ました。このウェビナーでは、Forrester ResearchのPrincipal AnalystであるDavid Mooterが、企業がKafkaを大規模に導入する際に直面する4つの一般的な課題について解説し、同僚であるSolaceのフィールドCTOであるJonathan Schabowskyが、それらの課題を乗り越えた実在の企業事例を紹介しました。
このブログ記事では、Kafkaを活用し、Kafkaインフラを最大限に活かしたいと考えているすべての方に役立つと思われる、ウェビナーのハイライトをまとめました。
David Mooter、Principal Analyst、Forrester Research
Davidはまず、Kafkaの概要を簡単に説明したうえで、企業がKafka環境をより多くのミッションクリティカルなユースケースへと拡大していく中で、以下の4つの課題のうち1つ以上に直面する傾向があると述べました。
- インフラの管理
- 負荷とスケーリングの管理
- トピックの乱立への対処
- データとイベントストリームのカタログ化
課題1：インフラの管理
Davidはまず、Kafkaの管理は以前より容易になった—例えば、もはやZookeeperは不要になった—と説明しましたが、エンタープライズ規模のデプロイメントという観点では、依然としてかなり複雑であると述べました。
彼は以前、Kafkaをブラウザ分析（Webクリックの解析）に使用するチームを率いていたと説明し、当時は短時間のサービス停止は大きな問題ではなかったが、メッセージの損失が許容されないミッションクリティカルな業務にKafkaを使い始めると、状況が複雑になったと述べました。
例として、Uberが2つのデータセンターを通じてメッセージの高可用性を確保するために採用した「アクティブ/アクティブ」トポロジーを紹介しました。このトポロジーでは、すべてのメッセージはローカルのリーダーに提供されるだけでなく、すべてのトピックのデータを受信する「グローバル読み取りクラスター」にも提供されます。しかし、障害発生時のハンドオーバーを管理するジョブをコーディングする必要があり、各読み取りクラスターがメッセージを受信するタイミングによっては、メッセージが順序通りに配信される保証はありませんでした。
彼のアドバイスは？メッセージングのニーズが複雑になるにつれて、どのように複雑さを管理するかを十分に検討することです。例えば、ディザスタリカバリ、オフセット、重複メッセージの扱い、そして冪等性（すなわち、受信者が重複メッセージを無視するようにすること）の必要性についてです。
課題2：負荷とスケーリングの管理
Davidは次に、取り込まれるデータ量が増加するにつれてクラスターが高スループットを処理できるようにするために、経験豊富なKafkaエンジニアを採用することが重要である理由を説明しました。それはハードウェアのプロビジョニング、最適化、スケーリングを慎重に行う必要があるためです。また、経験豊富なエンジニアは、スループットに大きな影響を与える「at least once」、「at most once」、「exactly once」デリバリーに関連するトレードオフにも適切に対処する方法を理解しています。
Kafkaに精通したエンジニアは、サービスとしてのKafka環境においてクラウドネイティブな自動スケーリングを効果的に機能させるようにシステムを設定し、パーティショニングに関する先を見越した戦略を策定するうえでも最適な人材です。
彼は、パーティショニングが並列処理にどのような影響を与えるかについて例を挙げました。
トピックのパーティショニング戦略を誤ると修正が非常に困難になり、通常は新しいトピックを作成し、すべてのプロデューサーとコンシューマーを新しいトピックに移行するという最初からのやり直しが必要になります。
課題3：トピックの乱立
次に、トピックの乱立という課題について説明しました。これは、どのアプリがどのトピックからデータを消費しているかが分からなかったり、どのトピックがどのクラスターで公開されているかが分からなかったりする状況であり、彼はこれを「シャドウトピック」と呼びました。シャドウトピックをなくすための鍵は、APIディスカバリツールを使うのと同様に、トピックディスカバリツールを活用することです。また、どのサービスがどのトピックと通信しているかを示す可視化ツールも重要なツールの1つです。
課題4：データのカタログ化
トピックの乱立に関連するもう一つの一般的な課題は、利用可能なトピックに関する信頼性の高い最新のドキュメントが存在しないことです。多くの企業はプロデューサー中心のレジストリを持っていますが、コンシューマーが有用なトピックを特定してサブスクライブするために利用できるカタログを持っていません。Davidが、eBayやSAPが公開しているイベントストリームの事例を紹介しながら強調したように、イベントストリームがAsyncAPIで構築されている場合、このようなカタログは再利用を促進するうえで特に強力なものとなります。
Davidのまとめ
Davidは、APIとEDAは収束しつつあるという見解でトークを締めくくりました。APIとEDAの最大の価値は、特定の機能を実行するアプリケーションではなく、個別で柔軟かつ再利用可能なケイパビリティとして自社のITインフラを考えるようになるため、モジュール型のビジネス変革を可能にするという点にあります。主な違いは、そのサービスが「リクエストするもの」なのか、「受け取ることを求める情報のストリーム」なのかという点にあります。彼の推奨事項は、APIとEDA資産のライフサイクル管理とガバナンスのための共通プロセスを確立することです。
その点を述べた後、彼はJonathanにバトンを渡し、Jonathan自身が目撃してきた、まさにDavidが説明した課題を乗り越えた企業の事例を紹介してもらいました。
Jonathan Schabowsky、フィールドCTO、Solace
Jonathanは、Davidが語ったAPIとEDAの収束は、私たちの顧客基盤において常に見られることだと説明しました。彼は3つの事例を紹介しました。
ある大手小売業者は、COVID以降、店舗またはオンラインでの購入、配送や受け取り、返品対応など、新しいインタラクションモデルをサポートする必要から事業変革を迫られました。これらはすべてイベントドリブンなインタラクションに適した領域です。その変革を支えるために、それらの機能を実現するイベントを整理し、自社組織および店舗・サプライヤー・フルフィルメントパートナーのネットワーク全体に公開する方法を見つける必要がありました。
2つ目の事例は航空分野で、何千もの飛行機が常に離着陸や飛行を繰り返しながら、搭乗、位置情報、手荷物、離陸・到着などに関するあらゆる種類の情報を生成しています。それらすべての活動に関するデータを収集し、燃料節約や旅客サービス向上などに向けてインサイトを導き出し意思決定を行うために利用する、すべてのシステム・担当者・ステークホルダーに配信する必要があります。
3つ目の事例は金融サービス分野で、オープンバンキングや「フィンテック」といった取り組みにより、金融機関がリアルタイムデータで機密情報を交換する場面が増えています。これにより、金融機関はデータのガバナンスを強化し、コンプライアンスを確保するために、規制の観点からどの組織がどのイベントを消費しているかを把握するという新たなプレッシャーに直面しています。
Jonathanは続けて、Kafkaを真に活用するためには、効果的なイベント管理戦略が必要だとSolaceは考えており、その戦略とは以下の質問に自信を持って「はい」と答えられるものでなければならないと説明しました。
- 自社のKafkaシステムを把握していますか？ディストリビューション、クラスター数、トピック数は？
- すべてのトピックにデータに基づいたアクセス制御が設定されていますか？
- チームが加えた変更の影響を確認できますか？
- チームが再利用するイベントを容易に見つけられますか？
彼は、企業がKafkaをどれだけ効果的に管理しているかを評価するために私たちが開発したツール、「Kafkatosis Risk Assessment」を紹介してトークを締めくくりました。https://solace.typeform.com/kafkatosis からご自身で試すことができます。
「高リスク」という結果にならないことを願っていますが、その過程でKafka環境をさらに活用するためのヒントについて少し学べることは間違いありません。
質疑応答
有益なウェビナーの締めくくりとして、聴衆からの質問を受け付け、DavidとJonathanがそれぞれいくつかの質問に回答しました。その質問には以下が含まれます。
- RESTful APIとKafkaイベントの両方をカタログ化できるツールはありますか？
- センサーデータの処理においてKafkaはどの程度効率的ですか？
- KafkaストリームにおけるOpenAPIのような新しい仕様はありますか？