True MLトーク #4 - Salesforceにおける機械学習プラットフォーム

True ML Talksの新しいエピソードをお届けします。今回は、深く掘り下げていきます。 Salesforceの MLプラットフォームについて、お話を伺います。 アルピート・ケール氏。

アルピート氏は、SalesforceでMLプラットフォーム全体を構築したエンジニアリングチームの一員でした。彼は、 Builders Fundで、同僚と共に世界中のML/AI企業に投資し、アドバイスを行っています。同時に、彼は Skiffのインフラ責任者でもあります。

📌

アルピート氏との対談では、以下の点について取り上げます。
- SalesforceにおけるMLユースケース
- SalesforceのMLチーム構成
- Salesforce MLインフラストラクチャの概要
- SalesforceでのMLモデルのプロトタイピング
- クラウドにおける大規模MLプロジェクトのコスト管理
- モデル移行のための自動化されたフロー
- マルチテナント型リアルタイム予測サービスの構築
- エンタープライズAI向けモデルの最適化
- Salesforce AIプラットフォームにおけるセキュリティと信頼性対策
- MLインフラストラクチャプラットフォーム vs ソフトウェアデプロイメントプラットフォーム

全編はこちらからご覧ください：

SalesforceにとってMLが重要である理由

1. パーソナライズされた顧客体験 → MLによりSalesforceは顧客データを分析し、顧客とのインタラクションを改善するためのインサイトを生成することで、パーソナライズされた顧客体験を提供できます。
2. マーケティングキャンペーンの自動化 → 画像、テキスト、ソーシャルメディアデータを分析することで、Salesforceの顧客がマーケティングキャンペーンを自動化できるよう支援し、顧客ペルソナに集中し、マーケティング戦略を最適化することを可能にします。
3. 効率的な顧客サポートのためのチャットボット → MLを活用したチャットボットは、企業の顧客サポート自動化を支援し、待ち時間の短縮とコスト削減に貢献します。
4. セキュリティリスクの特定と軽減 → MLは、データを分析し異常を検出することで、Salesforceが潜在的なセキュリティリスクを特定し、軽減するのを支援します。
5. 製品とサービスの継続的な改善 → MLを活用することで、Salesforceは顧客フィードバックを分析し、その情報を使って新機能や改善点を開発することで、製品とサービスを継続的に改善できます。

Salesforce MLチームの組織構造

Salesforceでは、MLチームは以下の3つのチームに分かれていました。

1. リサーチチーム：リサーチチームは、数百人の研究者で構成され、斬新な研究課題に焦点を当て、研究論文を発表していました。
2. 応用科学チーム： 応用科学チームは、純粋な製品やデータサイエンスのユースケースを担当していました。
3. エンジニアリングチーム： エンジニアリングチームは、研究チームと応用科学チームをサポートできるMLプラットフォームのインフラストラクチャの構築を担当していました。

SalesforceがMLをどのように活用しているかについて、興味深いブログを見つけました：

‍

How Machine Learning is Building Better Salesforce Systems

Rather than simply automating activities such as data processing, machine learning attempts to reproduce how humans think.

AppExchange and the Salesforce Ecosystem Steve Pogrebivsky

‍

Salesforce MLインフラストラクチャの概要

SalesforceのMLインフラストラクチャは、スケーラブルで信頼性の高いプラットフォームを提供するために選ばれた技術スタックの上に構築されました。インフラストラクチャに関する最も関連性の高い、ユニークなポイントをいくつかご紹介します。

1. インフラストラクチャはAWS上で稼働しており、すべてのコンピューティングはKubernetesで管理されていました。Kubernetesを使用することで、TensorFlowやPytorchなど、あらゆる種類の機械学習フレームワークを簡単にデプロイできました。
2. 研究チーム、応用科学チーム、エンジニアリングチームの間でクラスターが分離されていました。これにより、コンピューティング能力とリソースの管理が向上しました。
3. プラットフォームは、トレーニング用のオーケストレーター、リアルタイム予測サービス、バッチ予測サービス、および認証や認可などのユーザー操作を管理するためのフロントエンドAPIを中心に構築されていました。
4. インフラストラクチャは、構造化されたSQLデータベースとS3のような非構造化ファイルストアで構成されており、これらはデータ管理に使用されました。プラットフォームは、この2つの間でデータを管理する役割を担っていました。
5. ユースケースに応じてGPUクラスターは混在していました。これにより、リソースの効率的な使用とパフォーマンスの向上が可能になりました。

