ibm integration bus kafka node · 2 ©2017 ibm corporation はじめに p当資料では、iib...

IBM Integration BusKafka node

2017.09日本アイ・ビー・エムシステムズ・エンジニアリング（株）

©2017 IBM Corporation2

はじめにp 当資料では、IIB V10.0.0.7で新規に提供、V10.0.0.8で機能拡張されたKafkaノードについてご紹介してい

ます。p Apache Kafkaの基本的な動作や⽤語などについては「IBM MQ V9.0アップデートセミナー」資料

“Message Hubの紹介”をご参照ください。IBM MQ V9.0 アップデート・セミナー

当資料に記載している内容は可能な限り稼動確認を取っておりますが、日本アイ・ビー・エム株式会社、及び日本アイ・ビー・エムシステムズ・エンジニアリング株式会社の正式なレビューを受けておらず、当資料で提供される内容に関して日本アイ・ビー・エム株式会社、日本アイ・ビー・エムシステムズ・エンジニアリング株式会社は何ら保証するものではありません。

従って、当資料の利用またはこれらの技法の実施はひとえに使用者の責任において為されるものであり、当資料によって受けたいかなる被害に関しても一切の補償をするものではありません。


⽬次p Kafkaノード概要

p Kafkaノードとはp Kafkaノードのユースケースp Kafkaノード概要

Ø KafkaProducerノードØ KafkaConsumerノード

p KafkaノードのMessage Hubへの接続p Message Hubサービスの作成p サービス資格情報の確認p トピックの作成p Message Hubサービス資格情報のIIBへの登録p Kafkaノードのプロパティ設定

p メッセージの配信パターンとノード構成p 負荷分散型配信p 同報型配信p メッセージ順序保証型配信


Kafkaノード概要


Kafkaノードとはp Kafkaノードを使⽤してApache KafkaまたはIBM Message Hubに接続し、メッセージをKafkaトピックにパ

ブリッシュしたり、 Kafkaトピックにパブリッシュされたメッセージを受け取ることが可能p V10.0.0.7でKafkaノードの提供p V10.0.0.8でKafkaノードでのメッセージ・キーをサポート

Ø メッセージのパブリッシュ時、メッセージに対してストリング値(key)を関連付ける事が可能

p Apache Kafkaサーバー(IBM Message Hub)にクライアントとして接続し、Kafkaメッセージの処理を⾏うp V0.10.0.1以上のKafkaサーバーと接続可能

p Message HubはKafka V0.10.2.1がベースp Kafkaノードとして以下2つのノードを提供

p Kafka ProducerノードØ Kafkaサーバ―上のトピックに対し、メッセージフロー内で⽣成したメッセージをパブリッシュする

p Kafka ConsumerノードØ Kafkaサーバー上のトピックに対しサブスクライブし、そのトピックにパブリッシュされたメッセージをメッセージフローの⼊⼒として

受信する

In FailureOut

OutCatch

Failure


補⾜:Apache Kafka概要p オープンソースの分散メッセージング・システム

p LinkedInにより開発され、2011年にオープンソースとして公開p ⼤容量のログを⾼スループット/低レイテンシに収集/配信することを⽬的に開発された

p Apache Kafkaの４つの特徴p Fast：⾼スループット/低レイテンシのメッセージング処理が可能p Scalable： Kafkaクラスター構成によりスケールアウトが可能p Durable：データの損失を防ぐため、メッセージを永続化しKafkaクラスター内で複製p Distributed by Design：複数ブローカー構成により、Kafkaクラスターは⾼い耐障害性を持つ

p データの送受信⽅式p ProducerとConsumerがトピックを介してM対Nで通信するパブリッシュ/サブスクライブ・モデルp 負荷分散/耐障害性のためKafkaではトピックに送信されたデータを複数サーバーで管理

KafkaCluster

Producer Producer Producer

Consumer Consumer Consumer

ServerServerBrokerTOPIC


p トピックp メッセージを送受信する対象となるオブジェクト

Ø ユーザーが任意で作成可能Ø それぞれのトピックは独⽴している

ü JMSやMQTTのトピックと異なり、階層構造になっていないØ トピックは1つ以上のパーティションで構成される

