どんな場面で検討するか
HTTPの業務APIやWebアプリをコンテナのまま配備し、要求量に合わせてインスタンスを増減したい場合。完了型の処理はサービスとJobsの違いも比較する。
組織で使う条件
公開範囲とサービス用IDを管理し、リビジョン単位のトラフィック配分・切戻しを用意する。スケール上限で接続DBを過負荷にしない。
採用前に試すこと
- 検証用イメージを配備し、認証必須・最大インスタンス・同時実行と外部保存先を設定する。
- 通常と集中の合成要求各100件を送り、成功数・初回応答・DB接続数・資源時間を記録する。
- 新リビジョンへ一部配分してから旧版へ戻し、アクセス拒否と結果の一致を確認する。
合格と判断する条件
- 権限外要求が拒否され、許可100件の結果が一致する。初回と負荷時の応答が事前に定めた許容値内に入る。
- 旧リビジョンへ戻せ、接続数と課金資源を説明できる。
見落としたくない点
- ホストOSやKubernetesのノード制御が必要ならGKE/VMと比較する。HTTPサービスで要求終了後もCPUが常時使える前提にする場合は、要求ベース/インスタンスベース課金と処理形態を見直す。
- ホストOSやKubernetesのノード制御が必要ならGKE/VMと比較する。HTTPサービスで要求終了後もCPUが常時使える前提にする場合は、要求ベース/インスタンスベース課金と処理形態を見直す。