Kafkaの導入拡大に伴う4つの主要課題

Apache Kafkaは、LinkedInで開発され2011年にオープンソース化された分散ストリーミング技術です。それ以来、Kafkaは爆発的な人気を獲得し、あらゆる業界の企業に広く採用されてきました。どのような技術においても、成熟して広く採用されるほど管理が難しくなり、Kafkaも例外ではありません。

リアルタイムデータ配信の力を活用しようとする顧客や見込み客と仕事をした経験から、Kafkaの人気は5〜7年前に急上昇し、それ以来、多くの企業に採用されているのを見てきました。ほとんどの技術採用サイクルと同様に、小規模な企業は新しい技術をより素早く採用して本番環境に変更を反映させますが、大企業はエンタープライズグレードの機能を必要とし、本番稼働までに時間がかかります。ここ1〜2年、数年前にKafkaを導入した企業の中で、採用拡大に伴う複雑さに気づき始める企業がますます増えていると感じます。どのメッセージング技術においても、異なる事業部門やイベントドリブンアーキテクチャの導入を目指す組織による採用拡大には、何らかの副作用が伴います。

ここでは、組織がエンタープライズ全体でKafkaの展開を拡大するにつれて直面する4つの主要課題を説明します。これらの課題が、Solace Event Portal for Apache Kafkaという「event portal」と呼ばれるまったく新しい種類のソフトウェアを発明し、市場に投入する原動力となりました。

Kafkaの課題1：可視性の欠如

まず、すべてをどのようにドキュメント化するのでしょうか？エンタープライズのKafka環境は、複数のKafkaクラスター、多数のトピック、いくつかのコンシューマーグループ、そして複数のスキーマで構成されています。採用の初期段階では、これは問題になりません。アプリケーションを本番稼働させた初日に存在するかもしれない5つ程度のトピックを、わざわざドキュメント化しようと思う人はいないでしょう。しかし、採用が増えると、明日には10倍のトピック、5倍のスキーマ、そしておそらく3倍のコンシューマーグループを持つことになるかもしれません。時間が経つにつれ、Kafkaクラスター上にこれらのオブジェクトがいくつ存在するかを把握することが、次第に難しくなっていきます。私が支援した大手米国銀行の一社は、自社のトピック数を把握していると思っていましたが、Event Portalのディスカバリースキャンを実行して詳しく調べたところ、実際の数は想定と桁違いだったことが判明しました。同僚のJesseが彼らの経験についてのブログ記事を書いており、ぜひ読むことをお勧めします。

それがなぜ重要なのでしょうか？自分が持っていると思っていたよりも少し多くのトピック（あるいははるかに多くのトピック）を発見したとしても、誰が気にするでしょうか。それらはただのディスク上のファイルであり、ストレージは安価です。確かにそうですが、組織はデータに対してより優れた制御を持つべきであり、トピックはそのログファイルの中にデータを保持しています。組織はどのようなデータを持ち、それがどのように使用されているかを把握し、データの重複を積極的に回避すべきです。組織が多くの未知のトピックを持つ理由の一つは、開発者が承認やレビューなしにトピックを作成したためです。作成されたこれらのトピックを誰も追跡しておらず、既に存在するトピックと重複している可能性が非常に高いです。これは、これらの重複トピックへのデータの公開が繰り返されることを意味し、非効率性、追加のストレージコスト、追加の管理オーバーヘッド、および新しいトピックへの依存度増大につながります。例えるなら、組織にマスターテーブルが存在し、それを各チームが次々と複製していった結果、最終的に誰がそのマスターテーブルからデータを消費しているのか誰にも分からなくなってしまう、という状況と同じです。

