すべてのプロダクト
Search

このプロダクト

    Function Compute:概要

    ドキュメントセンター

    Function Compute:概要

    最終更新日:Feb 12, 2025

    このトピックでは、Function Computeのカスタムコンテナランタイムの背景情報、原則、および制限について説明します。 また、HTTPサーバー設定の要件についても説明します。

    背景

    クラウドネイティブ時代では、コンテナイメージはソフトウェアの開発とデプロイで広く使用されています。 開発者エクスペリエンスを最適化し、開発と配信の効率を向上させるために、Function Computeはカスタムコンテナランタイムを提供し、開発者がコンテナイメージを関数の成果物として使用できるようにします。 カスタムコンテナーランタイムには、次の利点があります。

    • コードの変更やバイナリファイルの再コンパイルを必要としないため、移行は低コストで実行できます。 共有オブジェクト (*.so) は、開発環境と本番環境の一貫性を確保するために使用されます。

    • コードと依存関係の分離が回避され、配布と展開が簡単になります。

    • コンテナイメージは、キャッシュ階層にネイティブに格納されます。 これにより、コードのアップロードとプルの効率が向上します。

    • 標準の複製可能なサードパーティライブラリを使用して、リソースの参照、共有、ビルド、保存、およびコードのアップロードとバージョン管理を容易にすることができます。 これにより、継続的な統合と継続的な展開 (CI/CD) のための包括的なオープンソースエコシステムが作成されます。

    • HTTPリクエストは、Function Computeとのやり取りに使用できます。

    • ユーザ対話なしに動作する画像を実行することができる。

    原則

    Function Computeは、インスタンスを初期化する前に、関数に設定されたサービスロールを引き受け、一時的なユーザー名とパスワードを取得し、イメージをプルします。 イメージがプルされた後、Function Computeは指定されたstartupコマンドとargsパラメーターを使用してイメージを開始します。

    HTTPサーバーをコンテナーイメージに含める必要があります。 Function Computeは、設定されたCAPortを使用してHTTPサーバーをリッスンします。 HTTPサーバーは、イベント関数とHTTP関数の両方の呼び出しを含む、Function Computeへのすべての要求を引き継ぎます。 関数の対話ロジックを開発する前に、関数がイベント関数かHTTP関数かを判断する必要があります。 イベント関数とHTTP関数の動作を次の図に示します。

    • イベント関数 buhuo1containercustom1

    • HTTP関数 nuhuo2customcintainer2

    制限事項

    画像サイズ

    Container Registry Personal Edition、およびContainer Registry Enterprise EditionのBasic、Standard、およびAdvanced Editionは、最大10 GBの非圧縮イメージをサポートします。

    画像起動の高速化

    関数が作成または更新された後、Function Computeコンソールで関数を呼び出す前に、アクセラレーションイメージが使用可能になるまで待つ必要があります。

    イメージリポジトリ

    Container Registry Enterprise EditionおよびPersonal Editionのインスタンスからイメージをプルできます。 詳細については、「Container Registry の概要」をご参照ください。

    画像アクセス

    Container Registry Personal Editionインスタンスでのみ、アカウントとリージョン間のパブリックイメージリポジトリからイメージを読み取ることができます。 Container Registry Enterprise Editionインスタンスでは、同じリージョン内で同じアカウント内のプライベートイメージリポジトリからのみイメージを読み取ることができます。

    コンテナファイルの読み取りおよび書き込み権限

    既定では、コンテナーのrun-as-user UIDはルートユーザーのIDで、0に設定されています。 Dockerfileでユーザーを指定した場合、コンテナーイメージは指定したユーザーによって実行されます。

    コンテナ内の書き込み可能レイヤーのデータサイズ

    読み取り専用のイメージレイヤーを除き、コンテナーによって生成されるデータのサイズは、詳細設定で機能用に設定されたディスクサイズに応じて、512 MBまたは10 GBに制限されます。 詳細については、「関数の作成」をご参照ください。

    説明

    コンテナの書き込み可能なレイヤーに格納されたデータは保持されません。 コンテナが削除されると、データも削除されます。 永続ストレージが必要な場合は、ファイルストレージNAS (NAS) またはObject storage Service (OSS) ファイルシステムをFunction Computeにマウントできます。 詳細については、「NASファイルシステムの設定」および「OSSファイルシステムの設定」をご参照ください。 Tablestoreなどの他の共有ストレージサービスを使用することもできます。

    画像アーキテクチャ

    Function Computeは、AMD64イメージアーキテクチャのみをサポートしています。 したがって、Appleチップを搭載したMacコンピュータなど、ARMアーキテクチャを実行しているデバイスを使用する場合は、イメージをビルドするときにイメージのコンパイルプラットフォームをlinux/amd64として指定する必要があります。 コマンドのサンプルはdocker build -- platform linux/amd64 -t $IMAGE_NAMEです。

    説明

    ビルド操作が完了したら、docker inspectコマンドを実行してアーキテクチャを確認できます。 出力に "Architecture" : "amd64" が含まれている場合、ビルドしたイメージは正しいアーキテクチャになります。

    HTTPサーバーの構成要件

    • カスタムコンテナランタイムで開始されるサービスは、0.0.0.0:CAPortまたは *:CAPortでリッスンする必要があります。 127.0.0.1:CAPortポートを使用すると、タイムアウトエラーが発生します。 エラーメッセージの例を次に示します。

      {
"ErrorCode":"FunctionNotStarted",
"ErrorMessage":"TheCA'shttpservercannotbestarted:ContainerStartDuration:25000000000.PingCAfaileddueto:dialtcp21.0.XX.XX:9000:getsockopt:connectionrefusedLogs:2019-11-29T09:53:30.859837462ZListeningonport9000"
}

      カスタムコンテナランタイムのデフォルトのリスニングポート (CAPort) はポート9000です。 カスタムコンテナランタイムがこのデフォルトのリスニングポートを使用する場合、コンテナイメージ内のHTTPサーバーのリスニングポートもポート9000である必要があります。 カスタムコンテナランタイムがリスニングポートとしてポート8080を使用する場合、HTTPサーバーのリスニングポートはポート8080である必要があります。

    • 接続のキープアライブ機能を有効にし、サーバー側のリクエストタイムアウト時間を15分以上に設定する必要があります。 次のコードスニペットに例を示します。

      // In this example, the Express framework for Node.js is used.   
