低レイテンシでデータ漏洩のない 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ソリューションの詳細はこちら。
ニュースレターのサインアップ
関連記事
Ubuntu Pro for AzureにConfidential VMを導入する
近年のクラウドエコシステムでは、堅牢なセキュリティに向けた大きな進歩として、Confidential VM(CVM)が登場しました。CVMは外部のコードによる攻撃には強いものの、境界内の脆弱性によって侵害を受ける可能性は残ります。ここに、Ubuntu ProとMicrosoft Azure上のConfidential VMの相乗効果が力を発揮します。CVMで外堀を固め、Ubuntu Proで内部をしっかりと保護することで、強度、規制への適合性、管理しやすさを備えたクラウドベースのワークロード向けの領域が形成されます。この統合は、セキュリティを大幅に強化するだけでなく、企業の要件にスムーズに対応し、実運用環境で業務用のワークロードに対応したコンフィデンシャルコンピューティン […]
Kubernetes対応のCephストレージ
相反する存在、ステートフルとステートレスが相乗効果を生み出す。 ストレージとコンテナ管理システムは、ほぼ正反対の機能を持ちます。ストレージはデータを必要な限り永続的に保存し、保護。コンテナ管理システムは変動の激しいワークロードを自動的に管理し、必要に応じてリソースを増減します。 アプリケーションのデプロイと管理については、コンテナを優先する組織が増えていますが、データを安全かつ確実に保存するという根本的な課題は依然として残っています。どのようなストレージシステムも、ハードウェアの障害から保護し、組織の最も重要な資産であるデータの可用性を維持する必要があります。 データ量は急速に増加し、1日に生成されるデータは推定で2,500ペタバイト(PB)を上回ります。幸いにも、データ […]
[Webinar] 安心したUbuntu運用に向けて
日時:2023年12月14日(木)15:00~16:00 費用:無料 Ubuntuは世界中で高いシェアを持つLinuxディストリビューションで、パブリッククラウドの隆盛やCentOSの開発打ち切り(CentOS Streamへの移行)、RHELのソースコード公開ポリシーの変更等に伴い、日本国内でも近年注目度がますます高まっています。 本Webinarでは、Canonical社 リージョナルセールスマネージャの柴田憲吾氏が、Ubuntuサポートの国内導入事例についてご紹介いたします。 そのほか、NTTテクノクロス社の経験豊富なスピーカーが、Ubuntuを商用利用する場合に重要となる、脆弱性の対応や、サーバ管理に便利なツールについても、わかりやすくご紹介いたします。 名称 【 […]