Tencent クラウド上の Apache Pulsar のベストプラクティス

導入

StreamNative が主催する Pulsar Meetup 北京 2023 は、2023 年 10 月 14 日に無事終了しました。このイベントには、Tencent、Didi、Huawei、Zhaopin、RisingWave、StreamNative の業界専門家を含む著名人が集まり、Pulsar の制作について徹底的なディスカッションが行われました。環境内のアプリケーションのベストプラクティスを示し、Pulsar コミュニティの最新の開発とダイナミクスを共有します。

このミートアップでは、Tencent Cloud のシニアエンジニアである Lin Yuqiang が、「Tencent Cloud 上の Apache Pulsar のベストプラクティス」というテーマで素晴らしいスピーチを行いました。次の章では、システムアーキテクチャ、設計アイデア、サービスのアドレス指定、クロスクラスターについて説明します。移行とリージョン間の災害復旧の観点から、Tencent Cloud 上の Apache Pulsar のベストプラクティスを詳しく紹介します。

パルサーシステムのアーキテクチャ

上の図は、非常に一般的な Pulsar 導入アーキテクチャです。ZK は Tencent Cloud TSE ZK を使用しています。内部設定センターと CICD プラットフォームに接続して、標準化された導入を実現できます。Bookie と Broker の残りの部分は、オープンソースのそれとあまり変わりません-構築された展開モデル。

ここでは、Tencent Cloud の自社開発部分であるメトリクス、トレース、ログ収集の診断 3 点セットを紹介する必要があります。

メトリック: ブローカーが自己調査して収集 → モニタークラスターのトピックに報告 → パルサーシンクの集計前処理 → Tencent クラウドのモニタリング。ここで言及する価値があるのは、監視リンクが地域レベルにあるため、ブローカーとクラウド監視の間のバッファとして Pulsar Broker クラスター (モニタークラスター) のレイヤーを追加し、メトリクスデータの前処理に Pulsar 独自のシンクを使用したことです。は、広州に 1 セットのみ展開されていますが、外部ビジネスサービスを提供する Broker クラスターの数が多く、Topics の総数も多いため、クラウド監視への負荷を軽減するために中間層を追加する必要があります。量的な変化が質的な変化をもたらす結果です。

トレース: ブローカーが独自に調査して収集したもの → トレースログ → Filebeat レポート → APM と、これも進化の結果です。本来のアーキテクチャは、Skywalking収集→メモリキューレポート→APMというシンプルなアーキテクチャに見えますが、Brokerのトラフィック規模が一定レベルに達すると、レポート速度よりもトレース生成速度が高くなり、メモリが増大し続け、OOMになります。 , ということでトレース結局、元に戻り、スカイウォーキングは諦め、円盤を使って短期的な洪水のピークに耐えることになりました。もちろん、トラフィックが高くなり続け、トレースログの生成にレポートが追いつかない企業もあります。この場合、方法は 2 つしかありません。メッセージトレースに固執しない企業の場合は、オフトレースレポート。トラフィックが多くてもトレースの要件がない企業向け。必要に応じて、構成をアップグレードすることによってのみ、Filebeat で使用可能なコアの数を増やすことができます。

CLS ログ収集: メトリクスとトレースはブローカー独自のロジックと強く結合されているため、ブローカー向けにカスタマイズされた開発のみを実行できます。ただし、ログ収集はユニバーサル機能であるため、ログの収集と要約、環境、地域、クラスターによる分類、キーワード監視、長期ログアーカイブ、キーワードアラームなどの目標を達成するために Tencent Cloud CLS を直接使用します。

Lookup Service: Lookup Service はリージョンレベルのモジュールです。各リージョンに 1 つのセットのみがデプロイされます。同じリージョン内のすべての Broker クラスタのルーティングおよびアドレス指定機能に使用されます。このモジュールについては、後で詳しく説明します。

デザインの背景とアイデア

