革新的なストリーミング: Apache Pulsar が自動スケーリングを導入

Apache Pulsar は、常に自分自身をクラウドネイティブであると考えてきました。それはホームページにあります：

「Apache® Pulsar™ は、クラウド用に構築されたオープンソースの分散メッセージングおよびストリーミング プラットフォームです。」

Pulsar は、Pulsar ブローカーがメッセージの提供を処理し、Apache BookKeeper がメッセージのストレージを処理するストレージからコンピューティングの分離や、次のように自由にスケールアップおよびスケールダウンできるステートレス コンポーネントのアイデアなど、多くのクラウド ネイティブの原則を確かに体現しています。パルサーブローカー。

しかし、クラウドの究極の約束である自動スケーリングを実際に実現することはできませんでした。少なくとも今日までは。

Kubernetes Autoscaling for Apache Pulsar (KAAP) を導入できることを嬉しく思います。 KAAP は、 OperatorHub で利用できる Kubernetes オペレーターです。これには、Kubernetes オペレーターに期待されるすべての機能が含まれています。 Kubernetes クラスターに Operator をインストールしたら、次のように単一のカスタム リソース定義 (CRD) を適用することで、完全に機能する Pulsar クラスターを取得できます。

 apiVersion: kaap.oss.datastax.com/v1alpha1 kind: PulsarCluster metadata: name: pulsar spec: global: name: pulsar image: 'apachepulsar/pulsar:3.0.0'

Pulsar には、ZooKeeper、BookKeeper、ブローカー、プロキシなどの複数のコンポーネントがあります。オペレーターは、 PulsarCluster CRD を使用してそれらすべての構成を処理します。オペレーターはクラスター レベルで動作するため、コンポーネントがどのように連携するかを心配する必要はありません。オペレーターがそれを処理します。

自動段階的アップグレード

