HTTP トリガーの制限と、HTTP トリガーを使用して関数を呼び出す方法 - Function Compute

HTTP トリガーを使用すると、HTTP リクエストを介して関数を呼び出すことができます。このトリガーは、Web サービスの迅速な開発に特に役立ちます。 HTTP トリガーの使用を開始する前に、このトピックで説明されているように、HTTP トリガーの制限と、HTTP(S) リクエストとレスポンスの制限について理解しておくと、これらの制限を超過することによって発生する関数エラーを回避できます。このトピックでは、HTTP トリガーの呼び出し方法と認証方式、およびオリジン間リソース共有 (CORS) リクエストの処理方法についても説明します。

使用上の注意

HTTP トリガーが匿名に設定されている場合、つまり、[認証方式] が [認証なし] に設定されている場合、ID 検証は不要になり、誰でも HTTP リクエストを介して関数を呼び出すことができます。これは深刻なセキュリティリスクとなります。このようなリスクを防ぐために、HTTP トリガーの署名認証を設定し、HTTP リクエストの Authorization ヘッダーを介してリクエスト元の ID を検証できます。詳細については、「HTTP トリガーの署名認証を設定する」をご参照ください。
中国のサイバーセキュリティ規制によると、2024 年 6 月 10 日以降、新しく作成された HTTP トリガーを使用して、パブリックエンドポイントから Android Package Kit (APK) ファイル (MIME タイプ: application/vnd.android.package-archive) をダウンロードすることはできません。ダウンロードしようとすると、400 エラーコードが返されます。詳細については、「HTTP トリガーのパブリックエンドポイントが .apk ファイルを返さないのはなぜですか?」をご参照ください。
仮想 IP アドレス (VIP) のローテーションメカニズムに注意してください。
システムの回復力とサービスの安定性を高めるために、Function Compute は VIP ローテーションメカニズムを実装しています。具体的には、Function Compute の HTTP トリガーのパブリックエンドポイントと内部エンドポイントに対応する VIP は、時々ローテーションされます。 VIP ローテーションメカニズムは、インフラストラクチャの堅牢性の不可欠な部分を構成します。
したがって、VIP のハードコーディングは、サービスの中断を引き起こす可能性があります。サービスの堅牢性を確保するために、カスタムドメイン名を使用することをお勧めします。 VIP の不適切な使用によって発生した障害は、Function Compute の補償範囲の対象外であることに注意してください。 VIP が不適切に使用されている場合は、設定を確認し、必要な調整を行ってください。
CNAME を使用したカスタムドメイン名を使用して、Function Compute にアクセスできます。詳細については、「カスタムドメイン名を設定する」をご参照ください。

制限

トリガーの制限

関数の各バージョンまたはエイリアスに対して、作成できる HTTP トリガーは 1 つだけです。詳細については、「バージョンを管理する」および「エイリアスを管理する」をご参照ください。
デフォルトでは、HTTP トリガーによって提供される組み込みドメイン名は、テスト目的のみを想定しています。その安定性は保証されないため、オンラインサービスに影響を与える可能性があります。したがって、外部オンラインサービスには組み込みドメイン名を使用しないことをお勧めします。
説明
公開 Web サイトでは、ICP 登録を取得したドメイン名のみを使用できます。登録済みのカスタムドメイン名を設定し、関数をバインドしてから、そのドメイン名を使用して Web サイトサービスを外部に提供できます。詳細については、「カスタムドメイン名を設定する」をご参照ください。

HTTP(S) の制限

説明

関数をトリガーするには、GET、POST、PUT、DELETE、HEAD、PATCH、OPTIONS の方法を使用できます。 HTTP(S) は、単純なリクエスト-レスポンスシナリオに適しています。詳細については、「HTTP トリガーを設定する」をご参照ください。

HTTP リクエストの制限
- リクエストヘッダーは、x-fc- で始まるカスタムフィールド、または次のフィールドをサポートしていません。
  - connection
  - keep-alive
- リクエストが次の制限のいずれかを超えると、システムは 400 状態コードと InvalidArgument エラーを返します。
  - ヘッダーサイズ: ヘッダー内のすべてのキーと値の合計サイズは 8 KB を超えることはできません。
  - パスサイズ: すべてのパラメータを含むパスの合計サイズは 8 KB を超えることはできません。
  - 本文サイズ: 同期呼び出しリクエストの本文の合計サイズは 32 MB を超えることはできません。非同期呼び出しリクエストの本文の合計サイズは 128 KB を超えることはできません。
HTTP レスポンスの制限
- レスポンスヘッダーは、x-fc- で始まるカスタムフィールド、または次のフィールドをサポートしていません。
  - connection
  - content-length
  - date
  - keep-alive
  - server
  - upgrade
  - content-disposition:attachment
    説明
    セキュリティ上の理由から、Function Compute のデフォルトドメイン名 aliyuncs.com を使用する場合、サーバーは強制的に content-disposition: attachment レスポンスヘッダーを追加します。これは、ブラウザから返された結果を添付ファイルとしてダウンロードするために使用されます。この制限を削除するには、カスタムドメイン名を使用します。詳細については、「カスタムドメイン名を設定する」をご参照ください。