Pulsar システムアーキテクチャを紹介した後、Tencent クラウドシナリオで直面する問題とその解決方法を紹介します。

● 完全なコンテナ化: ZK、BK、Broker およびその他の周辺施設を含み、すべてコンテナプラットフォーム上に展開されます。

●複数の環境と複数のリージョン: これは、クラウドサービスプロバイダーにとって比較的従来型のビジネスです。テスト環境、プレリリース環境、オンライン環境だけでなく、オンライン環境にも北京、上海、広州、シンガポール、香港などの複数のリージョンがあり、各リージョンに複数のクラスターがあります。

● 複数のアベイラビリティーゾーン (同一都市内の複数のコンピュータ室): クラウド自体が同一都市内の複数のコンピュータ室を備えているため、同一都市内の複数のユーザーの災害復旧に非常に便利です。

● 多数のクラスタと大規模なトピック: 多数のクラスタと多数のトピックにより、標準化された展開プロセスを設計する必要があり、前述の監視リンクもこの背景から生まれました。

● さまざまな製品形式: 製品形式は、展開アーキテクチャの違いや、テナント、ブローカー、ブックメーカー間の展開関係の違いに対応しています。

● 仮想ネットワーク、多様なアクセス方法: これは、クラウドサービスプロバイダーが直面しなければならないマルチネットワークプレーンの問題です。

● クラスターのホットマイグレーションをサポート: クライアント URL を変更せずにテナントをクラスター 1 からクラスター 2 に移行します。これは、クラスターを標準バージョンからプロフェッショナルバージョンにアップグレードするなど、クラウドサービスプロバイダーに必要な製品機能でもあります。テナントの移行と基礎となる物理リソースの割り当てまで。

コンテナ化

Pulsar Broker はクラウドネイティブのメッセージキューと呼ぶことができますが、実際には、Topic と Broker の間の所有権関係など、Broker は実行時にステートフルです。

したがって、コンテナ化を行う際の全体的な考え方は、Pod と VM を可能な限り同等にすることであったため、次の設計を行いました。

● 固定 IP: ポッドが破棄されて再構築されても、IP はランダムに変更されません。

● ポッドとノードのネットワークレベリング: Tencent クラウドシナリオの場合、クライアントはブローカーによってデプロイされたコンテナクラスター上で実行されていてはなりません。そうでない場合は、コンテナネットワーク (オーバーレイ) と基本ネットワーク (アンダーレイ) の間のマッピングを考慮する必要があります。 Lookup: 関係により、Lookup は非常に複雑になります。

● クラウドディスク: ポッドに接続されているデータディスクはクラウドディスクであり、コンピューティングとストレージを完全に分離します。

● CVM との共存: 各ポッドには排他的な CVM があり、両者の CPU とメモリのパラメータは等しいため、Pulsar ランタイムの物理的な分離を最大限に確保できます。もちろん、これも Tencent が自然に提供する機能です。クラウド EKS (TKE サーバーレス) 。さらに、コンテナ移行プロセス中は、Pod ノードと CVM ノードが同じクラスター内に共存する必要があるため、2 つの間の互換性も考慮する必要があります。

● 正常なシャットダウン: ポッドが破棄されるときは、Pulsar のシャットダウンロジックがトリガーされることを確認する必要があります。そうしないと、クライアントに非常に認識されやすくなります。これは、Pulsar 間の CICD プロセスの違いにより注意を払う必要があるものでもあります。コンテナシナリオとCVMシナリオ。

● Liveness Probe のチューニング: Liveness Probe にも興味深い点があり、k8s 自身のさまざまなヘルスチェック機構は実際にはタイムアウトに依存しているため、Broker の起動フェーズが合意されたタイムアウト内に正しい結果を返せない場合、k8s はエラーを起こしやすいと判断されます。これは失敗として発生し、ブローカーが無期限に再起動されます。例: ブローカークラスターに数万のトピックがある場合、そのブローカーの起動時間は 90 秒以上かかる可能性があります。Liveness 設定のタイムアウトがこの値より低い場合は、特別な注意が必要です。もちろん、これはクラスターが大規模であるためでもあり、さまざまなクラスターがさまざまなビジネスシナリオで使用される可能性があるため、多くの同様のパラメーターをそれに応じて調整する必要があります。

