大手オンライン・デリバリー・サービス

産業

技術情報

はじめに

NashTechは、Amazon SNSとSQSメッセージングレイヤーを、NashTechクラウドソリューションとApache Kafkaをベースとしたイベントドリブンアーキテクチャに置き換えるお手伝いをしました。

食料品や生活必需品のオンライン・デリバリー・サービスは、シームレスな取引を迅速かつ確実に完了できるかどうかにかかっている。顧客が欲しい商品を選択し、注文をすることから始まり、ショッパーがその注文を主張し、選択した小売店を訪問し、商品を購入し、顧客に配送する。

課題

米国で最も急成長しているデリバリーサービスの1つでは、これらのトランザクションは、Apache Kafka®とNashTech Cloudソリューションをベースにしたイベントドリブンアーキテクチャによって支えられています。顧客注文のほぼリアルタイムのイベント・ストリームの処理に加え、このアーキテクチャは、数テラバイトのデータと1日あたり最大2,000万件のメッセージを処理する製品データ・パイプラインをサポートしている。

イベント・ストリーミング・インフラストラクチャは、Amazon Simple Notification Service（SNS）とAmazon Simple Queue Service（SQS）をベースにしていた同社のレガシー・メッセージング・レイヤーを置き換えたもので、多くの重要な利点を提供している。ナッシュテックのクラウド・ソリューションは、クラウド・ベンダーにとらわれないソリューションを提供しながら、迅速なスタート、運用上のオーバーヘッドの最小化、エンジニアリングの省力化を可能にした。

SNSとSQSメッセージングをKafkaとNashTechクラウドソリューションに置き換えたことで、同社はビジネスプロセスを最適化し、イベントストリーミングの利点を新たな取り組みに拡大する機会を捉えている。「私たちはすでに、開発したすべての新サービスをナッシュテック・クラウド・ソリューションで開始しています」とエンジニアは言う。「ボトルネックを減らし、リアルタイムオペレーションに近づける。

解決策

SNSとSQSを数年間使用した後、同社はAmazonサービスのいくつかの問題点を解決するために、KafkaとNashTechクラウド・ソリューションに移行した。重要な要因は、CTOが推進するクラウドにとらわれないソリューションへの全社的な後押しだった。 SNSとSQSのその他の欠点には、メッセージ・サイズの制限、メッセージ保持やメッセージ圧縮の欠如などがあり、同社は社内で回避策を開発するために多大なエンジニアリング労力を費やす必要があった。

レガシー・メッセージング・レイヤーをKafkaに置き換えることで、これらの制限は即座に解消された。エンジニアリング・チームは、トピックごとにメッセージ・サイズ制限を設定し、あらゆるプロデューサーの圧縮を有効にして、ペイロード・サイズと帯域幅の消費を抑えることができるようになった。

それは、小売業者から商品データを消費し、それをエンリッチして、他のサービスで利用できるようにする既存のサービスを置き換えるというものでした。「Kafkaがこのユースケースでうまく機能するなら、私たちが考えている他のユースケースでもうまく機能するはずだと考えていました。「エラーを起こしても、元のソースからデータストアを再構築することができる。

初期設定と開発作業を通じて、チームはナッシュテックのエンジニアと定期的に会い、ベストプラクティスと運用の詳細について話し合った。「NashTechとは毎月同期を取り、ミラーリングのトピックやクラスタの監視、その他関心のある問題について話し合いました。

最初のプロジェクトでの成功を受けて、チームはイベント駆動型アーキテクチャに新しいサービスを追加し、パイプラインの大規模なリファクタリングを計画している。「新しいサービスを立ち上げたとき、既存のトピックから利用を開始することができ、データはすでにそこにあります。「ログ・コンパクションを利用して製品パイプラインをリファクタリングし、並列非同期モデルへと移行することは、我々にとってさらに大きな勝利となるだろう。

チームはまた、全社的なイベント・ストリーミングの採用をさらに加速させるため、標準的なライブラリとツールの開発にも取り組んでいる。これには、チームが宣言的な設定ファイルを使ってTerraform経由でトピックを作成できるようにする、infrastructure-as-codeイニシアチブが含まれる。

「SNSでは、メッセージ圧縮のためにカスタムコードを書くか、より大きなペイロードが必要とする余分な帯域幅のためにお金を払う必要がありました。ナッシュテックのクラウド・ソリューションでは、サービス間通信のための、より柔軟で堅牢なソリューションとともに、すぐにそれを実現することができました。”

シニア・ソフトウェア・エンジニア

その結果

初期設定時間が数ヶ月から数分に短縮。 「ナッシュテックのクラウド・ソリューションを使えば、Kafkaクラスタをセットアップし、シンプルなイベント・パブリッシングを1時間ほどで行うことができました。「すべてを自分たちで立ち上げなければならなかったとしたら、学習曲線のせいもあって、4カ月から6カ月はかかっただろう」。

エンジニアリングの労力を削減。「過去に直面したSNSのメッセージサイズ制限では、大きなペイロードを分割するコードを書かなければならず、効率が悪かった。「同様に、メッセージ圧縮ができないため、より多くのコードを書くか、より多くの帯域幅を支払う必要がありました。ナッシュテックのクラウドソリューションでは、簡単な設定変更でメッセージサイズを設定し、圧縮を有効にすることができるため、そのような心配は一切ありません。”

運営管理は最小限に。 「Kafkaインフラを100％管理する専任のスタッフはいません。「ナッシュテックのクラウド・ソリューションは、信頼性と可用性を備えた大量のトラフィックを処理します。

新たな能力が可能になった。 「Kafkaのメッセージ保持とNashTechクラウド・ソリューションによって、コア・パイプラインのすべてのデータを並行して処理し、商品情報を充実させることができます。「さらに、コンシューマーのひとつにバグが見つかれば、それを修正し、以前のメッセージを再生して、発生した問題を解決することができます。また、トピックに新しいコンシューマーを追加する際も、何日分ものデータを保持しているので、それを使ってシードすることができます。以前は不可能だったことです。

スループットは倍増した。 「レガシーのメッセージング・レイヤーは、近隣で毎秒2万件のメッセージを処理していました。「ナッシュテックのクラウド・ソリューションに切り替えたところ、大きな変更を加えることなく、この割合を2倍以上に高めることができました。

「NashTech Cloudソリューションのおかげで、社内でKafkaを運用するための学習期間を短縮することができました。NashTech Cloudのソリューションにより、社内でKafkaを運用するための学習曲線を遅らせることができました。現在、自社でクラスタをホストし管理するためのリソースや帯域幅はありません。

シニア・ソフトウェア・エンジニア