では、どのように解決するのでしょうか？Event Portal for Kafkaは、ユーザーがスキャンを実行してKafkaクラスター全体の重要なオブジェクト（トピック、コンシューマーグループ、スキーマ）を発見してドキュメント化できるようにすることで、この課題に対応します。これにより、Kafka環境を完全に可視化できます。Kafkaへの投資において何が起きているかが、もはや見えない状態ではなくなります。適切なガバナンスを確立し、既存トピックの重複を排除することで、トピックとデータの再利用性を高めることができます。さらに、発見されたオブジェクトはカタログに保存されるため、開発者やアーキテクトが容易に横断検索し、利用可能なデータを見つけることができます。結局、この情報をすべて収集してドキュメント化しても、それを公開・活用して効率を高めることができなければ意味がありません。これらすべてにより、生産性の向上、効率の改善、重複および関連するインフラコストの削減、そしてより優れたガバナンスが実現します。

Kafkaの課題2：関係性の欠如

最初の課題がトピックやスキーマなどのオブジェクトに焦点を当てていたのに対し、ドキュメント化が非常に重要なもう一つの次元があります。それはオブジェクト間の関係性です。トピック、スキーマ、コンシューマーグループの数を把握することは重要ですが、異なるアプリケーションがこれらのオブジェクトとどのように相互作用するかを把握することも非常に重要です。企業がKafkaの採用を増やすにつれ、アプリケーションがトピックとスキーマをどのように活用しているかを追跡することはますます困難になります。これが現在あなたが直面している課題かどうかを確認するために、自問すべきいくつかの質問を以下に示します。

• どのアプリケーションがどのデータを公開・消費しているか？
• データがどのトピックに公開・消費されているか？
• トピックに関連するスキーマは何か？
• どのコンシューマーグループがどのトピックから消費しているか？

なぜこれを知ることが重要なのでしょうか？データはすべての企業にとって重要であり、データがどのように使用されているかを知ることも同様に重要だからです。これらのオブジェクト間の関係をマッピングすることで、主要な依存関係を発見できます。例えば、あるパブリッシュ側アプリケーションが、詐欺検知やバリデーションなど5つのダウンストリームアプリケーションに消費されているトピックにクレジットカードのトランザクションデータを公開しているとします。このトピックに変更を加える場合は、どのアプリケーションが影響を受けるかを事前に把握しておく必要があります。

Event Portal for Kafkaは、（前のセクションで述べた通り）Kafkaオブジェクトをカタログ化できるだけでなく、これらのオブジェクトとアプリケーション間の重要な関係もマッピングできます。この情報により、Kafkaクラスターで何が起きているかを完全に把握でき、Kafka環境をより適切に管理・統制できます。

では、企業はどのような恩恵を受けるのでしょうか？最大のメリットは、変更に起因する障害の減少です。主要な依存関係への可視性が高まり、破壊的な変更がある際には主要なステークホルダー（ダウンストリームアプリケーションのオーナー）に通知できます。アップストリームアプリケーションの変更が原因で発生した障害の記憶が、ふと頭に浮かんだ方もいるのではないでしょうか？もう一つのメリットは、人気の高いオブジェクトと孤立したオブジェクトを区別できることです。もはや使用されていない多数の孤立したトピックとスキーマを発見することは非常に有益であり、新しいアプリケーションが誰にも管理されていない古いデータストリームを消費することを防ぎます。

Kafkaの課題3：自動化の欠如

エンタープライズ全体で新しい技術を採用すればするほど、自動化の必要性が高まります。Excelファイルにどのようなトピックやスキーマがあるかをドキュメント化するといった単純な作業は、もはや現実的ではありません。主要な関係をマッピングするために使用していたwikiページは陳腐化し、更新を維持するたびに困難な戦いになっています。そのため、上記の両課題はEvent Portal for Kafkaで対処できますが、別のツールを最新の状態に保つ責任を本当に負いたいでしょうか？私たちは皆、それをするには多忙すぎます（まあ、怠惰とも言えますが）。そして手動での介入は、タイプミスや見落としなどのヒューマンエラーのリスクを常に招きます。