● Helm オーケストレーション: Pulsar のデプロイメント手順は実際には非常に複雑で、Bookie デプロイメント、Bookie 初期化、Broker デプロイメント、Broker 初期化に加えて、必要な Secret、ConfigMap、ネットワークモジュールなどが含まれます。非常に多くのモジュールを秩序だった方法で整理するには、 , もちろんヘルムが最適です。

話題の規模が大きい

トピックの数が多いと、次の問題が発生します。

● ZK にはメタデータが多すぎて負荷が高い

● 起動が遅くなり、K8s の準備状況が誤って判断される

● ブローカーが大きな爆発半径で再起動する

● ルックアップ性能が低下する

● 監視と収集の集計が質的な変化を引き起こす

さまざまな製品形態

Tencent Cloud Pulsar は、基盤となる導入アーキテクチャの多様性に対応するさまざまな製品形式を提供しており、これは各インスタンスの最終販売価格と Tencent Cloud 自体のコストに対応します。

● 共有版：Bookie と Broker の両方を共有しており、本質的には企業が社内の全業務チームが共有するクラスタを構築するのと同じモデルであり、共有版のインスタンスが Pulsar のテナントに相当します。

● Professional Edition: Bookie と Broker は両方とも排他的であり、クラスターにはテナントが 1 つだけあり、すべての物理リソースを排他的に所有します。

アクセス方法

Tencent Cloud Pulsar はさまざまなネットワークアクセス方法を提供しており、ネットワークアクセスはブローカーとクライアント間のネットワーク接続関係です。

イントラネットへのアクセス

イントラネットアクセスは、本質的には従来の社内での自社構築と同様です。ブローカーとクライアントの両方が同じイントラネット内にあり、完全に相互運用可能です。クライアントによって接続された IP はブローカーのノードでもあります。オリジナル IP、ネットワーク翻訳なしで。

VPC アクセス

VPC は仮想プライベートネットワークです。各ユーザーは複数の VPC を作成でき、各 VPC は複数のサブネットを作成できます。詳細については、プライベートネットワーク製品概要 - 製品紹介 - ドキュメントセンター - Tencent Cloud をご覧ください。

クラウドネットワーキングやピアリング接続などの VPC 間の相互作用製品が使用されない限り、図の 10.0.0.0/8 と 192.168.0.0/16 など、2 つの VPC は通常相互に通信できませんが、これは範囲を超えています。私たちの議論です。

図に示すように、Broker は 10.0.0.0/8、Client は 192.168.0.0/16 に配置されており、この時点で Client は Broker にアクセスできなくなります。

クラウドネットワークシナリオでは、VPC は、2 つの VPC 間の相互運用性 (クロスネットワークプレーンの相互運用性と呼ばれます) をサポートするクラウド仮想ゲートウェイ (内部コンポーネントのみ) を提供します。

もちろん、その本質は次のようなネットワークマッピングを行うことです。

● Broker1: 10.0.0.0/8 の IP は 10.2.0.1 です。クラウド仮想ゲートウェイ経由で Broker1 を作成し、192.168.0.0/16 の IP は 192.168.1.1 です。次に、クライアントが 10.0.0.0/8 にあるとき、 Broker1 にアクセスするには 10.2 .0.1 を使用する必要があります。クライアントが 192.168.0.0/16 にある場合、Broker1 にアクセスするには 192.168.1.1 を使用する必要があります。

● Pulsar クライアントの接続プロトコルは最初にルックアップを使用し、次に直接接続を使用するため (これについては、以下のルックアップアドレス指定シーケンス図を参照してください)、ブローカーのルックアップインターフェイスの要件が増加し、ブローカーは次のことを自動的に決定する必要があります。

