Kafka は人気のあるメッセージ キュー ミドルウェアです。大量のデータをリアルタイムで処理でき、高スループット、低レイテンシ、信頼性の高い非同期メッセージ伝送メカニズムという特徴を備えています。異なるシステム間のデータ通信および転送の問題を効果的に解決できます。 Kafka は Mafengwo でも広く使用されており、多くのコアビジネスをサポートしています。この記事では、Mafengwo ビッグデータ プラットフォームでの Kafka の適用実践に焦点を当て、関連するビジネス シナリオ、Kafka 適用のさまざまな段階で発生した問題とその解決方法、および将来の計画について説明します。 パート1. アプリケーションシナリオ ビッグデータ プラットフォームにおける Kafka のアプリケーション シナリオの観点から見ると、主に次の 3 つのカテゴリに分けられます。 1 つ目のタイプは、Kafka をデータベースとして使用し、ビッグデータ プラットフォーム上でリアルタイム データのストレージ サービスを提供するものです。リアルタイムデータは、ソースと目的という2つの側面から、ビジネス側DBデータ、監視型ログ、埋め込みポイント(H5、WEB、APP、ミニプログラム)に基づくクライアントログ、およびサーバー側ログに分類できます。 2 番目のカテゴリは、データ分析用のデータ ソースを提供することです。さまざまな追跡ポイントのログは、多次元クエリ、リアルタイム Druid OLAP、ログ詳細など、会社のオフラインデータ、リアルタイムデータウェアハウス、分析システムをサポートおよび接続するためのデータソースとして使用されます。 3 番目のカテゴリは、ビジネス関係者にデータ サブスクリプションを提供することです。ビッグデータ プラットフォーム内のアプリケーションに加えて、Kafka を使用して、レコメンデーション検索、公共交通機関、ホテル、コンテンツ センターなどのコア ビジネス向けに、リアルタイムのユーザー機能計算、リアルタイムのユーザー ポートレート トレーニングとリアルタイムのレコメンデーション、不正防止、ビジネス監視とアラームなどのデータ サブスクリプション サービスも提供しています。 主な用途を下図に示します。 第2部 進化への道 4つのステージ 初期のビッグデータ プラットフォームがビジネス ログ収集および処理システムとして Kafka を導入した主な理由は、その高スループット、低レイテンシ、複数のサブスクリプション、データ バックトラッキングなどの特性により、ビッグデータ シナリオのニーズをより適切に満たすことができるためです。しかし、業務量の急激な増加や、登録メカニズムや監視メカニズムの不完全性により問題をすぐに特定できない、一部のオンラインリアルタイムタスクが失敗してもすぐに回復せずメッセージのバックログが発生するなど、業務利用やシステムメンテナンスで発生した問題により、Kafka クラスターの安定性と可用性が課題となり、いくつかの重大な障害が発生しました。 上記の問題を解決することは私たちにとって緊急かつ困難なことです。ビッグデータ プラットフォームで Kafka を使用する際のいくつかの問題点に対応するため、クラスターの使用からアプリケーション層の拡張まで、一般的に次の 4 つの段階を含む一連のプラクティスを実行しました。 フェーズ 1: バージョンのアップグレード。プラットフォームデータの生成と消費におけるいくつかのボトルネックと問題に焦点を当て、現在の Kafka バージョンの技術的な選択を行い、最終的にバージョン 1.1.1 を使用することを決定しました。 フェーズ 2: リソースの分離。ビジネスの急速な発展をサポートするために、複数のクラスターの構築とクラスター内のトピック間のリソース分離を改善しました。 第3段階:権限制御と監視アラーム。 まず、セキュリティの面では、初期の Kafka クラスターは裸の実行状態にありました。複数の製品ラインで Kafka を共有しているため、他の事業のトピックを誤って読み取ることでデータセキュリティの問題が発生する可能性が高くなります。そこで、SASL/SCRAM + ACL に基づく認証機能を追加しました。 監視と警告の面では、Kafka は現在、リアルタイム コンピューティングの標準入力データ ソースとなっているため、ラグ バックログとスループットは、リアルタイム タスクが正常であるかどうかを示す重要な指標となっています。そのため、ビッグデータ プラットフォームは、Kafka クラスターとユーザーを多次元で監視するための統合 Kafka 監視およびアラーム プラットフォームを構築し、「Radar」と名付けました。 フェーズ 4: アプリケーションの拡張。 Kafka を会社のさまざまな事業ラインに公開した当初は、統一された使用仕様がなかったため、一部の事業部門で誤った使用が行われていました。この問題を解決するために、当社はリアルタイムサブスクリプションプラットフォームを構築し、アプリケーションサービスを通じてビジネス関係者に力を与え、データ生成および消費アプリケーション、プラットフォームユーザー認証、ユーザー監視およびアラームなど、多くのリンクのプロセス自動化を実現し、需要側の使用から総合的なリソース管理および制御までの全体的なクローズドループを作成しました。 以下にいくつかの重要なポイントを紹介します。 コアプラクティス 1. バージョンアップグレード 以前、ビッグデータ プラットフォームでは、初期の Kafka バージョン 0.8.3 を使用していました。現時点では、Kafka の最新の公式リリースは 2.3 です。したがって、バージョン 0.8 を長期使用する際に発生する多くのボトルネックや問題は、バージョン アップグレードによって解決できます。 たとえば、以前のバージョンで発生した一般的な問題は次のとおりです。
同時に、次のような対象バージョンの機能に関する選定調査を実施しました。
最終的にバージョン 1.1 が選択された理由は、Camus と Kafka のバージョン間の互換性と、バージョン 1.1 が使用シナリオで重要な新機能をすでにサポートしているという事実に基づいています。ここでは、Linkedin によってオープンソース化されている Camus コンポーネントについて簡単に説明したいと思います。当社のビッグデータ プラットフォームでは、主に Kafka データを HDFS にダンプする重要な方法として使用されます。 2. リソースの分離 以前は、ビジネスの複雑さと小規模さのため、ビッグデータ プラットフォームの Kafka クラスターの分割は比較的単純でした。その結果、一定期間が経過すると、会社のビジネスデータが混在することになります。特定のビジネストピックを不当に使用すると、一部のブローカーに過負荷が発生し、他の通常のビジネスに影響を及ぼす可能性があります。一部のブローカーに障害が発生した場合でも、クラスター全体に影響が及び、企業全体の業務が利用できなくなるリスクが生じます。 上記の問題に対応するために、クラスター変換の 2 つの側面が実装されました。 独立したクラスターを機能属性ごとに分割する クラスター内のトピックレベルでのリソース分離 (1)クラスター分割 複数の Kafka 物理クラスターは機能ディメンションに従って分割され、ビジネスを分離し、運用と保守の複雑さを軽減します。 最も重要な追跡データの使用例を挙げると、現在は 3 種類のクラスターに分かれています。各クラスターの機能は次のように定義されます。
クラスターの全体的なアーキテクチャは次のように分類されます。 (2)資源の分離 トピックのトラフィック サイズは、クラスター内のリソース分離の重要な基礎となります。たとえば、当社のビジネスでは、大量の POS ログを持つ 2 つのデータ ソースは、バックエンドの POS データ ソースであるサーバー イベントと、エンドの POS データ ソースであるモバイル イベントです。 2 つのデータを格納するトピック パーティションをクラスター内の同じブローカーのノードに割り当てることは避けたいと考えています。異なるトピックを物理的に分離することで、ブローカー上のトラフィックの偏りを回避できます。 3. 権限制御と監視アラーム (1)権限制御 冒頭で述べたように、初期の Kafka クラスターはセキュリティ検証が設定されていない裸の状態であったため、ブローカーの接続アドレスがわかっていれば生成と消費を実行でき、深刻なデータ セキュリティの問題が発生していました。 一般的に、SASL を使用するユーザーは Kerberos を選択します。ただし、プラットフォーム上の Kafka クラスターの使用シナリオでは、ユーザー システムは複雑ではなく、Kerberos を使用するのはやややりすぎです。同時に、Kerberos は比較的複雑であり、他の問題を引き起こすリスクがあります。また、暗号化に関しては、すべてイントラネット環境で実行されているため、SSL暗号化は使用されていません。 最終的なプラットフォーム Kafka クラスターは、SASL/SCRAM + ACL の軽量な組み合わせに基づいて SASL を認証方法として使用し、ユーザーの動的な作成を実現してデータのセキュリティを確保します。 (2)監視と警報 これまで、クラスターを使用すると、消費者向けアプリケーションのパフォーマンスが理由もなく低下することがよくありました。問題の原因を分析すると、通常、遅延しているコンシューマーによって読み取られたデータがページ キャッシュにヒットしない可能性が高く、ブローカー側のマシンのカーネルが最初にディスクからデータを読み取り、ページ キャッシュにロードしてから、結果をコンシューマーに返すことになります。これは、書き込み操作を処理できたはずのディスクが、データの読み取りを必要とすることになり、ユーザーの読み取りと書き込みに影響し、クラスターのパフォーマンスが低下することに相当します。 このとき、遅れている消費者向けアプリケーションを見つけ出し、事前に介入して問題の発生を減らす必要があります。したがって、監視と警告はプラットフォームとユーザーの両方にとって非常に重要です。以下は私たちの実践的なアイデアの紹介です。 全体的な解決策: 全体的なソリューションは、主にオープンソース コンポーネントの Kafka JMX Metrics + OpenFalcon + Grafana に基づいています。
監視について:
アラートについて: レーダー システム: Falcon と Eagle を通じて Kafka インジケーターを取得し、設定されたしきい値に基づいてアラームを生成する独自開発の監視システム。消費パターンを例にとると、ラグは消費が正常かどうかを測る重要な指標となります。 Lag が増加し続ける場合は対処する必要があります。 問題が発生した場合、コンシューマー管理者だけでなくそのユーザーもそれを知る必要があるため、アラーム システムでもユーザーに通知する必要があります。具体的な方法は、企業向け WeChat アラーム ロボットを通じて、対応するコンシューマー グループの担当者またはユーザーと Kafka クラスターの管理者に自動的にリマインドすることです。 監視例: 4. アプリケーションの拡張 (1)リアルタイムデータサブスクリプションプラットフォーム リアルタイム データ サブスクリプション プラットフォームは、Kafka の使用状況の完全なプロセス管理を提供するシステム アプリケーションです。データ生成および消費アプリケーション、プラットフォーム ユーザーの認証、作業指示の承認によるユーザーの監視とアラームなど、多くのリンクを自動化し、統一された管理と制御を提供します。 中心となる考え方は、Kafka データ ソースの ID 認証と権限制御に基づいてデータ セキュリティを強化し、Kafka ダウンストリーム アプリケーションを管理することです。 (2)標準化された申請手続き 生産者や消費者のニーズに関係なく、ユーザーはまず作業注文の形でサブスクリプション申請を提出します。申込情報には、事業内容、テーマ、申込方法等の情報が含まれます。作業指示書は最終的に承認のためにプラットフォームに転送されます。承認されると、ユーザーには承認されたアカウントとブローカー アドレスが割り当てられます。この時点で、ユーザーは通常の生産と消費を実行できます。 (3)監視と警報 プラットフォームの場合、権限はリソースにバインドされ、リソースはプロダクション用の Topics または消費用の GroupTopic になります。権限が割り当てられると、これらのリソースの使用は、リソースのライフサイクル全体を監視するためのレーダー監視システムに自動的に登録されます。 (4)データリプレイ データの整合性と正確性を考慮すると、Lamda アーキテクチャは現在、ビッグデータでよく使用されるアーキテクチャです。しかし一方で、Lamda アーキテクチャには、リソースの過剰な使用や開発の難易度の高さなどの問題もあります。 リアルタイム サブスクリプション プラットフォームは、消費者グループに任意の場所のリセットを提供し、時間、場所などによるリアルタイム データの再生をサポートし、Kappa アーキテクチャ シナリオをサポートして上記の問題点を解決します。 (5)テーママネジメント トピック管理を提供する理由は何ですか?簡単な例を見てみましょう。たとえば、ユーザーにクラスター上で独自の Kafka トピックを作成させたい場合、当然、ノード上で直接操作させたくはありません。したがって、前述のサービスの場合、ユーザー向けであれ管理者向けであれ、誰もが SSH 経由でサーバーに接続することは不可能であるため、操作するためのインターフェースが必要です。 そのため、統一されたエントリを作成し、トピックの作成、リソース分離の指定、トピックのメタデータ管理などのトピック管理サービスを導入するための管理機能を提供するサービスが必要です。 (6)データ転用 以前のアーキテクチャでは、ユーザーによる Kafka データ消費の粒度は、各 Kafka トピックが LogSource の完全なデータを格納するというものでした。ただし、使用時には、多くのコンシューマーは各 LogSource のデータの一部のみを消費する必要があります。これは、特定のアプリケーションの複数の埋め込みイベントのデータである可能性があります。下流のアプリケーションが独自のフィルタリング ルールを記述する必要がある場合、リソースが無駄になり、使いやすさに問題が生じることは間違いありません。さらに、複数のデータ ソースを結合して使用する必要があるシナリオもあります。 上記の 2 つの状況に基づいて、ビジネス ニーズに応じてトピックの分割、マージ、カスタマイズを実装し、データ ソース間のデータ マージと、アプリ コードとイベント コード条件の任意の組み合わせに対するフィルター ルールをサポートしています。 パート3. フォローアップ計画 データ重複の問題を解決します。現在のプラットフォームのリアルタイム ストリーム処理における障害回復などの要因によって発生するデータ重複の問題を解決するために、Kafka のトランザクション メカニズムと Flink の 2 フェーズ コミット プロトコルを組み合わせて、エンドツーエンドで 1 回限りのセマンティクスを実現しようとしています。プラットフォーム上で小規模にテストされており、テストに合格すれば実稼働環境に導入される予定です。 消費者の電流制限。 1 回の書き込みと多数の読み取りのシナリオでは、コンシューマー操作が大量のディスク データを読み取ると、プロデュース レベルでの他のコンシューマー操作のレイテンシに影響します。したがって、消費フローを制限し、Kafka Quota メカニズムを通じてしきい値の動的な調整をサポートすることも、私たちの将来の方向性です。 シーン拡大。 Kafka 拡張 SDK、HTTP およびその他のメッセージ サブスクリプションおよび生成方法に基づいて、さまざまな言語環境とシナリオの使用要件を満たします。 [この記事は51CTOコラムニストMafengwo Technologyによるオリジナル記事です。著者のWeChat公開アカウントはMafengwo Technology(ID:mfwtech)です] この著者の他の記事を読むにはここをクリックしてください |
<<: 金融グレードの分散データベースアーキテクチャの設計を1つの記事で理解する
>>: 知っておくべきパブリッククラウドの最適な帰還ユースケース
中小企業のデジタル変革が始まって10年、クラウドコンピューティングは企業にとって不可欠なテクノロジー...
上記ではTektonのインストールと理論的知識を紹介しました。この記事を注意深く読めば、何か得られる...
Toutiao の背後にある企業 ByteDance は、ついにソーシャル分野に「宣戦布告」した。同...
[51CTO.com からのオリジナル記事] COVID-19 パンデミックにより、企業はデジタル変...
我が国は知的財産権の保護が比較的弱い国です。まさにこのため、イノベーションへの道が閉ざされています。...
「オリジナル本物カウンター検査」 24時間サブダイヤルは動かない偽造時計鑑定レポート「消費者クレーム...
最近、百度を悩ませ、ロビン・リーを眠らせないのは、おそらく神馬検索の立ち上げだろう。全世界5億人のユ...
ロイター通信は3月25日夜、北京2022年冬季オリンピック招致委員会の王輝副事務総長が水曜日、北京が...
多くのウェブマスターはマーケティング志向のウェブマスターで、ウェブサイトを宣伝するためにあらゆる手段...
企業と顧客・潜在顧客との関係やさまざまな双方向戦略を管理するシステムとして、CRM(顧客関係管理)が...
クラウドによる変革は、ほとんどの企業にとって IT 展開をアップグレードするための選択肢となっていま...
[51CTO.com からのオリジナル記事] 最近、2020 コンテナ クラウド職業スキル コンペテ...
まず、プロモーションを行うには、Baiduプロモーションの基礎知識を理解する必要があります。 1. ...
会社の製品写真を Baidu に表示させるにはどうすればよいでしょうか。これは多くの SEO 担当者...
呉暁波氏はこう言っています。「企業がユーザーに見つけてもらいたいなら、インターネット検索に頼らざるを...