低レイテンシでデータ漏洩のない 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 StackCOS Lite)などの可観測性ソリューションは、この作業を容易にします。必要なのは、デプロイされているテレメトリコレクター(マシン環境ならCOS Proxy、KubernetesならGrafana Agentなど)にKafkaを結びつけることだけです。

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

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

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

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

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

ニュースレターのサインアップ

Ubuntuニュースレターの配信登録

お客様が購読登録を行われる場合、以下の条件に同意されたことになります。Canonicalのプライバシーに関するお知らせ個人情報保護ポリシー

関連記事

2022年クラウド価格レポート

クラウドインフラストラクチャの選択におけるクラウド価格の影響 さまざまなクラウドプラットフォームのコストの見積もりや比較は、決して簡単ではありません。パブリッククラウドプロバイダーはリソース単価の形でサービスの定価を提示しますが、プライベートクラウドの分野で同じことをするのは至難の業です。リソース単価が明確でも総所有コスト(TCO)の完全な把握にはなりません。多くの企業は、あらゆる種類のクラウドリソースの需要を自社で計算できないからです。この結果、大手クラウドプロバイダーはTCO計算機能を用意し、顧客によるコストの見積もりやデータに基づいた決定をサポートしています。 本レポートは3部構成です。まず、2022年7月時点の大手パブリック/プライベートクラウドプロバイダーのクラ […]

Open Source MANO TWELVEによるテレコムネットワークの回復と自動拡張

2番目の長期サポート付きOpen Source MANO(OSM)リリースが到着しました。Open Source MANO Release TWELVEは、2年間のサポートとセキュリティパッチを含みます。また、MANO(Management and Network Orchestration)エコシステムに属するVNFベンダーにもシステムインテグレーターにも有利な特長を備えています。ETSI OSM(Open Source MANO)には、複数のクラウドプラットフォームと仮想インフラストラクチャマネージャー(VIM)を統合できます。サービスプロバイダーやオペレーターはOSMプラットフォームを利用し、仮想マシン(VM)またはコンテナ化されたフレームワーク(Kubernete […]

小売業界のAI/ML:ショッピングに生じた変化とは

AI/MLは小売を含め、多くの業界の現実を塗り替えています。実店舗でもオンラインショップでも、小売企業は、競争力を高め、顧客を深く理解し、いくつかの長年の問題を解決すべく、AI(人工知能)への投資を強化しています。 他の業界と異なる点は、小売業者がデータ重視型のビジネスに急速に移行し、データストリームをスピード、効率化、事業上の意思決定に活用し始めたことです。小売業者は、さまざまな形式で収集した大量の生データを、短時間で抽出、読み込み、変形し、実用的な情報を引き出します。どんなメリットがあって急速に普及しているのでしょうか? 以下に、業界の主な変化とAI/MLの活用方法をご紹介します。 小売におけるAI/MLのメリット AI/MLには小売業界の情勢を変えるだけの力がありま […]


© 2023 Canonical Ltd. Ubuntu および Canonical は、Canonical Ltd の登録商標です。