さまざまなシナリオにおけるユーザー要件を満たすために、Function Compute は、イベント関数、Web 関数、タスク関数、GPU 関数の 4 種類の関数タイプを提供しています。さまざまな開発ワークフローに対応するため、Function Compute は、組み込みランタイム、カスタムランタイム、カスタムイメージの 3 種類の実行環境を提供しています。さまざまなリソース使用率の要件と課金のプリファレンスに対応するため、Function Compute は CPU 関数にはエラスティックインスタンスのみを提供し、GPU 関数にはエラスティックインスタンス、プロビジョニング済みインスタンス、プロビジョニング済みインスタンス + エラスティックインスタンス (混合モード) の 3 種類のインスタンスタイプを提供しています。このトピックでは、お客様の技術選定に役立つよう、Function Compute の特徴と適用シナリオについて説明します。
選定の概要
Function Compute を使用する際、ビジネスシナリオや技術スタックのプリファレンスに応じて適切な関数タイプとランタイムを選択し、インスタンスタイプを使用してパフォーマンスとコストを最適化できます。
Web アプリケーションおよび API サービス：Web 関数と カスタム実行時の使用を推奨します。この関数タイプは多くの一般的な Web アプリケーションフレームワークをサポートしており、ブラウザからアクセスしたり、URL を介して直接呼び出したりできます。
ファイル処理およびデータストリーム処理：イベント関数と 組み込み実行時の使用を推奨します。イベントトリガーを設定して、Object Storage Service、ApsaraMQ for RocketMQ、Simple Log Service (SLS) などのさまざまな Alibaba Cloud サービスと統合できます。
Chatbot、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 プロジェクトのコンテナイメージをサポートし、AI モデル推論サービスを迅速に構築できます。 |
ユースケース |
|
|
|
|
ランタイム | 推奨：組み込みランタイム | 推奨：カスタムランタイム | 推奨：組み込みランタイム | カスタムイメージのみをサポート |
デフォルトで無効 | デフォルトで無効 | デフォルトで有効 | デフォルトで無効 |
実行環境の選定
比較項目 | 組み込みランタイム | カスタムランタイム | カスタムイメージ |
開発ワークフロー | Function Compute が定義するインターフェイスを使用してリクエストハンドラを記述します。 | Web フレームワークのテンプレートを使用してアプリケーションを開発し、パブリックエンドポイントで結果を即座に確認します。 | カスタムイメージを ACR にアップロードしてから関数をデプロイするか、ACR 内の既存のイメージを使用します。 |
サポートされるインスタンスタイプ | CPU インスタンス | CPU インスタンス | CPU インスタンスと GPU インスタンス |
非サポート | サポート | サポート | |
最速。コードパッケージにランタイムが含まれていないため、コールドスタート時間が最も速くなります。 | 高速。コードパッケージである HTTP サーバーはサイズが大きくなりますが、イメージのプルが不要なため、コールドスタートは高速です。 | 低速。イメージのプルが必要なため、コールドスタートが遅くなります。 | |
コードパッケージのフォーマット | ZIP、JAR (Java)、またはフォルダ | コンテナイメージ | |
一部のリージョン (中国 (杭州) など) では最大サイズが 500 MB、その他のリージョンでは 100 MB です。 説明 Layers の設定により、依存関係を追加してコードパッケージのサイズを削減できます。 |
説明 AI 推論アプリケーションの場合、NAS または OSS に大規模モデルを保存することで、イメージサイズを削減できます。 | ||
サポートされるプログラミング言語 | Node.js、Python、PHP、Java、C#、Go | 制限なし | 制限なし |
インスタンスタイプの選定
CPU 関数では、エラスティックインスタンスのみがサポートされます。GPU 関数では、ビジネスのリソース使用率、遅延感度、コスト安定性の要件に基づいて最適なインスタンスタイプを選択できます。サービスを中断することなく、いつでも 3 つのインスタンスタイプを切り替えることができます。
プロビジョニング済みインスタンスは、Ada、Ada.2、Ada.3、Hopper、または Xpu.1 シリーズに属する GPU 関数にのみバインドできます。
エラスティックインスタンス
関数の最小インスタンス数を 0 に設定すると、インスタンスはリクエスト量に基づいて自動的にスケーリングされ、リクエストがない場合はリリースされます。これにより、使用した分だけが課金される従量課金モデルが実現し、コストを最大限に節約できます。リクエスト頻度が高いほど、仮想マシンと比較してリソース使用率が向上し、コスト削減効果も大きくなります。
コールドスタートの動作
はい、コールドスタートが発生する可能性があります。遅延の影響を受けやすいワークロードの場合、最小インスタンス数を 1 以上に設定することでコールドスタートを緩和できます。これにより、エラスティックリソースが事前に割り当てられ、インスタンスが迅速にアクティブ化されて受信リクエストを処理できるようになります。
課金 (従量課金)
関数コストには、アクティブなエラスティックインスタンスとシャローハイバネーション状態のエラスティックインスタンスの料金が含まれます。最小インスタンス数を 1 以上に設定する場合は、シャローハイバネーションモードを有効にすることを推奨します。この状態では、vCPU リソースは課金されず、GPU リソースはアクティブなレートのわずか 5 分の 1 で課金されるため、アクティブなエラスティックインスタンスと比較してコストを大幅に削減できます。
アクティブ状態とシャローハイバネーション状態のユースケースの詳細については、「エラスティックインスタンス」をご参照ください。
プロビジョニング済みインスタンス
このインスタンスタイプは GPU 関数にのみ適用されます。事前にプロビジョニング済みリソースプールを購入し、特定の数とタイプのプロビジョニング済みインスタンスを関数に割り当てます。このアプローチは、予測可能で固定のコストを提供し、高いリソース使用率、厳しい遅延要件、または安定した課金要件を持つワークロードに最適です。
月次プロビジョニング済みリソースプールを購入すると、プラットフォームはサブスクリプションベースのプロビジョニング済みインスタンスに加えて、一定クォータのブーストインスタンスを割り当てます。このブーストインスタンスクォータは課金されません。
コールドスタートの動作
いいえ、コールドスタートは発生しません。プロビジョニング済みインスタンスを使用する場合、割り当てられたキャパシティ内のリクエストはリアルタイムで応答を受け取ります。関数が処理できる最大同時リクエスト数は、(割り当てられたプロビジョニング済みインスタンス数) × (インスタンスの同時実行数)+ ブーストインスタンスクォータとして計算されます。この上限を超えたリクエストはスロットリングされます。
課金 (サブスクリプション)
関数コストは、購入したすべてのプロビジョニング済みリソースプールの合計サブスクリプション料金です。ブーストインスタンスクォータは課金されません。
プロビジョニング済みインスタンスとエラスティックインスタンス (混合モード)
このモードは GPU 関数にのみ適用されます。プロビジョニング済みインスタンスとエラスティックインスタンスの利点を組み合わせたもので、トラフィックの変動が大きいワークロードに最適です。システムはまず、プロビジョニング済みリソースプールを使用して定常トラフィックを処理します。リクエストがプロビジョニング済みプールのキャパシティを超えると、システムはエラスティックインスタンスを起動して自動的にスケールアウトします。このアプローチにより、安定したベースラインキャパシティを保証しつつ、突発的なトラフィックバーストを効果的に管理します。
コールドスタートの動作
部分的に発生します。プロビジョニング済みリソースプールによって処理されるリクエスト (最小インスタンス数まで) は、コールドスタートなしでリアルタイムに処理されます。ただし、トラフィックがオートスケーリングをトリガーし、新しいエラスティックインスタンスが起動されると、それらの新しいインスタンスではコールドスタートが発生します。
課金
混合モードのコストは、サブスクリプションと従量課金の両方のコンポーネントで構成されます：
プロビジョニング部分：購入したプロビジョニング済みリソースプールのクォータに対して課金されます。
エラスティック部分：プロビジョニング済みクォータを超えて起動されたインスタンスは、アクティブおよびシャローハイバネーションのエラスティックインスタンスと同じレートで従量課金制で課金されます。