p プロデューサーとコンシューマーp メッセージを送受信するユーザーアプリケーション

Ø プロデューサー: トピックに対してメッセージを送信するØ コンシューマー: トピックをサブスクライブし、メッセージを受信する

KafkaCluster

補⾜: Kafkaの⽤語解説

Broker3

TOPIC A

PartitionPartition

Producer

Consumer

Broker2Broker1

TOPIC A

ProducerProducer

Consumer Consumer

TOPIC B

PartitionPartition

TOPIC C

PartitionPartition


補⾜: Kafkaの⽤語解説p パーティション

p メッセージが保管される領域p パーティションを複数に分けることも可能

Ø トピック作成時に数を指定するp メッセージには送信順にオフセットと呼ばれるIDが付与される

Ø オフセットはパーティション内でユニークとなる

p レプリカp トピックの各パーティションは他のブローカーにレプリカを作成することが可能

Ø IBM Message Hubでは1パーティションに対して2つのレプリカが作成されるp 全てのレプリカの内、1つがリーダー、その他のレプリカはフォロワーと呼ばれ、リーダーがProduce/Consumeのリク

エストを受け付けるØ 書き込まれたメッセージは同期/⾮同期でフォロワーのパーティションに転送される

ü 同期/⾮同期はProducerのackプロパティにて設定するp リーダーがダウンした場合、いずれかのフォロワーが⾃動的にリーダーに昇格する

KafkaCluster

Broker1 Broker2 Broker3TOPIC

Partition 0

Partiton 2replica

Partition 0replica

Partition 1replica

Partition 1 Partition 2

Partition2についてはBroker3がリーダー、Broker1がフォロワー

複製複製複製


補⾜:IBM Message Hub概要p IBM Cloud(Bluemix)で提供されるApache Kafkaベースの分散メッセージング・サービス

p 複数サービスを⾮同期に接続するハブとして利⽤可能p RESTやKafkaプロトコルなどのオープン・プロトコルを利⽤したアプリケーション開発が可能

Ø Message HubではさらにMQ Light APIとの接続も可能p Streaming AnalyticsサービスやApache Sparkサービスなどの分析基盤と連携が可能

p 提供機能p パブリッシュ/サブスクライブ・ブローカー機能を提供

Ø アプリケーションは、Kafka API/Kafka REST API/MQ Light APIを使⽤してメッセージを送受信p トピック管理機能

Ø トピックの作成/削除、パーティション数の設定(Bluemix ダッシュボード/管理 REST API)p モニタリングおよびロギング機能の提供

Ø Message Hubの使⽤状況(トピックのメトリック、トピックのイベント)をモニター可能p セキュリティー

Ø Kafka API: SASL認証、 Kafka REST API: APIキーによる認証(TLS 1.2 での接続が必須)

Message Hub

REST

Streaming Analytics

Apache Spark

アプリケーション


Kafkaノードのユースケース

Message HubIBM WatsonIoT Platform

MQTT

Device Events

IoT Devices

p クラウドとオンプレの連携p クラウド上のアプリケーションやIoTデバイスからのデータの収集

Ø アプリケーションログをMessage HubへパブリッシュØ デバイスから送られてきたイベントデータをWatson IoT Platformで受信、Message Hubへパブリッシュ

p データの活⽤Ø MQ, JMSを使⽤して既存のMQオンプレ環境との接続Ø 収集したログ・データをSparkなどの分析基盤で分析Ø イベントデータの異常値を検知・通知

ü デバイスの温度上昇などを検知、担当者への通知

on-premise

IIB

JMS,MQ

Apache Spark

…


Kafkaノード概要p Kafka Producerノード

p Kafkaクラスター上のトピックに対し、メッセージフロー内で⽣成したメッセージをパブリッシュするp Producerノードでのメッセージのパブリッシュは⾮トランザクション

Ø Producerノードを通過後にフローがロールバックしてもパブリッシュされたメッセージはロールバックしない

p Kafka Consumerノードp Kafkaクラスター上のトピックに対しサブスクライブし、そのトピックにパブリッシュされたメッセージをメッセージフ

ローの⼊⼒として受信するp Consumerノードでのメッセージのサブスクライブは⾮トランザクション