- レスポンスが次の制限のいずれかを超えると、システムは 502 コードと BadResponse エラーを返します。
  - ヘッダーサイズ: ヘッダー内のすべてのキーと値の合計サイズは 8 KB を超えることはできません。

メリット

HTTP トリガーと API Gateway トリガーの両方を使用して、Web アプリケーションを作成できます。以下に、各タイプのトリガーについて説明します。

HTTP トリガー: カスタムドメイン名をバインドすると、パスと関数の間のマッピングを設定できます。これにより、異なるパスからのリクエストが異なる関数をトリガーできます。詳細については、「カスタムドメイン名を設定する」をご参照ください。
API Gateway トリガー: バックエンドサービスとして Function Compute を設定した API Gateway を使用して、同様の機能を実装できます。詳細については、「Function Compute」をご参照ください。

API Gateway トリガーと比較して、HTTP トリガーには次のメリットがあります。

HTTP トリガーは、開発者にとって学習、使用、デバッグが容易です。これにより、開発者は Function Compute を使用して、Web アプリケーションと API を迅速に構築できます。
HTTP トリガーを使用して、リクエスト処理を最適化できます。 HTTP トリガーは、効率的なリクエストおよびレスポンス形式をサポートしています。リクエストを JSON 形式にエンコードまたはデコードする必要はありません。これにより、パフォーマンスが向上します。
HTTP トリガーを使用すると、使い慣れた HTTP テストツールを使用して、Function Compute の機能とパフォーマンスをテストできます。
HTTP トリガーは、CDN や Simple Message Queue (formerly MNS) など、Webhook をサポートする他のサービスと簡単に統合できます。

呼び出し方法

同期呼び出し

同期呼び出し中は、関数はリクエストを処理してから結果を返します。デフォルトでは、HTTP トリガーはこの同期モードで関数を呼び出します。詳細については、「同期呼び出し」をご参照ください。

非同期呼び出し

非同期呼び出し中は、Function Compute はリクエストを永続化し、実行が完了するのを待たずにすぐにレスポンスを返します。

非同期呼び出し: "X-Fc-Invocation-Type":"Async" リクエストヘッダーを追加することにより、HTTP トリガーを使用して関数を非同期モードで呼び出すことができます。
非同期タスク: 関数の非同期タスク機能を有効にすると、"X-Fc-Async-Task-Id":"g6u*****iyvhd3jk8s6bhj0hh" リクエストヘッダーを追加して、非同期タスクの呼び出し ID を設定できます。

リクエストヘッダーの詳細については、「InvokeFunction」をご参照ください。

非同期呼び出しが成功すると、Function Compute は 202 コードを返します。これは、リクエストが正常に受信されたことを示します。また、Function Compute は、リクエストヘッダーに基づいてリクエスト ID を返します。 ID の形式は "X-Fc-Request-Id": "80bf7****281713e1" です。

説明

202 以外の状態コードは、障害を示します。障害の原因の詳細については、「再試行メカニズムを設定する」をご参照ください。

参照

非同期呼び出しの詳細については、「非同期呼び出し」をご参照ください。
非同期タスクの詳細については、「非同期タスク」をご参照ください。

認証

HTTP トリガーの認証を設定して、関数が処理する前に外部リクエストが認証を通過する必要があるようにすることができます。

HTTP トリガーには、署名認証と JSON Web トークン (JWT) 認証を設定できます。

署名認証

HTTP トリガーに署名認証ポリシーが設定されている場合、リクエストは、割り当てられた AccessKey ID と AccessKey シークレットを使用して署名する必要があります。呼び出し中に、AccessKey ID、AccessKey シークレット、および署名が認証のために Function Compute に渡されます。詳細については、「HTTP トリガーの署名認証を設定する」をご参照ください。

この認証方法は非常に安全ですが、クライアントは署名アルゴリズムを実装する必要があり、コストがかかる可能性があります。また、AccessKey ID と AccessKey シークレットをクライアントに保存する必要があるため、漏洩のリスクが高まります。セキュリティトークンサービス (STS) トークンを使用すると、この問題を軽減できますが、アーキテクチャが複雑になります。

JWT 認証

JWT は、API の認証とアクセスに広く使用されている安全な方法であり、JavaScript や Web フロントエンドなどのセキュリティの低いクライアントシナリオに特に適しています。詳細については、「HTTP トリガーの JWT 認証を設定する」をご参照ください。

CORS リクエスト処理

デフォルトでは、Function Compute を使用すると、オリジンをまたいで関数を呼び出すことができます。また、CORS リクエストを処理するコードを記述することもできます。