私が知っている誰よりも長く Pulsar の実稼働クラウド サービスを運用してきました (最初はケスクそして今では DataStax Astra Streaming を使用しているため、Pulsar クラスターの適切なアップグレードにどれくらいの時間がかかるかを直接知っています。すべてのコンポーネントを一度に YOLO アップグレードすることもできますが、推奨される最も安全な方法は、各コンポーネントを一度に 1 つずつアップグレードし、各コンポーネントが正常にアップグレードされたことを確認してから次のコンポーネントに進むことです。

これは、顧客サービスの可用性が最も重要であるため、Astra Streaming サービスの Pulsar クラスターをアップグレードするときに従うプロセスですが、生産エンジニアリング チームにとっては非常に時間がかかります。実際、これが彼らの最大の要望です。アップグレードをよりスマートかつ自動化できないか? KAAP では、まさにそれを実現しました。

PulsarCluster CRD を 1 行変更するだけで、Pulsar クラスターの段階的なアップグレードをトリガーできます。 KAAP オペレーターは、クラスターの慎重かつ段階的なアップグレードを調整します。もちろん、アップグレード中はメトリクスを監視する必要がありますが、KAAP オペレーターに運転してもらうこともできます (居眠り運転は禁止です)。

オープンソースの自動スケーリング

段階的な自動アップグレードは便利ですが、私が KAAP で最も楽しみにしているのはそこではありません。弾力性のあるリソースの概念は、クラウドの重要な約束です。 AWS サービスの多くの名前に「elastic」が含まれているのはこのためです。私 (実際にはChatGPT ) が簡単に検索したところ、少なくとも 10 件ありました。

クラウドを使用すると、オンデマンドでリソースを取得および解放できるため、自動スケーリング技術を使用して、アプリケーションが使用しているリソースの数をアプリケーションの負荷に合わせることができます。負荷が増加すると、自動的にリソースを追加できます。負荷が減少すると、リソースを解放できます。クラウド プロバイダーはリソースの使用量に対して料金を請求するため、自動スケーリングはクラウド費用を最も効率的に使用するのに役立ちます。

誰もが、舞台裏で自動スケーリングを備えたクラウド サービスの例を思い浮かべることができると思います。これらの「弾力性のある」AWS サービスのほとんどはそのように動作します。ただし、自動スケーリングの実装は独自のものであり、ベンダーのプライベート リポジトリにロックされています。場合によっては、次のように自動スケーリングをどのように実装したかについて話します。紙AWS DynamoDB について、またはこれブログ投稿Confluent Cloud が Kafka をどのように柔軟にするかについて。しかし、私の知る限り、自動スケーリングの実装をオープンソースにして、真のオープンソース ライセンスの下ですべてのユーザーが自由に利用できるようにした人は一人もいません。それがまさに私たちが KAAP で行っていることです。

KAAP は、高度な自動スケーリング機能を Pulsar (またはルナストリーミング、当社の Pulsar ディストリビューション）は、Apache 2.0 ライセンスに基づいています。あなたはそれをチェックアウトすることができますGitHub リポジトリ。気に入ったら、星を付けることを忘れないでください。

Pulsar + オートスケーリング: 完璧な組み合わせ

KAAP を使用すると、Kubernetes で実行するときに Pulsar に自動スケーリングを追加する方法が提供されます。 Pulsar ブローカーのデプロイメントに追加された単純な水平ポッド オートスケーラー (HPA) ではなく、Pulsar の既存のクラウドネイティブ コンポーネントと連携して真に弾力性のあるストリーミングおよびメッセージング システムを提供する洗練されたオートスケーラーです。私の意見では、これは負けられない組み合わせです。

ステートレスブローカーのスケーリング

KAAP の 2 つの主要な自動スケーリングの側面を見てみましょう。まず、Pulsar ブローカーを見ていきます。ご存知かもしれませんが、Pulsar ブローカーはステートレスです。つまり、必要に応じて簡単にスケールアップおよびスケールダウンできます。しかし、あまり知られていないかもしれませんが、Pulsar には、各ブローカーの CPU、メモリ、ネットワーク帯域幅を継続的に監視するブローカー ロード バランシング メカニズムが組み込まれています。その情報と構成可能な負荷分散アルゴリズムの 1 つを使用して、Pulsar はトピックをブローカーからブローカーに移動し、ブローカーが過負荷になるのを防ぎます。

素朴な自動スケーリング ソリューションは、ブローカー上で Kubernetes 水平ポッド オートスケーラー (HPA) を構成し、CPU などのメトリックが高くなったときに別のブローカー ポッドをスケールアップすることです。ただし、Pulsar ブローカーのロード バランサーは同時に負荷を均等にするためにトピックをシフトすることを決定する可能性があるため、これは実際には必要ではない可能性があります。これで、Pulsar ロード バランサーがバランスをとったため不要になったブローカー ポッドがスケールアップされました。そこで HPA は新しいブローカー ポッドをスケールダウンすることを決定し、その結果、そこで作成された新しいトピックは既存のブローカーに移動されます。ご想像のとおり、Pulsar ロード バランサーと HPA は、ブローカーが上がったり下がったり、トピックがブローカーからブローカーへと移されるという混乱を引き起こす可能性があります。

KAAP は、Pulsar ロード バランサーと直接統合することで、この問題を回避します。 KAAP は、単一のブローカー ポッドがビジー状態のときではなく、Pulsar ロード バランサーからのクラスター全体のメトリクスがクラスターの容量に近づいていることを示唆しているときにブローカーをスケールアップします。また、クラスター全体の使用量が設定されたしきい値を下回った場合にのみ、ブローカーをスケールダウンします。 KAAP オペレーターは、Pulsar ブローカー ロード バランサーに対してではなく、Pulsar ブローカー ロード バランサーと連携して動作します。

ストレージの拡張と拡張: 驚くべきことです。

Pulsar のコンピューティング (またはサービス) レイヤーをスケーリングするのは優れていますが、真の自動スケーリングの実装には十分ではありません。確かに、処理する必要があるメッセージ (またはイベント) の数は時間の経過とともに変化する可能性がありますが、保存する必要があるメッセージの数はどうでしょうか?おそらく誰もが、ダウンストリーム システムの障害が原因で蓄積されるメッセージのバックログに対処しなければならなかったことがあるのではないでしょうか。停止が長引くにつれて、ストリーミング システム上の利用可能なストレージが不足し始めます。

これは、Pulsar とその BookKeeper への依存が光るシナリオです。 Pulsar クラスターにストレージ容量を追加するには、愛情を込めて「ブックキー」と呼ばれる新しい BookKeeper ノードを追加するだけです。 BookKeeper ストレージはトピック全体ではなくトピックのセグメントに基づいているため、新しいブックキーをすぐに使用して、トピックの再バランスやその他の操作上の面倒な介入を行って、ストレージへの負担を軽減できます。

もちろん、KAAP がこのケースを処理できます。ブックキー ノードのディスク使用状況を常に監視し、利用可能なストレージが少なくなった場合は、新しいブックキー ノードをスケールアップします。これはそれほど驚くべきことではありません (少なくともパルサーでは)。 Kubernetes に新しいレプリカを追加するのは、ステートフルで永続ボリュームによってバックアップされている場合でも、非常に簡単です。しかし、停止が終了し、バックログが解消された場合はどうでしょうか?本当に必要のないリソースを消費する余分なブッキー ノードに悩まされていませんか?

KAAP の場合は違います。 BookKeeper ストレージが設定されたしきい値を下回ると、KAAP オペレーターは不要な Bookie ノードの削除を慎重に調整します。これは非常に安全な方法で行われ、メッセージが失われず、必要なレプリケーション係数が常に維持されることが保証されます。たとえば、各メッセージのコピーを 3 つ保持するように Pulsar を設定した場合 (書き込みクォーラムと確認応答クォーラムは両方とも 3 に等しい)、KAAP は BookKeeper と対話して、スケールダウン中のブックキーから他のブックキーにメッセージをコピーします。メッセージの少なくとも 3 つのコピーが利用可能です。それが正常に完了すると、不要なブックキーの削除に進みます。

KAAP を使用すると、Pulsar クラスター内のストレージを上下両方で自動スケーリングできるため、クラスター内のストレージ使用量を最適化し、不運な運用インシデントの後にアイドル容量で行き詰まることを回避できます。あなたはどうか知りませんが、それはかなり素晴らしいことだと思います。

ゾーン認識および移行ツール

KAAP は、Pulsar クラスターの段階的なアップグレードとスマートなスケーリングを実行できます。しかし、それだけではありません。クラウド プロバイダーで高可用性クラスターを運用するには、可用性ゾーン (AZ) を考慮することが重要です。コンポーネント、特に BookKeeper を可用性ゾーン全体に分散しない場合、AZ 障害に耐えて複数の 9 の可用性を提供することはできません。

幸いなことに、Pulsar には、高可用性展開をサポートするラック認識などの優れた機能が組み込まれています。難しい部分は、これを適切に設定するには、ゾーン認識を使用して Kubernetes を正しく構成し、Pulsar も構成する必要があることです。 KAAP オペレーターは、リソース セットの概念を導入することで対応します。これにより、コンポーネントをグループ化し、コンポーネントにラック認識を与えることができます。 KAAP オペレーターは、リソース セットの宣言的構成に基づいて、Kubernetes と Pulsar の両方の構成を自動的に適用します。リソース セットは柔軟なので、さまざまな Pulsar 導入オプションをサポートできます。

また、Helm チャートや Kubernetes マニフェスト マジックを使用して既に Pulsar を実行している場合はどうなるでしょうか? KAAP には、それを支援する移行ツールがあります。移行ツールを既存の Kubernetes Pulsar デプロイメントに指定すると、KAAP オペレーターにクラスターの操作を引き継がせるために使用できる、一致する CRD 構成が自動的に生成されます。

KAAP スタック

KAAP オペレーターには多くの優れた機能があり、通常の Pulsar クラスターを十分に潤滑された可用性の高い自動スケーリング マシンにターボチャージャーします。しかし、実稼働 Pulsar クラスターを長年運用してきた者として、私は、TLS 証明書の管理、認証、監視など、実稼働 Pulsar クラスターの作成には他にも多くの考慮事項があることを知っています。

そのため、オペレーターに KAAP スタックと呼ばれるものを含めました。これは、次のような重要な制作ツールとともに KAAP オペレーターをインストールする包括的な Helm チャートです。

• 証明書マネージャー
• キークローク
• プロメテウス スタック (グラファナ)
• Pulsar Grafana ダッシュボード

これらは、実稼働 Pulsar クラスターを実行するときに必須のツールであり、ユーザーを興奮させて乾燥させたくなかったので、これらをすべてまとめて 1 つの便利なパッケージに統合しました。

KAAP を使用する理由

Apache Pulsar 用の Kubernetes Autoscaling の優れた機能についてはもうお聞きになりました。単一の CRD を使用して Pulsar クラスター全体を作成できます。アップグレードを自動操縦に設定し、KAAP オペレーターに安全な段階的なアップグレードを実行させることができます。ブローカーが過負荷になっているという Pulsar ブローカー ロード バランサに基づいて、Pulsar ブローカーを自動的にスケールアップおよびスケールダウンすることができます。また、クラスターのストレージ要件に基づいて BookKeeper ノードを安全に (!) スケールアップおよびスケールダウンすることができます。高可用性を実現するために、可用性ゾーンを認識するようにクラスターを簡単に構成できます。また、移行ツールも含まれているため、古い Helm ベースのデプロイメントから、ターボチャージャ付きの KAAP オペレーターベースのデプロイメントに簡単に移行できます。

優れた機能がたくさんありますが、KAAP の利点は何でしょうか?いくつか考えられます。

• Kubernetes で実行される可用性の高い Pulsar クラスターを簡単に構成および運用できるため、お客様と実稼働チームの労力が軽減されます。
• 需要に合わせてクラスター リソースを自動スケーリングすることで、変化する需要に合わせて Pulsar のスケーリングを大幅に簡素化します
• ピーク負荷へのプロビジョニングや運用インシデントの結果としての過剰プロビジョニングを排除することで、Pulsar クラスターの総所有コストを削減します。
• すべてのオープンソース テクノロジーを使用してベンダー ロックインを回避する

私の意見では、KAAP のリリースは、ストリーミングとメッセージングの分野において真に革新的な瞬間です。 Apache Pulsar のストリーミングおよびメッセージングの能力と、クラウド コンピューティングの究極の約束である完全な弾力性、自動スケーリングを組み合わせたオープンソース プロジェクトは他にありません。ぜひお試しください。リポジトリの GitHub ディスカッションに参加して、ご意見をお聞かせください。

もっと詳しく知る

KAAP について技術的に詳しく知りたい場合は、 このブログ投稿を参照してください。 KAAP の完全なドキュメントを見つけることができます。ここ。とここは GitHub リポジトリです。

Chris Bartholomew、DataStax 著