もっとも重要なシステムの柔軟性
・柔軟性を考える
ストリーミングデータは、第1回でも記載しましたが、無限に発生するデータや恒久的に継続されるデータになります。ストリーミングデータの内容や送られてくる場所、処理のタイミングなどバラバラなものになります。また、恒久的に継続されるデータであることから容量なども時間とともに膨大になっていきます。また、ストリーミングデータの種類はさまざま増えてくることが予想されるものであり、どのようにそれらを処理するかを考える必要があります。その中で発生すると考えられる最大の技術的課題の一つが処理システムの柔軟性になります。
ストリーミングデータを処理することにおいて必要な柔軟性は、システム面、インフラ面の双方で重要視しなくてはいけません。
- テクノロジー・システム面
- 異なるデータ内容に対して適切な処理ができること
- 異なるシステムから送られてくるデータを処理できること
- 異なるシステムにデータを送信できること
- 新たに処理を追加できること
- データの受け取り、データの配信をまとめて処理ができること
- インフラ面
- 複数のサーバーに処理を分散できること
- リソースを拡張できること
というような柔軟性を持つことが必要になります。特にストリーミングデータは、恒久的に継続されるデータを処理することからさまざまなシステムとの接続を作る際などに停止することができない処理が多くあります。これらの要件に対しても対応できる必要があります。
まずは、システム面です。システムに応じて異なるデータフォーマットに対して柔軟に対応できる必要があります。JSON、XML、Apache Avro、Protocol Buffersなどさまざまなデータフォーマットにてデータが送られてきます。もちろんデータの形式などは送られてくる仕組みによって異なります。データがさまざまな状態、状況であるのに対して対応する必要があります。
次に異なるシステム（プログラムやインターフェイス）からデータは送られてきます。データの取り込みは、さまざまな場所から行われます。異なるプログラミング言語で書かれたさまざまなアプリケーションサーバーやMySQLなどのDBMSや種々のミドルウェアなど、さまざまな外部システムとのつなぎ込みが必要になります。これらからデータを受け取る場合には、それぞれが提供している接続ドライバなどがあります。それらを利用できるかによっても柔軟性は変わってきます。
インフラ面においても、データが送信されてくる元や配信する先などは新たな試みをすればどんどん増えていきます。合わせてデータボリュームもデータの送信元や処理が多くなれば増えていきます。そのため、オートバランシングしたり、したりして複数のサーバーで処理できることや保持するためのデータ容量を柔軟に増やすことができるようになっていることが重要になります。
参考資料：
Apache Kafkaを使ったマイクロサービスエコシステム
https://www.confluent.io/blog/building-a-microservices-ecosystem-with-kafka-streams-and-ksql/
・Confluentにおける柔軟性
Confluent、Apache Kafkaにおいては、これらの柔軟性に関する対応が細部まで検討されています。Confluentは、ストリーミングデータプラットフォームとしてさまざまなデータ処理を行うことを想定しています。ソーシャルデータやIoTのセンサーなどに代表されるビッグデータ向けのイベント駆動型の処理、不正検知やカスタマーエクスペリエンス向上の為のミッションクリティカルなリアルタイム処理、レガシーなアプリケーションと最新のアプリケーションを結合するデータ処理、マイクロサービスアーキテクチャや分析の為のデータ処理に至るさまざまなデータ処理に対してスケーラブルに対応します。
これらの処理を実現するために、各種システムと接続するためのConnectorが各種用意されています。前述のJavaで使われるJDBCやJMS、MQ関連などさまざまなコネクタを提供しており、システム間やプロダクト間の接続を容易に実現することができるようになっています。基本的にはこのConnectorとConnectorを動作させるフレームワークであるKafka Connectを使ってデータを外部から受け取ります。Kafkaにデータを取り込んでくるデータの提供元を「Source」といい、Kafkaからデータを保存する先を「Sink」といいます。これらの処理を行うためのさまざまなConnectorをConfluent社のサイトなどで提供しています。
参考資料：
Confluent Hub
https://www.confluent.io/hub/
これらの処理をConnectorを使ってKafkaとの接続を容易に行えるため、さまざまなデータ種別やソフトウェアに対して簡単につなぎこむことができます。
次にKafkaは、データを受け取り、それらを配信する際に「Topic」で種別管理を行いBrokerにて保持します。Kafkaはデータの論理的なまとまりとして、Topicという単位で管理を行います。ひとつのKafkaクラスタにTopicは任意数作ることができ、Kafkaにデータを書き込んだり、読みだしたりする際はこのTopicを宛先として行います。
データを受け取る、配信するという双方の処理を効率的に行うために一つの処理で効率的にデータの送配信を実現する仕組みを保持しています。
・データの堅牢性への対応
さまざまなデータを受け取り、配信する仕組みを支えるには障害時への対応なども重要な要素になります。そこにはデータを複数台に冗長化して保持する構成をとることができるという部分とデータの永続化があります。
まず、データの保存、配信を行うBrokerが一つの重要な役割を持っていますが、KafkaはBrokerを複数台でクラスタ構成することが可能になっています。これにより障害が発生した際にも別のサーバーにて稼働しているBrokerを介してデータの送受信を継続することができます。Kafkaを利用する上では複数のTopicがある状態を保つのが一般的で複数台のサーバーにBrokerを配置して保存と配布を実行します。これにより、耐障害性への対応もスループットの向上も期待することができます。これらのレプリカの保持については設定で行うことができ、システムの状態に合わせて柔軟に対応することができます。
さらに、Kafkaではストリーミングデータをディスクへ永続化することができます。受信して配布したら消えてしまうのではなく、ディスクに保持しているため、再送信の処理などを行うことができます。これによりデータの再処理などを行うことができるようになっています。データを受け取るConsumerは、Brokerにデータが残っていればその内容を指定することでデータを読み出すことができます。この処理は、データを保持している時間やデータサイズなどで制御することができ、無駄に保持し続けないなどシステム全体の可用性を考えた形で保持しています。これらの処理が実現できることにより、インフラ面などにおける柔軟性をしっかりと持って大量のデータの送受信を可能としています。
データの堅牢性を保つための機能についても、データのレプリケーションやと持続性を担保するなどの機能が提供されています。インフラ面においては、オンプレミスで自社のデータセンターにて実装する形とCloudで提供されているマネジドサービスを利用する形の双方を利用することができます。
ストリーミングデータという永続的に配信されてくるデータを処理する際にはデータを処理する際に必要な柔軟性と障害時などに処理が継続されるようにするための柔軟性の双方が必要になり、それらをKafkaをベースにしたConfluent Platformは実現しています。
参考資料：
Kafkaを利用した複数データセンターでのレプリケーション
https://www.confluent.io/blog/enterprise-streaming-multi-datacenter-replication-apache-kafka/
まとめ
現在は、データの重要性は日に日に増しており、柔軟性を持ったプラットフォームを構築することも重要な要素になっています。Kafkaは、TopicやConectorという機能で、さまざまなデータ種別を扱える、さまざまなソフトウェアとつなぎ込めることという部分と、マシントラブルなどの際にも可用性やデータの堅牢性を保てるという柔軟性の高いソフトウェアであることを紹介しました。
次回は、データのやり取りが重要になってきている現在においてデータハブとしてConfluent、Kafkaを利用するための技術的な課題について解説します。
