Kafka は人気のあるメッセージ キュー ミドルウェアです。大量のデータをリアルタイムで処理でき、高スループット、低レイテンシ、信頼性の高い非同期メッセージ伝送メカニズムという特徴を備えています。異なるシステム間のデータ通信および転送の問題を効果的に解決できます。 Kafka は Mafengwo でも広く使用されており、多くのコアビジネスをサポートしています。この記事では、Mafengwo ビッグデータ プラットフォームでの Kafka の適用実践に焦点を当て、関連するビジネス シナリオ、Kafka 適用のさまざまな段階で発生した問題とその解決方法、および将来の計画について説明します。 1. 応用シナリオ ビッグデータ プラットフォームにおける Kafka のアプリケーション シナリオの観点から見ると、主に次の 3 つのカテゴリに分けられます。
主な用途を下図に示します。 2. 進化の道 1. 4つの段階 初期のビッグデータ プラットフォームがビジネス ログ収集および処理システムとして Kafka を導入した主な理由は、その高スループット、低レイテンシ、複数のサブスクリプション、データ バックトラッキングなどの特性により、ビッグデータ シナリオのニーズをより適切に満たすことができるためです。 しかし、業務量の急激な増加や、登録メカニズムや監視メカニズムの不完全性により問題をすぐに特定できない、一部のオンラインリアルタイムタスクが失敗してもすぐに回復せずメッセージのバックログが発生するなど、業務利用やシステムメンテナンスで発生した問題により、Kafka クラスターの安定性と可用性が課題となり、いくつかの重大な障害が発生しました。 上記の問題を解決することは私たちにとって緊急かつ困難なことです。ビッグデータ プラットフォームで Kafka を使用する際のいくつかの問題点に対応するため、クラスターの使用からアプリケーション層の拡張まで、一般的に次の 4 つの段階を含む一連のプラクティスを実行しました。 フェーズ1: バージョンアップグレード プラットフォームデータの生成と消費におけるいくつかのボトルネックと問題に焦点を当て、現在の Kafka バージョンの技術的な選択を行い、最終的にバージョン 1.1.1 を使用することを決定しました。 フェーズ2: リソースの分離 ビジネスの急速な発展をサポートするために、複数のクラスターの構築とクラスター内のトピック間のリソース分離を改善しました。 フェーズ3: 権限制御と監視アラート まず、セキュリティの面では、初期の Kafka クラスターは裸の実行状態にありました。複数の製品ラインで Kafka を共有しているため、他の事業のトピックを誤って読み取ることでデータセキュリティの問題が発生する可能性が高くなります。そこで、SASL/SCRAM + ACL に基づく認証機能を追加しました。 監視と警告の面では、Kafka は現在、リアルタイム コンピューティングの標準入力データ ソースとなっているため、ラグ バックログとスループットは、リアルタイム タスクが正常であるかどうかを示す重要な指標となっています。そのため、ビッグデータ プラットフォームは、Kafka クラスターとユーザーを多次元で監視するための統合 Kafka 監視およびアラーム プラットフォームを構築し、「Radar」と名付けました。 フェーズ4: アプリケーションの拡張 Kafka を会社のさまざまな事業ラインに公開した当初は、統一された使用仕様がなかったため、一部の事業部門で誤った使用が行われていました。この問題を解決するために、当社はリアルタイムサブスクリプションプラットフォームを構築し、アプリケーションサービスを通じてビジネス関係者に力を与え、データ生成および消費アプリケーション、プラットフォームユーザー認証、ユーザー監視およびアラームなど、多くのリンクのプロセス自動化を実現し、需要側の使用から総合的なリソース管理および制御までの全体的なクローズドループを作成しました。 以下にいくつかの重要なポイントを紹介します。 2. コアプラクティス 1) バージョンアップグレード 以前、ビッグデータ プラットフォームでは、初期の Kafka バージョン 0.8.3 を使用していました。現時点では、Kafka の最新の公式リリースは 2.3 です。したがって、バージョン 0.8 を長期使用する際に発生する多くのボトルネックや問題は、バージョン アップグレードによって解決できます。 たとえば、以前のバージョンで発生した一般的な問題は次のとおりです。
同時に、次のような対象バージョンの機能に関する選定調査を実施しました。
バージョン1.1、保守性が向上しました。たとえば、コントローラーがシャットダウンするときにブローカーをシャットダウンする場合、以前は長くて複雑なプロセスでしたが、バージョン 1.0 では大幅に改善されました。 最終的にバージョン 1.1 が選択された理由は、Camus と Kafka のバージョン間の互換性と、バージョン 1.1 が使用シナリオで重要な新機能をすでにサポートしているという事実に基づいています。ここでは、Linkedin によってオープンソース化されている Camus コンポーネントについて簡単に説明したいと思います。当社のビッグデータ プラットフォームでは、主に Kafka データを HDFS にダンプする重要な方法として使用されます。 2) リソースの分離 以前は、ビジネスの複雑さと小規模さのため、ビッグデータ プラットフォームの Kafka クラスターの分割は比較的単純でした。その結果、一定期間が経過すると、会社のビジネスデータが混在することになります。特定のビジネストピックを不当に使用すると、一部のブローカーに過負荷が発生し、他の通常のビジネスに影響を及ぼす可能性があります。一部のブローカーに障害が発生した場合でも、クラスター全体に影響が及び、企業全体の業務が利用できなくなるリスクが生じます。 上記の問題に対応するために、クラスター変換の 2 つの側面が実装されました。
①クラスター分割 複数の Kafka 物理クラスターは機能ディメンションに従って分割され、ビジネスを分離し、運用と保守の複雑さを軽減します。 最も重要な追跡データの使用例を挙げると、現在は 3 種類のクラスターに分かれています。各クラスターの機能は次のように定義されます。 ログ クラスター: 各端からのデータが収集された後、最初にこのクラスターにデータが配置されます。したがって、Kafka の問題により収集プロセスを中断することはできず、Kafka の可用性に対する要件が高くなります。したがって、クラスターは、消費者がそれを制御できるようにするために外部サブスクリプションを提供しません。同時に、クラスター事業はオフライン収集の源としても機能します。データは Camus コンポーネントを通じて 1 時間単位の粒度で HDFS にダンプされます。この部分のデータは、後続のオフライン計算に使用されます。 フルサブスクリプション クラスター: このクラスターのトピック内のデータのほとんどは、ログ クラスターからリアルタイムで同期されます。前述のように、ログ クラスター内のデータは一般に公開されていないため、消費とサブスクリプションはクラスター全体で管理されます。現在は主にプラットフォーム内のリアルタイムタスクで使用され、複数の業務ラインのデータを分析し、分析サービスを提供しています。 パーソナライズされたカスタマイズされたクラスター: 前述のように、ビジネス ニーズに応じてデータ ログ ソースを分割および結合できます。カスタマイズされたトピックもサポートしています。クラスターは、転送後のトピックのランディング ストレージのみを提供する必要があります。 クラスターの全体的なアーキテクチャは次のように分類されます。 ② リソースの分離 トピックのトラフィック サイズは、クラスター内のリソース分離の重要な基礎となります。たとえば、当社のビジネスでは、大量の POS ログを持つ 2 つのデータ ソースは、バックエンドの POS データ ソースであるサーバー イベントと、エンドの POS データ ソースであるモバイル イベントです。 2 つのデータを格納するトピック パーティションをクラスター内の同じブローカーのノードに割り当てることは避けたいと考えています。異なるトピックを物理的に分離することで、ブローカー上のトラフィックの偏りを回避できます。 3) 権限制御と監視アラーム ①権限制御 冒頭で述べたように、初期の Kafka クラスターはセキュリティ検証が設定されていない裸の状態であったため、ブローカーの接続アドレスがわかっていれば生成と消費を実行でき、深刻なデータ セキュリティの問題が発生していました。 一般的に、SASL を使用するユーザーは Kerberos を選択します。ただし、プラットフォーム上の Kafka クラスターの使用シナリオでは、ユーザー システムは複雑ではなく、Kerberos を使用するのはやややりすぎです。同時に、Kerberos は比較的複雑であり、他の問題を引き起こすリスクがあります。また、暗号化に関しては、すべてイントラネット環境で実行されているため、SSL暗号化は使用されていません。 最終的なプラットフォーム Kafka クラスターは、SASL/SCRAM + ACL の軽量な組み合わせに基づいて SASL を認証方法として使用し、ユーザーの動的な作成を実現してデータのセキュリティを確保します。 ② 監視アラーム これまで、クラスターを使用すると、消費者向けアプリケーションのパフォーマンスが理由もなく低下することがよくありました。問題の原因を分析すると、通常、遅延しているコンシューマーによって読み取られたデータがページ キャッシュにヒットしない可能性が高く、ブローカー側のマシンのカーネルが最初にディスクからデータを読み取り、ページ キャッシュにロードしてから、結果をコンシューマーに返すことになります。これは、書き込み操作を処理できたはずのディスクが、データの読み取りを必要とすることになり、ユーザーの読み取りと書き込みに影響し、クラスターのパフォーマンスが低下することに相当します。 このとき、遅れている消費者向けアプリケーションを見つけ出し、事前に介入して問題の発生を減らす必要があります。したがって、監視と警告はプラットフォームとユーザーの両方にとって非常に重要です。以下は私たちの実践的なアイデアの紹介です。 全体的な解決策:
監視について:
アラートについて: レーダー システム: Falcon と Eagle を通じて Kafka インジケーターを取得し、設定されたしきい値に基づいてアラームを生成する独自開発の監視システム。消費パターンを例にとると、ラグは消費が正常かどうかを測る重要な指標となります。 Lag が増加し続ける場合は対処する必要があります。 問題が発生した場合、コンシューマー管理者だけでなくそのユーザーもそれを知る必要があるため、アラーム システムでもユーザーに通知する必要があります。具体的な方法は、企業向け WeChat アラーム ロボットを通じて、対応するコンシューマー グループの担当者またはユーザーと Kafka クラスターの管理者に自動的にリマインドすることです。 監視例: 4) アプリケーションの拡張 ①リアルタイムデータサブスクリプションプラットフォーム リアルタイム データ サブスクリプション プラットフォームは、Kafka の使用状況の完全なプロセス管理を提供するシステム アプリケーションです。データ生成および消費アプリケーション、プラットフォーム ユーザーの認証、作業指示の承認によるユーザーの監視とアラームなど、多くのリンクを自動化し、統一された管理と制御を提供します。 中心となる考え方は、Kafka データ ソースの ID 認証と権限制御に基づいてデータ セキュリティを強化し、Kafka ダウンストリーム アプリケーションを管理することです。 ②標準化された申請プロセス 生産者や消費者のニーズに関係なく、ユーザーはまず作業注文の形でサブスクリプション申請を提出します。申込情報には、事業内容、テーマ、申込方法等の情報が含まれます。作業指示書は最終的に承認のためにプラットフォームに転送されます。承認されると、ユーザーには承認されたアカウントとブローカー アドレスが割り当てられます。この時点で、ユーザーは通常の生産と消費を実行できます。 ③ 監視と警報 プラットフォームの場合、権限はリソースにバインドされ、リソースはプロダクション用の Topics または消費用の GroupTopic になります。権限が割り当てられると、これらのリソースの使用は、リソースのライフサイクル全体を監視するためのレーダー監視システムに自動的に登録されます。 ④データ再生 データの整合性と正確性を考慮すると、Lamda アーキテクチャは現在、ビッグデータでよく使用されるアーキテクチャです。しかし一方で、Lamda アーキテクチャには、リソースの過剰な使用や開発の難易度の高さなどの問題もあります。 リアルタイム サブスクリプション プラットフォームは、消費者グループに任意の場所のリセットを提供し、時間、場所などによるリアルタイム データの再生をサポートし、Kappa アーキテクチャ シナリオをサポートして上記の問題点を解決します。 ⑤テーマ管理 トピック管理を提供する理由は何ですか?簡単な例を見てみましょう。たとえば、ユーザーにクラスター上で独自の Kafka トピックを作成させたい場合、当然、ノード上で直接操作させたくはありません。したがって、前述のサービスの場合、ユーザー向けであれ管理者向けであれ、誰もが SSH 経由でサーバーに接続することは不可能であるため、操作するためのインターフェースが必要です。 そのため、統一されたエントリを作成し、トピックの作成、リソース分離の指定、トピックのメタデータ管理などのトピック管理サービスを導入するための管理機能を提供するサービスが必要です。 ⑥データ転用 以前のアーキテクチャでは、ユーザーによる Kafka データ消費の粒度は、各 Kafka トピックが LogSource の完全なデータを格納するというものでした。ただし、使用時には、多くのコンシューマーは各 LogSource のデータの一部のみを消費する必要があります。これは、特定のアプリケーションの複数の埋め込みイベントのデータである可能性があります。下流のアプリケーションが独自のフィルタリング ルールを記述する必要がある場合、リソースが無駄になり、使いやすさに問題が生じることは間違いありません。さらに、複数のデータ ソースを結合して使用する必要があるシナリオもあります。 上記の 2 つの状況に基づいて、ビジネス ニーズに応じてトピックの分割、マージ、カスタマイズを実装し、データ ソース間のデータ マージと、アプリ コードとイベント コード条件の任意の組み合わせに対するフィルター ルールをサポートしています。 3. フォローアップ計画 1. データ重複の問題を解決します。現在のプラットフォームのリアルタイム ストリーム処理における障害回復などの要因によって発生するデータ重複の問題を解決するために、Kafka のトランザクション メカニズムと Flink の 2 フェーズ コミット プロトコルを組み合わせて、エンドツーエンドで 1 回限りのセマンティクスを実現しようとしています。プラットフォーム上で小規模にテストされており、テストに合格すれば実稼働環境に導入される予定です。 2. 消費者電流制限。 1 回の書き込みと多数の読み取りのシナリオでは、コンシューマー操作が大量のディスク データを読み取ると、プロデュース レベルでの他のコンシューマー操作のレイテンシに影響します。したがって、消費フローを制限し、Kafka Quota メカニズムを通じてしきい値の動的な調整をサポートすることも、私たちの将来の方向性です。 3. シーンの拡大。 Kafka 拡張 SDK、HTTP およびその他のメッセージ サブスクリプションおよび生成方法に基づいて、さまざまな言語環境とシナリオの使用要件を満たします。 上記は、Mafengwo のビッグデータ プラットフォームにおける Kafka のアプリケーション実践の共有です。ご提案やご質問がございましたら、バックグラウンドでメッセージを残してください。 |
<<: SpringBoot で Spring Session を使用して分散セッション共有の問題を解決する
>>: AWS クラウド認定職トップ 10、その年収はいくらですか?
月収10万元の起業の夢を実現するミニプログラム起業支援プランSEO 最適化は現在一般的なプロモーショ...
今日、ますます多くの企業がアプリケーションとワークロードをクラウドに移行していますが、その移行計画の...
SEO 界では、ウェブサイトとユーザー間の双方向性を確保し、より多くのリンクを獲得するために、現在す...
12月12日、雷軍氏が所有するKingsoft Cloudは、クラウド業界では単一ラウンドの資金調達...
今日、Baidu が小さなアップデートを行いました。アップデート後、データを整理してデータ分析を行い...
[[278270]] 1982 年、コンピュータ分野の先駆者であるアラン・ケイは次のように述べました...
「クラウドコンピューティングの人材不足をどう解決するか?」これは多くの IT リーダーにとって重要な...
邯鄲不動産ネットワークの運営を始めて2年が経ちました。この2年間、私は多くの苦労をしてきました。今で...
投資ポイント世界の IT 支出に占めるクラウド コンピューティング支出の割合は増加し続けています。世...
最近、Baidu でキーワードを検索すると、注意深い友人は大きな変化に気づくでしょう。一部の Web...
あらゆる大規模なサイバー攻撃や、あまり知られていない障害の背後では、IT セキュリティ専門家、アプリ...
ドメイン名ニュース:長年沈黙していたダブルピンインドメイン名xiaoxing.comが最近、国内の個...
1. ウェブサイトのランキングの基本原則 検索エンジンの「古代」の時代では、検索結果におけるウェブサ...
ショートビデオ、セルフメディア、インフルエンサーのためのワンストップサービスどのような状況でメモ取り...
企業ウェブサイトのコンバージョン率が比較的低いことは、現在ほとんどの企業が直面している共通の問題であ...