Kafka が Netflix の 1 日 2 兆件のメッセージを処理する方法

[51CTO.com からのオリジナル記事] 最初から、さまざまなマイクロサービスがさまざまな方法で相互に通信する必要があります。

[[253396]]

HTTP REST API を使用することを好む人もいますが、独自のキューの問題に遭遇する可能性があります。 RabbitMQ などの古いメッセージキューを使用することを好む人もいますが、拡張や操作などの関連する問題を考慮する必要があります。

[[253397]]

そこで、上記 2 つの問題を解決することを目的とした Kafka ベースのアーキテクチャが誕生しました。

この記事では、Apache Kafka がこれまでマイクロサービスで使用されてきた HTTP REST API とメッセージキューアーキテクチャをどのように改善し、サービス機能をさらに拡張するかについて説明します。

二つの陣営の物語

最初のキャンプでは、HTTP REST API やリモートプロシージャコール (RPC) などの他のサービスを呼び出すことによって通信が直接処理されます。

2 番目の陣営は、サービス指向アーキテクチャ (SOA) からエンタープライズサービスバス (ESB) の概念を借用し、他のサービスとの通信を担当するメッセージキュー (RabbitMQ など) をメッセージエージェントとして使用して、さまざまな操作を実装しました。

この方法では、サービス間の直接的な「通信」による通信負荷を 1 つずつ軽減できますが、ネットワーク内に余分な「ホップ」のコストが追加されます。

HTTP REST API を使用したマイクロサービス

HTTP REST API は、サービス間で RPC を実行するための一般的な方法です。その主な利点は、初期設定が簡素化され、メッセージ送信の相対的な効率が向上することです。

ただし、このパターンでは、実装者はキューなどの問題や、受信リクエストの数がノードの容量を超える問題への対処方法を考慮する必要があります。

たとえば、長いサービスチェーンがあり、そのうちの 1 つがノードの処理能力を超えているとします。

次に、この問題に対処するために、サービスチェーン内のすべての先行サービスに対して同じタイプのバックプレッシャー処理 (翻訳者注: システムはソースまたはアップストリームの送信レートを適応的に削減します) を実行する必要があります。

さらに、このパターンでは、すべての個別の HTTP REST API サービスが高可用性である必要があります。そして、さまざまなマイクロサービスで構成された長いパイプラインでは、どのマイクロサービスもそのすべてのコンポーネントを失う余裕はありません。

したがって、特定のグループ内の少なくとも 1 つのプロセスが正常に機能している限り、通信は引き続き機能します。

もちろん、通常はこれらのマイクロサービスの前に負荷分散モジュールを構成する必要があります。同時に、さまざまなマイクロサービスが呼び出しを通じてどこで通信するかを知る必要があるため、サービス検出モジュールが必要になることがよくあります。

このモードの利点の 1 つは、レイテンシが非常に低いことです。特定のリクエストパスでは仲介者の役割がほぼ排除されるため、Web サーバーや負荷分散などのコンポーネントは実戦テスト済みで、高いパフォーマンスを発揮します。

異なる RPC タイプのマイクロサービスの場合、それらの間の共通の依存関係を処理する必要があるため、すぐに非常に複雑になり、最終的には開発プロセスに影響を与えたり、開発プロセスを遅らせたりする傾向があることがわかります。

今日、業界ではいくつかの新しいソリューションも導入されています。たとえば、Envoy プロキシはサービスメッシュを使用してこの問題を解決します。

このパターンは負荷分散やサービス検出などの問題を解決しますが、単純で直接的な RPC 呼び出しと比較すると、システム全体の複雑さが大幅に増加します。

下の図に示すように、多くの企業では、最初は相互に通信する必要があるマイクロサービスが少数しかありませんが、システムが徐々に「成長」するにつれて、それらの間の呼び出し関係と通信チャネルは最終的にスパゲッティのボウルのように複雑になります。

[[253398]]

メッセージキュー

マイクロサービス間の通信を構築するもう 1 つの方法は、メッセージバスまたはメッセージキューシステムを使用することです。

以前のサービス指向アーキテクチャでは、これをエンタープライズサービスバス (ESB) と呼んでいました。通常、メッセージブローカーとして RabbitMQ または ActiveMQ が必要です。

集中型メッセージサービスとして、メッセージブローカーは、それに接続されているすべてのマイクロサービス間の通信を容易にすることができます。

