スパイキーなワークロードに対するKubernetesとサーバーレス関数の比較

API中心のプロダクトにとっての「スパイキーなワークロード」

スパイキーなワークロードとは、トラフィックが一定でない状態を指します。短時間の大きなバーストがあり、その後長く静かな期間が続き、再びバーストが来る。バーストは通常の負荷の10倍〜100倍になり、数分で発生することもあります。

よくある原因は単純で現実的です:

• マーケティングメールや広告キャンペーンの配信
• パートナーアプリが障害後にリクエストを再送し始める
• ライブイベント（チケット発売、ウェビナー、製品ローンチ）
• 一斉にファンアウトする定期ジョブ
• ループや繰り返しポーリングを引き起こす小さなバグ

API中心のプロダクトは特にスパイクの影響を受けやすいです。ユーザーの1つの操作が多数の小さなリクエストに変換されるからです。1つの画面表示が認証チェック、フィーチャーフラグ、検索、レコメンド、監査ログなど複数のAPI呼び出しを誘発します。トラフィックが急増すると、これらの呼び出しが一気に積み重なります。依存先のどれか1つでも遅くなれば、タイムアウトやリトライが発生し、それがさらにクライアントからの再送を生みます。

具体例：顧客ポータルは終日問題なく動作しているが、キャンペーンで数千人が5分間で一斉にログインするとします。各ログインで認証、プロファイル、権限チェックが走ります。認証サービスが一時的に停止したりスケールが遅かったりすると、ユーザーには「サイトが落ちている」と感じられます。実際には一部のコンポーネントが苦しんでいるだけかもしれません。

だからこそ、Kubernetesとサーバーレス関数の比較は「どちらが絶対に正しいか」ではなく、バースト時にどんなトレードオフが出るかという議論になるのです。

簡単なおさらい：Kubernetesとサーバーレスを簡単に説明すると

Kubernetesとサーバーレス関数を比較する時、どちらも「リクエストに素早く応答するAPIを動かす」という同じ目的を果たす手段です。違いは実行モデルと運用の仕方です。

Kubernetes（常時稼働するコンテナ）

Kubernetesはアプリを通常常時稼働させるコンテナとして動かします。コンテナはポッドに入って稼働し、Kubernetesはクラスター上で望ましいポッド数を維持します。

通常はAPIと、データベースプロキシ、ジョブワーカー、キャッシュなどの補助的なパーツをデプロイします。トラフィックが増えればオートスケーリングでポッドを増やし、減れば削除しますが、ゼロにまで落とす設計にしない限り完全に停止することは稀です。

多くの場合、Kubernetesはマネージドサービスとして動かされます（例：AWS、Azure、Google CloudのマネージドKubernetes）。物理サーバーは管理しませんが、プラットフォームの選択や維持は必要です。

サーバーレス関数（リクエストごとにコードが動く）

サーバーレス関数は必要なときだけコードを実行します。各リクエストで関数がトリガーされ、プラットフォームが必要なだけインスタンスを立ち上げ、リクエストが止まるとスケールダウンします。典型的なモデルは「ゼロまでスケールダウン」です。

多くのチームはマネージドな関数プラットフォーム（AWS Lambda、Azure Functions、Google Cloud Functionsなど）を使います。コードと設定を提供すれば、プロバイダがランタイム、スケーリング、多くのインフラ周りを処理してくれます。

ただし、マネージドであってもデプロイ、シークレット管理、モニタリング、ログ、トレーシング、タイムアウトやメモリ、同時実行数やクォータの管理はチームの責任です。

コスト比較：お金はどこに消えるか

コストは単に「コンピュート代」ではありません。API中心のプロダクトでは請求はコンピュート、ネットワーキング、ストレージ、マネージドアドオン、そして運用にかかる時間に分散します。

重要なコスト項目は：

• コンピュート：ノードと予約キャパシティ（Kubernetes）対 呼び出しごとの実行時間とメモリ（サーバーレス）
• ネットワーキング：ロードバランサー、NAT、プライベートネットワーク、データ転送（egress）
• ストレージ：データベース、キャッシュ、オブジェクトストレージ、バックアップ
• マネージドサービス：APIゲートウェイ、キュー、シークレット、ID、スケジューラ
• 運用時間：オンコール、アップグレード、セキュリティパッチ、スケーリングルール、インシデント対応

有用なメンタルモデルは「アイドルに対して払う」対「使った分だけ払う」です。Kubernetesでは夜間などトラフィックが少ない時間でもノードに対して24時間支払うことが多い一方、サーバーレスではコードが実行されたときに支払うため、真にゼロまで落ちる利用パターンと相性が良いです。

簡単な例：APIがマーケティングで10分間だけ毎秒50リクエストを受け、その後はほとんどゼロになるとします。Kubernetes構成ではピークを捌く十分なノード容量を確保する（あるいはスケールが遅いことを受け入れる）必要があり、平時は待機しているサーバーに支払うことになります。サーバーレスではバースト時の1リクエスト当たりの単価は高くなるかもしれませんが、静かな時間のコストを避けられます。

驚くべき隠れたコストがよくチームを困らせます。NATゲートウェイやロードバランサーはリクエストが少なくても月額費用の原因になります。ログ、メトリクス、トレースはリクエスト量やリトライ、チャッティなミドルウェアで急速に増えます。関数がサードパーティAPIを呼んだり大きなペイロードを返す場合、データのegressが一気に跳ね上がります。

Kubernetesはベースラインが安定していて利用率を高く保てる場合に安くなることが多いです（適切なノードサイズ、予約インスタンス、予測可能なトラフィック）。サーバーレスはリクエストが短く、バーストが稀でサービスが本当にゼロに落ちる場合に有利です。

実践的なヒント：平均RPSだけで見積もらず、実際のAPI挙動でコストを試算してください。バーストサイズ、ペイロードサイズ、リトライ、そして保持する可観測性データ量を含めること。

コールドスタートとレイテンシ：ユーザーが実際に感じるもの

コールドスタートは単純です：最初のリクエストが「スリープ中」の関数に当たると、プラットフォームは関数を起動してコードが動く準備をする必要があります。その最初の呼び出しは遅くなり、次の100回は速い、ということがあります。

API中心のプロダクトではこれが最も痛いところに現れます：p95やp99のレイテンシです。ほとんどのユーザーは素早い応答を受け取りますが、一部のユーザーは2〜10秒の待ち、タイムアウト、終わらないスピナーを経験します。これらの遅い外れ値がクライアントやゲートウェイのリトライを引き起こし、システムが既に苦しい時に追加負荷を生みます。

コールドスタートを悪化させる要因は実務的な詳細によります：

• ランタイムとパッケージサイズ：重いランタイムや大きな依存関係は読み込みに時間がかかる
• ネットワーク設定：プライベートネットワークへの接続は起動時間を伸ばすことがある
• メモリとCPU割り当て：リソースを増やすと起動が速くなるがコストも増える
• 起動時の外部呼び出し：シークレット取得、DB接続、SDK初期化
• 同時実行モデル：プラットフォームによっては1インスタンス1リクエスト型で、バースト時にコールドスタートが増える

現実的な例：モバイルアプリが午前9時に「最近の注文」画面を開くと、関数が夜間にアイドルだった場合、最初のユーザーは6秒の応答を受け、アプリが再試行すると同じコールドパスにさらにリクエストが来ます。平均レイテンシは問題なくても、そのユーザーは「このアプリは遅い」と感じます。

ユーザーへの影響を減らす方法は組み合わせて使われます：少量のウォームキャパシティを維持する、1つの大きな関数を必要な部分に分割して起動する範囲を狭める、キャッシュでコールドパスへの到達を減らす、など。ウォームアップのために定期的にPINGを送る手法もありますが、脆弱で回避策に感じられることが多いです。

Kubernetesはポッドを常時ウォームにしておけるため予測可能なレイテンシで優位なことが多いです。ただしKubernetesも免疫があるわけではなく、ゼロや極めて低いベースラインからのオートスケールに頼る場合、新しいポッドのイメージ取得や起動、ヘルスチェック通過に時間がかかります。違いは、Kubernetes側の「冷たさ」は自分たちのコントロール下に置きやすいのに対し、サーバーレスのコールドスタートは完全に排除しにくい点です。

ローカル開発：何がつらくなりがちか

API中心のプロダクトではローカル作業は退屈に感じられるべきです。APIを動かして、本物のエンドポイントに当てて、リクエストをエンドツーエンドでデバッグし、テストデータを用意し、自動テストを回す。環境がどれかを推測する必要がない状態が理想です。

Kubernetesでは、つらさは通常セットアップと設定のズレです。ローカルクラスタ（または共有開発クラスタ）はマニフェスト、サービスディスカバリ、Ingressルール、シークレットなどの追加の動く部品を増やします。ポッドがPostgresに接続できない理由を数時間追うこともあります。動いたとしても、ループは遅く感じがちです：イメージをビルドしてプッシュし、デプロイして待って、再試行。

サーバーレスではローカルとクラウドのギャップが問題になります。エミュレータは役立ちますが、イベントペイロードを少し間違えるだけで本番でしか動かない機能（IAMルール、マネージドトリガー、ベンダー固有のログ）に頼ることがあり、結局クラウド環境でテストすることになります。分散したリクエストをローカルで安定して再現できないこともあります。

例：APIが注文を作り、カードを決済し、レシートを送るフローを考えてみてください。Kubernetesでは支払いやメッセージングの依存をローカルで動かすためのネットワークと設定に苦労するかもしれません。サーバーレスではイベント形状や権限周りで正しい関数チェーンをトリガーするのが難しいかもしれません。

フィードバックループを短く保つ

どちらのアプローチでも予測可能に感じられるローカルワークフローを目指してください：

• APIと依存関係、テストデータを1コマンドで立ち上げる
• 設定を一貫させる（同じ環境変数名、同じデフォルト）
• 外部連携はデフォルトでモックし、必要なときだけ実際の連携に切り替える（決済、メール、SMS）
• ビジネスロジックは関数ハンドラやKubernetesの配線なしでユニットテストできるプレーンなモジュールに置く
• デバッグ用の繰り返し可能な「ゴールデン」リクエスト（ユーザー作成、注文作成、返金）を少数持つ

ローカルループが速ければ、Kubernetesとサーバーレスの議論は感情的になりにくく、日々の生産性コストが軽くなります。

可観測性：日常のデバッグと監視

良い可観測性とは、何が壊れているか、どこが壊れているか、なぜ壊れたかを素早く答えられることです。そのために必要なのはログ（何が起きたか）、メトリクス（どれくらい頻度があり遅いか）、トレース（単一リクエストがどのようにサービスを渡ったか）です。接着剤は相関IDで、通常はリクエストIDがすべてのホップを通じて追跡されます。

Kubernetes：一貫した配管が役立つ

長寿命のサービスでは、Kubernetesは予測可能な監視を作りやすくします。エージェントやサイドカー、標準的なネットワーク経路があるため、多数のサービスにわたりログ、メトリクス、トレースを一貫して収集できます。ポッドが単一リクエストより長く生きるため、デバッガをアタッチしたりプロファイルを取ったり、挙動を時間で比較することが容易です。

Kubernetesとサーバーレスを比べると日常的な現実はこうなりがちです：Kubernetesの環境の方が安定しているため、ツールや前提が壊れにくい。

サーバーレス：1呼び出しごとの詳細は良いが、エンドツーエンドが難しいことも

サーバーレスプラットフォームは通常、呼び出しごとのログと基本的なメトリクスを見やすくします。問題は、1つのリクエストが複数の関数、キュー、サードパーティAPIに触れるときです。相関IDを全てに渡さないとコンテキストが失われます。トレースはプラットフォームのデフォルトで制約を受けやすく、サンプリングの影響で実際の頻度を誤解することがあります。

ログ量もよくある驚きです。スパイクは呼び出し回数を増やし、ノイジーなログが請求を増やします。

両者で機能する実践的なベースライン：

• 構造化ログ（JSON）を使い、request_id、user_id（安全なら）、service/function名を含める
• いくつかの主要なメトリクスを出す：リクエスト数、エラー率、p95レイテンシ、リトライ数
• 主要なAPIパスと重要依存（DB、決済、メッセージング）のトレースを追加する
• ダッシュボードをいくつか持つ：全体の健全性、依存の健全性、遅いエンドポイント上位
• アラートは原因ではなく症状（エラー率、レイテンシ）で出す

例：チェックアウトが在庫、支払い、メールを呼ぶなら、1つのリクエストIDで完全なトレースと全ログを数分で引けることが理想です。

スケーリングの振る舞い：スパイク、制限、ボトルネック

スパイキートラフィックでは、スケーリングは見出し機能より「どれくらい速く反応するか」「何を拒否するか」「何が最初に壊れるか」が重要です。Kubernetesとサーバーレスはどちらもバーストを扱えますが、壊れ方が異なります。

サーバーレスは突然のバーストを吸収しやすいことが多いですが、強いスロットリング制限に当たることがあります。プロバイダは同時実行インスタンス数に上限を設けており、アカウントやリージョンのクォータに達することもあります。そのラインを越えるとリクエストがキュー化されたり遅くなったり拒否されたりします。立ち上がりは速いが即座ではありません。

Kubernetesのスケーリングは一度動き出すと滑らかですが、動く部品が多いです。ポッドはスケジュールされ、イメージをプルし、readinessチェックを通る必要があります。クラスターに予備のキャパシティがない場合、ノード追加を待つことになり、10秒のスパイクが数分の問題に変わることがあります。

比較すべき典型的な上限：

• サーバーレス：関数の同時実行上限、1秒あたりのリクエスト上限、下流の接続数制限
• Kubernetes：ポッドの起動時間、ノード容量、オートスケーラの反応時間
• 両者共通：データベース接続、サードパーティのレート制限、キューの深さ

状態管理は静かな制約です。APIハンドラはステートレスにすることを前提とし、状態はデータベース、キャッシュ、オブジェクトストレージに移すべきです。スパイク時にはキューが安全弁になることが多い：リクエストを素早く受け入れてキューに入れ、一定速度で処理する。

例：プロモーションでログインやWebhookトラフィックが50倍になると、コンピュートはスケールできても、ボトルネックはデータベース（接続数）や支払いプロバイダのレート制限であることが多いです。まず下流の限界を監視してください。コンピュートのスケーリングではそれらを直せません。

選び方：ステップバイステップの意思決定プロセス

Kubernetesとサーバーレスの間で迷っているなら、ツール論ではなくプロダクト判断で選んでください。ユーザーが何を感じ、チームが深夜2時に何をサポートできるかから始めます。

まず、計測できる事実を集める：

1. トラフィックパターンを測る：ベースラインRPS、ピークRPS、スパイクの長さ。30秒のスパイクと2時間のサージは全く違います。
2. レイテンシとエラーのSLOをp95とp99で書き出す。API中心ではテールレイテンシがユーザー向けの障害になりやすいです。
3. 各リクエストが触る依存を列挙する：データベース、キャッシュ、認証、決済、メッセージング、サードパーティAPI、AI呼び出し。これでコールドスタートや接続制限がどこで問題になるか見えます。

次に、金銭的と運用コストをモデル化し、テストします：

1. 実際のコストドライバーで簡単なスプレッドシートを作る。サーバーレスならリクエスト数、実行時間、メモリ、ネットワーキングやゲートウェイ費用。Kubernetesなら常時稼働のノード、オートスケールの余裕、ロードバランサー、データベース容量。
2. 代表的なエンドポイントやジョブでパイロットを作る。p95/p99レイテンシ、エラー率、月額コスト、オンコールのノイズ（アラート、リトライ、タイムアウト）を比較する。
3. ハイブリッドが最適か検討する：安定したコアAPIはKubernetes、バーストやcron、Webhook、ワンオフのバックフィルはサーバーレス、という組合せがよく効きます。

例：顧客ポータルはログインやアカウントAPIのベースラインが安定している一方、請求Webhookがバーストするなら、コアAPIをKubernetesに置いてテールレイテンシを守り、Webhook処理をサーバーレスで捌いてアイドル時のコストを抑える設計が考えられます。

サプライズ請求や障害を招くよくある間違い

最大の罠は「マネージドだから自動的に安い」と考えることです。サーバーレスでは請求が見えづらい場所に移ることがあります：チャッティなログ、高カーディナリティのメトリクス、関数間のデータ転送。小さなスパイクが各リクエストで大きなログを書き込むだけで請求を大きくします。

コールドスタートも本番で初めて気付く典型的な驚きです。ウォームな環境でしかテストしていないと、本番ではランダムに2〜10秒のリクエストやリトライが発生し、クライアント側で積極的なリトライロジックが組まれていると状況が悪化します。

Kubernetesの失敗はしばしば早計に過剰な構築をしてしまうことが原因です。小さなチームがクラスタ、Ingress、オートスケールルール、シークレット管理、CI/CD、アップグレードを運用する羽目になり、プロダクトのトラフィックが安定する前に保守負荷が増えます。部品が増えると真夜中に壊れる理由も増えます。

よく見かける間違い：

• 関数やポッドをステートフルに扱う（ローカルディスク書き込み、メモリキャッシュ依存、スティッキーセッション）
• エンドツーエンドのリクエストIDを出していないため、遅い呼び出しの原因特定が困難
• テレメトリを取りすぎて監視がノイジーかつ高コストになる
• 上限やバックプレッシャーを明確にしていないため、スパイクがデータベースへの大群衝撃につながる

簡単な例：モバイルアプリの9時の毎日のバーストで、各リクエストがそれぞれフルペイロードをログに書く3つの関数を呼ぶと、コストが急増し、コールドスタートがレイテンシを悪化させます。

コミットする前のチェックリスト

Kubernetesとサーバーレスの決定は、最初のスパイクや請求、障害が出るまでは明白に見えないことが多いです。本番に近いワークロードで両方を耐圧テストしてください。

数字で検証できる答えを書き出しましょう：

• コスト： 上位3つのコストドライバーとそれらがスパイク時にどう増えるかを特定する。平均ではなく最悪ケースの月を見積もる。
• パフォーマンス： スパイク型の負荷試験でp95とp99を確認する。ウォームパスとコールドパス、DBやサードパーティなどの依存を含める。
• 信頼性： タイムアウト、リトライ、レート制限が末端まで確認できているか。リトライで重複請求（重複課金）などが起きないようにする。
• 開発速度： 新しい開発者が30分以内に現実的な設定とテストデータでシステムをローカル起動できるか。できないなら障害対応が遅くなる。
• 可観測性： 1つのユーザーリクエストをAPIゲートウェイ、関数/ポッド、キュー、DBまでトレースできるか。ログが検索可能で、メトリクスが「何が変わったか」を答えられるか。

運用の責任範囲を明確にしてください。アップグレード、セキュリティパッチ、証明書のローテーション、深夜のインシデント対応は誰がやるのか？「誰かがやらなければならない」タスクをリストアップして、コミット前に名前を割り当てるだけでリスクが見えます。

例シナリオと実践的な次の一歩

想像してみてください：経理チームが使う管理APIを持つSaaS。普段は閑散としているが、給与日や月末には30分で利用が20倍に跳ね上がる。トラフィックはAPI中心で、レポートの大量読み取りと背景ジョブをトリガーする書き込みが混在しています。

Kubernetesでは、そのスパイクでオートスケーリングが動きます。Horizontal Pod Autoscalerが適切にチューニングされていれば、新しいポッドが立ち上がりAPIは応答を保てます。驚きは多くの場合コンピュート以外にあります。データベースが先に飽和（接続、CPU、I/O）し、APIが遅く見えることが多いです。クラスターに空き容量がなければノード追加の遅延が発生します。

サーバーレスでは、プラットフォームが多数の関数インスタンスを短時間で作成してバーストを吸収しようとします。短く不均一な需要には向いていますが、同時実行の急増やコールドスタートの鋭いエッジに当たることがあります。何百ものインスタンスが同時に立ち上がると最初のリクエストが遅くなり、データベースへの接続が大量に発生してしまう恐れがあります。

多くのチームで現実的な結論はハイブリッドです：

• 認証や社内管理APIなどの長寿命サービスはKubernetesで運用する
• Webhookやレポートエクスポート、ファイル処理のようなスパイクしやすく孤立したエンドポイントはサーバーレスで扱う
• 両方でDBプーリング、キャッシュ、厳格なレートリミットでデータベースを保護する

迅速に決着をつける実践手順：

1. 代表的なエンドポイントを1つ選ぶ（例：「月次レポートを生成」）。
2. 同じDBと同じペイロードサイズで両方の実装を作る。
3. 静かな時間とピーク時間で負荷試験を行い、p95レイテンシ、エラー率、総コストを記録する。
4. ガードレールを追加する：最大同時実行（サーバーレス）、最大レプリカ数（Kubernetes）、DB接続上限など。
5. 一般的なベンチマークではなく自分たちの数字で判断する。

アプリケーション側の作業を早めたいなら、AppMaster (appmaster.io) はビジュアルなブロックから本番対応のバックエンド、Webアプリ、ネイティブモバイルアプリを生成できるため、パイロットをワークロードの挙動に集中させ、スキャフォールドや接着コードに時間を使わずに済みます。