re:Invent 2024: Centric BrandsのBuy with Prime活用事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Centric Brands: A journey using AWS analytics and Amazon services (BWP303)
この動画では、Buy with PrimeのシニアソリューションアーキテクトのMadhav Guptaと、Centric BrandsのシニアディレクターBlair Rafuseが、IZODブランドでのBuy with Prime導入事例を紹介しています。Centric Brandsは年間40万件の注文を処理する大手アパレル企業で、物流パートナーのキャパシティ問題を解決するためにBuy with Primeを採用しました。導入にあたってはAWS LambdaやAWS Glue、Amazon S3などを活用し、注文データと手数料情報の統合や自動化を実現。Terraformを使用したインフラのプロビジョニングにより、効率的なデプロイメントフローを構築しました。その結果、Prime会員向けの迅速な配送と13,000件以上のレビュー連携を実現し、顧客体験を大幅に向上させることに成功しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Buy with Primeの概要とCentric Brandsの事例紹介
皆様、本日はご参加いただきありがとうございます。私はBuy with Primeのシニアソリューションアーキテクトを務めるMadhav Guptaと申します。本題に入る前に、会場の皆様に簡単にお伺いしたいと思います。Prime会員として、迅速な無料配送のメリットを享受されている方は何名いらっしゃいますか？挙手でお願いします。Buy with Primeが、これらと同じメリットを加盟店のウェブサイトで直接提供できるようになったとしたらどうでしょうか？Buy with Primeは、オンラインショッピングの場所を問わず、同じPrimeのメリットを提供できるよう、加盟店向けのサービスを変革しています。
本日は、そのようなユースケースの一つとして、Centric Brandsとそのeコマース分野における取り組みについてお話しさせていただきます。 特に、新しいDirect-to-Consumerウェブサイトの重要な要素としてBuy with Primeを選択した理由に焦点を当てます。その後、サービスとしてのBuy with Primeの主要なコンセプトについて掘り下げ、ショッパージャーニーにより詳しく注目します。この統合の一環として、Buy with Primeのチームは、特にアナリティクスに関連する複数の課題を解決するためにCentric Brandsと緊密に協力しました。これらの課題をAWSを使用してどのように解決したかについて詳しく説明し、その後、Centric Brandsの現在の取り組み状況についてお話しさせていただき、最後に質疑応答の時間を設けたいと思います。
Centric Brandsの事業概要とEコマース戦略
それでは、Centric Brandsのシニアディレクター（Eコマース担当）であるBlair Rafuseをお迎えしたいと思います。Blair、お願いします。素晴らしいLas Vegasで、Cyber MondayにAmazonとre:Inventで共同発表できることを光栄に思います。これは私にとって2回目のre:Inventへの参加になります。2013年の第1回re:Inventに参加する機会に恵まれました。クラウドの発展と、このカンファレンスの規模の拡大には本当に驚かされます。当時はVenetianだけで開催されていましたが、現在は5つのホテルに広がっていると思います。
皆様、こんにちは。Blair Rafuseと申します。Centric Brandsのテクノロジーリーダーを務めています。Centricには約4年在籍しており、Direct-to-ConsumerおよびBusiness-to-Business Eコマース、実店舗向けの小売アプリ、そしてオムニチャネル機能で構成されるデジタルエクセレンスセンターを率いる素晴らしい機会を得ています。 Centric Brandsは、製品設計、開発、調達、小売およびデジタルコマース、マーケティング、ブランド構築においてリーダー的存在であるグローバルなライフスタイルブランドの集合体です。私たちは、生涯価値を構築する多様な製品カテゴリーを通じてブランドを成長させる力を信じています。当社の製品は、主要小売店、専門店、百貨店、そしてオンラインで販売されており、Amazon.comは1Pおよび3Pの両面で、そして現在はBuy with Primeを通じて、Centric Brandsにとって非常に重要な戦略的パートナーとなっています。
端的に言えば、私たちはブランドを構築しています。メンズ、レディース、キッズのアパレル、アクセサリー、ビューティー分野でリーダー的存在であり、100以上のライセンスブランドと自社ブランドからなる素晴らしいポートフォリオを持っています。Calvin Klein、Tommy Hilfiger、Joe's Jeans、Under Armour、Disney、Coachなど、多数のブランドのライセンスで事業を展開しています。また、Robert Graham、Hudson Jeans、Avirex、Fiorelliなどの自社ブランドも所有しています。さらに、急成長中のFavorite Daughter、Jennifer Fisher、Preston Laneブランドを含む、非常に注目度の高いジョイントベンチャーも運営しています。これらすべてを実現する2,000人以上の情熱的な従業員を擁しています。本社はNew York Cityにあり、グローバルな市場へのリーチとサプライチェーンの効率性を高めるため、世界中にオフィスを構えています。
</transcript>
私の言葉をそのまま信じる必要はありません。私たちがどのような企業なのか、お見せしましょう。 Centric Brandsは主にホールセールビジネスを展開していますが、Direct-to-Consumerチャネルにおいても専門的な知見を持っています。私たちは優れたDirect-to-ConsumerのEコマースポートフォリオを持っており、私はそれを実現する支援ができることを光栄に思っています。11のEコマースウェブサイト（そして増加中）を運営しており、すべてを社内で支援しています。素晴らしい開発チームからデジタルマーケティングチーム、グラフィックデザイナー、商品撮影担当者、マーチャンダイザー、コピーライター、Eコマースマネージャーまで、すべてを一貫して行っています。
私のチームは、Robert Graham、JOE'S、Favorite Daughter、IZODなどの素晴らしいブランドをサポートしています。このセッションではIZODに焦点を当てます。私たちのデジタル・センター・オブ・エクセレンスは、請求時間や予算超過、エスカレーションのない社内Eコマースエージェンシーのように運営されています。クライアントの予算を超過する心配なく、私たちの好きな仕事に集中できます。そのため、ピクセルパーフェクトを追求するための追加作業も、ブランドパートナーの予算を圧迫することはありません。
Eコマースポートフォリオの規模感をお伝えすると、今年は約40万件の注文を処理する見込みです。全体で2,500万のオンラインセッションを達成する勢いです。300万人以上のアクティブなメール購読者を抱え、ブランドは驚くべき前年比成長を遂げています。あるブランドは過去数年間で年間50%の売上成長を達成しています。本当に素晴らしいことです。もちろん、Black Friday Cyber Monday週末はEコマースで最もエキサイティングな時期であり、この数日間のサイトパフォーマンス指標、コンバージョン率、トレンドを分析するのが待ち遠しいです。
IZODブランドのEコマース展開とBuy with Primeの採用
特に私たちのブランドの1つであるIZODのEコマースの journey についてお話ししたいと思います。IZODは皆さんもよくご存じのブランドだと思います。 ブランドの背景をお話しすると、IZODは80年以上にわたってアメリカ人の装いを支えてきた、タイムレスでクラシックなブランドであり、多くの男性のクローゼットに欠かせない存在です。IZODのロゴはゴルフコースでよく見かけますし、19番ホールで私が着ているのを見かけるかもしれません。ゴルフコース、テニスコート、オフィスでのビジネスカジュアルなど、あらゆるシーンに対応する
ワードローブソリューションを提供しており、素晴らしい商品カテゴリーを取り揃えています。 2021年にライセンスを取得して以来、Centricがブランドをどのように再構築したかを示す短いブランド動画をご覧いただきます。ご覧の通り、もはや昔のIZODではありません。
IZODのEコマース事業は2021年の夏に始まりました。私のチームは、わずか4ヶ月後のBlack Friday Cyber Monday週末までに、最先端のウェブサイトを構築するという任務を与えられました。その目標は達成したものの、残念ながら私たちの取り組みは物流パートナーのキャパシティの問題で妨げられてしまいました。IZODは主にホールセール事業を展開していたため、当然ながらホールセール出荷に特化した倉庫を選びましたが、ホールセールの取扱量に加えてDirect-to-Consumerの需要まで対応することができませんでした。ホールセールの収益を危険にさらすわけにはいかなかったため、私たちが懸命に作り上げたEコマースサイトは一時棚上げとなりました。物流パートナーがようやくホールセール業務を軌道に乗せたころ、グローバルなサプライチェーン危機が私たちの業界を直撃しました。入港できた商品については、ホールセール小売パートナーからの既存発注への対応を優先せざるを得ず、Direct-to-Consumerはさらに後回しになってしまいました。
サプライチェーン危機が収まった後、私たちは迅速なソリューションを必要としていました。物流の観点から、Direct-to-Consumerをホールセールのように運営できるソリューション、つまり商品をパック単位で出荷し、Amazonにダイレクト販売チャネルの配送を任せるというものでした。その解決策がBuy with Primeでした。市場投入までのスピードが私たちにとって重要でした。今年2月にプロジェクトを開始し、父の日に向けて顧客が新しいポロシャツを購入できるよう、6月までにローンチする必要がありました。
IZODはEコマースサイトです。すでにEコマースサイトが稼働していたのだから、4ヶ月の準備期間でのローンチは簡単だったはずだと思われるかもしれません。2年半前に構築したサイトのほこりを払い、クリーンアップし、Buy with Primeの機能を統合する必要がありましたが、それは難しい部分ではありませんでした。ご存知の方も多いと思いますが、常に最も時間がかかるのはダウンストリームのシステム統合で、この部分でAmazonは本当に力を発揮し、AWS（Amazon Web Services）を使用した持続可能なソリューションの設計と開発を支援してくれました。Amazonの強力な配送ネットワークのおかげで、物流のキャパシティの心配は不要となり、事実上無限のスケーラビリティを実現し、お客様が期待する最高レベルのサービスを提供することができるようになりました。また、私たちのEコマースプラットフォームとのネイティブ統合により、選択も容易でしたし、Prime会員の無料配送と返品サービスは誰もが喜ぶものです。Amazon Primeは間違いなくEコマース配送のゴールドスタンダードを確立しています。さらに、Amazon.comの商品レビューの連携も気に入っています。新しいIZODのEコマースサイトをローンチした初日から、主力商品の1つに約13,000件のレビューが付いており、これは私たちのブランドの全商品のレビュー数を合わせた以上でした。
これらすべてが可能だったのは、IZODが長年Amazonと1P（ファーストパーティ）の関係を築いてきたからで、これらのレビューはすべて1Pを通じて集められたものです。Amazonの商品レビューは大きな転換率向上要因であり、まさにここで勝負が決まると言えます。そして、消費者のレビューを読むなら間違いなくAmazon.comが一番の場所なのです。
Amazon.comは世界で最も信頼されているチェックアウト体験の1つを提供しており、彼らは本当に転換率の最適化を知り尽くしています。そのため、私たちの独自ドメインでこれを活用できることは大きな勝利でした。AmazonのチェックアウトとAmazon Payにより、Prime会員にはストレスのない体験を提供できます。すでにAmazon.comのセッションが開いている場合、顧客はログインする必要もなく、クレジットカードを取り出したり請求先住所を入力したりする必要もありません。すべてがAmazon Payに保存されているからです。スムーズなチェックアウトフローの作成は、Eコマースの転換率向上における重要な要素です。財布を取り出してクレジットカードを出す必要がある場合、転換率は低下してしまいます。
最後に、そして最も重要なのが、Amazon Seller Central とAmazon Payが持つデータ分析と財務照合のための充実したAPI機能です。Amazonは優れた顧客体験を構築するだけでなく、そのバックエンド機能によって、私たちのチームはビジネスプロセスの最適化、データ分析、そして財務照合を自動化するための下流システムとのシームレスな統合を簡単に実現できました。この照合の自動化は私たちにとって極めて重要でした。財務仕訳のためのERPとの持続可能で信頼性の高い統合、そして売上手数料や返品データを送信する機能が必要だったのです。ご想像の通り、会計チームの作業に手作業のプロセスが加わるようなプロジェクトを計画すると、技術チームは会計チームから大きな反発を受けるものです。
実際、ERPへの自動化の橋渡しがなければ、このプロジェクトは始まる前に頓挫していたでしょう。状況を説明すると、Centric Brandsは20億ドル以上の企業で、IZODはそのごく一部を占めるに過ぎません。私たちのスリムな会計チームには、取引を手作業で記録する余裕が単純にありませんでした。Amazonは要件収集から技術設計、開発まで、ソフトウェア開発ライフサイクルのあらゆる面で重要な役割を果たしました。Amazonは、プロジェクトの全ステークホルダーを満足させるソリューションの提供を支援してくれました。これらすべてが、AWSのパワーを活用することで実現できたのです。
Buy with Primeのショッパー体験と技術的課題
さて、私たちの課題や問題点、そしてソリューションについて内部の視点からお話ししてきました。ここで、Amazonの視点から、Buy with PrimeとAWSを使用してAmazonがどのように私たちの課題を解決したのかについて説明させていただきます。ありがとう、Blair。さて、ご覧の通り、Centric BrandsはBuy with Primeを含むこれらの革新的なサービスをすべて統合することで、顧客サービスの大きな一歩を踏み出しました。そして、これは実際に彼らの変革で重要な役割を果たした画期的なソリューションであるBuy with Primeについて話すきっかけとなります。ここで少しお時間をいただいて、実際のBuy with Primeのショッパー体験をご紹介し、CentricのようなブランドがどのようにしてPrimeの特典を拡張できるのかを説明させていただきます。
Buy with Primeのロゴ、つまりそこに表示されているPrimeスマイルロゴは、何百万ものPrimeメンバーが、Amazon.comで期待される信頼できる体験と同じように、直接マーチャントのウェブサイトで買い物ができるようにします。これにより、ブランドは自社のDirect-to-Consumerウェブサイトで、迅速、無料、かつ信頼性の高い配送を提供することができます。
今日はCyber Mondayですので、トースターを買い物している場面を想像してみてください。 Buy with Primeでのショッピングでは、ショッパーはPrimeバッジと配送予定日、そしてBuy with Primeを通じて提供される特典に関するその他の詳細を、そこにハイライトされているように確認することができます。これは、あらゆるマーチャントのEコマース環境における自然な一部となっており、それだけではありません。私たちは、成長を続けるエコシステムのサービスやリアルタイムイベントと、さまざまな高度な統合を提供しています。私たちの目標は、マーチャントのニーズに応えることであり、柔軟でカスタマイズ可能なインターフェースを提供することで、ブランドとその顧客の両方にとってよりスムーズな導入とシームレスな体験を確保できるのです。
次のステップでは、Primeボタンをクリックして Amazon にログインします。ユーザーはログインすると、Prime対象商品すべての更新された適格性と配送予定を確認できます。このシンプルでスムーズなプロセスにより、買い物体験を大きく変えることなく、同じPrimeの特典に簡単にアクセスできます。 ログインすると、これらの更新された配送予定がすべて表示され、どの商品が迅速な無料配送の対象となっているか、そしていつ商品が届くのかを正確に知ることができます。
Primeメンバーの場合、Amazonでおなじみの チェックアウト体験をそのまま楽しむことができます。Amazonアカウントに登録された配送先情報がすべて自動入力され、チェックアウトプロセスで使用されます。 販売者の視点からは、Primeメンバーが期待する注文後の体験を同様に提供します。Amazon.comのプラットフォームで直接注文を管理でき、リアルタイムの配送状況更新を活用することで、購入から配送までシームレスな体験を実現できます。
このプロセス全体を通じて、Buy with Primeは「販売者がショッピング体験と顧客情報を完全にコントロールできるべき」というシンプルな原則を守ってきました。ショッパーの体験を実現するために必要なさまざまなサービスを考えると、単に注文を受け付けるだけではないことは明らかです。配送予定の取得、注文の処理、返品の提供など、特定のタスクに焦点を当てた多くの小さなコンポーネントが相互に接続されていました。
私たちの課題は、これらのサービスすべてを統合することでした。これらのサービス間の相互依存関係の管理は複雑なタスクとなりました。この課題に対処するため、まず基本的なショッピング体験を提供するために不可欠な主要サービスを特定し、製品のスケルトンを作ることに注力しました。これは注文処理、返品、その他の類似機能の実現という形で具体化されました。これらのユースケースがBuy with Prime体験の基盤となり、新機能を開発する際には、このコア構造に沿うようにしました。例えば、必ずしも同じパッケージで発送される必要のない複数のアイテムを仮想的に関連付けることができるVirtual Bundlesなどがその例です。この方法は私たちにとってうまく機能し、最も重要な意思決定プロセスを前もって行うことができました。多くの異なるチームがそれぞれのコンポーネントを統合しようとする中で、一貫した製品提供を維持することができました。
これらの個々のサービスを分離したことで、いくつかの複雑な課題に直面しました。例えば、Primeショッパーが迅速で無料かつ信頼性の高い配送を楽しめるようにしたいと考えました。これはAmazonのフルフィルメントネットワークやAmazon Multichannel Fulfillmentという形で実現されました。同様に、Amazon Payをデフォルトの決済処理サービスとして採用しましたが、将来的に販売者が独自の決済処理サービスを選択できる余地も残しておきました。
Centric Brandsが私たちに相談に来た時、彼らは特殊なユースケースを抱えていました。銀行口座に入ってくる支払いについて、どの注文や返品がその支払いに関連しているのか、そしてBuy with Primeのサービスを利用する際に実際にどのような手数料を支払っているのかを知りたいということでした。一見シンプルな問題に思えましたが、私たちには複数の独立したサービスがあり、彼らはBuy with Primeだけでなく、それらすべてと統合する必要がありました。そのショッパージャーニーを見てみると、顧客がBuy with Primeを通じて注文を行い、Centric BrandsはBuy with PrimeのAPIを通じて注文情報と顧客情報を取得できます。
舞台裏では、サービスが分離されているため、フルフィルメントに関連する情報や保管・配送にかかる実際のコストを把握するために、Centric BrandsはAmazon Multichannel Fulfillmentとも連携する必要がありました。同様に、Centric BrandsがBuy with Primeで選択した決済方法はAmazon Payでした。つまり、取引に関連する手数料情報を取得するために、Centric BrandsはAmazon Payとも連携する必要がありました。まとめると、Centric Brandsは統一されたチェックアウト体験を作成しようとしていましたが、必要なデータを得るために実際には3つの異なるインターフェースと統合する必要があったのです。そしてこれらのデータを取得した後、手作業でそれらを結合する必要がありました。このデータがすべて相互に関連しており、Buy with Primeがまだ初期段階だったことを考えると、簡単な解決策は実際には存在しませんでした。
AWSを活用したアナリティクスソリューションの構築
ここで、Centric Brandsが構築したアナリティクスのセットアップについて詳しく見ていきましょう。まず免責事項として、Centric Brandsのユースケースではデータウェアハウスを通じてクエリを実行するのではなく、すべてのデータを下流のシステムにロードする必要があったため、ELT（Extract Load Transform）ワークフローではなく、ETL（Extract Transform Load）プロセスを使用することにしました。このアーキテクチャを作成するプロセスはとてもシンプルで、入力の決定、出力の決定、初期変換レイヤーの作成という3つのステップで構成されていました。
最初の問題に立ち返って、まず入力について見ていきましょう。Buy with PrimeはAPIを通じてJSONフォーマットでデータを提供していました。注文作成時間の開始時刻と終了時刻を渡す必要があり、ページネーション付きで対応するデータが提供されました。同様に、MCFも独自のフォーマットを持っていました。週単位で生成されるCSVフォーマットのSettlementファイルで、出荷された様々なアイテムとその保管・配送コストが含まれていました。最後に、Amazon Payは日次ベースでS3の署名付きURLを通じてCSVファイルで取引データを提供していましたが、これは前日のすべての取引を含んでいました。これらが私たちが扱うデータ入力でした。
いくつかの重要なポイントを強調しておきたいと思います。まず、受け取るデータフォーマットが異なっていました。JSONとCSVファイルがあり、それぞれに独自のデータクレンジング作業が必要でした。次に、このデータを受け取る頻度も異なっていました。Buy with Primeはアドホックなリクエストであったのに対し、Amazon Multichannel Fulfillmentは週次、Amazon Payは日次でした。
私たちのデータは2つの異なるフォーマットに対応していました。一方では、注文レベルのトランザクションファイルがありました。Amazon Payの手数料は、購入者がチェックアウトした時点で請求され、それが注文に対応する手数料となります。Amazon Multi-channel FulfillmentとBuy with Primeには、アイテムレベルまでの詳細情報が含まれていました。つまり、JSONファイルには注文データと、その注文を構成する全ての個別アイテムが含まれていました。Multi-channel Fulfillmentの場合、サマリーレポートには出荷された様々なアイテムとそれらに対応するコストも含まれていました。
Centric Brandsに全く新しいサービスを構築させ、分析サービスを再設計させるのではなく、まずこの2種類のデータを分割することにしました。注文レベルのデータは、アウトプットとしてトランザクションレポートの形で1つのファイルにまとめられました。もう一方は、アイテムレベルの詳細情報を提供する実データで、これは注文ファイルの形で提供されました。ここまでは順調でしたが、ETLプロセスに進む前に、技術要件を整理しておく必要がありました。
開発するソリューションは、容易にスケール可能で展開可能なものである必要がありました。Blairとそのチームがトラブルシューティングのために24時間体制で待機する必要がないようなものです。また、Centric Brandsは3つの主要なインプットに基づいて、全てのデータと変換を含む週次レポートを求めていました。レポート自体は完全に自動化され、固定されたスケジュールで実行される必要がありました。最後に、データは手作業による介入なしで、下流のシステムにロードされなければなりませんでした。
最初の要件に関して、BlairとそのチームがMicrosoft Azureで豊富な経験を持っていたため、Terraformを活用することにしました。AWS CDKのような新しいサービスを導入するのではなく、マルチクラウドに対応したアプローチを選択しました。Terraformにより、彼らの既存の専門知識に沿った、柔軟でスケーラブルなソリューションを構築することができました。Terraformで使用した機能については、このプレゼンテーションの後半で詳しく説明します。ですが今は、私たちが作成したアーキテクチャについて掘り下げていきましょう。ここでAWSが活躍することになり、プロセス全体をシームレスに処理するETL重視のアーキテクチャを構築しました。
私たちは、様々なソースからデータを読み込み、一時的なストレージ場所に保存する抽出ステージを設けました。変換ステージでは、Centric Brandsのレポーティングニーズを満たすために、データのクリーニング、集計、計算を行いました。ロードステージでは、変換されたデータを目的の下流システムにロードしました。これらの各レイヤーは、インプットからアウトプットまでデータが効率的かつ正確に流れることを保証する上で重要です。さらに詳しく見ていきましょう。まず抽出レイヤーから始めます。ここでの目標は明確です。各システムから必要なデータを取得し、次の処理ステップに向けて準備することです。定期的にレポートを生成するために、Amazon EventBridge Schedulerを活用することにしました。これにより、AWS Lambda関数をトリガーし、全てのデータソースからデータを取得して、変換ステージでの処理に向けて準備することができました。変換ステージでの処理に関して、
クリーンデータはレポートタイプとRunごとにパーティション分けされてAmazon S3に保存されました。このパーティションについて詳しく説明したいと思います。分析の世界では、パーティションの設計によってクエリの実行時間が数秒で済むか数時間かかるかが決まってくるからです。具体的に、これらのパーティションを選んだ理由は、Blairとそのチームが問題発生時にデータの出所に基づいてデバッグしやすくするためでした。取引データが欠落している場合、対応するAmazon Payのレポートを確認することができます。
Runの日付を選んだ理由は、これらの異なるレポートにはそれぞれ独自のデータ頻度があったからです。次の7つのAmazon Payファイルに関連するパーティションを取り込むための追加の複雑さを組み込むのではなく、代わりに独自のスケジュールを作成し、様々なアップストリームシステムから切り離すことを選択しました。また、これにより過去のトレンド分析も容易になりました。各データセットを照会して、過去1年間や過去3ヶ月間のパフォーマンスを分析し、製品に関する洞察を得ることができます。例えば、過去3ヶ月間で最も売れた商品や、過去6ヶ月間で最も手数料が発生した商品を特定することができます。この構造により、データプロセスが常に最新のデータを持ち、Transform層での利用に適した、整理されてアクセスしやすい形式であることを確保しました。
これら3つのソースからデータを抽出してAmazon S3に保存した後、次のステップは実際にデータを変換することでした。そのためには、各データセットの正しいパーティション情報を読み込む必要がありました。AWS Lambdaがデータをamazon S3に保存すると、AWS Glueがトリガーされます。 AWS Glueでは、いくつかの重要なステップを実行しました。まず、スキーマの検証を行いました。各システムから50や10のフィールドが提供されますが、実際に必要なのは約10の属性だけでした。このステップで、本当に必要な10の属性を確保しました。これにより、明日Buy with PrimeやAmazon multi-channel fulfillmentで新しいフィールドが追加されても、ブランドへの影響を受けないようにしました。
次のステップはデータクリーニングでした。出力形式がCSVファイルである必要があったため、3つのデータセット間の結合条件を適切に処理する必要がありました。例えば、注文IDは異なる形式で保存されており、item IDなどの他のサブ属性も、すべてのデータセット間で一貫性を持たせる必要がありました。その後、欠損値のあるレコードをフィルタリングする必要がありました。ここでいくつかのエッジケースに遭遇しましたが、最終的に解決しました。先ほど説明した頻度に関して、手数料は異なるタイミングで課金されることに気づきました。Amazon Pay手数料は、ショッパーが取引を行った時点で課金されます。しかし、その取引が発生してから商品が実際に出荷されるまでにはタイムラグがあり、Amazon multi-channel fulfillmentは商品が出荷される時点で保管料と配送料を請求します。この場合、今日商品を注文して同日中にレポートを実行すると、対応する注文情報とAmazon Pay取引手数料は得られますが、Amazon multi-channel fulfillmentの手数料は得られません。すべてのデータを確実に取得するために、現在のパーティションだけでなく、前回のパーティションのデータも取り込み、主要な結合条件が持っているデータに基づいて処理されるようにしました。
日付範囲でフィルタリングを行い、生成されたレポートが関連する注文データを正確に反映し、すべての情報が存在することを確認しました。これが完了すると、この情報をS3に保存し、これは通常Load段階と見なされます。私たちにとっては、Centric Brandsのダウンストリームシステムで処理するために、この情報を確実にロードする必要があったため、一時的な保存という位置づけでした。
S3オブジェクトの作成イベントは、 AWS Lambdaのトリガーとして使用されました。これは私たちにとって理想的な選択でした。設計時点では出力先の正確な性質が不明確で、将来的な変更に対応できる必要があったため、例えばCentric Brandsがメールでの送信を選択する可能性もありました。Lambdaを採用したことで、基本的なアーキテクチャを変更することなく、そのような変更にも対応できるようになりました。
さて、アーキテクチャができあがりましたが、ここでTerraformについてもう一度見直してみましょう。これを構築した後も、適切な制御を行いながらスケールアップとデプロイができることを確認する必要がありました。理想的なシナリオでは、Centric Brandsが変更を加え、下位環境でテストを行い、承認を得た後にProductionにプッシュする、という流れになります。Terraformでは、Backend設定ファイルと環境ファイルという2つの重要な概念を使用してこれを実現しました。
通常、Terraformはデフォルトでローカルデプロイメント設定を許可しています。ユーザーは変更を加え、自分のコンピューターから直接デプロイすることができます。しかし、これによってState変更の競合が発生する可能性があります。例えば、Blairがある変更をテスト環境にプッシュしている時に、私が別の変更を同じテスト環境にプッシュしようとした場合、同じリソースを変更することになるため、競合が発生してしまいます。これに対応するため、私たちはリモートデプロイメント設定を採用しました。
環境ごとに1つのファイルが必要で、これはTerraformの初期化、つまりデプロイメントの最初のステージで提供されます。このファイルの目的は、Stateファイル管理のためのリモートBackendストレージの詳細、具体的にはAWSの場合、StateファイルとState lockを管理するS3バケットとDynamoDBテーブルを指定することでした。StateファイルはAmazon S3に保存され、そのためにリージョンとバケット情報を確実に持っている必要がありました。State lockはDynamoDBテーブルに保存され、そのためにテーブル名とそのテーブルのパーティションキーを確実に持っている必要がありました。
Backend設定に加えて、環境ファイルも必要でした。DevとProd環境を完全に分離する必要がありました。この環境ファイルには、異なるAPIを呼び出すために使用されるSecretsのARNや、実行頻度、レポートの保存場所など、必要な特定の情報がすべて含まれていました。これはPlanとApplyステージで指定されました。これら2つのファイルにより、Centric Brandsは異なる環境のためにコードを修正する心配をする必要がなくなりました。将来、新しい環境を追加したい場合は、リポジトリ内でこれら2つのファイルを適切に設定するだけで済むようになりました。
Centric BrandsのBuy with Prime導入後の成果と今後の展望
Blair と彼のチームは、このアーキテクチャを成功裏に実装し、Buy with Prime と共に積極的に活用して業務の効率化を図っています。この統合は、特にデータ管理において、プロセスの最適化に大きく貢献しています。ここで、Blair に再び登壇していただき、現在の取り組みの状況と、これらのソリューションが彼らのビジネスにどのような影響を与え続けているかについて、アップデートをお話しいただきたいと思います。
では、現在の状況についてお話しします。私たちは、部門横断的なチームの努力により、2024年6月の目標期日通りに、リニューアルした IZOD.com のローンチを達成しました。Buy with Prime での堅調な売上成長とともに、Eコマース事業の規模を拡大し続けています。先ほど紹介したテクノロジーソリューションは、社内の開発チームが完全にサポートしていますが、これは私たちにとって全く新しい技術スタックであり、この新技術を採用することは間違いなく大きな挑戦でした。
このプロジェクトの検討時点で、Centric Brands は AWS にほとんど足跡がなく、私のチームは様々な AWS サービスやインフラのプロビジョニングについてあまり経験がありませんでした。しかし、フルスタック開発者たちは必要なプログラミング言語を素早く習得し、Terraform でのインフラストラクチャ・アズ・コードの運用により、サーバーのプロビジョニングも容易になりました。Serverless モデルは素晴らしく、非常にコスト効率が良いものでした。そして、もちろん Madhav のサポートは本当に助かりました - 彼は素晴らしい技術パートナーであり、おそらく出会える中で最も素晴らしい人物の一人です。
Amazon との提携関係は、ますます強化されています。最近、Lionel Messi のブランドを Amazon Fashion でローンチし、また、ハイファッションブランドの HERVE LEGER に最適な Amazon Luxury Stores など、新しい Amazon プログラムの展開を続けています。IZOD の Buy with Prime カスタマーエクスペリエンスについて、チェックアウトをさらに簡単にする新機能の開発を進めており、Buy with Prime ソリューションのアナリティクス連携と在庫管理機能の改善も継続的に行っています。
そしてもちろん、新しいビジネスチャンスも広がっています。IZOD での Buy with Prime の経験が非常に良かったため、新しいブランドをプラットフォームに追加することを検討しています。新しいブランドを獲得したり、既存ブランドの市場展開を検討したりする際には、常に Buy with Prime がビジネス戦略の議論に含まれています。また、既存のクラウドやオンプレミスの資産を AWS に移行することも検討しており、re:Invent での時間を最大限活用して、新しい潜在的な技術パートナーとの出会いを期待しています。以上で、プレゼンテーションを終わります。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion