データハブとしての活用
・データハブの必要性
データハブという言葉には、明確な定義があるわけではないが、さまざまなシステムからデータを収集して集め、必要とされるシステムからの要求に応じて提供可能な、高い信頼性とスケーラビリティを持ったシステムと考えることができます。
データの必要性が日に日に増している現在において、自社もしくは第3者データなどを取得して利用することは、企業のビジネスの拡大においては必要な要素になります。レガシーなシステムが徐々にオープン化されてきてデータをより効率的に利用できる状況になっていますが、現在においてはレガシーなシステムのデータをどのように活用するかだけではなく、今まで取得できなかったデータが取得できるようになった結果、複数の異なるデータに関連を見出して分析するなど、以前よりも活用の可能性が広がっています。そういった各種さまざまなものからデータを取得だけでなく、集積、配信もすることができるデータハブは多種多様なデータを取り扱う上では必須の要素です。
・データハブにおける課題
前回の記事でも書きましたが社内ではさまざまなシステムが存在しており、それらを接続するには、システム間やプラットフォーム間でのデータ連携を行える必要があります。Kafkaでは、これらに対応する柔軟性があるため、この部分はクリアしやすい課題になります。
次にこちらも前回の記事で書きましたが、データのロストが許されないことやタイミングや仕組みが別々であるという部分も課題になります。そういったこともKafkaでは、データの永続化や複数のConnectorを提供していることから解決可能な課題になります。
今、企業は自社の点在するデータや第3者データなどいろいろなところにあるデータを取り込み、集積し、そのデータを必要な形式に加工して必要なところに提供することで今までできていなかったさまざまなサービスや効率化を実現することができるようになり、その取り組みに力を注いでいます。
しかし、それらのデータを使いたいところとどんどん接続していけば、以下の図のようにさまざまなシステムとの連携が発生し、N:Nの接続になっていきます。今後も接続するデータは増えていき、すぐに全体像の把握ができなくなり、管理不能に陥ったりするのがわかります。
上記のような密結合されたアーキテクチャには、以下のようなさまざまな問題を引き起こります。
- 送り先の障害が送り元に波及する。
- バッファがないため、送り元で発生したワークロード（瞬間的なBurstingなど）が送り先にそのまま波及する。結果受けきれなかったデータがロストする。
- 送り元が複数の送り先に対して、同じようなデータを何度も送る必要があり、リソースの効率が悪い
Kafkaを導入することでデータの送信元はKafkaに必要なデータを放り込むことで対応が完了し、受け取る側もさまざまなシステムからデータを受け取るのではなく、Kafkaから必要なトピックを指定して取得すればよい形になります。
このようなアーキテクチャが可能になることからデータハブが不在な状態で問題になるデータの種別やどの部署がどこにどういったデータを持っているかなどを考えなくてもよくなり、サイロ化が起きることを防いでくれます。
Kafkaを導入することでシンプルになるアーキテクチャ
また別の課題としては、あとあと連携するシステムが増えることにあります。接続する仕組みは将来にわたって増えていき、その都度接続を新たに追加する必要があります。しかし、システムを追加する際にシステムを停止することができないことが多くあります。ストリーム処理ではリアルタイムデータを分析して、そのデータを利用したアクションをしていることからデータが止まるとアクションすべてが止まる状態になってしまいます。そのため、既存で動作しているデータの送受信処理をしながら新たな処理を追加していく必要があります。
Kafkaでは、データを信頼性を担保できる形で保存するBrokerがProducerからデータを受け取り、Comsumerからの要求に応じてデータの提供を行います。Kafkaをデータハブとして用いる場合に新たな処理は、Topicに対してComsumerを追加する形になります。KafkaはTopicのデータを永続して保持しており、それぞれのComsumerが処理した地点（offset）を管理しています。また、単一のTopicについて複数のComsumerが存在できるという特性もあります。新たにComsumerをTopicに追加した際にはそのComsumerは遡ってデータを取得して利用することができます。この特性が将来にわたって連携するシステムが増えても連携やそれまでのデータの取得など柔軟に実現することができるKafkaの大きな特徴になります。
・マイクロサービスの基盤としても利用
ここ最近のアーキテクチャの流れとしてデカップルドアーキテクチャという言葉がよく聞かれます。機能単位で分解して保持し、必要なときに必要な機能を呼び出す流れになります。これらの流れはリアルタイムにデータを呼び出し行う仕組みであり、表現の柔軟性や機能の再利用性、機能の独立性など利点があり使われてきているアーキテクチャになります。
以下の図のように、マイクロサービスにてさまざまな機能を構築してつなぎ合わせる仕組みが考えられます。機能を実行するために必要な処理をKafkaのTopicにセットすることで、リアルタイムにそのTopicからデータの取得し、必要なデータを取得してレスポンスを生成します。このような形でバックエンドやその他さまざまな個所にあるデータをKafkaを通じて取得する形で構築することもできます。
このようなアーキテクチャを構成するメリットは前章で述べたものと同様ですが、Kafkaはより高い信頼性が求められるユーザーに直面したサービスレイヤーでも広く利用されています。
参考資料：
ストリーミングアプリケーションの構築
https://www.confluent.io/blog/stream-processing-part-1-tutorial-developing-streaming-applications
まとめ
多くのデータの提供元、利用先がある中で実践的かつ効率的なアーキテクチャを構成するためには、データハブが必要になります。Kafkaを用いることでデータの提供元になるシステムと利用先のシステムを疎結合に保ち、アーキテクチャをシンプルにするとともに、ワークロードの分離やデータの耐久性、送達保証を実現し、新たな処理の追加にも柔軟かつ低いコストで対応が可能です。
次回は、Confluentが提供しているサービスについて解説します。