単純なリクエスト

単純なリクエストでは、プリフライトリクエストは不要です。関数コードで Access-Control-Allow-* で始まるヘッダーを設定して、簡単にアクセス制御を実装できます。単純なリクエストの場合、Function Compute は、Access-Control-Allow-Origin、Access-Control-Allow-Headers、Access-Control-Request-Method、Access-Control-Max-Age のカスタムヘッダーをサポートしています。

カスタムヘッダーを設定しない場合、Function Compute は次のレスポンスヘッダーを入力します。

Access-Control-Allow-Origin: リクエストのオリジンヘッダー。
Access-Control-Allow-Credentials: 資格情報を許可するかどうか。デフォルト値は true です。
Access-Control-Expose-Headers: Function Compute のカスタムヘッダー。

複雑なリクエスト

複雑なリクエストが送信される前に、プリフライトリクエストが送信されます。ブラウザは OPTIONS メソッドを使用してプリフライトリクエストを送信し、関数を呼び出すための実際のリクエストを開始します。複雑なリクエストを開始するためのルールは、単純なリクエストを開始するためのルールと同じです。プリフライトリクエストのカスタムレスポンスを指定する場合は、HTTP トリガーに OPTIONS メソッドを追加し、関数コードで OPTIONS リクエストを処理する必要があります。具体的には、Access-Control-Allow-* で始まるヘッダーを設定して、関数がクロスオリジンリクエストでどのように動作するかを制御できます。

プリフライトリクエストの場合、Function Compute は、Access-Control-Allow-Origin、Access-Control-Allow-Headers、Access-Control-Allow-Methods、Access-Control-Max-Age のカスタムヘッダーをサポートしています。

この例では、組み込みの Node.js ランタイムを使用して、関数コードでプリフライトリクエストを処理する方法について説明します。

exports.handler =  (event, context,callback) => {
      console.log('hello world'); // こんにちは世界
      const method = JSON.parse(event).requestContext.http.method;
      if (method === 'OPTIONS') {
          // プリフライトリクエストを処理するためにレスポンスヘッダーを設定します。
          const fcResponse = {
            'statusCode': 204,
            'headers': {
              'Access-Control-Allow-Origin': 'http://www.fc.com',
              'Access-Control-Allow-Methods': 'POST',
              'Access-Control-Allow-Headers': 'Content-Type, Authorization',
              'Access-Control-Max-Age':'3600'
            },
            'body': 'hello world' // こんにちは世界
        };
        callback(null, fcResponse);
      } else {
        callback(null, {
            'statusCode': 500,
            'body': 'hello world' // こんにちは世界
        });
      }
    };

FAQ

リスニングポートを設定する必要がありますか?

[Web 関数] を選択した場合にのみ、関数を作成するときにリスニングポートを設定する必要があります。

関数の呼び出しに長い時間がかかる場合はどうすればよいですか?

関数が頻繁に使用されない場合は、関数を初めて呼び出すときに、関数のコールドスタートが完了するまで待機する必要があります。
詳細については、「使用頻度の低い関数の呼び出しに時間がかかるのはなぜですか?」をご参照ください。コールドスタートを軽減する方法の詳細については、「コールドスタートの影響をなくすためにインスタンスを稼働状態に保つにはどうすればよいですか?」をご参照ください。
関数呼び出しが時々タイムアウトする場合は、実行タイムアウト期間を調整し、ログをクエリしてタイムアウトの原因を見つけることができます。詳細については、「関数の実行がタイムアウトし、「Function time out after」というエラーが報告された場合はどうすればよいですか?」をご参照ください。
トラフィックのピークを処理するために、関数にインスタンス同時実行機能を設定することをお勧めします。詳細については、「インスタンスの同時実行を設定する」をご参照ください。

499 状態コードがクライアントに返され、クライアントがリクエストをキャンセルした場合はどうすればよいですか?

クライアントで 499 状態コードが発生すると、関数インスタンスが再起動されます。これらのインスタンスのヘルスチェックを設定して、不要な再起動を回避できます。詳細については、「クライアントで 499 エラーが発生した後に関数インスタンスが再起動されるのはなぜですか?」をご参照ください。
クライアントで関数呼び出しがタイムアウトした場合は、時間のかかるロジックを新しい関数のコードに移動できます。次に、新しい関数を非同期モードで呼び出します。クライアントで呼び出しを開始するときに、非同期呼び出しモードを使用することもできます。

実行中の関数の設定を更新するにはどうすればよいですか?

関数設定は、関数の実行が完了した後にのみ更新されます。関数の設定を更新した後も、実行中のリクエストに対しては以前の設定が引き続き有効になります。更新された設定は、後続のリクエストに対して有効になります。
現在の関数を削除し、ビジネス要件を満たす設定を持つ別の関数を作成できます。