Ø フローが⼊⼒ノードにロールバックする場合を考慮し、必要に応じてエラー時にメッセージの再処理や退避するような実装を検討する

In FailureOut

OutCatch

Failure


Kafka Producerノードp Kafka Producerノードの主なプロパティ

タブ設定項⽬必須備考Basic Topic name ○ メッセージの配信先トピックを指定する。

Bootstrap servers ○ 接続先Kafkaクラスターを指定する。カンマ区切りで複数指定することも可能。Client ID クライアントIDを指定する。クライアントIDを論理アプリケーション名としてKafkaログに含めること

で、ユーザーがIPとポート以外の情報でリクエスト元を追跡するために使⽤する。Add IIB suffix to client ID チェックを⼊れると、クライアントIDに統合サーバー名と統合ノード名を接尾語として付加する。Acks ○ メッセージが正常にパブリッシュされたと判断するためにKafkaから返されるACKの数を指定する。

0: ACKを待たない1: Kafkaからの1つのACKで正常にパブリッシュされたと判断するAll: トピックの全てのレプリカからのACKを待つ

Timeout (sec) ○ リクエストのタイムアウト値を指定する。Security Security protocol ○ 使⽤するセキュリティプロトコルを以下から選択する。

• PLAINTEXT• SSL• SASL_PLAINTEXT• SASL_SSL

Message Hubに接続する場合はSASL_SSLを指定する必要がある。SSL Protocol ○ Security protocolでSSLまたはSASL_SSLを指定する場合、使⽤するSSLプロトコルを指定する。

Message Hubを使⽤している場合はTLSv1.2を指定する必要がある。


Kafka Consumerノードp Kafka Consumerノードの主なプロパティ

タブ設定項⽬必須備考Basic Topic name ○ メッセージを受け取るトピックを指定する。

Bootstrap servers ○ 接続先Kafkaクラスターを指定する。Consumer group ID ○ コンシューマーグループIDを指定する。Default message offset ○ メッセージを受け取るオフセットのデフォルト位置を以下の2つから選択する。

• Earliest• Latest

Commit message offset in Kafka 有効にすると、Kafka上に受け取ったメッセージのオフセット位置を保存する。このパラメーターが有効、かつ保存されたオフセットのメッセージが有効な場合、そのオフセット番号からメッセージを受け取る。

Client ID クライアントIDを指定する。クライアントIDを論理アプリケーション名としてKafkaログに含めることで、ユーザーがIPとポート以外の情報でリクエスト元を追跡するために使⽤する。

Add IIB suffix to client ID チェックを⼊れると、クライアントIDに統合サーバー名と統合ノード名を接尾語として付加する。Advanced Connection timeout (sec) ○ 接続タイムアウトを指定する。セッションタイムアウトより⼤きくする必要がある。

Session timeout (sec) ○ セッションタイムアウトを指定する。Kafkaがこの値の間にConsumerからのハートビートを受信できなかった場合、このクライアントをConsumer Groupから削除する。接続が切れたクライアントが受け持っていたパーティションは、別の同⼀グループ内のConsumerに⾃動的に割り当てられる。

Receive batch size ○ 単⼀のバッチでKafkaから受け取るレコードの最⼤数を指定する。


Kafka Consumerノードp Kafka Consumerノードの主なプロパティ(続き)

p 追加インスタンス設定時のメッセージの処理p 追加インスタンスを構成した場合でも、Kafka側から⾒えるコンシューマーインスタンスは1つp コンシューマーインスタンスが追加インスタンスにメッセージを配布するp メッセージの順序性は保証されないため、順序保証が必要な場合は使⽤しないか、アプリ側で制御する

タブ設定項⽬必須備考Security Security protocol ○ 使⽤するセキュリティプロトコルを以下から選択する。

• PLAINTEXT• SSL• SASL_PLAINTEXT• SASL_SSL

Message Hubに接続する場合はSASL_SSLを指定する必要がある。SSL Protocol ○ Security protocolでSSLまたはSASL_SSLを指定する場合、使⽤するSSLプロトコルを指定する。

Message Hubを使⽤している場合はTLSv1.2を指定する必要がある。Instances Additional Instances pool 追加インスタンスの取得元のプールを指定する。

• Use Pool Associated with Message Flowメッセージフローの値から追加インスタンスを取得する