📌

機械学習インフラストラクチャにおいてクラスターを分離することが重要である主な理由は次のとおりです。

1. セキュリティ： クラスターを分離することで、データ漏洩や機密データへの不正アクセスのリスクを低減します。各チームは、必要なセキュリティ対策を講じた独自の環境で作業できます。
2. データコンプライアンス： チームごとに異なるデータコンプライアンス要件がある場合がありますが、クラスターを分離することでこれらを満たすことができます。これにより、各チームが必要な規制要件を満たすデータで作業できるようになります。
3. リソース管理： クラスターを分離することで、チームは他のチームのリソースと干渉することなく、タスクを完了するために必要なリソースを確保できます。これにより、リソースの効率的な利用が保証され、リソース競合が防止されます。

Salesforceでのプロトタイピング：独自の（Opinionated）アプローチ

Salesforceでは、プロトタイピングフレームワークはJupyter Notebooksを中心に構築され、データサイエンティストは短期間の実験をインタラクティブかつリアルタイムで実行できました。その後、実験は大規模クラスター上の長時間実行ジョブに移行され、ジョブの実行中にリアルタイムのメトリクスが生成されました。

トレーニングおよび実験用SDKは、ジョブのスケジューリング、データのプルとプッシュ、システム依存関係の複雑さを抽象化するために構築されました。データサイエンティストは、Python APIまたは関数を呼び出すことでこれらのタスクを処理でき、ワークベンチダッシュボードで実験の進捗、メトリクス、ログなどを追跡できました。

このフレームワークは独自の思想に基づいており、抽象化されたソリューションを提供していましたが、データサイエンティストがプラットフォームをどのように使用するかについては、ある程度の柔軟性を許容していました。しかし、完全に自由形式の実験ではなく、従うべき内部ガイドラインと標準がありました。

📌

機密データを伴う大規模なJupyter Notebooksのホスティングにおける課題：
機密データを伴う大規模なJupyter Notebooksをホスティングする場合、主な課題は認証のための承認ワークフローです。データサイエンティストは、データにアクセスするために特定の人物またはマネージャーから承認を得る必要があります。ノートブック環境は一時的であり、実験が完了すると破棄されますが、生成されたすべての成果物は永続化されます。認証はAPI駆動型であり、内部システムと統合されています。

クラウドにおける大規模機械学習プロジェクトのコスト管理方法

大規模な機械学習プロジェクトは、特にクラウドでGPUリソースを利用する場合に、すぐにコストがかさむ可能性があります。プロトタイピング段階でコストを管理するために、いくつかの戦略を採用できます。

1. 予約済みキャパシティ： 必要なキャパシティがわかっている場合、事前に予約することで、料金の割引を受けることができます。これは、長期的なリソース要件について明確な見通しがある場合に有効です。
2. オートスケーリング： 必要なキャパシティが不明な場合や、リソース要件が変動する場合、オートスケーリングが役立ちます。需要に応じてリソースを自動的にスケールアップまたはスケールダウンすることで、未使用のキャパシティに対する支払いを回避できます。

スポットインスタンスの利用など、コスト削減のための他の戦略もありますが、これらは多くの場合、多大なエンジニアリング作業を必要とし、長時間実行されるジョブには実用的ではない可能性があります。さらに、GPUリソースを持つリージョンでは、スポットインスタンスが常に利用可能であるとは限りません。

リザーブドキャパシティとオートスケーリングを活用することで、機械学習プロジェクトに必要なリソースを確保しつつ、コストを効果的に管理できます。これらの戦略は今日でも有効であり、あらゆるパブリッククラウドプロバイダーに適用できます。

モデル移行のための自動化されたフロー

