低レイテンシでデータ漏洩のない Apache Kafka サービスのデザイン

by Canonical on 10 January 2023

Apache Kafkaを使用し、低レイテンシでデータ漏洩のない大規模な実運用向けのサービス環境を設計するのは簡単ではありません。まさに究極のメッセージングシステムと言えます。このブログ記事では、適切なサービスアーキテクチャを構築できるよう、サービス設計における基本的な検討事項を紹介します。

基本から始めましょう。

Apache Kafkaソリューションの基礎サービス

基礎サービスとは、NTP（Network Time Protocol）サービス、DNS（Domain Name Services）、ネットワークルーティング、ファイアウォール、ゾーニングなどを指します。これを準備しない限り、アプリケーションのデプロイを検討することすらできません。皆さんはこう言うでしょう。「クラウドでKafkaをデプロイするから大丈夫。ここに書いてあることは関係ない。」そうとは言えません。

たとえクラウド上でも、VPC環境のネットワークルーティングが正しく設定されていること、ファイアウォールの出入りルールが適切で機能的であること、そしてネットワークゾーニングがきちんと設計されていてKafkaベースのアプリケーションの予想どおりに通信が流れることを確認する必要があります。たとえばクライアントのプロデューサーとコンシューマーは通常、クラスター内のすべてのKafkaブローカーにアクセスできる必要があります。クラウドのDNSサービス（利用するのであれば）が適切に設定されていることも確認が必要です。

オンプレミスにデプロイする場合は、おそらくNTPサービスの手配も必要でしょう。Apache Kafkaのような分散型クラスターアプリケーションでは、緊密な時間同期が極めて重要です。仮想化とCharmed OpenStackのようなプライベートクラウドソリューションを使用する場合、ゲストVMの時間が信頼性の高い安定した（理想的にはハイパーバイザクラスター外の）時間ソースに同期している必要があります。さもなければ、マシン間でタイミングに大きな差が生じ、ゲストVMの時間が前後に動くことすらあるため、Apache Kafka環境に大きな混乱が生じてしまいます。

基礎サービス計画が完了した後は、Kafkaソリューションのアプリケーションデプロイメントアーキテクチャを計画しましょう。

Kafkaのアプリケーションデプロイメントアーキテクチャ

Kafkaは、同じクラスターのノードが複数のデータセンターに分散するストレッチクラスターパターンでデプロイし、復元性を高めることができます。もちろん同じデータセンターで複数のクラスターをホストすることも可能です。たとえばプライマリとバックアップのKafkaクラスターを並べてデプロイし、クラスターを複製すれば、サービスが中断したときのダウンタイムを最小化できます。いつものことですが、ここにもトレードオフがあります。同じクラスター内のデータセンター間で複製すると、Kafka Brokerノードに障害が生じた場合、クラスターの他の場所にホストされていたパーティションを再構築するために多大なネットワーク容量を消費します。また、複数のサイト間に高性能のネットワークインタコネクトがなければ、Kafkaのプロデューサーアプリケーションで書き込み中に長いレイテンシが生じます。

あるいは、サイト固有のKafkaクラスターを複数持つアーキテクチャを検討してみましょう。サイト間では非同期にミラーリングを行います。ここでも、可用性、完全性、コストのトレードオフを考慮する必要があります。

以下の図は、3つのサイトにデプロイしたストレッチクラスターです。サイトAとサイトBはKafka BrokerとApache ZooKeeperをホストしていますが、サイトCはZooKeeperのみホストし、「スプリットブレーン」を防ぐアービターの役割を果たしています。「スプリットブレーン」は、ネットワークパーティションに生じたイベントがサイトAとサイトBを分離した場合に起こります。このとき各サイトが別サイトを失ったと仮定し、サービングを続ける（データが古くなっている可能性もあり）ため、ネットワーク接続が再確立されたときに共存不能なデータの競合が生じてしまいます。

このタイプのデプロイで重要なのはサイト間のネットワーク容量です。サイト間リンクのタイプ、リンクの総容量のほか、クラスター内複製にKafkaサービスが利用できるコミット容量など、すべて慎重に評価する必要があります。

Ubuntu Serverのホスト設計

Kafkaソリューションの総性能は、ホストサーバーのレイアウトでかなり決まります。オペレーティングシステム、メモリ容量、ストレージクラス、ボリューム、ファイルシステムはすべて、さまざまな程度でソリューションの性能に影響を与えます。

たとえばKafkaブローカーの消費者向けアプリケーション処理データの性能は、TLS（Transport Layer Security）を有効化している場合、Ubuntu Server 22.04 LTSなど、維持管理済みの安定したOpenSSL実装で配布されるLinuxベースのプラットフォームでデプロイすれば大幅に向上します。

KafkaのログデータをホストするボリュームにXFSファイルシステムなどの高性能ファイルシステムを選択すれば、この成熟したファイルシステムの安定性と性能上のメリットをKafka環境に生かすことができます。

クラスター内にある各Kafkaブローカーノードの安定性と性能を確保するには、両方のKafkaブローカー（通常、Java JVMヒープには約6GBのメモリ割り当てが必要）をホストする十分なメモリを持つシステムを設定する必要があります。Kafkaのログデータを含む有効なページキャッシュを構築できるよう、オペレーティングシステムにも十分なメモリが必要です。

そのほか、Kafka用のUbuntu Serverホストを設計する際に検討すべき点には（低レイテンシ環境だけの問題ではありませんが）、不要な特権をすべて取り消すなど、システムのハードニングが挙げられます。適切なガベージコレクターと関連の設定を使用し、OpenJDK JRE（Java Runtime Environment）のインストールを適切にチューニングする必要もあります。

負荷、レイテンシ、可用性の目標を満たすKafkaブローカーノードをデプロイできるよう、クラスターのディメンション分割に関する詳細な指針を示すことは、本ブログの範囲ではありません。しかし、これは、Kafkaサービスを自社の用途に合ったサイズに調節するための練習だと思ってください。容量の拡張が高度に自動化され、数分しかかからないエラスティッククラウドを使用する場合でも、やはりソリューションの実行にかかる総コストを理解する必要があります。ですからこの手順は省略すべきではありません。

デプロイの可観測性

当初の概念実証の段階であれ、サービスの実運用中であれ、トラブルシューティングが必要になるときは必ず来ます。このために十分なモニタリング機能と診断機能を統合しておきましょう。通常これには、syslog-ngのようなログ集計ソリューションをデプロイする、tcpdumpをネットワークトラフィック検査に使用するなど、Java JVMで数値をエクスポートし、TelegramやPrometheusのようなツールで収集および処理できるようにします。

Canonical Observability Stack（COS Lite）などの可観測性ソリューションは、この作業を容易にします。必要なのは、デプロイされているテレメトリコレクター（マシン環境ならCOS Proxy、KubernetesならGrafana Agentなど）にKafkaを結びつけることだけです。

実運用向けKafkaサービスの設計まとめ

低レイテンシ、大容量、ゼロデータ漏洩の実運用向けKafkaサービスを設計するのは簡単ではありません。しかし、包括的、計画的にサービス設計に取り組めば、ダウンタイムが少なく、しかも大規模で低レイテンシを提供する堅牢なサービスを構築できます。

Canonicalは、Apache Kafkaのデプロイに関する豊富な専門知識を持ち、オンプレミスでもクラウドでも、お客様固有のニーズに合わせて設計/調整したApache Kafka向けフルマネージドサービスを提供します。

こちらからお客様のニーズをお聞かせください。

Apache Kafkaに対応するCanonicalソリューションの詳細はこちら。