Confluent Japan Community Blog

Confluent Japan Community が提供するストリーミングデータを扱うConfluent、Apache Kafkaに関する情報を提供します。

Confluent Japan Community が提供する apache Kafka および Confluent に関するブログ

Kafkaプラットフォームの運用

- さまざまなデータを処理することの重要性 -

 

・Kafkaの運用

Kafkaはオープンソースのであるため、自社のインフラにて運用することができます。前述のようにKafkaは、スケーラビリティや耐障害性といった特性を持っていることから基本的には複数台で運用を行わないとそれらの特性を生かすことができません。

Kafkaクラスタは、1台以上のBrokerで構成されます。複数台で構成する際にBrokerの分散処理管理のためにZooKeeperが存在します。

クラスタを組む場合は、少なくとも3台以上で構成する必要があります。

Kafkaは、耐障害性が高いソリューションであるが、大量のデータ処理を行うソリューションであることから適切な運用が不可欠です。運用を行う上ではKafkaにて行っているデータの取り込み、集積、提供などといった動作において問題が起きていないかなどを監視します。また、監視だけではなくスケールする際にはインフラの追加などを行う必要があります。企業によっては、Kubernetesなどを利用してオーケストレーションするなども考えると思います。膨大なデータを扱うKafkaは、強力なインフラで支えられている必要があります。Kafkaを利用してストリーミングデータを処理する仕組みを構築した際に、監視はしているがエラーは起きた際に対処がうまくできないやインフラのスケールにおいての問題に直面したりすることがあると思います。
実際にGoogleなどで検索すると、LINEやYahoo! JAPAN などで運用している大規模なKafkaのプラットフォームにてさまざまな技術的な課題があり、それらに対しての対処の内容などを確認することができます。

f:id:Confluent:20190329100654p:plain

参考資料:

エラーハンドリングとデッドレターキュー

https://www.confluent.io/blog/kafka-connect-deep-dive-error-handling-dead-letter-queues

Apache KafkaとKubernetes

https://www.confluent.io/blog/apache-kafka-kubernetes-could-you-should-you

 

Confluent社は Apache Kafka をベースにしたストリーミングプラットフォーム「Confluent Platform」を提供している会社です。Confluent社は、プラットフォームの提供だけではなく、運用監視を行うツールであったり、運用におけるサポートを提供しています。Kafkaをベースにしたパッケージであるため、Kafkaを利用してサービスを提供した際に直面する問題であったり、インフラにおける問題などに直面した場合は、Confluent社が提供しているサービスを利用することでそれらを解決し、安定したサービス提供を行う流れを検討するのも一つの流れと考えます。Confluent Platform には大きく3つの構成があります。

 

  • Confluent Open Source(Confluent Community License)
    • Apache Kafka をベースにし、Rest Proxy や KSQL などの仕組みやConfluent Connector などを合わせて提供しているオープンソースのパッケージ。

  • Confluent Enterprise
    • Confluent社が独自に提供するエンタープライズ向けのサービスを付加し、商用のサポートを合わせて提供するサービス。自社のデータセンターなどに導入したい企業向けに提供されているオンプレミス環境向け。

  • Confluent Cloud
    • AWSGoogle Cloud PlatformにConfluent Enterpriseとほぼ同機能のものを配備し、マネージドサービスを追加したエンタープライズ向けのサービス。インフラ環境なども含めてConfluent社のマネジメントサービスを利用することができます。

 

Confluent社のサービスの全体像は以下のようになっており、Kafkaをメインにして付随するサービスを数々提供しています。Confluentのオープンソース版と異なる点は、運用を行う上で対応すべきさまざまな内容について組み込まれている部分が大きくあります。

f:id:Confluent:20190329100752p:plain

Confluent Enterprise については、Apache Kafkaに実装された強固なセキュリティ機能に加えて、LDAPなどの外部システムとの連携がサポートされていること以外に以下のサイトにあるように大きく4つの機能が提供されます。

URL:https://www.confluent.io/subscription/

 

  • 複数データセンターにおけるレプリケート
    • 複数のデータセンター間でデータを共有できます。複数のデータセンターにアプリケーションがデプロイされている場合などにおいても、それぞれのデータセンターにあるKafkaクラスタを通じて保持するデータを同期することができます。
  • データの自動分配
    • Kafkaサーバー間でのデータリソースの自動分配をして負荷などを均一化します。
  • クラウドマイグレーション
    • オンプレミスとクラウド間のデータ移行を可能とし、必要に応じてクラウド側とのデータ共有を行えます。
  • コントロールセンター
    • データパイプラインをGUIを用いて作成したり、稼働している内容における処理がどのような状態になっているかを可視化してダッシュボード表示したりできます。

 

これらの機能が提供されており、更に24時間365日のサポートや優先的なパッチの提供などがあります。大規模でKafkaのプラットフォームを利用する場合においては、テクニカルのサポートはもちろん、これらの運用時における問題などを細かくサポートしてもらえるサービスがあると低コストでの運用が可能です。

クラウドサービスを利用する利点

