呼び出しの仕組み

your code ── invoke('hello') ──▶ gateway (data plane)
                                   • checks the key and the user's token
                                   • finds the project from the host
                                   • adds x-aura-role, x-aura-user-id, x-aura-project-id
                                   │  message bus (request / reply)
                                   ▼
                           functions service
                                   • access policy: only invoke is public
                                   • reads the function, reserves one invocation of the plan quota
                                   │  HTTP
                                   ▼
                            edge runtime
                                   • loads code, limits and variables
                                   • starts an isolated V8 worker
                                   • rebuilds the request you described
                                   ▼
                             your function ── Response ──▶ back along the same path

ゲートウェイと機能サービスはメッセージ バスを介して通信します。そのバス上のメッセージにはサイズ制限があるため、約 256 KiB を超えるリクエストまたは応答は通過しません。 の制限を参照してください。

• 呼び出しごとに 1 人のワーカー。 エッジ ランタイムは、メモリ制限と関数のタイムアウトを設定して、呼び出しごとに新しい分離された V8 ワーカーを開始します。ある呼び出しから次の呼び出しまでメモリ内に残るものは何もありません。状態を変数に保持しないでください。データベースまたはストレージを使用します。
• コードは数秒間キャッシュされます。 ランタイムはコードと関数の制限を 5 秒間保持し、デプロイ時に削除します。変数は呼び出しごとに読み取られます。
• リクエストは再構築されます。 ランタイムは、記述されたリクエスト (method、 path、 headers、 body) を作成し、それを Deno.serve ハンドラーに渡します。したがって、関数は他の HTTP サーバーと同様に動作します。
• ランタイムはタイムアウトを強制します。 timeout_secs が経過すると、ワーカーがキャンセルされます。呼び出し元では、その遅延が経過するとエラーが発生します。
• WASM 関数 は、メモリ、時間、命令の制限付きでサービス自体の内部で実行されます。 WASM 関数は、応答の logs フィールドに表示されるログ行をレポートできます。 Deno 関数ではできません。

このサービスには関数の応答を返す 2 つの方法があり、X-Aurabase-Invoke-Mode リクエスト ヘッダーによって選択されます。

エンベロープは、1 つの JSON 応答で通話のステータス、ヘッダー、および継続時間を伝送できるようにするために存在します。その制限は、JSON 内でバイトをやり取りできないことです。これが、バイナリ応答に raw モードが必要な理由です。 SDK は responseTypeからモードを選択します。

raw モードでは、サービスは関数の応答に x-aurabase-invoke-origin: function を追加します。ゲートウェイまたはランタイムから発生するエラーにはそれが伝わりません。これは、SDK が FunctionsHttpError (関数が応答した) と FunctionsRelayError (プラットフォームが失敗した) を区別する方法です。

3 つのタイムアウトがネストされているため、その中にあるタイムアウトより前に終了するものはありません。

gateway 380 s  ⊃  message bus 370 s  ⊃  function timeout_secs (≤ 300 s) + margin

サービスは、timeout_secs プラスマージンのランタイムを待機します。ランタイムは timeout_secsでワーカーをキャンセルするため、通常はその時点で関数からのエラーが表示され、ランタイム自体が応答を停止した場合にのみ 504 TIMEOUT が表示されます。したがって、504 は、関数 が で開始され、効果があった可能性があることを意味します。非冪等呼び出しをやみくもに繰り返さないでください。

メータリングとクォータ:

1. 呼び出しの前に、サービスはプラン クォータから 1 つの呼び出しを予約します。クォータが使い果たされた場合、呼び出しはここで 403で停止します。
2. 呼び出し後、呼び出しとその継続時間をミリ秒単位で記録します。
3. 関数が応答する前に呼び出しが失敗した場合、予約は解放され、何もカウントされません。

• 各呼び出しは短く、ステートレスにしてください。長時間の作業の場合、 はジョブをキューに入れます。
• リクエストとレスポンスは小さくしてください。ファイルをストレージに置き、参照を渡します。
• 関数を冪等にする: 再試行されたジョブ、ネットワーク エラー後のクライアントの再試行、または重複した cron 配信により、コードが 2 回実行される可能性があります。
• プラットフォームの ID ヘッダーは呼び出し元が偽造できない唯一の値であるため、これらのヘッダーで承認します。 セキュリティを参照してください。
• 独自のレイテンシーを測定します。呼び出しごとに、ワーカーの起動に料金がかかります。最小限の関数がローカル スタック上で duration_ms: 74 を報告しました。