Function Compute は、5 つの関数タイプ、3 つのランタイム環境、複数のインスタンスタイプを提供しています。このトピックでは、各オプションの主な違いを説明し、ワークロードに適した組み合わせを選択するのに役立つ情報を提供します。
選定の概要
Function Compute を使用する際、ビジネスシナリオや使用する技術スタックに基づいて適切な関数タイプとランタイム環境を選択し、インスタンスタイプを組み合わせてパフォーマンスとコストを最適化できます。
-
Web アプリと API サービス:Web 関数と カスタムランタイム を使用します。Web 関数は、多くの一般的な Web アプリケーションフレームワークをサポートしており、ブラウザからアクセスしたり、URL で直接呼び出したりできます。
-
ファイル処理と データストリーム処理:イベント関数と 組み込みランタイム を使用します。イベントトリガーを設定して、Object Storage Service (OSS)、ApsaraMQ for RocketMQ、Simple Log Service (SLS) など、さまざまな Alibaba Cloud サービスと統合できます。
-
チャットボット、text-to-image、その他の AI 推論シナリオ:GPU 関数と カスタムコンテナ を使用します。ComfyUI、RAG、TensorRT などの一般的な AI プロジェクトのコンテナイメージをベースに、AI モデル推論サービスを迅速に構築できます。
-
非同期タスク:タスク関数と 組み込みランタイム を使用して、定期タスク、オーディオ/ビデオトランスコーディング、その他のシナリオを処理します。
-
コードインタープリター、ブラウザ自動化、その他のインタラクティブシナリオ:サンドボックス関数と カスタムコンテナ を使用します。サンドボックス関数は、セッションレベルのインスタンスキープアライブを備えた永続的なサンドボックスインスタンスを提供します。
-
組み込みランタイムとカスタムランタイムはどちらもコードパッケージとしてデプロイされ、軽量アプリケーションに適しています。
-
コンテナ化されたデプロイの場合は、カスタムコンテナを選択します。GPU 関数はカスタムコンテナのみをサポートします。
関数タイプの選定
|
イベント関数 |
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 モデル推論:テキストからテキスト、テキストから画像、テキストから音声の生成。 |
コードインタープリター:コードの実行とデータ分析。ブラウザ自動化: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 ワークロードとコンテナ化されたデプロイ |
インスタンスタイプの選定
イベント関数、Web 関数、タスク関数、およびサンドボックス関数はエラスティックインスタンスのみをサポートします。GPU 関数は 3 つのインスタンスタイプをサポートしており、サービスを中断することなくいつでも切り替えることができます。
選定ガイド
適切なインスタンスタイプを選択するには、次の質問を参考にしてください:
-
ワークロードはレイテンシーに敏感でインタラクティブですか? たとえば、リアルタイムのチャットボットや画像生成 API などです。その場合は、プロビジョニング済みインスタンスを使用してコールドスタートをなくし、応答時間を保証します。
-
トラフィックに予測可能なベースラインがあり、時折スパイクが発生しますか? その場合は、混合モード (プロビジョニング済み + エラスティックインスタンス) を使用して、安定したベースライン容量を維持しながらトラフィックのバーストを吸収します。
-
トラフィックは変動性、バースト性、または低頻度ですか? その場合は、エラスティックインスタンスを使用し、アクティブな使用量に対してのみ課金されます。
インスタンスタイプの比較
|
エラスティックインスタンス |
プロビジョニング済みインスタンス |
プロビジョニング済み + エラスティック (混合モード) |
|
|
適用対象 |
GPU 以外の関数 (唯一のオプション)、GPU 関数 |
GPU 関数のみ |
GPU 関数のみ |
|
コールドスタート |
はい、最小インスタンス数が 0 の場合。最小インスタンス数を 1 以上に設定すると、リソースが事前に割り当てられ、コールドスタートが削減されます。 |
なし。割り当てられた容量内のすべてのリクエストは、リアルタイムで処理されます。 |
部分的。専用リソースプール内のリクエストにはコールドスタートがありませんが、スケールアウトしたエラスティックインスタンスでは発生します。 |
|
課金モデル |
従量課金 |
サブスクリプション |
サブスクリプション (プロビジョニング済み部分) + 従量課金 (エラスティック部分) |
|
最適な用途 |
変動性または低頻度のトラフィック、コスト重視のワークロード |
レイテンシーに敏感または安定したトラフィックのワークロード |
予測可能なベースラインと予測不可能なトラフィックバーストを持つワークロード |
エラスティックインスタンス
エラスティックインスタンスは、リクエスト量に応じて自動的にスケールし、アイドル状態になると解放されます。最小インスタンス数を 0 に設定すると、純粋な従量課金モデルとなり、アクティブな使用量に対してのみ課金されます。
コールドスタートの動作:コールドスタートは、インスタンスがゼロからスケールするときに発生します。コールドスタートのレイテンシーを削減するには、最小インスタンス数を 1 以上に設定します。これにより、エラスティックリソースが事前に割り当てられ、インスタンスが受信リクエストを迅速に処理できるようになります。
課金:コストには、アクティブ状態と浅い休止状態の両方のインスタンスに対する料金が含まれます。浅い休止状態では、vCPU リソースは課金されず、GPU リソースはアクティブ料金の 5 分の 1 で課金されます。最小インスタンス数を 1 以上に設定する場合は、浅い休止状態を有効にしてアイドルコストを削減します。
エラスティックインスタンスが適しているケース:
-
トラフィックが変動性、バースト性、または低頻度である
-
料金を実際の使用量に抑えたい場合
-
ワークロードが時折発生するコールドスタートのレイテンシーを許容できる (または、最小インスタンス数でそれを緩和する)
プロビジョニング済みインスタンス
プロビジョニング済みインスタンスは GPU 関数にのみ適用されます。事前に専用リソースプール (旧称:常駐リソースプール) を購入し、特定の数とタイプのインスタンスを関数に割り当てます。これにより、割り当てられた容量内でのコールドスタートがなくなり、予測可能な固定コストで利用できます。
コールドスタートの動作:なし。割り当てられた容量内のすべてのリクエストは、リアルタイムで処理されます。最大同時リクエスト数 = (割り当てられたプロビジョニング済みインスタンスの数) × (インスタンスの同時実行数)。この制限を超えたリクエストはスロットリングされます。
課金:購入したすべての専用リソースプールの合計サブスクリプション料金となります。
プロビジョニング済みインスタンスは、Ada、Ada.2、Ada.3、Hopper、または Xpu.1 シリーズの GPU 関数でのみ利用できます。
プロビジョニング済みインスタンスが適しているケース:
-
ワークロードがレイテンシーに敏感でインタラクティブである (例:リアルタイムのチャットボットや画像生成 API)
-
トラフィックが安定しており予測可能である
-
保証された容量と一貫した応答時間が必要である
プロビジョニング済み + エラスティックインスタンス (混合モード)
混合モードは GPU 関数にのみ適用されます。プロビジョニング済みインスタンスとエラスティックインスタンスを組み合わせたものです。専用リソースプールがまず定常状態のトラフィックを処理し、リクエストが専用リソースプールの容量を超えるとエラスティックインスタンスが自動的にスケールアウトします。これにより、保証されたベースラインと、突然のトラフィックバーストを吸収する柔軟性が得られます。
コールドスタートの動作:部分的。専用リソースプール内で処理されるリクエストにはコールドスタートがありません。新しいエラスティックインスタンスへの自動スケーリングをトリガーするリクエストでは、コールドスタートが発生します。
課金:プロビジョニング済みの部分は、購入した専用リソースプールのクォータに対して課金されます。専用リソースプールのクォータを超えて起動されたエラスティックインスタンスは、アクティブ状態および浅い休止状態のエラスティックインスタンスと同じレートで、従量課金制で課金されます。
混合モードが適しているケース:
-
トラフィックに予測可能なベースラインがあるが、時折スパイクが発生する
-
通常の負荷に対して安定したパフォーマンスを確保しつつ、バーストトラフィックを処理する能力も必要である
-
コストの予測可能性とスケーリングの柔軟性のバランスが必要である