re:Invent 2024: CarGurusのMLOpsプラットフォーム構築事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Using machine learning to enhance the online car-shopping experience (AUT205)
この動画では、オンラインの自動車マーケットプレイスCarGurusにおけるMachine Learning活用事例について解説しています。CarGurusのIMV（Instant Market Value）アルゴリズムによる車両価格の適正評価や、リアルタイムレコメンデーション機能の実装について、具体的なアーキテクチャと共に説明されています。特に、Amazon SageMaker、Amazon Kinesis、Apache Flinkなどを活用したMLOpsプラットフォームの構築事例は詳細に語られており、大規模なデータセットを扱うための自動化、ガバナンス、モニタリングの実践方法が示されています。Data ScientistとMachine Learning Engineerの協業による、再現性と信頼性の高いMachine Learningプロセスの実現方法が具体的に解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
CarGurusのMachine Learning活用：自動車オンラインマーケットプレイスの革新
おはようございます。ヘッドフォンから声は聞こえていますでしょうか？ありがとうございます。このようなサイレントセッションは私にとって初めての経験です。国連での同時通訳用ヘッドフォンのようなイメージで考えると、この形式にも慣れやすいかなと思っています。本日は、オンラインの自動車購入プロセスにおけるMachine Learningの活用についてお話しさせていただきます。私はAWSのSolutions ArchitectのJason Stehleで、主にデジタルカスタマーエクスペリエンス、自動車産業、そしてAIを専門としています。今回はCarGurusのMachine Learning活用事例についてお話しし、CarGurusからJason PrenticeとRaghu Mulukutlaのお二人をお招きして、CarGurusが過去数年間でどのようにMachine Learningを活用してきたかについて詳しくご説明いただきます。
まず私から、業界のトレンドやデジタルカスタマーエクスペリエンス、そしてMachine Learningについてお話しします。その後、JasonとRaghuからCarGurusのMachine Learningの取り組みについて、そして彼らが時間をかけて構築してきたアーキテクチャとプラットフォームについて詳しくご説明いただきます。 デジタルカスタマーエクスペリエンスにおけるMachine Learningの大きなトレンドの一つとして、大規模なデータセットが実用的になってきていることが挙げられます。より複雑なモデルを構築し、新しい知見を得ることができるようになってきましたが、これら大規模なデータモデルやMachine Learningモデルを管理するためには、より優れた実践方法や自動化、そして運用プラクティスが必要となってきています。
よくある氷山の図で恐縮ですが、基本的な考え方としては、氷山の頂上部分で様々な業界におけるAIアプリケーションや革新的な取り組みを目にすることができます。しかし、それらの機能を構築するために必要なデータ関連の作業量は、必ずしも目に見えるものではありません。データのストリーミング、自動化、ガバナンス、ストレージ、データベースなど、すべてが必要不可欠です。これらがあってこそ、AIアプリケーションで表面化させたときに「garbage in, garbage out（質の悪いデータを入れれば、質の悪い結果しか得られない）」という事態を避けることができるのです。
デジタルカスタマーエクスペリエンスにおけるMachine Learningの重要性
このようなデータがあることで、より高度なモデルを構築できるようになります。大規模なモデルを大規模にトレーニングする計算能力と機能を手に入れることができました。現在、特にGenerative AIの分野では多くの興味深い進展が見られます。ただし、重要なポイントとして、Generative AIは画像や言語、テキストの分野で優れた性能を発揮する一方で、従来のMachine LearningやDeep Learningで解決すべき課題もまだまだ多く残されているということです。従来型のMachine LearningやDeep Learningへの投資も、Generative AIと同様に重要だということを忘れてはいけません。
デジタルカスタマーエクスペリエンスの場合、私たちが目指すのはカスタマーの成果を向上させることです。関連性の高いレコメンデーション、適切な商品やサービスの推奨、そしてカスタマーの興味に最適化された優れた検索結果を提供したいと考えています。これを適切に実現できれば、カスタマーは望む商品を手に入れることができ、私たちは購買サイクルを短縮できるという、Win-Winの関係を築くことができます。
パーソナライゼーションにおいて、1ヶ月後に実現される個別化は特に有用でも価値があるものでもありません。1ヶ月後、あるいは数日後、時には数時間後に発動するドリップキャンペーンは、ユーザーがWebサイトやアプリを使用している最中に提供されるレコメンデーションと比べると、その効果は大きく劣ります。私たちが目指すのは、ユーザーがアプリを使用している瞬間を捉えることです。そのためには、数秒あるいは1秒未満での最適化を実現するという、非常に興味深いエンジニアリングの課題を解決する必要があります。
これらのDatasets、高度なモデル、そしてリアルタイム処理には、多くの要素が関係しています。そのため、優れたMachine Learning Operationsのプラクティスを導入することが非常に重要です。自動化、ガバナンス、そして常時の状況把握が必要不可欠なのです。
このプロセスを成熟させることは、システムを機能させる上で非常に重要です。なぜなら、最終的に目指すのはプラグアンドプレイのフレームワークだからです。 標準的なインフラと標準的なプロセスがあれば、チームが開発した新しいモデルを、この標準化された環境にドロップインして処理を高速化することができます。つまり、モデルのイノベーションに注力しながら、デプロイとテストの段階では標準的なスタックの一部として扱えるようになるのです。
企業がこれらのプロジェクトを進める中で、常に意識すべきなのは、 成熟度を向上させることです。最初はクラウドホスト型のNotebooksから始めて、やがてContinuous IntegrationやContinuous Trainingなどの自動化されたプロセスを持つ再現可能な段階に進みます。その後、モデルやデータの継続的なモニタリングなど、より信頼性の高い段階へと進んでいきます。最終的には、異なるプロジェクトや異なるチーム間でプロセスを再現できる、スケーラブルな段階に到達することを目指します。CarGurusが今日ここにいるのは、このスケーラブルな段階まで成熟度を高めることに成功したからです。
CarGurusのビジネスモデルとデータ資産の強み
ここで、CarGurusのSenior Manager of Data ScienceであるJasonに登壇していただき、CarGurusの取り組みについてお話しいただきます。ありがとうございました。はい、ありがとうございます。本日は皆様にCarGurusについて、そしてデータとMachine Learningが私たちのビジネスにとっていかに不可欠な要素であるかをお話しできることを大変嬉しく思います。 CarGurusはオンラインの自動車プラットフォームです。私たちは自動車ディーラーと車を購入したい消費者をつなぎ、カーショッピングプロセスのあらゆる段階で両者をサポートする製品やツールを提供しています。ディーラー向けのサービスは、在庫の調達から始まります。子会社のCarOfferを通じてホールセールマーケットへのアクセスを提供し、さらにオンラインの下取りや車両買取プロセスを通じて、消費者から直接在庫を調達する機能も提供しています。
CarGurusでは、ディーラーが在庫をリストアップすることで、米国最大級のオンライン自動車マーケットプレイスの消費者層に向けて、マーケティング、販売、露出の機会を得ることができます。車を探している方は、通常、新車を購入する目的でCarGurusにアクセスします。中にはクールな車を眺めるのが好きな人もいますが、ほとんどのお客様は新車の購入を検討しています。そのため、私たちは希望する車種を絞り込んでいくためのリサーチツールを提供しています。また、米国最大規模を誇る在庫の中から、関連性の高い車両を表示する高度な検索機能とレコメンデーション機能を提供しています。そして、ユーザーがディーラーとコンタクトを取り、購入したい車両を見つけられるようサポートしています。さらに、ショッピング体験全般をカバーするため、ファイナンス、下取り、オンラインでの車の売却といったツールも提供しています。私たちは米国、カナダ、イギリスで展開する多国籍企業です。
CarGurusは素晴らしいビジネスモデルだと思いますが、Data Scientistとして私が毎日仕事に来るのが楽しみになる理由は、私たちのデータにあります。これは、双方向のマーケットプレイスというビジネスモデルと、私たちの運営規模や到達範囲が組み合わさることで実現されています。その結果、自動車マーケットプレイスに関する非常にユニークで強力なデータセットが得られています。先ほど申し上げたように、米国内で24,000以上のディーラーから収集した、業界をリードする在庫リストを誇っています。それぞれのリストには、販売中の車に関する詳細な情報が含まれています。メーカー、モデル、トリムレベル、価格、履歴、多数の高品質な写真などです。これらを私たちの運営規模で集約することで、自動車市場の供給サイドについて比類のない洞察が得られています。需要サイドについても素晴らしいカバレッジがあり、米国では毎月3,000万人以上の訪問者を集め、月間8,000万以上のセッションを記録しています。
これらは新車購入を検討している意欲的なショッパーたちです。彼らは様々な地域のディーラーに対して、リサーチを行い、比較検討し、問い合わせを送信しています。このデータを活用することで、機械学習とAIのテクニックを導入して自動車マーケットプレイスのトレンドやパターンを発見し、それを基にお客様により良い製品や機能を提供することが可能になっています。
Instant Market Value：CarGurusの革新的な価格評価システム
私たちの優れたデータ資産を考えると、機械学習とデータ駆動型の製品は、CarGurusの創業当初から不可欠な要素でした。このスライドでは、CarGurusで機械学習とデータによって実現している製品機能のほんの一部をご紹介しています。これら以外にも、社内用途を含め、多くのアプリケーションがあります。MLを重点的に活用している分野には、Jasonが先ほど触れたレコメンデーション機能があります。これはeコマース全般、特に車の購入において重要な機能です。また、検索機能にAIを活用したり、マーケティング戦略において広告費用対効果を最適化するためにデータを活用したりしています。そして最後に、今日少し詳しくご説明させていただく機能として、供給サイドの在庫データを活用して、Instant Market Valueアルゴリズムによる車両価格と適正市場価格の把握があります。
では、Instant Market Valueについて詳しくお話しさせていただきます。これは実際にCarGurusが最初に開発したデータ駆動型製品の一つで、競合他社との差別化要因となりました。ここにいらっしゃる皆様も、ここ数年で車を購入された方が多いのではないでしょうか。うまく良い取引ができて、支払った価格に満足されている方もいらっしゃると思います。しかし、中には十分な情報を得られないまま決断を迫られ、その価格が本当に最適だったのかどうか確信が持てなかった方もいらっしゃるかもしれません。
自動車業界は、消費者にとって何が適正価格なのかを知る上で最も透明性に欠ける業界として知られており、ディーラー側と消費者側の間には大きな情報の非対称性が存在します。そこでCarGurusは、データを活用してこの情報格差を埋め、車を購入する人々に信頼性と透明性をもたらす機会を見出しました。その仕組みを説明すると、私たちはIMV（Instant Market Value）というアルゴリズムを構築しました。このアルゴリズムは、先ほど触れたサイト上の在庫リストから多くの特徴を取り込みます。これらの特徴には、車両のメーカー、モデル、グレード、オプションレベルといった基本情報に加え、車齢、履歴、走行距離、状態、過去のオーナー数などが含まれます。
次に、その車両が販売されている地理的地域内で、類似のリストと比較し、その地域内での適正市場価格を判断します。また、市場の変動に応じて動的に更新も行います。適正市場価格を算出するためのモデル構築プロセスがIMV、つまり私たちのサイト上の各リストに対して推定する価値を出力します。そして、このIMVと実際の販売価格を比較して、取引評価を行います。IMVよりもかなり低い価格で出品されている場合は「Good」や「Great」な取引、IMVと同等であれば「Fair」な取引、場合によっては割高な価格のものもあり、これらの情報を消費者に提供しています。
IMVはCarGurusが市場に提供する価値提案の中核を担っているため、当然ながら私たちのプロダクト全体に深く組み込まれています。最も重要で中心的な機能は検索機能で、リストの取引評価（Good、Great、Fair）が検索順位に影響を与えます。より良い評価の取引が検索結果の上位に表示されるようにし、それらの取引評価をバッジとして検索結果に目立つように表示しています。
検索機能以外にも、先ほど触れた下取りや車の売却を支援するツールも提供しています。その一つが、オンラインで車を下取りや売却する際の予想価格を知ることができる計算ツールです。この査定ツールも同じIMVアルゴリズムによって動作しています。また、ディーラー向けのアプリケーションもあり、在庫の取引評価を確認し、市場に対して自社の在庫価格がどの程度競争力があるかを理解するためのツールを提供しています。
IMVは私たちにとって非常に重要であり、同時に非常に難しい課題でもあります。特に中古車の場合は特に困難で、実は多くの自動車購入者が探しているのがこの中古車なのです。商品化された多くのカテゴリーや、MSRPや標準化が存在する新車とは異なり、中古車の各リストはそれぞれが独自の特別な「雪の結晶」のようなもので、それぞれが市場価値に影響を与える固有の履歴を持っています。その結果、リストにIMV値を割り当てるためには、比較対象が必要です。つまり、その価値を判断するために、市場内の類似したリストを見つける必要があります。あまりにも特殊な、例えばメーカーやモデルが一般的でない場合や、古すぎる場合、または地理的に薄い地域にある場合などは、正確な価値を割り当てることができません。
私たちの目標はユーザーへの信頼性と透明性にあるため、正確性は絶対に最優先事項です。確信を持って正確な価値を算出できない場合、そのリスティングに価値やディール評価を付けることはできません。これは避けたい状況です - 私たちはすべてのリスティングに正確なディール評価を付けられるようにしたいのです。この問題について考えていただくために、中古Tesla Model Threeの例を見てみましょう。Tesla Model Threeは市場に出てから数年経っていますが、より確立されたブランドほどの歴史はなく、特に中古車市場では他の主要メーカーやモデルほどの実績がありません。Tesla Model ThreeはEV（電気自動車）であり、価値を算出する際には市場の他の中古EVも考慮する必要があります。また、これは高級セダンでもあり、EVではない他の高級セダンについては、より多くのデータを持っています。
Teslaについてどうすべきでしょうか？EVのデータを重視すべきでしょうか？高級セダンのデータを重視すべきでしょうか？それとも両方を組み合わせるべきでしょうか？それぞれの特徴にどの程度の重みを付けるべきでしょうか？今日はこの質問への答えを持ち合わせていません - これはデータを使用することでしか答えられない問題であり、市場の変化や、ガソリン価格、EVへのインセンティブによって変わっていくものです。このような問題には、データを活用し、これらのトレンドを理解できるモデルを使用する必要があります。
私たちはIMVアルゴリズムを継続的に改善するプロセスを進めており、できるだけ多くのリスティングにディール評価を付けられるよう、精度の向上とカバレッジの拡大を目指しています。より多くの特徴、より洗練された特徴を取り入れ、そしてより優れたデータを活用するために、より強力なMachine Learning技術を採用することでこれを実現してきました。IMVには製品内に多くのユースケースとクライアントがあるため、コアとなるMachine Learningサービスを改善しながら、複数のクライアントがそれを利用できるMicroservicesアーキテクチャへの移行が必要だと分かりました。IMVアルゴリズムをAWSとSageMakerに移行したことで、これが非常に容易になりました。
Amazon SageMakerを活用したMachine Learningプラットフォームの構築
最近のいくつかの改善により、ディール評価を付けられないリスティングの数を50%以上削減できることを実証することができました。これにより、より多くの在庫を購入者に提示できるようになり、その反面、ディーラーにとってはより多くの露出機会を得られることになります。これはマーケットプレイスビジネスにとって素晴らしいwin-winの結果となっています。
Instant Market Value は、CarGurus における機械学習の非常に重要なアプリケーションの1つです。Jason が言及したもう1つが、レコメンデーションです。 私たちは、ユーザーに関連性の高いと思われる車両リストのレコメンデーションなど、ユーザー向けの車両情報体験をパーソナライズするために様々な取り組みを行っています。ここでの課題は、いかにしてそれらのレコメンデーションの関連性を高めるかということです。自動車購入は興味深い分野です。というのも、ユーザーの好みを学習し、価値のある関連性の高い在庫を提示するための時間が限られているからです。考えてみてください - 典型的な車の購入者は、5年から10年に1回程度しか車を購入しません。熱心なユーザーが毎日のように購入を行い、生涯価値を築いていくAmazonのような状況とは異なり、私たちの場合はより断続的なものとなります。
私たちはオンラインマーケットプレイスですから、当然ながら競合他社も存在し、ユーザーがCarGurusと他のサイトを併用するためのスイッチングコストは比較的低いものです。そのため、ユーザーと接する限られた時間の中で、最も関連性の高いリストを表示し、CarGurusで得られる価値を示すことが重要となります。より良いレコメンデーションに加えて、保有するデータをより迅速に活用することで、タイムリーなレコメンデーションを実現できることがわかりました。このトークでは、リアルタイムのデータパイプラインとリアルタイムのFeature Storeの構築について、詳しくご紹介させていただきます。
これらは、CarGurusにおける機械学習の重要なアプリケーションのほんの一例です。 約2年前、私たちは本番環境で価値を生み出すモデルをいくつか構築し、新しいモデルやアプリケーションを構築するロードマップを持っていましたが、モデルの構築は場当たり的で断片的なものでした。標準化も十分ではなく、プロトタイプ段階から本番環境へのデプロイまでには多くの障壁がありました。機械学習オペレーションを本格的にスケールさせるためには、ツールとプロセスへの投資が必要だと認識しました。
最初に下した決断が、今日皆さんにお話しする理由でもありますが、機械学習プラットフォームの基盤としてAmazon SageMakerを採用することでした。SageMakerには、当初から魅力的で、今でも大きな価値を感じている点がいくつかあります。機能が充実していることと、エンドツーエンドの機械学習アプリケーションを構築するために統合できるAWSサービス群全体にアクセスできることが素晴らしいと感じています。本格的なアプリケーションには単なるモデルエンドポイント以上のものが必要ですから、既存のツールチェーンとの柔軟な統合が可能なことも魅力です。先ほど申し上げたように、私たちはすでに構築済みのものがあり、それらを壊したくありませんでした。本番環境のモデルに対するサポートは非常に重要で、SageMakerは導入時のサポートや、ベストプラクティスに関する初期の意思決定、SageMaker上に構築するツールの情報提供において素晴らしいサポートを提供してくれました。
2022年にこの採用を行い、それ以降、私はSageMaker上に自社の機械学習プラットフォームを社内ツールと共に構築してきました。私たちの目標は、機械学習のライフサイクル全体をサポートすることでした。データサイエンティストが最初の段階からモデルの探索とプロトタイピングを行い、それを本番規模でテスト可能なものへと進化させ、さらに継続的なモニタリングとメンテナンスを伴う本番デプロイモデルとして稼働させる必要がありました。デプロイメントの障壁を取り除くことが重要で、これはつまり、データサイエンティストがローカルでモデルを構築・実行する場合と、同じデータを使用してクラウドで作業する場合で、まったく同じように動作する必要があるということです。このプラットフォームを構築した時点で既存のモデルがありましたので、それらを壊したり、すでに提供している価値を損なうリスクを取りたくありませんでした。
私たちは、すでに構築済みのモデルを最小限の変更で組み込めるプラットフォームを設計したいと考えていました。この講演で時間をかけて説明する重要な点は、SageMakerを活用するためのチームのベストプラクティスとパターンを特定し、それらをプラットフォームとツールチェーンに組み込むことでした。このアプローチにより、データサイエンティストやMLエンジニアが自然と正しい方法で作業できるようになります。デプロイメントの障壁を取り除くため、モデルを取り込んでデプロイし、数分以内にクラウドで稼働させることができるプロジェクトの骨格を構築するためのスキャフォールディングとスタブコードを作成しました。
このプラットフォームを約2年間運用してきました。 私たちが構築し、本日ご紹介するプラットフォーム上で、すべてのモデルが稼働しています。新規プロジェクトはすべてこのシステムを使用しています。後ほど詳しく説明するベストプラクティスを、ツールとコードで確実に実践できるようになりました。以前は標準化の欠如とプロセスの煩雑さにより数ヶ月かかっていたところを、現在ではプロトタイプ段階から本番環境まで数週間で移行できるようになりました。先ほど触れたスキャフォールディングとコード生成ツールセットにより、1日以内に完全な end-to-end パイプラインを立ち上げることができ、データサイエンティストが詳細を詰めていくための優れた出発点となっています。
リアルタイムFeature Storeを活用した高度なレコメンデーションシステムの実装
ここで、CarGurusのシニアマシンラーニングエンジニアである同僚のRaghuに引き継ぎ、プラットフォームの仕組みについて詳しく説明してもらいます。ありがとう、Jason。皆さん、こんにちは。私はRaghuです。本日はCarGurusのマシンラーニングプラットフォームについてお話しできることを大変嬉しく思います。先ほどJasonが説明したように、マシンラーニングは私たちのオンライン自動車マーケットプレイスで数百万人のユーザーに提供している体験の中核を成しています。事業の成長に伴い、データインフラ、複雑性、マシンラーニングのユースケース、そしてニーズも拡大してきました。これらの増大する要求に応えるため、私たちは懸命に取り組んでマシンラーニングプラットフォームを大きく進化させてきました。
これまでの道のりを振り返ると、特に際立つのは、 ベストプラクティスの実装が、マシンラーニングによるマーケットプレイスの効果的なスケーリングの成功に不可欠だったということです。プラットフォームを通じて、複数のマシンラーニングワークロードにおけるスケーラビリティ、再現性、モニタリング、標準化を優先してきました。モデル開発からデプロイメント、そしてその先まで、マシンラーニングの運用ライフサイクル全体を効率化しました。これらはすべて、SageMakerをはじめとする様々なAWSサービスを積極的に活用することで実現できました。
本日は、私たちのプラットフォームのベストプラクティスと、多様なAWSサービスと機能がそれらの実装にどのように役立ったかについてお話しします。素早い実験とモデルのプロトタイピングには、SageMakerのクラウドホステッドノートブックを使用しています。本番環境のAIモデルには、様々なプロジェクトでのパターンとベストプラクティスを確立し、パイプラインを定義するための自社ライブラリcg-sagemakerを使用しています。パイプラインはSageMaker Pipelinesを使用し、SageMaker PipelinesとAmazon CloudWatchを組み合わせて、新しいモデルの継続的なトレーニングとデリバリーを行っています。トレーニング済みのモデルは、エンドポイントにShadow Variantとしてデプロイし、SageMakerのModel Shadow Variant機能を使用して広範なシャドウテストを実施します。最後に、パイプラインとエンドポイントの両方のデプロイメントを監視するために、Amazon CloudWatchとSageMaker Model Monitorを使用しています。
データサイエンティストは通常、探索的データ分析や新しいモデルの構築・評価のために、ローカルマシン上でJupyter Notebookを使用しています。しかし、大規模なデータセットを扱う場合や、トレーニングジョブに高速な計算能力やGPUが必要な場合など、ローカルマシンでは対応できないケースがあります。SageMaker Notebookは、データサイエンティストが数クリックでAWS上のGPU搭載インスタンスや計算最適化インスタンスを起動できる、完全なセルフサービスオプションを提供するため、大きな助けとなっています。また、Machine Learning Engineerにとっても、NotebookをVPC内で安全に実行するためのネットワーク設定を行い、定期的にコストを追跡するだけでよいため、作業が楽になります。
重要な点として、SageMaker Notebookはモデルのプロトタイピングにのみ使用し、本番環境のワークロードにはより多くの機能と保守性を提供するSageMaker Pipelinesを使用することを好んでいます。先ほど少し触れましたが、cg-sagemakerは私たちの社内フレームワークで、パターンの確立とベストプラクティスの実施を支援します。これは少し漠然とした定義なので、cg-sagemakerが具体的に何なのかを説明させていただきます。簡単に言えば、cg-sagemakerはチーム全体で様々なプロジェクトのSageMaker Pipelinesを効率的に定義するのを助けるPythonライブラリです。boto3のラッパー、あるいはインフラストラクチャ・アズ・コードのパターンとして考えることができます。というのも、パイプライン定義をPythonコードとして保存できるだけでなく、データやモデルの要件に応じて、インスタンスタイプ、インスタンス数、パイプラインステップのストレージサイズなどのオプションを動的に設定できるからです。
cg-sagemakerの設計思想は、データサイエンティストとMachine Learning Engineer双方の開発体験を向上させることを中心に据えており、そのため宣言的なアプローチを採用しています。実際には、これには複数のメリットがあります。第一に、cg-sagemakerは、boto3呼び出しを通じて複数のAWSサービスと相互作用する複雑な内部ロジックを抽象化することで、プラットフォームの運用を実装します。第二に、cg-sagemakerはデータサイエンティストがプロジェクトを素早く立ち上げるためのテンプレートを提供し、SageMakerへの標準化されたインターフェースを通じて、新規プロジェクト全体で最初からパターンとベストプラクティスを確実に実施できるようにします。
内部フレームワークについて説明したところで、cg-sagemakerのユースケースについて説明したいと思います。私たちはcg-sagemakerを使用して、開発、ステージング、本番環境でいつでもパイプラインを実行しています。これらのパイプラインはPythonコードです。パイプラインのスケジューリングについては、EventBridge Rulesを設定して継続的に繰り返し実行されるよう自動化しています。また、後ほど説明するエンドポイントのフェイルセーフシャットダウンとデプロイメント、そしてモデルのプロモーションにもcg-sagemakerを使用しています。利用可能なモデルやパフォーマンスメトリクスなどのメタデータを一覧表示するために、Model Registryとの連携にもcg-sagemakerを活用しています。最後に、SageMaker EndpointsやSageMaker Notebook Instancesのコストとリソース使用状況を追跡するために、cg-sagemakerの組み込みコマンドを使用しています。
私たちのトレーニングパイプラインは、正確なモデルのトレーニングと維持以上のことを行っています。ステージング環境に存在するSageMaker Endpointsに、フェイルセーフな方法でモデルをShadow Variantsとしてデプロイするというベストプラクティスを実装しています。最初の2つのステップとして、IngestとProcessがあります。これらはSnowflakeデータウェアハウスに接続し、トレーニング用のデータを準備するためのETL（Extract, Transform, Load）処理を実行します。
次の2つのステップはトレーニングと評価で、これらはかなり単純明快です - モデルのトレーニングと評価を行います。この時点で、トレーニング済みのモデルが完成しています。Create Modelステップでは、このトレーニング済みモデルを取り上げ、ECRからのモデルコードコンテナとS3に保存されている重みなどのモデルアーティファクトをリンクして、SageMakerモデル定義を作成します。私の理解では、SageMakerモデル定義は機械学習モデルの一種の抽象化のようなものだと考えています。
その後、3つのステップが並行して実行されます。Register Modelステップでは、モデル定義をモデルのパフォーマンス指標と共にModel Registryに保存します。Deploy Test Endpointステップは、モデル定義に基づいてテストエンドポイントを立ち上げるLambdaステップです。ここでのLambdaステップは、SageMakerが提供する軽量なデプロイメント用の特殊なパイプラインステップで、私たちのユースケースに完璧にフィットします。同じくLambdaステップであるTest APIステップは、作成したばかりのテストエンドポイントを呼び出し、エンドポイントから受け取った応答の正確性を検証します。
ここでのポイントは、Deploy Test EndpointステップとTest APIステップの両方が、クライアントがトラフィックを送信し、そのトラフィックに対するモデルの応答動作を検証するシミュレーションを担当しているということです。すべてのテストにパスすると、これもLambdaステップであるDeploy Shadow Variantステップが、既存のエンドポイント（すでにProduction Variantが稼働している）にShadow Variantとしてモデル定義をデプロイします。これは実際のモデルプロモーションではありません - 本番トラフィックで広範なShadowテストを実行し、その後でプロモーションするかどうかを判断したいため、Shadowとしてデプロイしているのです。
トレーニングパイプラインが定義され、それらのパイプラインがデプロイメントを処理できるようになったので、次のベストプラクティスは、モデルを最新の状態に保つために、これらのトレーニングパイプラインを定期的なスケジュールで自動実行することです。これには、再びSageMakerを活用して、Cronジョブ式で指定された特定のスケジュールで実行されるEventBridgeルールを作成します。このルールが実行されると、ECRからパイプライン定義（これも Python コード）を取得し、その定義を使用してSageMakerパイプラインを実行するLambda関数がトリガーされます。実際に起こることは、スケジュールされたパイプラインが正常に実行され、モデルをトレーニングし、それをModel Registryに保存し、さらにエンドポイントにShadow Variantとしてデプロイするということです。
スケジューリングが整備されたところで、次はデプロイメントの経時的なモニタリングに焦点を当てることができます。ここでのデプロイメントとは、エンドポイントだけでなく、スケジュールされているパイプラインも含みます。このベストプラクティスには2つの重要な要素があります。まず、エンドポイントの運用面での健全性と安定性をモニタリングし、パイプラインが失敗することなくスケジュール通りに実行されているかを追跡します。そのために、Amazon CloudWatchのダッシュボードとアラームを使用して、CPU使用率、レイテンシー、スループットといった主要なパフォーマンス指標（いわゆる定番の指標です）を追跡し、Amazon SNSトピックに転送します。このAmazon SNSトピックはインシデント管理システムにリンクされており、ダウンタイムやパイプライン実行の失敗などのイベントが発生した場合、オンコール中の機械学習エンジニアにアラートが送信されます。
第二に、私たちはData Captureと呼ばれる機能を有効にすることで、エンドポイントのモデル品質を継続的に評価しています。Data CaptureはSageMakerエンドポイントの機能で、エンドポイントへの入力と出力をS3上のファイルにログとして記録することができます。これらのログは最終的にデータウェアハウスに取り込まれ、データサイエンティストがオフラインでモデルの品質を分析・評価することができます。
ここまでの道のりを振り返ってみましょう。私たちのパイプラインは新しいモデルを継続的にトレーニングし、エンドポイントとしてデプロイしています。また、すべてのデプロイメントに対して、時間の経過とともにモニタリングを実装してきました。プラットフォームのベストプラクティスのおかげで、モデルを本番環境にプロモートするための十分な可観測性を手に入れることができました。では、本番環境へのプロモートについて、その理由と現状を確認してみましょう。
私たちのSageMakerエンドポイントには、ProductionバリアントとShadowバリアントという2つのモデルがあります。これらのバリアントの健全性はAmazon CloudWatchを使用してモニタリングしており、Data Capture機能を使用してデータとモデルの品質も評価しています。Shadowバリアントは本番トラフィックの100%に対して推論を生成していますが、クライアントのリクエストには応答していません - それはすべてProductionバリアントが処理しています。運用の観点から見ると、これは安定した状態、つまり健全な状態であり、エラーを起こすことなく、この設定を本番環境で望むだけ維持することができます。
モデルの品質は時間とともに劣化します。これは特に、ダイナミックな市場に存在する車両価格において顕著です。IMVサービスの目的が正確な車両価格予測を提供することであるならば、モデルを最新の状態に保つことが私たちの利益になります。Shadowバリアントは常にトレーニングパイプラインによって最新の状態に保たれています。モデルをプロモートするためには、Shadowバリアントを確認し、そのモデル品質のパフォーマンス指標がプロモーションの閾値を超えているかどうかを確認します。cg-sagemakerを使用すれば、ProductionバリアントとShadowバリアントを簡単に入れ替えることができます。入れ替えが完了すると、Shadowバリアントがクライアントトラフィックの100%に応答するようになります。オプションとして、cg-sagemakerを使用してModel Registryからモデルを選択し、それをShadowバリアントとしてデプロイし、その後Productionバリアントとしてプロモートすることもできます。このように、人間による監視を維持しながら、最小限の労力でモデルを最新の状態に保ち、正確な価格予測を提供することができます。
Machine Learning活用の成熟度向上とCarGurusの今後の展望
では、リアルタイムFeature Storeを活用した高度なレコメンデーションについて、Jasonに説明を譲りたいと思います。Raghuが説明した私たちのコアとなるMachine Learningプラットフォームとは異なる領域として、レコメンデーション向けのリアルタイムデータパイプラインというアイデアがあります。これを構築する際、レコメンデーションのレイテンシーを下げてよりリアルタイムにするというアイデアをテストしたいと考えていましたが、比較的小規模なチームでした。成功するためにはいくつかの要件がありました。マネージドサービスを使用して構築することを決定し、それはAWSとSageMakerを使用することを意味しました。どのようなMachine Learningプロジェクトでも、トレーニングと推論の一貫性は非常に重要です - デプロイされたモデルが、トレーニングと評価時に期待した通りの動作をすることが求められます。これはリアルタイムのコンテキストでは非常に難しい課題となります。
最後に、既存のモデルを活用しながら、すでに機能している部分を壊さないようにするという課題に取り組みました。推薦システムの機能の一部はすでにSQLとPythonコードで定義されており、リアルタイム環境に移行する際もこれらのコードを活用したいと考えていました。私たちが採用したソリューションは、 Amazon Kinesisを生のイベントデータとClickstreamデータのソースとして使用することから始まります。そして、計算エンジンとして Apache Flinkと Amazon Managed Service for Flinkを採用しました。
この選択の理由の1つは、マネージドサービスとして利用できることでした。また、Flink Table APIを通じて、既存のSQLベースの機能定義を再利用することができました。最初のFlinkジョブでは、イベントストリームを解析し、イベントタイプごとにフィルタリングして分割します。重要なサブセットの1つが Page Views、つまりユーザーがサイトのどのページを訪れているかを追跡するものです。このPage Viewイベントタイプを処理することでモデルの特徴の一部を生成し、他のイベントタイプについても並行してパイプラインを構築します。
これらの各イベントタイプについて、マネージドKafkaソリューションであるAmazon MSKを活用してKafkaでイベントをバッファリングします。フィルタリングされバッファリングされたイベントは、その後のFlinkの計算ステージに取り込まれ、そこで特徴の定義と生成という重要な処理が行われます。このステージでは、モデルに供給する特徴値を生成するためのデータ拡張、変換、集約を実行します。これらの異なるイベントタイプを統合し、最終的なKafkaステージで再度バッファリングします。ここから、リアルタイムFeature Store（Amazon ElastiCacheをデータストアとして実装）に取り込むためのインジェストジョブによってデータを取得できます。また、トレーニングとオフライン分析のために、同じ特徴値をData Warehouseに出力する並列パイプラインも存在します。
このパイプラインは、発生したイベントを取り込んで処理し、ElastiCache Feature Storeに保持されている特徴値を更新します。これらの特徴は、その後モデルが利用できる状態になります。サイト上で推薦を提供する際には、モデルをホストしているSageMakerエンドポイントが呼び出されます。この呼び出しが行われると、モデルはElastiCacheにアクセスして、推薦を提供するために必要な特徴を取得します。
このアーキテクチャは、リアルタイムパイプラインを構築するという目標を達成する上で、私たちにとってうまく機能しました。これは単純なシステムではありませんでしたが、マネージドサービスを基盤として選択したことは本当に良かったと言えます。ただし、それは無償では得られませんでした。私たちが必要とする規模で運用し、サービスを統合する複雑さの中で、いくつかの課題に直面しました。エンドツーエンドのシステムを構築し、実際のデータ規模で運用してみて初めて明らかになった、デフォルトでは利用できないサービスの隠れた設定値やメトリクスにアクセスする必要がありました。
私たちは学習時と推論時の特徴量の完全な一貫性を目指しましたが、このようなリアルタイムのアーキテクチャでは、必要なスループットと低レイテンシーを維持しながら、どれだけ高度で大規模な計算ができるかには限界があります。複雑さを抑えるために、一部の特徴量の定義をシンプルにする必要がありました。システムのパフォーマンスを評価し、これらのエンジニアリング上のトレードオフを検討する際に、Data Scientistの参加が非常に有効でした。彼らはモデルを再学習し、各特徴量の重要性を分析し、必要な予測精度を維持しながら、計算をどの程度複雑にする必要があるかを判断することができました。Machine Learning EngineerとData Scientistのこのようなコラボレーションは、このプロジェクトで非常に成功を収めました。
本日は、CarGurusがMachine Learningをどのように活用しているかについてお話ししてきました。 Jasonが最初に説明した成熟度カーブに沿って、私たちが歩んできた重要なステップについてご理解いただけたのではないかと思います。私たちは、Data ScienceとMachine Learningモデルのアドホックで個別の開発を行っていた世界から、Machine Learningプラットフォームを採用し、ベストプラクティスを定義し、それらをツールに組み込むことで、再現性のある信頼できるプロセスを実現し、新しいMachine Learning開発のためのプラットフォームを構築しました。これは、私たちの活動を拡大し、Machine Learningを通じて顧客に価値を継続的に提供するための確かな基盤となっています。
私たちは、効率化と標準化が非常に重要だと実感しています。なぜなら、それが私たちのスケールアップと、より迅速で自信を持った行動を可能にする鍵となったからです。Data ScienceやMachine Learning、AIのチームにとって、チームやビジネスの文脈において最も重要なベストプラクティスとツールは何か、そして提供すべき価値に最も適しているものは何かを理解することは非常に重要です。そして、ベストプラクティスを定義したら、さらに一歩進んで、それらを本当に自動化し、運用を自動化し、ツールに組み込み、チームの全員が自然に正しいことを行えるような、実際の形のあるものにすることが大切です。
この方法は私たちに大きな成功をもたらしており、これは終着点ではないと考えています。私たちにとって、これは常に学び、常に改善を重ねる継続的な旅路であり、今後の展開にとても期待しています。以上で締めくくらせていただきます。本日は、CarGurusでの学びを皆様と共有できて光栄でした。ご質問がありましたら、この後も会場におりますのでお気軽にお声がけください。アンケートのご記入をお願いいたします。残りのカンファレンスもお楽しみください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion