Kafka の紹介

Comments

現在、IT の世界で分散メッセージングやストリーミング・データに対応するために最もよく使われているプラットフォームは、Apache Kafka (以降、Kafka と略称) です。あらゆるタイプのデータ (ログやイベントなど) を処理して転送し、場合によってはコンポーネント間を移動する際にデータを変換する必要もあるアプリケーションであれば、どのようなアプリケーションにでも Kafka が役立ちます。Kafka は LinkedIn 内のプロジェクトとして誕生し、その後、導入を促進するためにオープンソース化されました。この数年間にわたり、Kafka はオープンソース・プロジェクトとしてかなりの成熟を遂げました。IT 業界の大企業のいくつかでも、本番環境内で Kafka が使用されています。

Kafka は以下の基本コンポーネントからなります。

  • ブローカー: Kafka に送信されたデータは、Kafka ブローカーに保管されます。ブローカーは着信したデータを受け取り、保管する役割を果たします。また、リクエストに応じてデータを提供する役割も果たします。多数の Kafka ブローカーが連動することで Kafka クラスターを形成します。Kafka では、クラスターに関するメタデータを Apache ZooKeeper に保管します。ブローカーはこのメタデータを使用して障害 (他のブローカーの障害など) を検出し、検出した障害から回復します。
  • プロデューサー: プロデューサーは、データをブローカーに送信するエンティティーです。プロデューサーには、いくつかのタイプがあります。Kafka には Java で作成された独自のプロデューサーが付属していますが、他にも C/C++、Go、Python、REST などに対応する Kafka クライアント・ライブラリーが多数あります。
  • コンシューマー: コンシューマーは、ブローカーにデータをリクエストするエンティティーです。プロデューサーと同様に、組み込み Java コンシューマーの他にも、Java 以外の API に興味を持つ開発者が使用できるオープンソースのコンシューマーがあります。

Kafka ではデータをトピック内に保管します。プロデューサーは特定の Kafka トピックにデータを送信します。コンシューマーも特定のトピックからデータを読み取ります。各トピックには 1 つ以上のパーティションがあります。特定のトピックに送信されたデータは、最終的に、そのトピックのいずれか 1 つのパーティション内にだけ保管されます。各パーティションは 1 つのブローカーによってホスティングされ、複数のブローカーにまたがることはできません。

IT 業界で Kafka が定評を維持し、採用が進んでいる理由として、以下の点が挙げられます。

  • スケーラビリティー: Kafka のスケーラビリティーは、以下の重要な 2 つの特性によって支えられています。
    • Kafka クラスターは運用中にでも、停止することなく容易に拡大縮小 (ブローカーを追加、削除) できます。
    • Kafka のトピックは、拡大してパーティションを追加できるようになっています。1 つのパーティションを複数のブローカーでホスティングすることはできないため、パーティションの容量はブローカーのディスク容量によって制限されます。けれどもパーティションの数とブローカーの数は増やすことができるため、1 つのトピックに保管できるデータの量に制限はありません。
  • 耐障害性と信頼性: Kafka はブローカーの障害をクラスター内の他のブローカーによって検出できるように設計されています。各トピックを複数のブローカー上に複製できることから、クラスターはサービスを中断することなくブローカーの障害から回復し、機能し続けることができます。
  • スループット: ブローカーは効率的にデータを保管し、しかも超高速にデータを取得できます。

図 1 に、4 つのブローカーからなる単純な Kafka クラスターを示します。このクラスター内には 3 つのトピック (t1、t2、t3) が保管されています。パーティションが 1 つだけあるトピック t1 は、3 回複製されます。2 つのパーティションを持つトピック t2 と t3 はそれぞれ 2 回複製されます。この図から明らかなように、いずれか 1 つのブローカーで障害が発生したとしても、このクラスターはデータを失うことなく存続することができます。2 つのブローカーで障害が発生した場合、その 2 つがブローカー 1 と 4、またはブローカー 3 と 4 であれば、データを失わずに存続できます。これ以外のブローカー・ペアで障害が発生した場合は、一部のデータが失われることになります。

図 1. 単純な Kafka クラスター
A simple Kafka cluster
A simple Kafka cluster

このクラスターでは、プロデューサーとコンシューマーをさまざまに構成することができます。例えば、次のような構成です。

  • クライアント 1 がトピック 1 にデータを送信する (プロデューサーの役割)
  • クライアント 2 がトピック 2 にデータを送信する (プロデューサーの役割)
  • クライアント 3 がトピック 1 と 2 からデータを読み取り、トピック 3 にデータを書き込む (コンシューマーとプロシューサーを兼任)
  • クライアント 4 はトピック 3 からデータを読み取る

使用ケースによっては、これらのトピックのいくつかに、継続的データ・ストリームをリアルタイムで配信することもできます。例えば、トピック 1 には工場内の各種センサーからの温度測定値が含まれる一方、トピック 2 にはそれらのセンサーの詳細な情報が含まれているとします。そして上記の構成に含まれているクライアント 3 が、継続的に温度測定値を受信し、最新のセンサー仕様と照合することで異常がないかどうかチェックし、異常が検出された場合はそれをトピック 3 に報告するようになっているとします。このシナリオでは、クライアント 3 が単純なストリーム・アプリケーションとして、1 つ以上の Kafka トピックからデータを読み取り、何らかの処理を行って、その出力を別の Kafka トピックに書き込むわけですが、このすべてがリアルタイムで行われます。

IoT デバイスから送られてくるデータのリアルタイム分析や、Web サイト上でのユーザーのアクションによるデータのリアルタイム分析は、Kafka Streams によって簡単に対処できる基本的な使用ケースの例です。他の使用ケースについては、この記事の最後に記載されている Kafka Streams のドキュメントを参照してください。

上述の機能を備えていることから、Kafka はストリーミング・データと ETL のシナリオでよく使われている手段となっています。実際、Kafka Streams API は Kafka の一部となっているため、 Kafka では、移動中のデータを処理するストリーム・アプリケーションを容易に作成できます。Kafka はバッチ処理用メッセージング・プラットフォームとして登場しましたが、今では人気の高いストリーム処理プラットフォームに成長したと言ってもいいでしょう。さらに、Kafka Streams は KSQL という別のオープンソース・プロジェクトによって増補され、Kafka Streams アプリケーションの作成を遥かに単純化するために、SQL のような宣言を使用できるようにもなっています。

Kafka と Kafka Streams が提供する機能は、この短い記事では紹介しきれません。以下の関連トピックに、Kafka および Kafka Streams の詳細とコーディングの例を参照できる資料がリストアップされています。Kafka および Kafka Streams の内部構造と実際の使用方法について理解を深めるには、ぜひ、これらの資料に目を通してください。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=ビジネス・アナリティクス, Open source
ArticleID=1063813
ArticleTitle=Kafka の紹介
publish-date=12132018