• Use Pool Associated with NodeAdditional Instancesの値を元に追加インスタンスを割り当てる

Additional Instances ノードが開始できる追加インスタンスの数。


LocalEnvironmentツリーの使⽤p Kafka(Message Hub)呼び出しに関するLocalEnvironment変数

p 以下3つのツリーの⼦エレメントとして指定Ø LocalEnvrionment.Destination.Output : KafkaProducerノードがメッセージを配信する際に宛先やキー値を上書き指定する事が可能Ø LocalEnvironment.WrittenDestination.Kafka : 出⼒メッセージの伝搬時にKafkaProducerノードによって書き込まれるØ LocalEnvironment.Destination.Input : 出⼒メッセージの伝搬時にKafkaConsumerノードによって書き込まれる

p LocalEnvironment.Destination.Output

変数上書きするノードプロパティ備考topicName Basicタブ Topic Name メッセージの配信先トピックを指定key N/A メッセージに関連付けるキー値を指定。同⼀のキー値が指定されたメッセージは、

同⼀トピック内の同じパーティションに配信される※ノードプロパティでの設定は不可。


LocalEnvironmentツリーの使⽤p LocalEnvironment.WrittenDestination.Kafka: 出⼒メッセージの伝搬時にKafkaProducerノードによって書き込まれ

る

p LocalEnvironment.Destination.Input: 出⼒メッセージの伝搬時にKafkaConsumerノードによって書き込まれる

変数タイプ備考partition String メッセージが格納されたパーティションtopicName String メッセージがパブリッシュされたトピック名offset Integer メッセージのパーティション内でのオフセット番号checksum Integer メッセージのチェックサムkey String LocalEnvrionment.Destination.Kafka.Output.keyで指定されたキー値(指定した場合)

変数タイプ備考partition String メッセージが格納されていたパーティションtopicName String メッセージがパブリッシュされたトピック名offset Integer メッセージのパーティション内でのオフセット番号checksum Integer メッセージのチェックサムkey String 受信したメッセージに関連付けられたキー(存在する場合)


KafkaノードのMessage Hubへの接続


KafkaノードのMessage Hubへの接続p KafkaノードをMessage Hubへ接続するための⼿順

p Bluemix上でのMessage Hubサービスの構成p サービス資格情報の確認p トピックの作成p Message Hubサービス資格情報のIIBへの登録p Kafkaノードのプロパティ設定


Message Hubサービスの作成1. IBM Bluemix カタログ > アプリケーション・サービス > Message Hubを選択


Message Hubサービスの作成2. サービスの作成に必要な情報を⼊⼒し、作成ボタンを押す

p サービス名p 資格情報名p デプロイする地域、組織、スペースp 接続


Message Hubサービスの作成3. サービスの管理画⾯が表⽰されれば完了


サービス資格情報の確認4. Message Hubのサービス資格情報を確認、メモする

p kafka_brokers-sasl内に記載されたホスト名p user/password


トピックの作成5. Message Hubサービスの管理画⾯から作成する

p パーティションは1サービスで合計100パーティションが使⽤可能

トピックの作成ボタンをクリック

トピック名、パーティション数、メッセージの保存期間を指定して、トピックの作成ボタンをクリック


Message Hubサービス資格情報のIIBへの登録6. Message Hubへ接続する統合サーバーにMessage Hubサービス資格情報を登録する

p 先の⼿順でメモしたuser、passwordを使い、mqsisetdbparmsコマンドで登録

$ mqsisetdbparms <統合ノード名> -n kafka::KAFKA::<統合サーバー名> -u <user ID> -p <password>BIP8071I: Successful command completion.


Kafkaノードのプロパティ設定7. Kafka Producer/Consumerノードのプロパティ設定

p BasicタブØ Topic nameに⼿順5.で作成したトピック名を設定Ø Bootstrap serversに⼿順4.で控えたホスト名を設定

ü カンマ区切りでの複数指定も可能p Securityタブにて下記の通り設定Ø Security protocol: SASL_SSLØ SSL protocol: TLSv1.2


参考: Apache Kafkaに接続する際の構成p Apache Kafkaではブローカー同⼠や、クライアント(Producer/Consumer)、ツールからの接続認証にSSL