1. クライアントが 10.0.0.0/8 ネットワークから来た場合、10.2.0.1 を返します。

2. クライアントが 192.168.0.0/16 ネットワークから来た場合、192.168.1.1 を返します。

これは、クラウドサービスシナリオで Pulsar サービスが直面する問題です。

パブリックネットワークアクセス

VPC アクセスについては先ほど紹介しましたが、実はパブリックネットワークアクセスと VPC アクセスは似ています。

唯一の違いは次のとおりです。

● VPC アクセス: ブローカーとクライアントは 2 つの異なるイントラネットネットワークプレーン上にあります。

● パブリックネットワークアクセス: Broker はイントラネット上に配置され、Client はパブリックネットワークからアクセスされますが、パブリックネットワークを直接特別な VPC とみなすことができることは容易に理解できます。

アドレス指定サービス

次に、アドレス指定サービスの価値でもある、Tencent Cloud のアドレス指定サービスのアイデアの源を紹介します。

RocketMQ アーキテクチャリファレンス

RocketMQ のサービスを見てみましょう。そのアーキテクチャは NameServer と Broker に分かれています。

● NameServer はクラスターのメタデータ (トピックとブローカー間の所有権関係) を保存するため、トピックとブローカー間の所属関係を動的に構成でき、異なるブローカークラスター間でトピックをスケジュールすることもできます。

● RocketMQ も、Pulsar と同様に、Lookup と同様のアドレス指定プロセスを持っていますが、RocketMQ Client によってアドレス指定されるリクエストオブジェクトが NameServer であるのに対し、Pulsar Client によってアドレス指定されるリクエストオブジェクトは Broker である点が異なります。この観点から、アーキテクチャは Pulsar Broker として理解できます。これは、RocketMQ NameServer と RocketMQ Broker の組み合わせに相当します。

長所と短所：

Pulsar の展開アーキテクチャはシンプルであり、追加の NameServer サービスは必要ありませんが、物理クラスター間でトピックをスケジュールする機能も失われます。

RocketMQ にはもう 1 つのモジュールがありますが、RocketMQ が提供するクラスタースケジューリング機能は非常に重要な運用およびメンテナンス機能です。

この種のスケジューリング機能はまさにクラウドサービスに必要なものであり、この種のスケジューリング機能により、当社のクラウドサービスはクラスタに対する操作性と柔軟なリソーススケジューリングを実現できます。

マルチネットワークルックアップ

前に述べたように、クラウドサービスシナリオでは、Pulsar Broker に対して、イントラネット、VPC、パブリックネットワークという 3 つのネットワークアクセスシナリオを提供する必要がありますが、これらは Pulsar Broker 自体が提供する検索機能と矛盾します。アドレス指定モジュールを使用すると、次のような利点があります。

● マルチネットワークアクセスなどのクラウドサービスシナリオをアドレッシングサービスコアに統合する一方で、Broker は依然として最も純粋なイントラネットサービスのみを提供し、Broker の元の機能とオープンソースとの接続をより適切に維持します。

● アクセスポイント (つまり、さまざまなネットワークアクセスメソッドの概念的な名前) を動的に増減します Pulsar クラスターの場合、イントラネット、VPC、またはパブリックネットワークアクセスポイントを追加または削除するときに、アクセスポイントを変更する必要はありません。ブローカー。

● 自動的かつ知覚できない拡張と縮小を実現するには、Broker の拡張と縮小には、クラスターのすべてのアクセスポイントのネットワークマッピングの拡張と縮小の変更も必要です。アドレッシングモジュールの存在により、この部分はすべてこのバージョンに統合されます。モジュールを使用する場合、Broker の拡張と縮小には既存のノードを変更する必要はありません。

ルックアップのタイミング

多くのアドレッシングモジュールとアドレッシングプロセスがこれまでに紹介されてきましたが、ここでは、以前の紹介と一般科学における Pulsar クライアントのメカニズムを補足するために、Pulsar-Client のアドレッシングタイミングに焦点を当てます。

