Kafkaレッドハットでミドルウェアのテクニカルサポートを担当している山下です。いうオープンソースプロダクトをご紹介します。Nativeにするためのプロダクト」です。具体的に言えば、オペレータパターンによってKafkaの運用管理を自動化するものになります。Native化」は、Kafkaだけに起こっていることではなくて、他のミドルウェア製品でも起こること、あるいは既に起こっていることです。今回は細かな機能を説明せずに、なぜ利用するべきなのかを3つのポイントから説明します。簡単にKafkaのおさらいをしましょう。Kafkaのおさらいストリーム処理のためのデファクト、といえるとても優秀なプロダクトです。クラスタリング前提の設計で、高スループットで水平にスケールします。それから、データはレプリカにコピーされ高い耐障害性を持ちます。ページキャッシュやSendfileといったLinuxの機能を利用して効率よく処理を実現します。いえ、多数のブローカー群やZookeeperの構築や設定、ネットワーク設定、トピックやパーティションのセットアップ。したことを個別のマシンやVMに対して、クラスタ全体の整合性を保ちながら、設定を行っていくのは大変な作業になります。これら運用上の設計を行い、各種の手順書や体制を整えていくのも、大きな困難を伴うものです。そこでStrimziというわけです。それではなぜStrimziを利用するべきなのでしょう。3つのポイントから説明します。1:一元管理されたリソース定義まずはじめに、StrimziではKubernetes上にリソースの定義が一元管理されます。ここにKafkaクラスタに求める姿それ自体を記述していきます。「ブローカーは20台で、Zookeeperは3台。ブローカーのメモリは32Gで、トピックの定義はこれこれ。ここでは、元々Kafkaブローカーごとに設定していた項目含む、ほぼすべての設定を完結させていきます。したリソース定義の一元化によって、設定は簡素化され、また全体的な整合性に対して問題が入る余地はなくなります。次に、オペレータパターンによる運用管理の自動化です。オペレータの実体は、運用管理者に代わってシステムを管理してくれるPodです。オペレータは、リソース定義と、現在のKafkaクラスタ状態を継続的に監視して、差分があれば、同期させるために必要なコマンドを自動的に発行します。「リソース定義上でブローカーの数を20から30に変更した場合、差分の10個を追加で構築する」ということを自動で行ってくれます。この際にもしも、通信を暗号化する設定になっていれば、暗号化のためのプロキシとなるサイドカーを生成したり、鍵を作ってクラスタ内のCAに登録する、といったコマゴマとしたことも代わって行ってくれます。結果として、運用管理者がコマンドラインツールを操作することはなくなっていきます。現時点で実際には、パーティションの再アサインメントなど、必要なコマンド実行もあるんですが、目指すところはそいういうところです。リソース定義の一元化とオペレータパターンの組み合わせは、運用管理上の、設計や、手順、それから体制の負担をかなり軽減させることになります。3:インフラはKubernetesにお任せそして最後は、ある意味当たり前なのですが、Strimziは、Kubernetesの機能を積極的に利用することで、運用管理の自動化を実現しています。共通的なインフラである、ヘルスチェック、ログ集約、メトリクスなどは、OpenShiftが提供するサービスを利用することでシステム全体の標準化にもにつながるはずです。最後にKubernetesやOpenShiftは、ミドルウェアにとって既に基本ソフトになっていて、ミドルウェアのKubernetes対応や進化は今後もさらに加速していくはずです。Strimziはオープンソースですし、オペレータパターンによりインストールも簡単です。4コマンドで新規のKakfaクラスタが立ち上がります。Native化」を体感していただければと思います。いう製品が提供されています。Hatでコンサルタントをしている織です。エンジニアリングの佐藤匡剛です。各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。