アンドパッドの ML API 基盤における MLOps の取り組み

はじめに

こんにちは。アンドパッドのデータ部 Data Platform チームに所属している t2sy8 です。 Data Platform チームは「ANDPADのあらゆるデータを整備し、使いやすくて信頼性のある基盤を構築」をミッションとし、他のチームと協力して日々、データ基盤や周辺システムの開発・運用を行っています。また、データ部 ML Product Dev チームと協力して ML API 基盤を開発・運用しています。今回は、ML API 基盤における MLOps の取り組みについて紹介します。

ML API 基盤

現在、豆図AIキャプチャーを始めとして複数の ML API エンドポイントを Google Cloud 上で運用しており、推論部分のアーキテクチャは、主に Cloud Run と Vertex AI Endpoint で構成しています。最近では、Vertex AI Gemini API を用いた API エンドポイントも追加されました。豆図AIキャプチャーについてはこちらの記事をご覧ください。

ML API 基盤の運用で利用している主なサービスは以下です。

CI/CD: GitHub Actions
モニタリング: Cloud Monitoring
ログ検索: Cloud Logging

日々の運用で、エラーや長いリクエストレイテンシは Cloud Monitoring アラートで検知・通知しています。関連ログの検索は Cloud Logging で行い、リソース利用状況は Cloud Run コンソールの指標から確認しています。また、必要に応じて入力データ (画像) を確認し対応を行っています。

次に、MLOps に関する取り組みをいくつか紹介します。

カナリアリリース

カナリアリリースは、最新バージョンのアプリケーションをリリースする際に、安定バージョンのアプリケーションを並行稼働させ、一部のトラフィックだけを最新バージョンにアクセスさせ、段階的に最新バージョンに切り替えるデプロイ手法です。

これにより、リリース時に最新バージョンで問題が発生した際、影響範囲を限定することができ、また安定バージョンに素早くロールバックすることができます。特に ML では、アプリケーションのコードだけでなくモデルや特徴量のバージョンなど依存関係が複雑になりやすく、思わぬ障害に繋がることがあるため、この観点は重要です。

ML API 基盤では、GitHub Actions から Cloud Run と Vertex AI Endpoint のデプロイを行っています。ワークフローを実行する際に、デプロイ先の環境やリリース内容に応じて初期トラフィックを入力します。初期トラフィックでのデプロイ成功後、リクエスト状況の監視やリリース内容に応じた検証を経て、最新バージョンに100%のトラフィックを割り当てるリリースフローとなっています。

Cloud Run や Vertex AI Endpoint ではこれを実現するトラフィックの制御・管理を簡単に行うことができます。詳しくは「ロールバック、段階的なロールアウト、トラフィックの移行」や「エンドポイントにモデルをデプロイする」を参照ください。

非同期処理アーキテクチャ

背景として、単一の Cloud Run サービス上に複数の同期 API が動いており、ML API エンドポイントが増えていく中で、当面は Auto Scaling によるスケールアウトで対応できるものの、急激なリクエスト増加時の可用性の維持・リクエストレイテンシの悪化が課題となることが予見されていました。この対策として Cloud Pub/Sub を用いた非同期処理アーキテクチャを導入しました。

最初の取り組みとして、推論処理に時間を要していた一部の同期 API を非同期 API に移行しました。これにより、スケーラビリティ・柔軟性を持たせることができました。今後も、リクエストレイテンシやリソース利用状況、あるいは同時接続数を減らしたいなどのニーズに応じて、既存の同期 API を非同期 API に移行していきたいです。

SLO の導入と運用

ML API エンドポイントが増加していく中で、継続的な品質維持・改善のために運用の高度化が必要になってきた背景から、ML API 基盤における SLO (Service Level Objective) をチーム内で導入しました。

今回、SLO 導入に向けて行ったことは以下です。

最初の SLI (Service Level Indicator) としてリクエストレイテンシ (95th percentile) を設定
API エンドポイントごとのリクエストレイテンシ計測
- 単一の Cloud Run サービス上に複数の API が動いているため、アプリケーション上でリクエストレイテンシを独自にロギング
- 上記ログを Cloud Logging の Log Sink 経由で BigQuery に転送し永続化
モニタリング用のダッシュボード作成
API エンドポイントごとの SLO 設定
- 最初は現実的な目標値を設定
SLO 運用フローの整備
- パフォーマンス改善時の効果測定として Locust による負荷検証

SLO の運用として、関係者による定例 MTG 内で SLO のモニタリング・振り返りを行っています。SLO 運用を通じて行うパフォーマンス改善の知見は、ドキュメントとして残していくことでチームの貴重な財産となっていきます。

おわりに

ML API 基盤における MLOps の取り組みについて紹介しました。結果的に DevOps に分類されるような内容になってしまいましたが、改めて MLOps を実践する上でベースとなる DevOps の考え方が重要だと実感しました。ML モデルのモニタリングなど、ML 特有の Ops については別の機会に紹介できればと思います。

この記事を書いている時点でも、新しい ML API が検討されています。今後も、サービス成長やユーザーニーズの変化に合わせてサービス品質を最適化していく必要があります。これらの変化に対して、継続的に品質改善・運用改善を行うことで ML API 基盤の信頼性向上に繋げていきたいです。