True ML Talks #8 - Intuitにおける機械学習プラットフォーム

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
True ML Talksの新たなエピソードが公開されました。今回は、深く掘り下げていきます。 Intuitの MLプラットフォームNumaFlowについて、お話を伺います。 Vigith Maurice。
Vigithは、IntuitのAI Opsプラットフォーム担当プリンシパルエンジニアです。TurboTax、Credit Karma、Mint、QuickBooks、Mailchimpを利用したことがある方ならご存知の通り、Intuitは、世界的なテクノロジープラットフォームであり、 皆様の経済的な安心をサポートしています。
📌
Vigith氏との対談では、以下の点について取り上げます。
- IntuitにおけるMLユースケース
- リアルタイム異常検知のためのNUMAアプローチ
- Argo Workflowsの知見
- KubernetesとNumaflowを用いたMLモデルのデプロイ
- 再学習システム、NumaflowとFlinkの比較
- IntuitのAIOpsにおけるセキュリティとコンプライアンス対策
- MLOpsとAIOpsの比較
- Vigith氏のKubeConプレゼンテーションの予告
全エピソードは以下でご覧いただけます。
IntuitにおけるMLのユースケース
運用指向のMLユースケース
IntuitのAIOpsチームは、ビジネスの運用面に焦点を当てた、MLの別のユースケースを持っています。このユースケースは、プラットフォームの問題を迅速に検出し解決し、検出から解決までの平均時間を短縮することを目的としています。このユースケースの側面には、以下のようなものがあります。
- 運用データレイクの構築: Vigithのチームは、ランタイムシステムのあらゆる層からリアルタイムデータを収集する運用データレイクを構築しました。このデータレイクは、純粋な非PII匿名化されたメトリクスに焦点を当てています。
- リアルタイム分析: チームは、問題の重大度に基づいてアラートやインシデントを検出し作成するため、このデータを1分未満のレイテンシーで分析しています。
- 高スループットと低レイテンシー: Vigithのチームが採用しているMLアプローチは、250のKubernetesクラスターという大規模な環境と、分析および処理のために毎日10億ものイベントが注入される状況を扱っているため、従来の顧客指向MLとは異なります。
- 異常イベントの予測: チームのシステムはデータメッシュの原則に従い、システム全体をスキーマ化することで、大規模なデータ分析のための統一されたアプローチを提供しています。これにより、リソースCPO、セキュリティ、その他の領域からの異常イベントを予測するのに役立っています。
顧客指向のMLユースケース
Intuitでは、顧客体験の向上に焦点を当てたMLのユースケースがいくつかあります。これらのユースケースには、以下のようなものがあります。
- 不正検出: MLアルゴリズムを使用して、なりすまし、偽の請求書、フィッシング詐欺などの不正行為を検出します。
- ドキュメントスキャン: MLモデルを使用して、領収書、請求書、税務書類などのドキュメントをスキャンし、重要な情報を自動的に抽出します。
- 予測: ML技術を使用して、売上、需要、収益などの将来の傾向を予測します。
- ドキュメント検索: MLアルゴリズムを使用して検索の精度と関連性を向上させ、顧客が探しているものをより簡単に見つけられるようにします。
リアルタイム異常検知のためのスケーラブルなプラットフォーム構築:NUMAアプローチ
リアルタイム異常検知システムは、膨大な量の非同期データストリームを処理する必要があります。従来の機械学習(ML)システムは、ペイロードが処理されて予測が生成されるリクエスト・レスポンスモデルで動作します。しかし、リアルタイム異常検知システムには、さまざまなデータ形式や言語に依存しない操作を処理できる、非同期の有向非巡回グラフ(DAG)ベースのパイプラインが必要です。
Intuitは、NUMA(New, Unique, and Mature Architecture)アプローチを採用した、リアルタイム異常検知のためのスケーラブルなプラットフォームを構築しました。NUMAアプローチは、毎日検証され使用されているモデル群であるNumalogicと、Numalogicモデルを実行するNUMAflowプラットフォームの2つの要素で構成されています。
NUMAflowプラットフォームのDAGベースのパイプラインには、ソース(非同期データストリーム)、頂点(言語に依存しない操作)、およびシンク(異常スコア出力)が含まれます。このパイプラインには、特徴量エンジニアリングのための前処理ステップ、推論ステップ、およびスコアを人間が読める形式に正規化するための後処理ステップが含まれています。
このプラットフォームは高いスケーラビリティと費用対効果を誇り、負荷計算を使用して必要な処理ユニット数を決定します。システムは、受信データ量に基づいて、処理ユニットをスケールアップまたはゼロまでスケールダウンできます。このプラットフォームは、ノードとポートの移行、オートスケーリング、システム障害に対応できるように構築されています。
全体として、NUMAアプローチとNUMAflowプラットフォームは、リアルタイム異常検知システム向けに非常に効率的で効果的なソリューションを提供します。
📌
AIOpsシステムにおけるゼロへのスケールダウンアーキテクチャ:
AIOpsシステムは、リアルタイムで処理されるデータ量に基づいてリソースをスケールアップおよびスケールダウンする能力を必要とします。これを実現するために、スケジューリングロジックとデータ処理ロジックは分離されています。これは、組み込みのオートスケーリングアルゴリズムを持つカスタムKubernetesコントローラーをデプロイすることで行われます。このアルゴリズムは、頂点の処理速度とメッセージの処理にかかる時間を理解し、この情報を使用してシステムに割り当てられるリソースを自動的に調整します。
カスタムコントローラーの使用は、ゼロまでスケールダウンできないネイティブのKubernetes Horizontal Pod Autoscaler (HPA)とは異なります。カスタムコントローラーを使用することで、AIOpsシステムはデータを処理していないときにゼロまでスケールダウンできるため、不要なリソースの浪費を防ぐのに役立ちます。
各頂点の独立したスケーリングを可能にするため、システムは2つの頂点間にバッファを使用します。このバッファは、データが効率的に処理されることを保証し、各頂点がその特定の要件に基づいて独立してスケールされることを可能にします。これは、AIOpsシステム内の異なるプロセスは異なるリソース要件を持つ可能性があり、それらを独立してスケーリングすることで、リソース使用率の最適化に役立つため重要です。
最もクールな機能の1つはスケールダウンできることで、私たちにとっては必須です。 - Vigith
オープンソースエコシステムとAIOps: Argo Workflowsに関する洞察
Argoワークフローは、機械学習ワークフローを管理するための人気ツールとなっており、Intuitはその開発に大きく貢献しています。Argoの成功はそのオープンソースの性質にあり、世界中のユーザーからのフィードバックや貢献を可能にしています。ソフトウェアを公開することで、コミュニティからアイデアやイノベーションが流入し、Intuitがユーザーのフィードバックに基づいてソリューションを改善することを可能にしています。
Airflowのような他のDAGオーケストレーターと比較すると、Argoはトレーニングタスクには適しているものの、バッチ指向です。ユーザーはストリーミングデータを処理できる同等のシステムを要求しました。Intuitはストリーミング指向のシステムであるNumaflowを開発することで応えました。ArgoとNumaflowの2つのシステムは統合され、リアルタイムデータ処理のための常時稼働型推論システムを構築できます。Numaflowにより、同社はより多くの機能を組み込み、その機能を向上させるためにArgoシステムを再設計しました。オープンソースアプローチはIntuitとコミュニティ全体にとって有益であることが証明されており、AIOpsワークフローを改善するための共同作業を可能にしています。
Argo Workflowsの詳細はこちらでご覧いただけます:
KubernetesとNumaflowによるMLモデルのデプロイ
KubernetesとNumaflowを用いた機械学習(ML)モデルのデプロイは、特にレイテンシーやトラフィックパターンが大きく変動することを考慮すると、困難な作業となる場合があります。Intuitは、運用AI Opsプラットフォームで独自のサービングシステムを使用しています。データが受信されると、推論プロセスは、protobufからデータへの変換であろうと推論であろうと、他のユーザー定義関数(UDF)と同様です。Numaflowは様々な言語に対応するSDKを提供していますが、Pythonは高スループットでの動作がマルチプロセスや手続き型Pythonを必要とするため、最もサポートが複雑です。他の言語では、これは問題になりません。
ハンドラー関数を作成するには、ユーザーはNumaflowが提供するメッセージをどのように処理するかを指定する関数を記述するだけで済みます。この関数はメッセージを受け取り、フラットマップを返します。これはそれぞれ入力と出力として機能します。この関数のシグネチャは、タスクに関係なく、どの頂点にも適用されます。
モデルに関しては、問題記述に基づいてプルされ、キャッシュされます。メッセージが受信され、処理され、推論として返され、次の頂点にプッシュされます。ユースケースに応じて、モデルは異なる方法で保存できます。高スループットで高度に分散されたアーキテクチャの場合、キーが使用されます。集中型アーキテクチャの場合、DynamoDBからS3への参照が配置されます。一般的に、目標はMLエンジニアのプロセスを簡素化することです。MLエンジニアはクラス名を変更するだけでよく、残りの部分は抽象化されています。
このプラットフォームはRESTではなくgRPCを使用しており、問題記述に応じて、モデルのライフサイクルを管理するために複数の技術が組み合わせて使用されます。適切な場合はMLflowがライフサイクル管理に使用されますが、MLflowが選択肢とならない、より分散されたアーキテクチャでは他の技術が使用されます。MLエンジニアにとって重要なのは、入力と出力を受け取り、残りの処理はシステムに任せるハンドラー関数を記述することです。
Numaflowの詳細はこちらでご確認いただけます。
再学習システム、NumaflowとFlink
Numaflowが使用する再学習システムは、ユースケースによって異なります。毎秒20リクエストのようなより複雑なケースでは、Numaflowはデータをフェッチしモデルストアを更新するための多段階の本格的なArgoワークフローを展開します。より軽量なシステムでは、Numaflowは目的の結果を達成するために関数を実行するユーザー定義関数(UDF)を使用します。
NumaflowとFlinkの違い
- 処理速度: Numaflowはメッセージ処理速度とレイテンシーの分離を優先しますが、Flinkは低レイテンシーでの高スループットに焦点を当てており、高スループットのデータ処理により適しています。
このスループットの違いは、Numaflowが大量の数値計算や入出力(I/O)集約型のアクティビティ向けに設計されているためです。一方、Flinkは高スループットのデータ処理により適しています。 - データシリアライゼーション形式: Flinkは独自の効率的で明確に定義されたシリアライゼーション形式を使用しますが、Numaflowはブラックボックスアプローチを使用しており、効率的なメッセージの保存と取得のためのハッシュコードと等価性を定義することが困難です。
Apache Flinkの詳細はこちらでご確認いただけます。
IntuitにおけるAIOpsのセキュリティとコンプライアンス対策
- Intuitでは、アプリケーションレベルの暗号化アルゴリズムを含む厳格なセキュリティ対策が講じられています。
- IntuitのAIOpsシステムは、厳重なコンパートメント化アプローチを採用しており、各ネームスペースは分離され、保存データと転送中のデータの両方でTLSにより暗号化されています。
- IntuitのAIOpsチームは、CNCF傘下のオープンソースプロジェクトであるArgoのセキュリティ原則に従い、メトリクスエンドポイントを含むすべてのレイヤーでデータを暗号化しています。
- Intuitの顧客データ向けAIOpsシステムは、さらに厳格なセキュリティ制約があり、ユーザーでさえアクセスできないほど厳しく監査され、適切に管理されたデータが扱われています。このため、運用データは顧客データから分離されていますが、セキュリティ対策は引き続き実施されています。
MLOpsとAIOps
機械学習オペレーション(MLOps)と人工知能オペレーション(AI Ops)は、しばしば同じ意味で使われる2つの用語ですが、実際には異なる原則とプロセスを持っています。
MLOpsは主にモデルのライフサイクル管理に焦点を当てているのに対し、AI Opsは運用領域に重点を置いています。
「 AI Opsでは、運用データに対応するように設計されたHyperLogLogやレイテンシーベースのスケッチなどのテクノロジーを通常使用します。これらのテクノロジーは、約0.89%の誤差率を持つことができ、近似を可能にします。また、平均解決時間(MTTR)の短縮を目標に、統計的有意性に基づいて問題を検出し、特定します。
対照的に、 MLOps は、ML Flowやその他のヒューリスティックといった異なるテクノロジーを活用して、モデルのライフサイクルを管理します。Intuitでは、モデルのライフサイクルを最適化するために、将来の管理のようなパターンも開発しています。MLOpsにおける彼らの目標は、トレーニングからデプロイ、監視、最適化まで、モデルのライフサイクル全体を管理することです。
VigithのKubeConプレゼンテーション予告:顧客中心のAI Opsと異常検知
VigithがKubeConで行う次回のプレゼンテーションは、顧客中心のAI Opsと異常検知に関するものです。システム側ではなく顧客の体験に基づいたアラートに焦点を当てており、これはトレーシングデータに基づいて複雑な依存関係グラフを構築し、異常を単に検出するだけでなく、特定することを意味します。
このプラットフォームは、複数のディメンションとメトリクスを組み合わせて時系列データに対する複合キー異常検知を実行し、非常に特定のレベルで異常を特定することを可能にします。このプロジェクトの目的は、異常検知のための汎用的なソリューションを提供し、「DIY異常検知」システムとすることです。
Vigithのプレゼンテーションでは、このプラットフォームの機能を紹介し、IntuitでAI Ops向けにどのように成功裏に導入されたかを実演します。顧客中心のAI Opsと異常検知における最新の進歩について学ぶこの機会をお見逃しなく。
TrueMLシリーズの以前の投稿を読む
TrueMLの YouTubeシリーズを 引き続きご視聴いただき、TrueMLの ブログシリーズをお読みください。
TrueFoundry は、Kubernetes上で動作するMLデプロイメントPaaSであり、開発者のワークフローを加速させるとともに、モデルのテストとデプロイにおいて完全な柔軟性を提供し、インフラチームには完全なセキュリティと制御を保証します。当社のプラットフォームを通じて、機械学習チームは モデルをデプロイおよび監視する ことを15分で可能にし、100%の信頼性、スケーラビリティ、そして数秒でのロールバック機能を備えています。これにより、コストを削減し、モデルをより迅速に本番環境にリリースできるようになり、真のビジネス価値の実現を可能にします。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.















.webp)
.webp)


.png)

.png)














