個人開発でAmazon SageMaker AIを使用する時に躓いたこと
1. はじめに
個人開発でAIモデルをデプロイする際、AWS SageMakerは魅力的な選択肢の一つである。しかし、実際に使ってみると様々な制約に直面することがある。
本記事では、画像のインスタンスセグメンテーションを行うSAMモデルをSageMakerにデプロイしようとした際に遭遇した問題と、その解決策について共有する。
この記事で伝えたいこと:
- SageMaker Endpointにモデルをデプロイし推論するには様々な制約があること
- Serverless推論にはイメージサイズ10GB、メモリ6GB (6144MB)、リクエスト4MBなど制約が多いこと
- リアルタイム推論でもリクエスト6MB (6291456バイト) の制限があること
- 画像を扱うなら非同期推論がおすすめであること(ただし条件次第)
2. やりたかったこと
今回のプロジェクトでは、画像のインスタンスセグメンテーション（画像内の各オブジェクトを個別に検出・分離する技術）を行うため、Meta社が開発したSAM (Segment Anything Model)をデプロイし、API経由で推論できる環境を構築することが目標だった。
個人開発特有の課題
個人開発のサービスでは、以下の特徴があった。
- リクエスト頻度が非常に低い(ほとんどアクセスがない時間帯が多い)
- できるだけコストを抑えたい
- しかしレスポンスはリアルタイムで返す必要がある
リアルタイムレスポンスが必須な理由
本サービスでは会員登録機能を実装しておらず、セッションIDでユーザーを一意に特定する仕組みを採用していた。そのため、非同期処理で後から結果を返す方式では、適切にエンドユーザーに結果を届けることが難しく、リアルタイムでのレスポンスが必須条件となっていた。
3. 前提環境
-
使用モデル: SAM (Segment Anything Model)
- モデルタイプ: vit_h (ViT-Huge)
- モデルサイズ: 約2.4GB
- チェックポイント: sam_vit_h_4b8939.pth
- PyTorchベースのモデル
- 必要なライブラリ: PyTorch 1.7+, TorchVision 0.8+
-
デプロイ先: Amazon SageMaker
- 試した構成: Serverless推論 → リアルタイム推論 → 非同期推論（検討のみ）
- 目指した構成: REST API経由での推論実行
- ユーザー管理: セッションベース(会員登録なし)
4. SageMaker Serverless推論でのデプロイに挑戦
Serverless推論を選んだ理由
個人開発で最も重視したのはコスト最適化である。SageMakerのServerless推論は、以下の理由から理想的に見えた:
- リクエストがない時間帯は課金されない
- インフラ管理が不要
- 自動スケーリング
低頻度のリクエストに対して、使った分だけ課金されるモデルは個人開発にぴったりだと考えた。
直面した制約
しかし、実際にデプロイを試みると、Serverless推論には厳しい制約があった（公式ドキュメント参照）:
- イメージサイズ: 10GB以下
- メモリ: 6GB以下 (6144MB)
- リクエストボディ: 4MB以下
下記、公式ドキュメント参照
使用できるコンテナイメージの最大サイズは 10 GB です。
サーバーレスエンドポイントの最小 RAM サイズは 1024 MB (1 GB) で、選択できる最大 RAM サイズは 6144 MB (6 GB) です。選択できるメモリサイズは、1024 MB、2048 MB、3072 MB、4096 MB、5120 MB、6144 MBです。サーバーレス推論は、選択したメモリに比例してコンピューティングリソースを自動的に割り当てます。
サーバーレス呼び出しのリクエストとレスポンスペイロードの最大サイズは 4 MB です。
特にSAMのような大きめのモデルと画像データを扱う場合、これらの制約は大きな壁となった。
メモリ不足との戦い
最初の問題はデプロイ時のメモリ不足だった。
デプロイを試みると、メモリが足りずにエラーが発生した。AWSのQuotas(サービスクォータ)からメモリの上限値を引き上げようと試みたが、該当する項目が見つからなかった。
そこでAWSサポートに問い合わせを行い、メモリ上限を6GB (6144MB) まで引き上げてもらった。
サポートからの回答:
今回制限に抵触しておりますのは「Memory size in MB per serverless endpoint」の項目となりますが、あいにく当該項目はService Quotaを通じた緩和リクエストに対応していないため、本サポートケースを通じて緩和のお手続きをさせていただきたく存じます。
デプロイ成功も、リクエストサイズ制限で断念
メモリの問題を解決し、なんとかデプロイには成功した。しかし、実際に推論リクエストを送ると新たな問題が発生した。
画像データを含むリクエストボディが4MBの制限を超えてしまい、エラーが返ってきたのである。画像のインスタンスセグメンテーションを行うには、ある程度の解像度の画像が必要であり、この制限は実用上大きな障害となった。
5. リアルタイム推論の検討
Serverless推論が使えないとわかり、次にリアルタイム推論を検討した。
リアルタイム推論の制約
リアルタイム推論では、Serverless推論よりも制約が緩和されている。しかし、それでも**リクエストボディは6MB以下 (6291456バイト)**という制限がある。
Length Constraints: Maximum length of 6291456.
画像を扱う場合の課題
6MB (6291456バイト) という制限は、高解像度の画像や複数の画像を一度に処理する場合には不十分である。また、リアルタイム推論はインスタンスが常時起動しているため、アクセスのない時間帯でも課金が発生する。
個人開発で低頻度のリクエストしかない場合、常時起動のコストは大きな負担となる。
6. 非同期推論という選択肢(検討のみ)
非同期推論の特徴とメリット
SageMakerには非同期推論という選択肢もある。非同期推論の特徴は以下の通りである:
- 大きなペイロードサイズに対応可能
- S3を経由してリクエスト・レスポンスをやり取り
- リクエストはキューに入り、順次処理される
画像処理に非同期推論がおすすめな理由
画像のような大きなデータを扱う場合、非同期推論は以下の点で優れている:
- リクエストサイズの制限が大幅に緩和される
- S3経由でデータをやり取りするため、大容量のデータも扱える
- バッチ処理のような使い方も可能
非同期推論を採用する場合の実装パターン
もし会員登録機能を実装する場合、以下のような構成で非同期推論を活用できる：
-
Webhook + S3パターン
- リクエストをS3にアップロード
- SageMaker非同期推論で処理
- 完了時にWebhookで通知
- ユーザーIDと紐付けて結果を保存
-
ポーリングパターン
- ジョブIDを発行してユーザーに返す
- フロントエンドで定期的にステータスを確認
- 完了したらマイページで結果表示
この方式なら、大きな画像データも扱えて便利である。
今回採用しなかった理由:セッション管理との相性問題
非同期推論は画像処理に適しているが、今回のプロジェクトでは採用できなかった。
理由は、本サービスがセッションIDでユーザーを特定しているためである。非同期処理では、リクエストを送ってから結果が返ってくるまでに時間がかかる。その間にセッションが切れたり、ユーザーがページを離れたりした場合、適切に結果を届けることができない。
会員登録機能があり、結果をメールで通知したり、マイページで確認できる仕組みがあれば非同期推論は有効な選択肢となるが、今回の要件ではリアルタイムレスポンスが必須だった。
7. 最終的な解決策:Google Cloud Runへの移行
SageMakerの様々な制約に直面した結果、最終的にはGoogle Cloud Runへの移行を決断した。
Cloud Runを選んだ理由は以下の通りである:
コンテナでAPIを起動可能
- 既存のDockerコンテナをそのままデプロイできる
- 特殊な制約やフォーマットに縛られない
メモリ・CPUの柔軟なスケーリング
- 必要に応じてメモリやCPUを簡単にスケールできる
- SageMakerのような厳しい制約がない
サーバレス環境:アクセスのない時間は課金なし
- これが最大の決め手だった
- リクエストがない時間帯は自動的にインスタンスがゼロにスケールし、課金が発生しない
- リクエストが来たときだけインスタンスが起動する
8. まとめ
SageMaker各推論タイプの制約一覧
本記事で紹介したSageMakerの各推論タイプの主な制約をまとめる:
| 項目 | Serverless推論 | リアルタイム推論 | 非同期推論 |
|---|---|---|---|
| イメージサイズ | 10GB以下 | 制約なし(EBSボリュームに依存) | 制約なし(EBSボリュームに依存) |
| メモリ | 6GB以下 (6144MB) | インスタンスタイプに依存 | インスタンスタイプに依存 |
| リクエストボディサイズ | --- | 6MB以下 (6291456バイト) | 1GB以下（S3経由） |
| 課金方式 | 使用量課金 | 常時課金 | 使用量課金 |
| レスポンス | リアルタイム | リアルタイム | 非同期 |
| 適用例 | 低頻度・小データ | 高頻度・中データ | 大データ・バッチ処理 |
個人開発でSageMakerを使う際の判断基準
SageMakerは強力なサービスであるが、個人開発で使う際には以下の点を事前に確認することをおすすめする:
-
モデルのサイズとリクエストデータのサイズ
- 特に画像や動画などの大きなデータを扱う場合は要注意
-
リアルタイム性の要件
- 即座にレスポンスが必要か、非同期でも問題ないか
-
リクエスト頻度とコスト
- 常時起動が必要か、サーバレスで十分か
-
ユーザー管理の仕組み
- 非同期処理を採用する場合、結果をどう届けるか
学びと今後の展望
今回の経験を通じて、SageMakerは企業向けのしっかりとしたMLOpsが必要なケースには適しているが、個人開発の小規模サービスでは、制約やコストの面でCloud Runのようなシンプルなサーバレスコンテナサービスの方が適している場合があることがわかった。
ただし、非同期推論は画像処理において非常に有用な選択肢である。会員登録機能や適切な結果通知の仕組みを実装できるのであれば、SageMakerの非同期推論は十分に検討する価値がある。
皆さんの開発の参考になれば幸いである。
Discussion