このブログは Google Cloud Japan Advent Calendar 2025 10日目の記事です。
開発者の皆さん、こんにちは。
冒頭の歌にあるような経験、Google Cloud を使っていて遭遇したことはありませんか？
機能開発もテストも完璧、デプロイパイプラインも整備した。さあリリースだ！という段になって、Google Cloud の Quota（割り当て） 上限に引っかかり、サービスが起動しない、あるいはスケールしないという悲劇。
今回は、そんな悲しい事故を防ぐために、Google Cloud でサービスをリリースする前に必ずやっておくべき「負荷試験」と「Quota管理」についてお話しします。
リリース前の負荷試験の重要性
「オートスケーリングを設定しているから、ユーザーが来ても勝手にスケールしてくれるはず」と安心してしまうことはありませんか？
確かに Google Cloud のオートスケーリングは強力ですが、設定されたリソースの範囲内で動作するものです。急激なスパイクに対しては、スケーリングが追いつくまでに時間がかかったり、そもそもプロジェクトの Quota 上限に達してスケールできなかったりする可能性があります。
リリース前に負荷試験を行うことは、以下の点を確認するために不可欠です。
- システムの限界を知る: 現在の構成でどれくらいのトラフィックまで捌けるのか。
- ボトルネックの特定: CPUなのか、メモリなのか、DBのコネクション数なのか、あるいは外部APIのレートリミットなのか。
- Quotaの確認: 想定されるピークトラフィック時に、クラウドのリソース制限（Quota）に達しないか。
Google Cloud 推奨の負荷テスト方法
Google Cloud では、効果的な負荷試験を行うためのベストプラクティスやツールがいくつか推奨されています。
1. 段階的なテスト計画
いきなり本番相当の負荷をかけるのではなく、小さな負荷から始めて徐々に上げていく「ステップアップテスト」が推奨されています。
これにより、システムがどの段階で不安定になるかを正確に把握できます。
2. 推奨ツール
- OSSツール: JMeter, K6, Locust など、使い慣れたツールを GKE や Compute Engine 上で動かすのが一般的です。
- 分散負荷試験: 単一のマシンからの負荷では限界があるため、分散負荷試験の構成を組むことが重要です。Google Cloud には Distributed Load Testing on Google Cloud というソリューションガイドもあり、GKE と Locust を使った構築例などが紹介されています。
3. 実施時の注意点
- Quotaの事前確認: テスト自体が大量のリソース（負荷をかける側のVMなど）を消費するため、テスト環境のQuotaも確認が必要です。
- 本番環境への影響: 可能であれば本番とは隔離された環境で行うのがベストですが、本番環境で行う場合はユーザーへの影響が出ないよう細心の注意を払いましょう。
- 申請は不要: Google Cloud では、自身のプロジェクトに対する負荷試験を行う際に、Google への事前申請は原則として不要です（ただし、Acceptable Use Policy は遵守する必要があります）。
実践：GKE での Quota 枯渇シナリオ
ここで、Google Kubernetes Engine (GKE) を使った、よくある「落とし穴」の例を見てみましょう。
シナリオ:
あなたは新しいキャンペーンサイトを GKE 上に構築しました。
予想されるトラフィックに合わせて、Horizontal Pod Autoscaler (HPA) を設定し、Pod が負荷に応じて増えるようにしました。また、Cluster Autoscaler も有効にしており、Pod が増えてノードが足りなくなったら、自動でノード（VM）が追加される構成です。
何が起きたか？
キャンペーン開始直後、アクセスが急増しました。
- HPA が検知し、Pod のレプリカ数を増やそうとします。
- 既存のノードに空きがないため、Pod は Pending 状態になります。
- Cluster Autoscaler が動き出し、新しいノードを追加しようとします。
- ここでエラー発生！ 新しいノードが立ち上がりません。
原因:
Google Cloud コンソールのログを見ると、以下のようなエラーが出ていました。
Quota 'CPUS' exceeded. Limit: 24.0 in region asia-northeast1.
なんと、プロジェクトのリージョンごとの CPU コア数の割り当て上限（Quota）に達してしまっていたのです。
オートスケーリングの設定は正しくても、それを支えるインフラの「枠」が足りなければ、スケールすることはできません。
他にも、In-use IP addresses（外部 IP アドレスの数）の上限に引っかかるケースも非常に多いです。
Quota Increase Request (QIR) の行い方
負荷試験の結果、あるいは見積もりの段階で「今のQuotaでは足りない」と分かったら、すぐに Quota Increase Request (QIR: 上限緩和申請) を行いましょう。
Google Cloud コンソールからの申請手順は非常に簡単です。
- [IAM と管理] > [割り当て] ページに移動します。
- フィルタを使って、緩和したいリソース（例:
CPUs,N2 CPUs,Persistent Disk SSDなど）とリージョンを特定します。 - 対象の割り当てのチェックボックスをオンにし、ページ上部の [割り当てを編集] をクリックします。
- 新しい上限値を入力し、リクエストの説明（例: 「来週のサービスローンチに伴う負荷増大のため」など）を記入して送信します。
ポイント
- 自動承認: 少量の増加であれば、システムによって即座に自動承認されることが多いです。「気軽に申請OK」なのはこのためです。
- 早めの申請: 大幅な増加が必要な場合は、Google のサポートチームによる審査が入るため、数日かかることがあります。リリース直前ではなく、余裕を持って申請しましょう。
- API Request Count: VMの数だけでなく、APIの呼び出し回数（Rate Limit）もQuotaの一種です。こちらも忘れずにチェックしましょう。
まとめ
サービスをリリースするときは、コードの品質と同じくらい、インフラの「容量」にも気を配る必要があります。
適切な負荷試験で必要量を見極め、早めにQuota緩和申請を行うこと。
これが、スムーズなリリースと、その後の安眠を守るための鍵です。
Discussion