Salesforceの、ある環境から別の環境へモデルを移行するためのプロモーションフローは、各ドメインのゴールデンデータセットという概念に依拠していました。データサイエンティストは、これらのデータセットとランダム化されたデータセットの両方でモデルのパフォーマンスを評価し、さまざまな種類のデータでモデルが適切に機能する能力を評価できました。これにより、モデルを上位環境に昇格させるかどうかを決定するのに役立ちました。

プロモーションプロセスはワークベンチを通じて行われましたが、モデルがn+1種類のデータセットで特定のしきい値を超えて機能することを保証するため、意図的にやや手動のままにされていました。Salesforceはマルチテナントシステムであり、顧客ごとに異なるデータセット（時には数十万に及ぶ）を持つため、これは困難でした。Salesforceは、顧客とデータセットごとに特化した数十万のモデルを構築し、プロセスを可能な限り自動化しました。

全体として、Salesforceのプロモーションフローは、モデルが上位環境に昇格される前に、徹底的に評価され、多様なデータセットで良好に機能することを保証するように設計されていました。

複雑なモデルのためのマルチテナントリアルタイム予測サービスの構築

マルチテナントのリアルタイム予測サービスを構築することは、特定のSLA要件を満たしながら、さまざまなサイズとアーキテクチャを持つ多数のモデルをリアルタイムで提供するという複雑なタスクです。この課題に対処するため、Salesforceのエンジニアリングチームは、いくつかの反復を経てサービングレイヤーを開発しました。

当初、チームはメタデータに構造化データベースを、モデルアーティファクトにファイルストアを使用していました。しかし、このアプローチは、より大規模で複雑なモデルにはスケーラブルではありませんでした。これを解決するため、モデルの複雑さと必要な計算の種類に基づいてクラスターをシャーディングしました。例えば、小規模なモデルはCPUで実行され、大規模なモデルはGPUを必要としました。クラスターは、NLPモデル、LSTMモデル、トランスフォーマーモデル、画像分類モデル、オブジェクト検出モデル、OCRモデルなど、特定の種類のモデルに特化していました。

チームはまた、異なるクラスターやノードグループへのサービスデプロイをオーケストレーションするレイヤーを開発しました。頻繁にリクエストされるモデルのレイテンシーを低く保つために、キャッシングを実装しました。当初、データサイエンティストと研究者は各自が好むフレームワークを使用することが許されており、モデルを統一的に提供することが困難でした。チームはフレームワークを1つか2つに絞り込み、これらのフレームワーク向けにモデルを最適化しました。

最終的に、チームは元のトレーニングフレームワークに関係なくモデルを統一された形式に変換し、各タイプのモデルのサービングコードを最適化できるようにしました。全体として、チームの努力により、スケーラブルで効率的かつ信頼性の高いリアルタイム予測サービスが実現しました。

リアルタイム推論は、私が最も気に入っていた取り組みでした。そして、最終的にはその特許も取得できたと思います。ですから、プラットフォームに追加した素晴らしいエンジニアリング機能でした。実際、最も利用された機能でした。1日に数千万件の予測を行っており、非常に多くの顧客に利用されているのを見るのは、とても満足のいくものでした。
- アルピート

MLレイクとSalesforceのデータプラットフォームのアーキテクチャに関する興味深いブログを見つけました。

‍

ML Lake: Building Salesforce’s Data Platform for Machine Learning - Salesforce Engineering Blog

Explore some unique challenges Salesforce has in the realm of data management and learn how ML Lake addresses them.

Salesforce Engineering Blog Eli Levine, Laura Lindeman

エンタープライズAI向けモデルの最適化

彼らはモデルを徹底的にベンチマークし、容易な変換を確実にするため、フレームワーク内で広くサポートされている演算子やその他の操作の範囲内に留まることを目指しました。カスタム演算子は変換の摩擦が大きく、手厚いアプローチが必要でしたが、チームは、95%のユースケースが、新しい技術を必要としない既製のモデルで容易に解決できることを発見しました。これにより、彼らは大部分のユースケースに最適化し、あまり広く使用されていない残りの5%のモデルに時間を費やすことができました。

アルピートはまた、Onyx、Triton、NVIDIAのInference Serverなどのフレームワークが、モデル形式の標準化とベンチマークにおいて大きな進歩を遂げており、大規模なリアルタイム推論のユースケースにとって貴重なツールとなっていると述べました。