● ステップ 1: トピックパーティションの数を取得します: クライアント→CLB→ブローカー 1 対多とは、リクエストが発生する CLB の背後にあるどのブローカーも同様に正しい結果を返すことができることを意味します。

● ステップ 2: 単一パーティションのトピックルックアップ: 単一パーティションでルックアップを実行し、トピックの現在のオーナーブローカーアドレスを要求します。これは 1 対多でもあり、異なるブローカー間でピアツーピアサービスを提供します。

● ステップ 3: 2 番目のステップで返されたトピックパーティションのオーナーブローカーアドレスに基づいて、直接接続を確立し、メッセージを送受信します。 1 対 1 とは、具体的には、現時点での直接接続が Broker クラスター内の特定の Broker (Broker-2 など) に正確に接続されている必要があることを意味します。他の Broker に接続されている場合、接続は失敗します。

これらは、Pulsar-Client がプロデューサー/コンシューマーを初期化する手順です。

アドレス指定モジュールのエントリポイントはどこですか?

図に示すように、これは最初と 2 番目のステップであり、これら 2 つのステップの間にプロキシ層を追加して、マルチネットワークアクセスのスケジューリング、アドレス指定の返される結果でのトピックおよび物理クラスターの所属を実行できるようにします。私たちの目的。

クラスタ間スケジューリング

上の図は、アドレッシングモジュールを追加した後の Pulsar アーキテクチャの変更を示しています。アーキテクチャ全体は RocketMQ に似ています。トピックリソースと物理コンピューティングリソース間の関係を管理するための中央メタデータサービスがあります。

クラスタ間の移行

アドレッシングモジュールとアーキテクチャの最適化を導入して、そのための道を切り開きました。次に、これに基づいて構築した製品化機能、つまりクラスタ間の移行を紹介します。

クラスタ間移行とは、具体的には、物理クラスタ 1 から物理クラスタ 2 へのテナントの移行を指します。2 つのクラスタは、オンラインホットスイッチングとわずかなクライアント認識により、同時にサービスを提供します。

図に示すように、プロセス全体も非常に単純です。アドレス指定サービスは、テナントと物理クラスター間のルーティング関係を保存します。ルーティング関係が変更されると、クラスターの移行も変更されます。

Pulsar Lookup アドレッシングプロトコルに基づいて、ルーティング関係切り替えの粒度は、テナントの粒度、名前空間の粒度、トピックの粒度、およびパーティションの粒度にすることができます。

切り替え方法：ルート切り替え+トピックアンロード

機械的に言えば、この切り替えプロセスは非常に簡単ですが、難しいのは次のような準備作業です。

● メタデータの移行: テナント、ネームスペース、ポリシー、トピック、サブスクリプション、トークンなど。

● メッセージの双方向同期: スイッチングプロセス中、両方のクラスタが同時にサービスを提供します。ロールバック機能を提供するには、送信されるメッセージが 2 つのクラスタ間で双方向に同期され、両方のクラスタに完全なメッセージが存在することが保証される必要があります。

● 進行状況の同期: 各トピックのサブスクリプション消費の進行状況は異なるため、切り替えプロセス中の繰り返しの消費を最小限に抑えるために定期的に同期する必要があります。

メッセージの同期

メッセージの同期は比較的簡単で、Pulsar に付属の GEO-Replicator 機能を使用しますが、ここでは詳しく説明しません。

進行状況の同期

ここでは、進行状況の同期のメカニズムを簡単に紹介します。

1. メッセージの移行: メッセージ同期フェーズ (GEO-Replicator) では、メッセージのソースクラスターのメッセージ IP がメッセージヘッダーに含まれます。

2. スケジュールされた同期: Compact トピックの同期と永続性に基づいて、ソースクラスターからターゲットクラスターへの消費の進行状況をスケジュールします。