同時に、キューイング処理メカニズムとメッセージサービスの高可用性の助けにより、さまざまなサービス間の通信も保証されます。

たとえば、メッセージキューのサポートにより、さまざまなメッセージを順番に受信して、システムが後続の処理を実行できるようになります。

リクエストのピークが発生し、処理能力の制限を超えた場合、システムは後続のキューを直接破棄しません。

ただし、多くのメッセージブローカーは、クラスター環境でのメッセージ配信および永続化機能にはスケーラビリティが欠けているか、制限されていることをユーザーに明示的に通知しています。

メッセージキューで注目すべきもう 1 つの領域は、エラーが発生したときにそれをどのように処理するかです。

たとえば、システムの信頼性の高いメカニズムは、メッセージ送信プロセスにおいて少なくとも 1 回は保証できますか?それとも最大で1回しか保証できないのでしょうか?

もちろん、そのセマンティクスの選択は、メッセージキューの実装によって完全に異なります。つまり、選択したメッセージとそれに伴うセマンティックルールに精通している必要があります。

さらに、既存のシステムのアーキテクチャにメッセージキューを追加すると、必然的に操作および保守する新しいコンポーネントが追加されます。

同時に、さまざまなメッセージを送信するために、ネットワークに新しい「ホップ」を追加すると、追加の遅延が発生し、Web サイトの待機も発生します。

客観的に言えば、このモデルは、さまざまなメッセージキューシステムに集中型アクセス制御リスト (ACL) を使用することで、さまざまなセキュリティの問題を簡素化します。

つまり、この集中制御方式では、さまざまなルールを一律に適用して、誰がどのようなメッセージを読み書きできるかを制限します。

集中型通信のもう 1 つの利点は、ネットワークセキュリティです。たとえば、以前は、すべてのマイクロサービスが独自に相互に通信していました。

メッセージエージェントを導入すると、すべての接続をメッセージキューサービス経由で転送し、ファイアウォールのようなルール設定を通じて他のマイクロサービス間の直接接続を除外できるため、攻撃対象領域を減らすことができます。

Kafka中心の利点

LinkedIn によって作成された Apache Kafka は、オープンソースのイベントストリーミングプラットフォームです。これまでの古いメッセージキューシステムと完全に異なるのは、送信者と受信者を完全に分離できる機能を備えていることです。つまり、送信者は送信したメッセージを誰が受け取るかを知る必要はありません。

[[253399]]

他の多くのメッセージブローカーシステムでは、送信したメッセージを誰が読むかを事前に知っておく必要があります。これにより、従来のキューイングシステムにいくつかの新しい未知のユースケースを追加することが多少妨げられます。

Apache Kafka を使用する場合、送信者によってさまざまなメッセージがトピックと呼ばれるログのようなデータストリームに書き込まれ、誰が、またはどのアプリケーションが実際にメッセージを読み取るかを気にする必要はありません。

したがって、新しいユースケースでは、新しい用途に応じて Kafka の関連トピックコンテンツをどのように処理するかを検討する余地が残ります。

Kafka の場合、送信されるさまざまなメッセージの特定のペイロードを気にする必要がないだけでなく、メッセージを任意の方法でシリアル化することもできます。

そのため、ほとんどのユーザーは依然として JSON、AVRO、または Protobuf を使用してデータ形式をシリアル化しています。

さらに、ACL を簡単に設定して、システム内のさまざまなプロデューサーとコンシューマーが読み取りまたは書き込みできるトピックを制限できるため、すべてのメッセージに対する集中的なセキュリティ制御を実現できます。

その結果、潜在的に非常に大量のデータを取り込むために、Kafka がファイアホーススタイルのデータパイプラインとして使用されることがよくあります。

たとえば、Netflix は Kafka を使用して 1 日あたり 2 兆件のメッセージを処理していると主張しています。

Kafka のコンシューマーには重要な特性があることに注目する価値があります。メッセージの負荷が増加すると、Kafka のコンシューマーは障害と容量要件の増加に応じて変化します。このとき、Kafka はコンシューマー間の処理負荷を自動的に再調整します。

開発者は、マイクロサービス内の高可用性の確保から Apache Kafka サービス自体に重点を移していることがわかります。

同様に、ストリーミングデータを処理する Kafka の運用能力も、Kafka をメッセージングシステムからストリーミングデータプラットフォームへと変革しました。