var server = app.listen(PORT, HOST);
server.timeout = 0; // never timeout
server.keepAliveTimeout = 0; // keepalive, never timeout

    • HTTPサーバーは120秒以内に起動を完了する必要があります。

    共通リクエストヘッダー

    カスタムコンテナランタイムの共通リクエストヘッダーは、カスタムランタイムのリクエストヘッダーと同じです。 詳細については、「Function Computeの一般的なリクエストヘッダー」をご参照ください。

    Log formats

    カスタムコンテナランタイムで標準出力 (stdout) に印刷されたログは、Simple Log Serviceの指定されたLogstoreに自動的に収集されます。 詳細は、「ロギングの設定」をご参照ください。

    カスタムコンテナランタイムは、カスタムランタイムと同じログ形式を使用します。 詳細については、「関数ログの形式」をご参照ください。

    コールドスタート緩和のベストプラクティス

    必要なランタイム環境が含まれているため、コンテナイメージの固有の複雑さとサイズが大きくなると、通常、より単純なコードパッケージと比較して、ダウンロード時間とアンパック時間が長くなります。 コールドスタートを軽減するには、次のベストプラクティスを参照することをお勧めします。

    • Function Computeと同じリージョンのVirtual Private Cloud (VPC) イメージアドレスを使用して、イメージプルレイテンシを短縮し、安定性を向上させます。

    • 画像のサイズを最小化します。 AlpineやUbuntuなどの最小化されたイメージに基づいてカスタムイメージを作成できます。 イメージ内の必要な依存関係のみを保持し、不要なドキュメント、データ、およびファイルを削除します。

    • プロビジョニングされたインスタンスと一緒にコンテナーイメージを使用します。 詳細については、「プロビジョニング済みインスタンスと自動スケーリングルールの設定」をご参照ください。

    • 関数がスレッドセーフで、十分なリソースがある場合は、インスタンスの同時実行性を設定して、インスタンスが一度に複数のリクエストを処理できるようにすることができます。 このアプローチはコールドスタートを減らし、コストを節約します。 詳細については、「インスタンス同時実行の設定」をご参照ください。

    • 関数を作成または更新すると、function Computeでデフォルトで有効になっているイメージ起動アクセラレーション機能により、コールドスタート時間が自動的に短縮されます。 詳細については、「Container Registry Personal Editionのイメージの起動の高速化」および「Container Registry Enterprise Editionのイメージの起動の高速化」をご参照ください。

    課金

    カスタムコンテナ関数の課金対象項目は、他のタイプのランタイムで実行される関数の課金対象項目と同じです。 詳細については、「課金の概要」をご参照ください。

    プルが開始されてからプルが終了されるまでのイメージプル期間は、イメージリソース使用に対する料金を計算するための基準として使用される。 たとえば、1 GBのメモリを持つインスタンスのイメージのプルに10秒かかる場合、リソースの合計消費量は10 GB-秒になります。

    コンテナイメージは一定期間キャッシュされます。 キャッシュイメージを使用する場合、イメージプル料金は発生しません。

    関連ドキュメント