3. 進行状況キャッシュ: ターゲットクラスターは、Compact トピック内の消費進行状況情報を読み取り、消費進行状況をメモリにロードします。

4. 配信フィルタリング: Pulsar の配信プロセスの Dispatcher 処理中に、配信される予定であるが、ソースクラスタの進行状況ですでに配信されているアイテムがフィルタリングされます。

地域を越えた災害復旧

地域間の災害復旧も、アドレッシングサービスに基づいたアーキテクチャの改善後に開発された製品化された機能です。

本質はクラスター間の移行と似ていますが、リージョン間のネットワーク遅延の問題により、焦点は異なります。

図に示すように、Pulsar インスタンスが広州エリアにあり、クライアントも広州エリアにあると仮定します。しかし、不可抗力により、広州エリアのすべての Pulsar インスタンスがダウンしており、短期間で迅速に復旧することができません。お客様のトラフィックを一時的に遮断し、上海に災害復旧インスタンスを提供して、お客様のオンラインビジネスの迅速な復旧を保証します。

● 同時にサービスを提供できるクラスタは 1 つだけです。

● 短期の一時的な切り替え: 地域間の遅延 (特に海外地域) は制御不能なため、災害復旧メカニズムは一時的なものでなければならず、広州地域の復旧後、できるだけ早くトラフィックを元に戻す必要があります。

● メタデータのスケジュールされた同期: 広州クラスターがいつダウンするか予測できず、このシナリオの使用頻度は低いため、これはトレードオフです。

● メッセージと進行状況が同期されていない: 私たちが直面しているのは、広州クラスター全体がダウンしていることです。現時点では、広州クラスターディスク内のデータを一時的に読み取ることができません。もう 1 つの理由は、リージョン間の遅延が大きく、リアルタイムメッセージ同期の費用対効果が低すぎます。

● 切り替え: 広州と上海のアドレッシングサービスが互いに独立して分離されているため、ドメイン名解決に基づいて切り替えます。この時点で広州クラスタに蓄積がある場合、その部分は蓄積し続けることができます。広州エリアが完了したときのみ、回復したら、再び消費する機会がありますか。

● スイッチバック: 上海クラスタは緊急時の災害復旧にのみ使用されるため、広州クラスタが復旧した後は、広州にスイッチバックする必要があります。スイッチバックプロセスで最も重要なことは、上海クラスタに蓄積されたメッセージが復元される必要があることです。その過程で、(同じパーティション内で) 消費が繰り返され、消費順序が乱れることは避けられません。

このソリューションは、地域レベルの災害シナリオでの災害復旧を目的としています。各地域自体が複数のアベイラビリティゾーン (同じ都市内の複数のコンピュータルーム) に展開されているため、地域全体が利用できなくなる可能性は低くなります。そのため、製品全体の設計が必要になります。リージョン間のディザスタリカバリでは、非常に厳密な双方向同期を必要とするクラスタ間移行のようなホットスイッチングではなく、主に緊急時の使用に重点が置かれています。

要約する

まず、Tencent Cloud Pulsar の全体的なアーキテクチャから始め、Tencent Cloud シナリオで直面する必要がある問題を紹介し、アドレス指定モジュール (Lookup Service) を紹介し、Pulsar の展開アーキテクチャへのアドレス指定モジュールの導入を紹介します。の上。次に、ルックアップサービスによって解決される 2 つの中心的な問題、つまりマルチネットワークルックアップとクラスタ間スケジューリングが導入され、クライアントアクセスが認識されず、アーキテクチャへの侵入が低く抑えられます。アドレッシングモジュールの存在により、その機能、クラスタ間移行、および地域間災害復旧に基づいてアドレッシングモジュールをさらに製品化することができ、さまざまなレベルの災害シナリオで対応する修復手段と運用および保守機能を提供できます。

当社は今後も、災害復旧機能、パルサー周辺機器のエコロジードッキング、ストレージの最適化などの面で努力を続け、より低コストで安定性の高いパルサー製品を提供してまいります。