だからこそ、Event Portal for Kafkaには更新を容易にする事前構築済みのインテグレーションが付属しています。開発者はAPIを使用してEvent Portalをパイプラインに簡単に統合できるため、変更を加えてgitにコミットすると、その変更がEvent Portalにも反映されます。同じ開発者がEvent PortalにアクセスしてAsyncAPI仕様ファイルをダウンロードし、コード生成に使用できるため、ボイラープレートコードの作成に時間を無駄にする必要がありません。その代わりに、ビジネスロジックの追加に集中できます。これらのインテグレーションにより、Kafka環境に関する情報が充実した統合されたポータルが常に最新の状態に保たれ、開発者の市場投入までの時間が短縮されます。

Slackとのインテグレーションにより開発者がEvent PortalのKafkaオブジェクトをSlack経由で同僚と共有できるなど、開発者の生産性を高めるインテグレーションは他にも多数あります。Confluenceとのインテグレーションもあり、Event Portalの最新データを含むwikiページを他の組織と共有できます。

Kafkaの課題4：深さの欠如

数人の開発者からなるチームで働く小規模スタートアップの開発者はバージョン管理を心配しませんが、数千人の開発者を抱える大規模なFortune 500企業は確実に心配します。時間が経ち、アプリケーション、トピック、スキーマの新しいイテレーションをリリースしていくにつれて、どのような変更が行われているか、誰が変更しているか、そしてなぜ変更されているかを追跡することが非常に困難になります。

上記で関係性の欠如について、そしてアップストリームアプリケーションがトピックに加えた小さな変更がダウンストリームで障害を引き起こす可能性について話しました。障害が発生すると、ステークホルダーは何が問題を引き起こしたのか、誰が原因なのか、そして今後どうすれば同じことを避けられるのかを知りたがります。

Event Portalは、バージョン管理とライフサイクル管理を備えた多次元的な構造でオブジェクトを保存します。これは、Event Portal内のオブジェクトが複数のバージョンで保存されることを意味します。変更が行われるたびに、既存のバージョンに適用することも、監査のために新しいバージョンを作成することもできます。誰が変更を加えたか、変更がいつ行われたか、なぜ変更が行われたかなどの追加情報も提供できます。企業が成長を続け、時間の経過とともに変更がますます増えていく中で、バージョン管理のサポートによって、トピックやスキーマなどのオブジェクトがどのように進化してきたか（そしてなぜそうなったか）について、深い洞察が得られます。

さらに、オブジェクトは永続するわけではありません。オブジェクトは作成され、テストされ、リリースされ、最終的に廃止されます。これらの存在の段階は消費側のアプリケーションに向けてドキュメント化し、周知することが重要であり、そうすることで廃止されたトピックから消費するという誤りを防げます。これはどのようなビジネス上の影響をもたらすのでしょうか？まず、バージョン管理により、Kafkaクラスターに存在するオブジェクトへのもう一段階深い洞察が得られます。誰が変更を加えたか、そしてより重要なことに、なぜその変更が行われたかなどの追加情報とともに、オブジェクトが時間とともにどのように変化したかを調査することで、障害の根本原因をより迅速に把握できます。最後に、ライフサイクル管理のサポートにより、ビジネスに影響を与える可能性のある古いデータをアプリケーションが消費することを防ぎます。

結論

Kafkaはさまざまな規模の企業に広く採用されており、企業とともにその採用が拡大するにつれて、多くの課題も明らかになっています。これらの課題とは、企業のKafka環境に存在するオブジェクトについての洞察の欠如、これらのオブジェクトの把握、手動介入なしにこれらのオブジェクトを最新の状態に保つ方法、そして時間をかけてバージョン管理とライフサイクル管理を提供する方法です。Event Portal for Kafkaはそのすべてを提供します。これらの課題が共感を呼ぶなら、是非ご連絡ください。Event Portal for Kafkaのdiscovery agentが、どのようにKafka環境を迅速に分析し、現状を可視化して、上記の課題に対処するために何ができるか、是非お話しさせて下さい。