ボンサイ、何百万ものデータポイントを処理する自動イベント駆動型アーキテクチャにAivenを採用

商品カタログの拡大に伴うデータ課題をAiven for Apache Kafka® on Google Cloudで解決

2016年に設立されたBonsaiは、北米とヨーロッパのエリート出版社や小売業者から信頼されているEコマースプラットフォームです。そのディスカバリーコマース技術により、ユーザーは好きなコンテンツ内で商品を購入することができる。Bonsaiの商品カタログがShopifyの小規模店舗で数千点だった商品から数百万点に拡大し、絶え間ない更新を受けるようになったとき、同社はAivenのマネージドサービスを利用したGoogle Cloud上の自動化されたイベント駆動型のデータアーキテクチャに注目しました。

Aivenのコマーシャルアカウントエグゼクティブであるアラン・スコットは最近、Google CloudカスタマーコミュニティであるC2C主催のウェビナーの一環として、Bonsaiのエンジニアリングディレクターであるブレント・ヴァン・ガートルイと対談しました。このウェビナーでは、Bonsaiの何百万ものデータポイントのデータパイプラインを構築する際の主な推進要因、課題、成果について話し合われました。以下はその抜粋です。

**アラン・スコット：Bonsaiについて教えてください。

ブレント・ヴァン・ガートルイ（以下、ブレント）：* 私たちは、消費者が購買意欲を形成しているときに購入できるよう、現場でのチェックアウトを提供するテック企業です。API、あらかじめ構築されたUIコンポーネント、商品フィードなど、さまざまな統合方法を用いて、現在ベストバイを含む400以上の小売業者から数百万点の商品を集めたカタログを提供しています。商品を提供するパートナー、カタログやAPI、UI製品を利用するパートナー、そしてそれらの商品を閲覧し購入する顧客がいます。

**アラン・スコット：Aivenを使い始めたとき、どのような問題を解決しようとしていましたか？

**Brent Van Geertruy:**ここ数年で、当社の商品カタログはShopifyの小さな店舗で数千点の商品から数百万点の商品に増えました。そのため、価格の変更から在庫の更新まで、毎日膨大な数の更新が必要です。

私たちは、私たちが構築し、維持している独自のカスタムダッシュボードを持っています。このダッシュボードは、注文処理、マーチャント、クライアント、商品カタログの管理に使用しています。数年前までは、小規模な加盟店から高品質の商品情報が届かないことがよくありました。社内のチームはすべての商品をチェックし、商品説明から色に至るまで手作業で確認し、当社のデザインに合っているかどうかを確認しなければなりませんでした。これでは拡張性も持続性もありません。

私たちは当初、商品をインポートするのに20近い同期ステップが必要な大規模なモノリシック・アプリケーションを持っていたため、イベント駆動型システムの研究を始めました。最初に取り組むべき課題のひとつは、画像のアップロードでした。商品を取り込むたびに、画像をサーバーにアップロードしなければなりません。販売店の画像URLはブロックされたり、画像加工が許可されないことが多いため、私たちは頼ることができませんでした。たった1,000点の商品、あるいは10万点の商品のフィードを想像してみてください！そのたびに、画像のアップロードが完了するのを待つパイプライン全体が混雑してしまいます。

私たちはAiven for Apache Kafka®を使い始め、同期的な処理を減らし、よりイベントドリブンなアプローチを取るようにしました。また、フィードを生成するために、MongoDBへのAivenコネクタを使用してKafkaを活用しています。手動で商品に変更があったことを表示してフィードを更新する代わりに、MongoDBコネクターを使って商品の変更を待ち、それを自動的にエクスポートシステムに移動しています。Aivenを使ったセットアップは簡単でした。インフラストラクチャーの観点からも、AivenのTerraformプロバイダーを使えるのは素晴らしいことです。

**アラン・スコット：モノリシックからイベント・ドリブン・アーキテクチャへの移行について教えてください。

ブレント・ヴァン・ガートルイ（以下、ブレント）：* 私たちのチームは、イベント駆動型アーキテクチャについて何年も議論してきました。アプリケーションをスケーリングする際のあらゆる問題を解決する聖杯のように思われていました。特にNetflixがその使い方を強調したときは、話題にもなりました。

しかし、私たちのアプリケーションにはすでに大量のロジックが含まれており、非常に結合性が高く同期的で、5年前にさかのぼる過去の実験による技術的負債がありました。そのため、クライアントからのカスタマイズ依頼を優先して、大規模な手直しは常に見送られていました。

私たちが最終的にKafkaを使い始めたのは、APIの利用が増えたからです。製品に成熟度を与えることができたので、技術的負債に取り組む時間を確保し、エコシステムのより大きな部分の再構築に集中することができました。私たちはシニア開発者たちと何度かセッションを重ね、完璧な世界とはどのようなものなのか、現在のボトルネックは何か、そしてイベントドリブン・アプローチでそれらを解決できるかどうかを確認しました。私たちはイベント・ドリブンを選択しましたが、モノリスからイベントへの全面的な再構築ではなく、移行を行いました。

**アラン・スコット：Aivenを選んだ基準は何ですか？

ブレント・ヴァン・ガートルイ（以下、ブレント）：* 私たちはこれまで、利用課金型のツールを選ぶことが多く、常に小さなコストから始めてきました。しかし、毎日何百万ものアップデートを処理する製品パイプラインに関連する場合、このコストはすぐに膨れ上がります。価格の透明性は、Aivenを選んだ理由のひとつです。また、Googleは私たちの主要なクラウドプロバイダーなので、Googleマーケットプレイスを通じてGoogleクラウドと統合することで、本当に簡単にプラットフォームを使い始めることができました。Aivenのチームは素晴らしいサポートを提供してくれますし、私たちはKafka以外の専門知識を持ったベンダーを探していました。また、マネージド・インメモリNoSQLデータベースのRedisにもAivenを使っています。Kafkaと同じプロバイダーから、GCPの課金を通じて入手することで、より簡単になりました。

**アラン・スコット：主な学習は何ですか？

ブレント・ヴァン・ガートルイ（以下、ブレント）：* 最初の提案は、すべてをイベント駆動型システムにすることでした。その代わりに、システムを測定し、ボトルネックを特定し、より機敏な方法で取り組むようになりました。あるボトルネックを解決すると、別のボトルネックが現れることがよくあります。

顕著な例は、商品画像を同期的にアップロードしていたのを、非同期的な方法でイベントを使用するように切り替えたときです。画像がパイプラインをブロックするという問題は解決しましたが、すぐに商品パイプラインが入荷商品のスピードを処理できないという問題にぶつかりました。基本的に、商品画像のアップロードの遅さが、パイプラインの遅さと安定性を保っていたのです。この問題を取り除くと、他の場所でも負荷を感じるようになり、現在はそれも改善されています。つまり大きな収穫は、大幅なオーバーホールをするよりも、より上位のアーキテクチャプランを考慮しながら、ボトルネックごとに取り組む方が良いということです。

ウェビナーの全容をご覧ください：https://aiven.io/webinar/building-real-time-event-streaming-engines

Aivenと私たちのサービスに関する最新ニュースや、オープンソースに関する様々な情報を入手するには、月刊ニュースレターを購読してください！Aivenに関する日々のニュースは、LinkedInとTwitterのフィードでご覧いただけます。

サービスのアップデート情報を知りたい方は、変更履歴をご覧ください。