生成AI予算を超えても仕事は止めない、Jamf式の段階制限
AI・自動化 6
AWS LambdaかCloud Runか、15分制限と60分処理が分岐点
短いAPIやAWSのイベントから起動する処理は、通常のAWS Lambda関数を軸に選びやすい。AWSのLambdaのクォータ表によると、通常の関数は1回の実行が最大15分で、Lambda Managed Instancesの一部の非同期呼び出しには別の上限がある。Google CloudのCloud Runの制限一覧では、サービスの1リクエストは最大60分、1インスタンスに設定できる同時リクエスト数は最大1000とされる。
単一実行が通常のLambda関数の上限を超えるなら、処理を分割するか、Cloud Runなど別の実行先を選ぶ必要がある。短い処理でも、外部サービスを待つ要求がピーク時に重なるAPIでは、Cloud Runのインスタンス内並行処理が有利に働く可能性がある。一方、同時処理の設定値を上げるだけで応答が速くなるわけではない。東京リージョンでの費用は、要求の長さと到着の偏りを含めて比べるべきだ。
実行時間の上限をどう判断するか
Lambdaの制限がかかるのは、通常の関数の各呼び出しである。長いバッチでも、入力を分けて各処理を短く終えられるならLambdaを使える。逆に、分割しにくい変換を一度の呼び出しで完了させる設計では、その実行上限が配置先を決める。外部APIの遅延や入力サイズの増加で所要時間が揺れる処理は、平常時に上限内で終わるというだけでは余裕を判断できない。
Cloud Runサービスの上限は、HTTPリクエストへの応答を待てる時間である。長時間処理の途中で呼び出し元の接続が切れれば、応答の行方と処理の行方を別々に扱わなければならない。利用者が完了をその場で待つ必要のないバッチなら、APIは受付を返し、実行と結果の記録を分ける構成が適する場合がある。Cloud Runジョブは、そのようなコンテナ処理をリクエストの応答時間から切り離す選択肢になる。
同期処理を長く保つ場合は、再試行時の二重実行にも注意が要る。たとえば処理自体は完了したのに応答だけが届かなければ、呼び出し元は失敗と判断して同じ要求を送り直し得る。受付と実行を分ければ状態管理が必要になるが、要求者に長い接続を維持させずに済む。必要なのは最長実行時間だけではなく、結果をいつ返す契約なのかという判断である。
同時処理はインスタンス数と待ち時間を変える
通常のLambda関数では、実行中の環境は別の呼び出しを同時に処理しない。同時に到着した要求が増えれば、空いている環境を使うか、新しい環境を起動することになる。Cloud Runサービスは一つのインスタンスで複数の要求を処理できるため、データベースや外部APIからの応答待ちが多いアプリケーションでは、計算資源を共有しやすい。
ただし、設定上の同時リクエスト数は処理能力の保証ではない。要求ごとにCPUを使い切る画像変換や、並行処理を想定していないコードでは、同じインスタンスに要求を集めるほど内部の待ち行列が伸び得る。データベースへの接続も、インスタンスごとの接続プールと増加するインスタンス数の両方で決まる。接続先が先に詰まれば、アプリケーション側のインスタンスを節約できても遅い要求は改善しない。
比較する負荷は月間件数だけでは表せない。同じ件数でも、短い時間帯に集中するAPIと一日を通じて均等に届くAPIでは、必要な同時実行容量が違う。応答時間の平均に加え、ピーク中の遅い要求、起動した環境やインスタンスの数、接続数、エラー率を同じ時間帯で見ると、どこが待ち時間を生んでいるか判断しやすい。
公開されたスパイク試験から分かる範囲
72TechnologiesのNode APIの並行運用記録は、約40倍の負荷増を伴うAPIを両基盤で6週間動かし、ピーク時のP99応答時間を、プロビジョンドコンカレンシーに余裕のないLambdaで約1.9秒、Cloud Runで約620ミリ秒と報告している。これは同社が公開した特定のアプリケーションと構成での値であり、東京リージョンの一般的な性能差を示すものではない。
記録では、短い期間のバーストを取り出すと、Lambdaは新しい実行環境を多数必要とし、Cloud Runは一つのインスタンスで要求を並行処理している。ここから読み取れるのは、コールドスタート一回の速さだけでは、ピーク時に遅くなる要求の割合を説明できないという点だ。起動が比較的遅いインスタンスでも、そのインスタンスが後続の要求を受けられれば、追加起動の回数を抑えられる。
同じ仕組みは別の制約も生む。アプリケーションが要求間で共有するメモリやデータベース接続を適切に扱えなければ、並行処理の利点は薄れる。したがって、スパイク型APIでCloud Runを選ぶ根拠は「同時実行を設定できること」だけでは足りない。実際の処理に入出力待ちがどれだけあり、並行時にも遅い要求を抑えられるかが分かれ目になる。
東京リージョンの費用は何で決まるか
AWSのLambda料金体系では、通常の関数は呼び出し回数と実行時間に応じた計算量が基本となり、プロビジョンドコンカレンシーを使えば設定した容量を維持する時間も課金対象になる。同じ月間件数でも、短い要求が散発する場合と、長い要求が一斉に届く場合では必要な容量が異なる。起動遅延を抑えるための待機容量を見積もりから外すと、スパイク型APIの費用を過小評価しやすい。
Google CloudのCloud Run料金表では、東京はasia-northeast1で、サービスの課金方式、割り当てたCPUとメモリ、請求対象のインスタンス時間、リクエスト数が見積もりに関わる。リクエストベース課金でも最小インスタンスを維持すれば待機中の料金が生じ、ジョブはサービスと異なる課金の扱いを受ける。他地域の単価や特定企業の請求額を、そのまま東京での予算には使えない。
比較の土台には、同じ月間件数だけでなく、時間帯別の到着率と処理時間の分布を置く。Lambda側ではメモリ設定と実行時間に加え、ピークに備えるプロビジョンドコンカレンシーの有無を入れる。Cloud Run側ではCPU・メモリ設定、実際にさばける同時要求数、インスタンスの稼働時間、最小インスタンスの有無を変えて見積もる。APIの入口、データベース、外向き通信なども、片方だけを省かず同じ範囲で計上する必要がある。
とりわけ入出力待ちの長いAPIでは、要求が占める経過時間とCPUが働く時間は一致しない。Cloud Runが待ち時間に別の要求を処理できれば、共有した資源の使い方が費用に効く。CPUを使い続ける処理では、その余地が小さい。単価の大小だけで勝者を決められない理由は、請求対象となる資源の使われ方がワークロードごとに変わるためだ。
コンテナを使えることと移しやすさは別の条件
既存のHTTPアプリケーションをコンテナとして配置したい場合、Cloud Runサービスはその実行形態に合う。Lambdaにもコンテナイメージによるデプロイ方法はあるが、イメージに入れられることだけでHTTPアプリケーションをそのまま移せるわけではない。イベントの受け取り方、応答方法、タイムアウト、並行処理の単位は、それぞれの実行モデルに合わせる必要がある。
AWSのイベントを起点に小さな処理を動かす構成なら、既存の連携を生かせることがLambdaの利点になる。反対に、HTTPアプリケーションやコンテナ内の処理を中心に組み立てるなら、Cloud Runが扱いやすい場合がある。移行の負担を左右するのはイメージ形式よりも、入口、認証、キュー、監視、再試行をどこまで作り替えるかだ。
処理時間別の判断モデル
次の例は、いずれも東京リージョンへの配置を想定した仮定のワークロードであり、料金や応答時間の実測値ではない。処理時間を起点に、ピーク時の振る舞いと費用を合わせて選ぶ。
- 平均100ミリ秒のWebhook API。検証と保存が短時間で終わり、AWS内のイベント連携が中心なら、通常のLambda関数が有力だ。アクセスの山で遅延が問題になるなら、要求の到着間隔と外部データベース待ちを見たい。入出力待ちが多く、同じコンテナで安全に並行処理できるアプリケーションなら、Cloud Runサービスも候補になる。
- 約8分のレポート生成。通常のLambda関数でも実行できる想定だが、入力の増加や外部APIの遅延で所要時間が伸びるなら余裕は小さくなる。利用者が画面で完了を待つ必要がなければ、受付と処理を分ける設計が合う。費用は件数だけでなく、長い実行時間に見合うメモリと、同時に走る件数を含めて比較する。
- 約30分のデータ変換。通常のLambda関数を単一実行の配置先にはできない。入力を分割できれば短い関数を連携させる案があり、まとまったコンテナ処理を保ちたいならCloud Runジョブが候補になる。Cloud Runサービスで同期応答を待つ案は、呼び出し元のタイムアウトと、接続が切れた後の再試行を扱える場合に限られる。
関連記事：
関連記事
ニュースレターを購読
Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。
0