さまざまな企業がクラウドサービスを提供していますが、これらのサービスを利用するべきなのか、自社で対応するべきなのかについては、色々な視点から検討する必要があります。

まずは、クラウド型のサービスを導入する際に受けられるメリットを確認します。クラウドを利用することの一番のメリットは、表側には見えてこないサンクコストが含まれたサービスであることにあります。自社でインフラを設置して対応するためには、インフラの用意及びそのインフラを運用しなくてはいけません。クラウドサービスを利用することで、これらインフラの調達、設定、運用のすべてのインフラに関する作業を提供してもらえることに一つのメリットがあります。

次にサービスインや開発をスタートするスピードになります。今はクラウドサービスを利用してインフラを簡単に調達することができるため、インフラの設置は以前のように時間がかかるものではありませんが、それでも別々で対応するには時間がかかります。クラウドサービスを使うことで契約締結から時間を要さずに利用できるインフラおよびシステムがセットアップされることもクラウドサービスを利用する利点になります。これらがソフトウェアをオンプレミスで行う際にはソフトウェアの費用とは別に必要になる作業やコストになります。

Confluent社においてもクラウド型のサービスを提供しています。Confluent Cloudにおけるサービスのポイントは以下になります。

 

  • 専門チームでマネジメントされ、SLA99.95%で提供
  • 適切なインフラパフォーマンスを提供
  • オンプレミスとの複合利用やマルチクラウドでの提供が可能

 

詳細は以下を参照ください。

https://www.confluent.io/confluent-cloud/

 

Confluent Cloud の利点は、さまざまな形式で導入できることにあります。オンプレミスとクラウドを組み合わせるハイブリッドクラウド形式、異なるクラウドサービスを組み合わせるマルチクラウド形式、一つのクラウドで導入するクラウドオンリー形式の3つの形式で導入を検討することができます。例えば社内でありとあらゆるデータを共有しており、社外ネットワークに出せないものをオンプレミスにて行い、社外のデータについてはクラウドで対応するなどといったことが可能になります。

f:id:Confluent:20190329100858p:plain



参考資料:

クラウド導入をどこからはじめるのか

https://www.confluent.io/blog/streaming-in-the-clouds-where-to-start 

・導入のための検討

オンプレミスにて導入するのかクラウドを利用するのかという部分は、企業の状況やポリシーなどから検討するものになります。特にKafkaを利用してデータのストリーム処理を行う場合にはそこを流れるデータが何であるのかなども含めて検討しなくてはいけません。検討すべき内容としては以下の内容になります。

 

  • 現在のシステム運用における検討
  • 見えないコストの検討
  • 扱うデータにおける検討

 

現在運用しているシステムがあり、そこで運用も含めたシステムが稼働しているような状態では、オンプレミスでそこに入れる方式も検討できると思います。前述のようにConfluent Cloud はオンプレミスからデータを取得することも可能なため、後述する扱うデータによっては現状のシステム運用に関係せずにクラウド利用を検討することもあるかもしれません。

見えないコストについては、現在運用しているシステムに応じるものかもしれませんが、いわゆるインフラ構築の費用や、新たに追加される運用において今までの運用とは別にコストがかかってくる部分があると思います。ソフトウェアの費用とは別にかかってくるこれらのコストについて、どのように考えるかがどちらを利用するかということの検討にあたると思います。Kafkaで扱うデータはストリーミングデータがメインになってきます。これらのデータ処理は今まで行ってきた処理とは異なる処理になりますので同じ運用に乗せることができるのかも含めて検討する必要があります。

最後に、扱うデータにおける検討です。Confluent Platfomを社内のサービスを対象としたデータの収集配信用途で使う場合は、もちろんクラウドを利用して外の仕組みを使ってデータのやり取りを行う必要はないと考えます。また、その導入後に外のデータも利用する拡張を行いたい場合においても、前述のようにハイブリッド型にて導入することが可能です。逆に外のデータの収集を行い、そのデータをAWSGoogleビッグデータ基盤にストアする場合であれば、Kafkaのプラットフォームも併せて同じ基盤上で運用することも考えられます。ポイントとなるのは、将来の拡張はKafkaを利用することで一定の考慮がされており、最初に導入した形式に影響されてその後の導入や拡張において連携ができないなどが起きないということです。

 

実際に現在Confluentを利用している企業の多くはオンプレミスで運用をしています。もちろんクラウド版が提供されたのが2017年であることも影響されていますが今後の拡張においてクラウド版を利用する企業が増えてくると予想されます。

f:id:Confluent:20190329101206p:plain

参考資料:

AWSクラウドへのマイグレーション

https://www.confluent.io/blog/want-migrate-aws-cloud-use-apache-kafka/

まとめ

システムの導入は、現在の状況だけではなく、将来における拡張も含めて慎重に検討するべきポイントになります。機能的な部分で将来を予測することは非常に難しいですが、インフラも含めた全体像における拡張性を持っているかどうかは重要な要素になります。Confluentの基盤は企業のデータの扱いに合わせて柔軟に対応することのできる機能を持っていることが選定を柔軟に検討できるポイントになります。

次回は、Confluentの重要な機能であるKSQLについて解説します。