全4492文字
PR

データ基盤に蓄積するデータにはマスターデータなどのほか、ストリーミングデータもある。サーバーログやセンサーデータなど1つひとつが小さく継続して生成される。分散データストリーミングプラットフォーム「Apache Kafka」を使って適切に扱える。

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

ストリーミング専用基盤を使う

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

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

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

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

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

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

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