Salesforce AIプラットフォームにおけるセキュリティと信頼性対策

1. 承認 ワークフロー: モデルを本番環境にデプロイする前に、データプライバシーを確​​保するためのデータセットに関する承認ワークフローがありました。
2. セキュリティ分離: 本番環境は完全に分離されており、HIPAAやISOコンプライアンスなどの認証を取得していました。
3. マルチテナンシー: 認証はすべてのテナントをカバーしており、特定の顧客のみが自身のデータにアクセスできるようにしていました。
4. 冗長性と高可用性: 信頼性を確保するため、十分な冗長性と高可用性対策がプラットフォームに組み込まれていました。

MLインフラストラクチャプラットフォームとソフトウェアデプロイメントプラットフォーム

AnuraagとArpeetの議論によると、機械学習インフラストラクチャプラットフォームとソフトウェアデプロイメントプラットフォームには多くの共通点があります。主なポイントは以下の通りです。

1. 類似点: どちらもデータ層、コンピューティング層、オーケストレーション層、認証サービスとAPIゲートウェイ、およびバックエンドサービスを必要とします。標準的なインフラストラクチャでは、バックエンドサービスは分析またはデータエンジニアリングのワークロードを実行する場合がありますが、MLインフラストラクチャではMLワークロードを実行します。
2. 相違点: MLインフラストラクチャは、MLワークロードのためにデータレイクまたはMLレイクを持つ場合がありますが、標準的なインフラストラクチャではそれを必要としない場合があります。MLインフラストラクチャは、特殊なオーケストレーションシステムを使用する場合もあります。
3. ツール: 両方のインフラストラクチャプラットフォームにおけるツールは異なります。MLインフラストラクチャはオーケストレーションに特殊なツールを必要とする場合がありますが、標準的なインフラストラクチャはよりシンプルなツールを使用する場合があります。しかし、両方のインフラストラクチャプラットフォームのデプロイツールは、特にKubernetesクラスターにデプロイする場合、ほとんどのケースで同じです。

全体として、ワークロードの性質とオーケストレーションに必要なツールを除けば、機械学習インフラストラクチャプラットフォームとソフトウェアデプロイメントプラットフォームの間に大きな違いはありません。

Arpeetからの追加考察

MLOps：自社構築か、外部導入か

1. 中小企業やスタートアップがMLインフラを構築する際は、すぐに使える多くの機能を提供する代替手段を活用しましょう。
2. シード期のスタートアップは、コスト削減のため、シンプルなPythonスクリプトを使用し、複数のGPUを搭載した1台のマシンで学習させ、何らかのオーケストレーションを導入しましょう。
3. 中小企業で確立されたMLワークフローがある場合は、オープンソースツールを直接使用しつつも、TrueFoundryのようなすぐに使えるソリューションの利用も検討しましょう。

MLエンジニアへのアドバイス

現時点では、大規模なAIワークフローの運用といったニッチな分野に注力することが、次の困難な課題の一つとなるでしょう。
- アルピート

TrueMLシリーズの過去のブログ記事もぜひご覧ください。

‍

‍‍True ML Talks #3 - Machine Learning Platform @ Facebook

In this blog, we dive deep into Facebook’s ML Platform FBLearner Flow. Understand how it solved both Software and ML deployment and understand its architecture‍TrueFoundry discussing ML platform in Meta

TrueFoundry Blog TrueFoundry

‍

引き続きTrueMLの YouTubeシリーズ そしてTrueMLのすべての ブログシリーズをぜひご覧ください。

TrueFoundry は、Kubernetes上で動作するMLデプロイメントPaaSです。開発者のワークフローを加速させ、モデルのテストとデプロイにおいて完全な柔軟性を提供するとともに、インフラチームには完全なセキュリティと制御を保証します。当社のプラットフォームを通じて、機械学習チームは デプロイと監視を 15分で、100%の信頼性、スケーラビリティ、そして数秒でのロールバック機能を提供しつつ実現できます。これにより、コストを削減し、モデルをより迅速に本番環境にリリースできるようになり、真のビジネス価値の実現を可能にします。