アパッチパルサーに移った理由

Narvarでは、サービスを提供する小売業者を通じて毎日何百万もの消費者と交流しています。 消費者 お客様のアカウント、注文や荷物の状態、返品状況に関するタイムリーなリマインダーや最新情報については、当社にお任せください。一方で、 当社のビジネス顧客 —世界中の何百もの大手小売業者やブランドが、消費者のニーズに合わせてNarvarの製品を柔軟に設定できるという点で、当社に信頼を寄せています。Narvarのプラットフォームは、データやイベントを処理して顧客とのタイムリーで正確なコミュニケーションを確保することで、小売業者やブランドを支援します。これに対応するために、カフカからAmazon SQS、キネシスストリームから Kinesis Firehose、RabbitMQ から AWS Lambda まで、さまざまなメッセージングおよび処理テクノロジーを使用してプラットフォームを時間をかけて構築しました。これらのシステムの多くは AWS にネイティブなもので、導入や運用が容易でした。これらのシステムはうまく機能し、しばらくの間私たちのニーズを満たしてくれました。

私たちの挑戦

会社が成長するにつれて、 新しいビジネスユースケース これらのシステムが登場し始めたとき、これらのシステムは、それらのユースケースの新しく拡大した要件に対応するのに必要なほどには機能していないことがわかりました。顧客ベースが拡大するにつれ、それに応じて拡張できる構成可能な方法でイベントを処理することは容易ではないことが明らかになりました。イベントを利用する必要のあるアプリケーションが増えるにつれ、メンテナンスのオーバーヘッドを伴う新しいサービスを立ち上げたり、高価な Amazon Lambda を使用したりする必要がありました。浮かび上がってきた他のビジネスケースでは、Kinesis Firehose には必要な形式と構造でデータを出力するのに必要な柔軟性がないことがわかりました。順序どおりの強固な保証とトピックスケーラビリティを必要とするユースケースが増えるにつれ、私たちが使用していたソリューションの多くがそれらの新しい課題には適していないことが明らかになりました。

新たなビジネスユースケースによるこれらの課題に加えて、次のことも確認しました。 スケールの課題。トラフィックが増えるにつれ、これらのシステムの保守とスケーリングに必要な DevOps と開発者サポートの量が増え続けることは持続不可能であることが明らかになりました。その多くはコンテナ化されていなかったため、インフラストラクチャの設定と管理が煩雑になり、頻繁な手動操作が必要でした。Kafka のようなシステムは、信頼性が高く、人気があり、オープンソースですが、規模を拡大するにつれてメンテナンスのオーバーヘッドが大幅に発生しました。たとえば、スループットを上げるには、パーティションを増やしてコンシューマーをチューニングする必要があり、開発者やDevOpsによる大量の手動介入が必要でした。同時に、Kinesis StreamsやKinesis Firehoseのようなソリューションはクラウドにとらわれないわけではなかったため、クラウドソリューションの選択肢を機能から切り離すことが難しく、他のクラウドのテクノロジーを活用したり、他のクラウドで実行する必要のあるお客様をサポートしたりすることが困難でした。これらの新たなビジネスケースの課題と、規模を拡大するにつれて遭遇していた面倒に直面して、私たちは次のプラットフォームに移行することにしました。 アパッチパルサー。

なぜアパッチパルサー

Kafkaと同様に、Pulsarは信頼性が高く、クラウドにとらわれず、オープンソースでした。Kafka とは異なり、Pulsar はメンテナンスのオーバーヘッドがほとんどなく、最小限の手動操作で拡張できました。Pulsar は当初からコンテナ化され、Kubernetes 上に構築されていました (つまり「クラウドネイティブ」)。内部には複数の複雑なコンポーネントが含まれていましたが、Streamlio チームの助けを借りて簡単に立ち上げて拡張できました。バージョンアップグレードは、ダウンタイムをほとんど発生させずに、特定のクラスターに簡単に適用できました。 ストリームリオ システム監視ダッシュボード（Grafanaベース）を提供してくれたため、すぐに使用して簡単に監視できます。Pulsarには、スケーラブルで保守が容易であることに加えて、いくつかのビジネスユースケースを可能にする差別化された機能が付属していました。たとえば、Pulsar Functions にアクセスできるようになりました。これにより、高価な Lambda 関数を使用したり、追加のサービスを立ち上げたりする必要がなくなり、消費されるイベントに対して行う処理の数を増やすことができました。あるトピック内の順序どおりの保証のサポートを強化することで、さらにいくつかのビジネスユースケースが可能になりました。

最後に、Pulsarは幅広い特徴と機能をすべて1つのシステムで提供してくれたため、これまで使用していた多くのポイントソリューションが不要になりました。これにより、パブ/サブ用のKafkaとキューイング用のRabbitMQとAmazon SQSという複数のメッセージングテクノロジーが不要になりました。また、処理に Kinesis Streams を使用する必要も、ストリーミングデータをデータストアにロードするのに Kinesis Firehose も不要になりました。このテクノロジーのリストから Pulsar に移行したことで、コストと複雑さが軽減されただけでなく、他のクラウドインフラストラクチャプロバイダーのサポートも容易になりました。Narvar は Pulsar を本番環境で使い始めてから 1 年近く経ちますが、非常に信頼できる主力製品であることが証明されています。

‍この記事の寄稿者: グナナ・プラカシュ、シャーウィン・ピント、ラジャン・ビジェイクマール、トミー・ミュースバーガー、コーリー・ホール

このビデオで、NarvarがApache Pulsarをどのように使用しているかについて詳しく学んでください。 パルサーサミット NA 2021でのアンクシュ・ゴヤルの基調講演

Narvarはエンジニアリング人材を採用しています —私たちと一緒に小売業の未来を築きましょう！