Function Compute は、5 種類の関数タイプ、3 種類の実行環境、および複数のインスタンスタイプを提供しています。このトピックでは、それぞれのオプションの主な違いについて説明し、ワークロードに適した組み合わせを選択するのに役立ちます。
関数タイプの選択
イベント関数 | Web 関数 | タスク関数 | GPU 関数 | サンドボックス関数 | |
説明 | OSS トリガー、Kafka トリガー、SLS トリガーなどのクラウドサービスのイベントによってトリガーされるファイルやデータストリームを処理します。 | 一般的な Web フレームワークをサポートします。ブラウザから、または URL を介して直接アクセスできます。 | 非同期リクエストを処理します。非同期呼び出しの各段階の状態を追跡し、保存します。 | Stable Diffusion WebUI、ComfyUI、RAG、TensorRT などの一般的な AI プロジェクトのコンテナイメージを実行します。 | セッションベースのインスタンスキープアライブ機能を備えた永続的なサンドボックスインスタンスを提供し、インタラクティブな実行環境を実現します。 |
ユースケース | クラウドサービス連携： OSS によるリアルタイムファイル処理、Simple Log Service (SLS) によるログ処理。 ETL データ処理： データベースクリーニング、メッセージキュー処理。 | 一般的な Web フレームワーク： SpringBoot、Express、Flask など。 既存アプリの移行： HTML5 Web サイト、REST API、Backend for Frontend (BFF)、モバイルアプリ、ミニプログラム、ゲーム決済など。 | 汎用タスク： スケジュールタスク、定期タスク、スクリプトタスク。 マルチメディア処理： 動画トランスコーディング、ライブ録画、画像処理。 | 従来の推論： コンピュータビジョン (CV) および自然言語処理 (NLP)。 AIGC モデル推論： Text-to-Text、Text-to-Image、Text-to-Audio 生成。 | Code Interpreter： コード実行とデータ分析。 ブラウザ自動化： Web スクレイピングと UI テスト。 AI エージェントツール実行： 大規模モデルのツール呼び出しに安全な実行環境を提供します。 |
推奨ランタイム | カスタムコンテナのみ | カスタムコンテナのみ | |||
デフォルトで無効 | デフォルトで無効 | デフォルトで有効 | デフォルトで無効 | 該当なし | |
最適な用途 | イベントトリガーを介した Alibaba Cloud サービスとの連携 | Web アプリケーションと API の構築および移行 | 状態追跡が必要な長時間実行タスク | GPU アクセラレーションを必要とする AI/ML 推論ワークロード | セッションキープアライブ機能を備えた永続的なインスタンスを必要とするインタラクティブなワークロード |
実行環境の選択
ビルトインランタイム | カスタムランタイム | カスタムコンテナ | |
開発ワークフロー | Function Compute が定義するインターフェイスを使用してリクエストハンドラを作成します。 | Web フレームワークのテンプレートを使用して開発し、パブリックエンドポイントで結果を即座に確認します。 | カスタムイメージを Alibaba Cloud Container Registry (ACR) にアップロードしてデプロイするか、ACR 内の既存のイメージを使用します。 |
サポートされるインスタンスタイプ | CPU インスタンス | CPU インスタンス | CPU インスタンスと GPU インスタンス |
サポートされていません | サポートされています | サポートされています | |
最速 — コードパッケージにランタイムが含まれていないため。 | 高速 — コードパッケージ (HTTP サーバー) は大きいですが、イメージのプルは不要です。 | 低速 — コールドスタート時にイメージをプルする必要があります。 | |
コードパッケージのフォーマット | ZIP、JAR (Java)、またはフォルダ | — | コンテナイメージ |
一部のリージョン (杭州など) では 500 MB、その他のリージョンでは 100 MB です。 レイヤーを使用すると、依存関係を追加してパッケージサイズを削減できます。 | — | CPU インスタンスイメージ：非圧縮で 10 GB。GPU インスタンスイメージ：非圧縮で 15 GB。AI 推論の場合、NAS または OSS に大規模モデルを保存してイメージサイズを削減します。 | |
サポートされる言語 | Node.js、Python、PHP、Java、C#、Go | 制限なし | 制限なし |
最適な用途 | サポートされている言語を使用し、コールドスタートが最速の軽量関数 | あらゆるフレームワークを使用する Web アプリと API | GPU ワークロードとコンテナ化されたデプロイメント |
インスタンスタイプの選択
CPU 関数は Elastic Instances のみをサポートします。GPU 関数は、サービス中断なしでいつでも切り替えることができる 3 つのインスタンスタイプをサポートします。
意思決定ガイド
以下の質問を参考にして、適切なインスタンスタイプを見つけてください。
ワークロードは遅延の影響を受けやすく、インタラクティブですか？ たとえば、リアルタイムチャットボットや画像生成 API などです。その場合は、プロビジョニング済みインスタンスを使用してコールドスタートをなくし、応答時間を保証します。
トラフィックは予測可能なベースラインに従い、時折急増しますか？ その場合は、混合モード (プロビジョニング済み + 弹性インスタンス) を使用して、安定したベースライン容量を維持しながらトラフィックバーストを吸収します。
トラフィックは変動が激しい、バースト的、または低頻度ですか？ その場合は、弹性インスタンスを使用し、アクティブな使用量に対してのみ料金を支払います。
インスタンスタイプの比較
弹性インスタンス | プロビジョニング済みインスタンス | プロビジョニング済み + エラスティック (混合モード) | |
適用対象 | CPU 関数 (唯一のオプション)、GPU 関数 | GPU 関数のみ | GPU 関数のみ |
コールドスタート | はい、最小インスタンス数が 0 の場合。最小インスタンス数を 1 以上に設定してリソースを事前割り当てし、コールドスタートを削減します。 | なし。割り当てられた容量内のすべてのリクエストは、リアルタイム応答を受け取ります。 | 部分的。プロビジョニング済みプール内のリクエストにはコールドスタートがありませんが、弹性スケールアウトインスタンスにはあります。 |
課金モデル | 従量課金 | サブスクリプション | サブスクリプション (プロビジョニング済み部分) + 従量課金 (弹性部分) |
最適な用途 | 変動が激しい、または低頻度のトラフィック、コスト重視のワークロード | 遅延の影響を受けやすい、または安定したトラフィックのワークロード | 予測可能なベースラインと予測不能なトラフィックバーストがあるワークロード |
弹性インスタンス
弹性インスタンスはリクエスト量に応じて自動的にスケールし、アイドル状態になるとリリースされます。最小インスタンス数を 0 に設定すると、完全な従量課金モデルとなり、アクティブな使用量に対してのみ料金を支払うことになります。
コールドスタートの動作： インスタンスがゼロからスケールアップするときにコールドスタートが発生します。コールドスタートの遅延を削減するには、最小インスタンス数を 1 以上に設定します。これにより、弹性リソースが事前割り当てされ、インスタンスが受信リクエストを迅速に処理できるようになります。
課金： コストには、アクティブ状態と Shallow Hibernation 状態の両方のインスタンスに対する料金が含まれます。Shallow Hibernation では、vCPU リソースは課金されず、GPU リソースはアクティブ状態のレートの 5 分の 1 で課金されます。最小インスタンス数を 1 以上に設定する場合は、Shallow Hibernation を有効にしてアイドルコストを削減してください。
次の場合に弹性インスタンスを使用します：
トラフィックが変動的、バースト的、または低頻度である場合
実際の使用量に対してのみ料金を支払いたい場合
ワークロードが時折発生するコールドスタートの遅延を許容できる場合 (または、最小インスタンス数でそれを緩和する場合)
プロビジョニング済みインスタンス
プロビジョニング済みインスタンスは GPU 関数にのみ適用されます。事前にプロビジョニング済みリソースプールを購入し、特定の数とタイプのインスタンスを関数に割り当てます。これにより、割り当てられた容量内でのコールドスタートがなくなり、予測可能で固定のコストが実現します。
月額のプロビジョニング済みリソースプールを購入すると、プラットフォームは追加料金なしで追加のブーストインスタンスクォータを提供します。
コールドスタートの動作： なし。割り当てられた容量内のすべてのリクエストは、リアルタイム応答を受け取ります。最大同時リクエスト数 = (割り当てられたプロビジョニング済みインスタンスの数) × (インスタンスの同時実行数) + ブーストインスタンスクォータ。この制限を超えたリクエストはスロットリングされます。
課金： 購入したすべてのプロビジョニング済みリソースプールの合計サブスクリプション料金。ブーストインスタンスは課金されません。
プロビジョニング済みインスタンスは、Ada、Ada.2、Ada.3、Hopper、または Xpu.1 シリーズの GPU 関数でのみ利用可能です。
次の場合にプロビジョニング済みインスタンスを使用します：
ワークロードが遅延の影響を受けやすく、インタラクティブである場合 (例：リアルタイムチャットボットや画像生成 API)
お客様のトラフィックは安定的で予測可能です
保証された容量と一貫した応答時間が必要な場合
プロビジョニング済み + エラスティックインスタンス (混合モード)
混合モードは GPU 関数にのみ適用されます。プロビジョニング済みインスタンスと弹性インスタンスを組み合わせたものです。プロビジョニング済みプールがまず定常状態のトラフィックを処理し、リクエストがプロビジョニング済み容量を超えると、弹性インスタンスが自動的にスケールアウトします。これにより、突然のトラフィックバーストを吸収する柔軟性を備えた、保証されたベースラインが得られます。
コールドスタートの動作： 部分的。プロビジョニング済みプール内で処理されるリクエストにはコールドスタートがありません。新しい弹性インスタンスへの自動スケーリングをトリガーするリクエストでは、コールドスタートが発生します。
課金: プロビジョニング済みの部分は、購入済みのプロビジョニング済みリソースプールのクォータに対して請求されます。プロビジョニング済みのクォータを超えて起動されたエラスティックインスタンスは、アクティブなエラスティックインスタンスおよびシャローハイバネーションのエラスティックインスタンスと同じレートで、従量課金で請求されます。
次の場合に混合モードを使用します：
トラフィックに予測可能なベースラインがあるが、時折急増する場合
通常の負荷に対して安定したパフォーマンスを確保しつつ、バーストトラフィックを処理する能力が必要な場合
コストの予測可能性とスケーリングの柔軟性のバランスが必要な場合