またはSASLを使⽤可能p Apache KafkaではSASLの⽅式として以下をサポート

Ø SASL/GSSAPI(Kerberos) 0.9.0.0以降Ø SASL/PLAIN 0.10.0.0以降Ø SASL/SCRAM-SHA-256, SASL/SCRAM-SHA-512 0.10.2.0以降

p セキュリティはオプションのため、平⽂でのやり取りも可能p Apache KafkaでのSASL, SSLの構成は公式のドキュメントを参照

Ø https://kafka.apache.org/documentation/#security

p IIB側の設定p ユーザーID/パスワードを使⽤して認証をする場合はmqsisetdbparmsコマンドで資格情報を登録する

Ø KafkaノードのSecurity protocolでPLAINTEXTを使⽤する場合は設定不要

p Kafkaノードのプロパティ設定p 設定項⽬はMessage Hubに接続する際と同じ

Ø BasicタブのBootstrap server: Kafkaのブローカーのホスト名:ポートを指定Ø Securityタブ

ü Security protocol: 任意のプロトコルを選択ü SLL protocol: Security protocolでSSLまたはSASL_SSLを選択した場合にはSSLのプロトコルを選択


メッセージの配信パターンとノード構成


メッセージの配信パターンp パーティションやプロデューサー、コンシューマーの構成によって、メッセージの配信パターンがある

p パターン1: 負荷分散型の配信p パターン2: 同報配信p パターン3: メッセージの順序性を保証した配信


補⾜: Kafkaの⽤語解説p 複数パーティションでの構成

p 1つのトピックは1つ以上のパーティションで構成されるØ トピック作成時にパーティション数を指定

p プロデューサーから送信されたメッセージが複数のパーティションに分散して格納されるØ プロデューサーはパーティションを明⽰的に指定して送信することも、指定せずラウンドロビンで振り分けることも可

p コンシューマーは特定のパーティションからメッセージを受信p パーティション毎にコンシューマーを⽤意することで分散処理を実現

Topic A

Partition 0

Producer

Message A

Message A (Offset 0)

Message BMessage C

Consumer

Partition 1 Partition 2Message B (Offset 0) Message C (Offset 0)

Message D (Offset 1) Message E (Offset 1)パーティション毎に送信順にオフセットが付与される

Consumer Consumer


補⾜: Kafkaの⽤語解説p コンシューマーグループ

p 接続時に指定したグループIDに従ってコンシューマー・グループを形成するØ 同⼀グループIDを指定したコンシューマー・インスタンスは同じグループに属する

p グループ内ではトピックを構成する全てのパーティションがそれぞれのインスタンスにアサインされるØ 1インスタンスが複数のパーティションを受け持つことはあるが、複数のインスタンスが1つのパーティションを受け持つことはないØ ⾃⾝にアサインされたパーティションからしかメッセージを受け取らないため、トピックに配信されたメッセージを分散して処理する事

ができる(負荷分散型)Ø 異なるグループ間のインスタンス同⼠は同じパーティションから同じメッセージを受信することになる(同報配信型)

ConsumerInst. A1 ConsumerInst. A2 ConsumerInst. A3ConsumerGroup A

CI B1 CI B2CG BGroupID:A GroupID:A GroupID:A GroupID:B GroupID:B

Topic APartition 0 Partition 1 Partition 2


パターン1: 負荷分散型の配信p ⼤量のメッセージを複数のコンシューマーで分散して処理させたい場合

p トピックは複数パーティションで構成するp コンシューマーは同⼀のグループIDを指定し、複数のコンシューマー・インスタンスを1つのグループに含めるp インスタンス数 = パーティション数とすることで、各インスタンスに均等にメッセージを分散できる

Ø いずれかのコンシューマーが障害等でダウンした場合は、パーティションのリバランスが⾏われ、ダウンしたコンシューマーが受け持っていたパーティションを別のコンシューマーが受け持つ

Topic A

Partition 0

Producer B

Message A (Offset 0)Partition 1 Partition 2

Message B (Offset 0) Message C (Offset 0)Message D (Offset 1) Message E (Offset 1)

Consumer Inst. A Consumer Inst. B Consumer Inst. CConsumerGroupA

Producer A

Message F (Offset 1)

A BED

CF


パターン1: 負荷分散型の配信 - ノード構成例p トピックのパーティション構成

p コンシューマー数と同数またはそれ以上になるように構成Ø コンシューマー数 > パーティション数の場合、パーティション数以上のコンシューマーには、割り当てられるパーティションが無いた

めメッセージを受け取らない

p Kafka Consumerノードp 任意のコンシューマー・グループIDを指定

p アプリケーションの配置p 同⼀のアプリケーションを複数の統合サーバーへデプロイ

ü コンシューマーグループ(MyGroup)の中で、そのコンシューマーが受け持つパーティションが振り分けられるMyTopic3

Partition 0 Partition 1 Partition 2

IIB統合ノード

IIB統合サーバー

IIB統合ノード


IIB統合ノード


同⼀アプリケーション

Consumer Group: MyGroup


パターン2: 同報配信p 複数のコンシューマーに同⼀メッセージを配信したい場合

p トピックは1つ、または複数のパーティションで構成p コンシューマーはそれぞれのインスタンス毎に異なるグループIDを指定して、複数のグループを構成p 各インスタンス(グループ)に同⼀メッセージが配信される

Producer B

Consumer Inst. A Consumer Inst. BConsumerGroupA

Producer A

ConsumerGroupB Consumer Inst. CConsumer

GroupC

Topic A

Partition 0Message A (Offset 0)Message B (Offset 1)

AB

AB

AB


パターン2: 同報配信 - ノード構成例p トピックのパーティション構成

p 順序性を意識する必要がある場合はパーティションは1つで構成するp 順序性を保証しない場合は、複数パーティションで構成することも可能

p Kafka Consumerノードp コンシューマー・グループIDの指定

Ø それぞれの統合サーバーで稼働するアプリケーション間でユニークなIDを指定する

p アプリケーションの配置p コンシューマーグループIDの異なるフローが稼働する為、各々のコンシューマーが全てのパーティションを受け持つ

MyTopic1Partition 0

IIB統合ノード


IIB統合ノード


IIB統合ノード



パターン3: 順序性を保証した配信p a. 全てのメッセージの順序性を保証したい場合

p トピックは1つのパーティションで構成p コンシューマーは1つのインスタンスを構成

Topic A

Partition 0

Producer

Message A (Offset 0)Message B (Offset 1)

Message C (Offset 2)

Consumer

p b. 特定の複数メッセージの順序性を保証したい場合p 複数のメッセージを論理的にグルーピングし、その中で

の順序性は保証するが、グループ間では順序性を保証しなくて良い場合

p プロデューサーがキーを使⽤してメッセージを配信することで、パーティションやコンシューマーを複数構成する事が可能

Ø 同⼀のキーを指定したメッセージは同じパーティションに送信される

Topic A

Partition 0key:A msg01 (Offset 0)key:A msg02 (Offset 1)

key:A msg03 (Offset 2)

Partition 1key:B msg01 (Offset 0)

key:B msg02 (Offset 2)

Consumer Inst. A Consumer Inst. BConsumerGroup A

Producer同じキーを指定したメッセージは同じパーティションに送信される

key:C msg01 (Offset 1)

key:C msg02 (Offset 3)


パターン3: 順序性を保証した配信 - ノード構成例p a. 全てのメッセージの順序性を保証する場合

p パーティション数1のトピックをサブスクライブする、単⼀のコンシューマーを構成Ø 構成⽅法は省略

p b. 特定の複数メッセージの順序性を保証する場合p トピックのパーティション構成

Ø パーティション数に特に制限なし(単⼀でも複数でも可)p Kafka Producerノードでの配信前にkeyをセット

Ø ローカル環境変数でkeyを設定ü Computeノードの場合

• InputLocalEnvironment.Destination.Kafka.Output.keyにセットü Mappingノード

• ローカル環境変数、Destinationツリー下にkeyの項⽬が存在しないため、ユーザー定義を作成して指定する

Computeノードでの指定例

MappingノードのDestinationツリー下にはkeyの項⽬がない

ユーザー定義を追加してkeyをセットする

ibm integration bus kafka node · 2 ©2017 ibm corporation はじめに p当資料では、iib...

Documents