リアルタイム AI と ML 向けの機能ストレージ プラットフォーム

翻訳者 | 陳俊

企業は通常、オンライン機能ストアを選択する前に、どのアーキテクチャが最も効率的でコスト効率が高いかを比較するために包括的なベンチマークを実行します。この記事では、リアルタイム AI/ML ユースケースに正常に導入された 4 つのオープンソースおよび商用の機能ストレージ アーキテクチャとベンチマークについて説明します。

今日では、不正防止やパーソナライズされた推奨事項などの実際のビジネスユースケースが広く使用されているため、機能ストアは AI/ML テクノロジーをリアルタイムで本番環境に導入する上で重要な役割を果たしています。

最も人気のあるオープンソース機能ストレージ プラットフォームの 1 つは Feast です。 Slack コミュニティ (https://slack.feast.dev/) で最も言及されている Feast の機能は、そのスケーラビリティとパフォーマンスです。結局のところ、リアルタイム AI/ML 機能ストレージの場合、最も重要な指標は、オンライン予測やスコアリングのために ML モデルに機能が提供される速度です。

一般的に、成功するフィーチャー ストアは、次の厳しい要件を満たす必要があります。

• 低レイテンシ（ミリ秒単位）
• 一貫性（99%のケースで測定）
• 規模（1秒あたり数十万または数百万のクエリ、ギガバイトまたはテラバイトのデータセット）
• 総所有コストが低く、精度が高い

企業は通常、オンライン機能ストアを選択する前に、包括的なベンチマークを実行して、どのアーキテクチャが最も効率的でコスト効率が高いかを比較します。以下では、リアルタイム AI/ML ユースケースにうまく導入されている 4 つのオープンソースおよび商用の機能ストレージ アーキテクチャとベンチマークについて説明します。

1. オープンソースの饗宴

まず、Feast (https://feast.dev/) オープンソース機能ストアのベンチマーク データとデータ アーキテクチャを見てみましょう。 Feast は最近のベンチマークの 1 つで、さまざまなオンライン ストレージ (Redis、Google Cloud DataStore、AWS DynamoDB など) を使用した場合の特徴提供のレイテンシを比較し、さまざまなメカニズム (Java gRPC サーバー、Python HTTP サーバー、ラムダ関数など) を使用して特徴を抽出する際の速度を比較しました。完全なベンチマーク設定とその結果については、リンク https://feast.dev/blog/feast-benchmarks/ から確認できます。その中で、Feast は、Java gRPC サーバーと Redis をオンライン ストレージとして組み合わせて使用​​した場合にパフォーマンスが最も高くなることを発見しました。

出典: https://www.applyconf.com/agenda/using-feast-in-a-ranking-syst

上の画像では、有名なオンライン住宅ローン会社である Better.com が、オープンソースの Feast 機能ストアを使用して、潜在顧客向けのスコアリングおよびランキング システムを構築している様子がわかります。 Better.com のシニア ソフトウェア エンジニアである Vitaly Sergey が、オフライン ストレージ (S3、Snowflake、Redshift) からオンライン ストレージ (Redis) への移行について語ります。同時に、ストリーミング ソース (Kafka トピック) からオンライン ストレージに機能も取り込みました。 Feast は最近、ストリーミング データ ソース (バッチ データ ソースに加えて) のサポートも追加しましたが、現在は Redis のみをサポートしています。

リアルタイム AI/ML ユースケースはリアルタイム データに依存するため、ストリーミング データ ソースのサポートは非​​常に重要です。たとえば、このスコアリングのユースケースでは、新しいリード データがリアルタイムで取り込まれます。新しい潜在顧客が発見されるたびに、モデルによって取り込まれ、スコア付けされ、後で再ランク付けできるようにオンライン ストレージに取り込まれます。一方、Better.com では、リード情報は 48 時間後に期限切れになります。これは Redis オンライン ストレージに実装されています。 TTL (存続時間) を 48 時間に設定するだけで、エンティティ (つまり、潜在的顧客) と関連する特徴ベクトルは 48 時間後に期限切れになります。つまり、機能ストアは自動的にクリーンアップし、古いエンティティや機能が貴重なオンライン ストレージ領域を占有しないようにします。

Feast のもう 1 つの実装は、Microsoft Azure の Feature Store (https://techcommunity.microsoft.com/t5/ai-customer-engineering-team/bringing-feature-store-to-azure-from-microsoft-azure-redis-and/ba-p/2918917) です。アーキテクチャについては、リンク https://techcommunity.microsoft.com/t5/image/serverpage/image-id/323561i3F763F78F483587D/image-size/large?v=v2&px=999 か​​ら参照できます。これは、低レイテンシのリアルタイム AI/ML ユースケース向けに最適化され、バッチ データ ソースとストリーミング データ ソースの両方をサポートし、Azure データおよび AI エコシステムに統合された Azure クラウド上で実行されます。さまざまな機能がバッチ ソース (Azure Synapse Serverless SQL、Azure Storage/ADLS) およびストリーミング ソース (Azure Event Hub) からオンライン ストレージに取り込まれます。オンライン ストレージでは、Azure Cache と Azure Redis のエンタープライズ ティアを使用します。これには、最大 99.999% の可用性を備えたグローバルに分散されたキャッシュを作成するためのアクティブな geo レプリケーションが含まれます。したがって、アプリケーションが既に Azure にデプロイされている場合、または Azure エコシステムに精通している場合は、このタイプの機能ストアの方が適しています。さらに、エンタープライズ フラッシュ層を使用して、メモリ (DRAM) とフラッシュ (NVMe または SSD) の両方を使用してデータを保存し、階層型メモリ アーキテクチャ上で Redis を実行することで、コストをさらに削減できます。

2. WixはDIY機能ストレージをMLOpsプラットフォームの基礎として活用している

人気のウェブサイト構築プラットフォーム Wix (https://www.wix.com/) は、推奨、制作、プレミアム、予測、ランキング、スパム分類などの MLOps プラットフォーム アプリケーションに機能ストア アーキテクチャを使用しています。 Wix は 2 億人を超える登録ユーザーにサービスを提供していますが、そのうちアクティブなユーザーはそのうちのごく一部にすぎません。したがって、これは機能ストレージの実装方法に一定の影響を与えます。次の画像は、Wix の ML エンジニアリング リードである Ran Romano による TechTalk プレゼンテーションからの抜粋です (https://youtu.be/E8839ENL-WY?t=2061)。 Wix の機能ストアはクリックストリームの 90% 以上を保存し、サイトまたはユーザーによって ML モデルをトリガーできます。 Ran 氏は、実稼働環境でのリアルタイムのユースケースでは、特徴ベクトルを数ミリ秒以内に抽出する必要があるため、遅延を回避する必要があると説明しました。

出典: https://youtu.be/E8839ENL-WY?t=2061

上の図に示すように、生データは AWS Parquet ファイルの S3 バケットに保存され、ビジネス ユニット (「編集」、「レストラン」、「予約」など) と日付ごとに分割されます。 Spark SQL を使用した毎日のビルド バッチ プロセス (数分から数時間かかります) 中に、すべてのユーザーの履歴機能が S3 から抽出され、ユーザーごとに変換および集計されてから、オフライン ストレージ (Apache Hbase) に取り込まれます。この「ユーザー別」アプローチにより、ユーザーの履歴検索が高速化されます。システムがユーザーが現在アクティブであることを検出すると、「ウォームアップ」プロセスがトリガーされ、ユーザーの特性がオンライン ストレージ (Redis) に読み込まれます。オンライン ストレージはオフライン ストレージよりもはるかに小さく、アクティブなユーザーの履歴を保存するためだけに使用されます。この「ウォームアップ」プロセスには通常数秒かかります。最後に、オンライン機能ストア内の機能は、ユーザーからの各イベント (Apache Storm を使用) によって「リアルタイム」ストリーミング データとして継続的に更新されます。

Feast アーキテクチャと比較すると、Wix アーキテクチャの読み取り速度と書き込み速度は低くなります。ただし、オンライン ストレージにはすべてのユーザーではなく、アクティブ ユーザーの特徴のみが保存されるため、実体化とオンライン ストレージの点で非常に効率的です。また、アクティブ ユーザーは Wix に登録されているユーザー全体のごく一部に過ぎないため、これにより多くのスペースを節約できます。

ただし、オンライン ストレージから機能を取得するには数ミリ秒しかかかりませんが、これは機能がすでにオンライン ストレージに存在していることを前提としています。逆に、ウォームアップ プロセスには数秒かかるため、アクティブになるユーザーの中には、関連する機能が十分な速さで読み込まれず、競合状態により、そのユーザーは低い評価で失敗する可能性があります。ご覧のとおり、このタイプのアーキテクチャは、ユースケースが重要なプロセスまたはタスク (トランザクションの承認や不正行為の防止など) でない限り使用できます。

3. 商用機能ストレージ - Tecton

バッチ データ ソースとストリーミング データ ソースに加えて、商用エンタープライズ フィーチャ ストア Tecton (https://www.tecton.ai/) アーキテクチャは、リアルタイム データ ソース (「リアルタイム フィーチャ」または「リアルタイム変換」とも呼ばれます) も「すぐに使用できる」状態でサポートします。 Tecton はすでに機能ストアでネイティブにサポートされているため、実装が簡単です。

Feast や Wix の機能ストアと同様に、Tecton はレジストリにさまざまな機能を定義し、オフラインおよびオンライン ストレージの 1 回限りの論理定義を可能にして、トレーニング サービスのバイアスを大幅に削減し、運用環境での ML モデルの高精度を保証します。

出典: https://www.tecton.ai/blog/delivering-fast-ml-features-with-tecton-and-redis-enterprise-cloud/

オフライン ストレージ、オンライン ストレージ、ベンチマークの観点から Tecton の機能を見てみましょう。オフライン機能ストレージに関しては、Tecton は S3 をサポートしています。オンライン ストレージについては、Tecton は顧客に DynamoDB と Redis Enterprise Cloud (https://www.tecton.ai/blog/delivering-fast-ml-features-with-tecton-and-redis-enterprise-cloud/) の選択肢を提供しています。最近のプレゼンテーションで、Tecton CTO の Kevin Stumpf 氏は、同社が最近実施したベンチマークに基づいて、オンライン フィーチャー ストアを選択する方法についてアドバイスしました。https://youtu.be/osxzKxiznm4 をご覧ください。 Tecton は、レイテンシとスループットのベンチマークに加えて、オンライン ストレージのコストもベンチマークしました。その理由は、高スループットまたは低レイテンシのユースケースでは、オンライン ストレージのコストが MLOps プラットフォーム全体の総所有コストの大部分を占める可能性があるため、コストの節約は非常に有益だからです。

Tecton は、ユーザー向けの一般的な高スループットのユースケースをベンチマークした結果、Redis Enterprise は DynamoDB よりも 3 倍高速で、コストは 14 分の 1 であることを発見しました。詳細なテスト結果については、https://www.tecton.ai/blog/announcing-support-for-redis/ をご覧ください。ユースケースが 1 つしかなく、高い同時実行性と厳しいレイテンシー要件がない限り、DynamoDB を使用できることがわかります。

4. Lightricks は商用機能ストレージを使用 - Qwak

Lightricks は、ビデオや画像編集用のモバイル アプリケーションを開発するユニコーン企業です。Facetune は、同社の有名な自撮り写真編集アプリです。また、推奨システムには機能ストレージも使用します。

出典: https://www.youtube.com/watch?v=CG2vUCcvnD8&t=1915s

上の図に示すように、Qwak の機能ライブラリは、バッチ機能、ストリーミング機能、リアルタイム機能の 3 つの機能ソースもすぐにサポートします。これはTectonと非常によく似ています。ただし、Qwak 機能ストアを使用する場合、オフライン (S3 上の Parquet ファイルを使用) およびオンライン (Redis を使用) で保存された元のデータ ソースから、機能ストアに機能を具体化します。これは、Wix、Feast、Tecton の機能ストアの例とは異なります。この移行の利点は、単一の機能の変換ロジックがトレーニング フローとサービング フローの間で統合されるだけでなく (上記の Feast、Wix、Tecton の機能ストアと同様に)、実際の変換または機能の計算も統一された方法で行われるため、トレーニングとサービングの偏りがさらに軽減されることです。つまり、オフラインとオンラインの生データのソースを統合することで、実稼働環境でより高い精度を確保できます。 Qwak の機能ストアのアーキテクチャとコンポーネントの詳細については、https://drive.google.com/file/d/1KfOMI9C-aitJNPdGB56L-6tA8BBp9gsl/view をご覧ください。

5. まとめ

リアルタイム AI/ML 機能ストアの上記の 4 つのベンチマークとアーキテクチャについての説明を通じて、アーキテクチャ、サポートされる機能タイプ、選択されたコンポーネントの違いにより、生成される機能ストアのパフォーマンスとコストが大幅に異なる可能性があることがわかります。また、どのオンライン ストレージが最もパフォーマンスが高く、最もコスト効率が高いか、またオンライン ストレージから機能を抽出するためにどのメカニズムまたは機能サーバーを使用するかについても比較します。

オリジナルリンク: https://www.kdnuggets.com/2022/03/feature-stores-realtime-ai-machine-learning.html

翻訳者紹介

51CTOコミュニティの編集者であるJulian Chenは、ITプロジェクトの実施において10年以上の経験を持っています。内部および外部のリソースとリスクの管理が得意で、ネットワークと情報セキュリティの知識と経験を広めることに重点を置いています。ブログ投稿、特別トピック、翻訳の形で最先端の技術と新しい知識を共有し続けています。オンラインとオフラインで情報セキュリティのトレーニングや講義を頻繁に行っています。