全5484文字
PR

 データ基盤に蓄積するデータは、データベース(DB)に記録されるアプリケーションのトランザクションデータやマスターデータだけではありません。サーバーログ、IoT(インターネット・オブ・シングズ)のセンサーデータなど、1つ1つが小さく継続的に生成される「ストリーミングデータ」も対象となります。今回はオープンソースの分散データストリーミングプラットフォームとして多くの企業で利用されている「Apache Kafka」について、その特徴や活用パターンを取り上げます。

なぜ分散ストリーミングプラットフォームを使うのか

 従来、個別のシステムで生成、蓄積されたデータをデータ基盤やその他のシステムと連係するにはバッチ処理の利用が一般的でした。バッチ処理は実装が比較的容易なものの、バッチ実行タイミングまで連係先ではデータを利用できません。連係先、連係元の数が増えると、相手先ごとの要件に合わせた追加開発や実行タイミングの調整が必要になるなど、管理が複雑化する傾向にありました。

ストリーミングデータは随時発生
ストリーミングデータは随時発生
図 バッチ処理とストリーミング処理の比較
[画像のクリックで拡大表示]

 最近では、IoTにおけるセンサーデータや、アプリケーションやサーバーのログのように、絶え間なく生成され続けるデータを、リアルタイムでデータ基盤に収集し、分析するニーズも高くなっています。しかし、データ基盤側ではデータレイクやデータウエアハウス(DWH)など、大規模データの格納や分析ワークロードに強みを持ち、1つひとつが小さく高頻度で発生する処理には向かないプロダクトを採用することが多い状況があります。データ基盤側で多数のクライアントや高頻度で生成されるデータをリアルタイムに接続・送信しようとすると、処理能力不足によりデータをロストすることがあるといった課題もありました。

 このような課題の解決に、Apache Kafkaのような分散データストリーミングプラットフォームが寄与します。データソース群とターゲット群をつなぐデータパイプラインの役割を担うことで、データ転送の構造がシンプルになり、データソースからの受け入れ能力の向上、確実な送受信などを実現します。

 サービス間のメッセージングキューとしての利用も可能です。各サービス間のメッセージのやりとりをすべてREST(Representational State Transfer)ベースとする場合、相手先サービスが正常稼働している前提での通信となります。送信先に負荷が集中した際のハンドリング、障害発生時の対応、連係すべきメッセージの欠落への対応などは、原則「送信元」に委ねられます。

中継基盤を介在し疎結合に
中継基盤を介在し疎結合に
図 多対多におけるデータ連係集約化
[画像のクリックで拡大表示]

 ここでApache Kafkaのような高可用性・高性能のメッセージキューサービスを介在させて疎結合にすることで、メッセージの送信元はApache Kafkaに届けるまでの責任だけを持てばよく、メッセージ送信先システムの状態に依存しなくて済みます。メッセージ送信先システムでは、自らの適切な処理速度でメッセージキューの内容を取得して処理を進め、障害時のリトライなどは、メッセージ送信先システムの責任範囲として扱えます。