オートスケールを設定していたのに、クォータという壁に当日まで気づかなかった。
大規模なキャンペーンを控え、GKEのHPA(水平Pod自動スケーリング)とCluster Autoscalerを設定して臨んだ。事前に負荷試験も実施して問題がないことを確認した。キャンペーン当日、想定通りトラフィックが急増した。HPAがPodのスケールアウトを開始した。しかしPodがなかなか起動しない。「Insufficient cpu」というPending状態のPodが増え続け、エラーレートが急上昇した。
GKEのCluster AutoscalerがノードのスケールアウトをCompute Engineに要求したが、そこでブロックされていた。GCPにはプロジェクト単位でvCPUの総数に上限(クォータ)が設定されており、そのクォータに達してしまい新しいノードを追加できなくなっていた。Cluster Autoscalerがノードをスケールアウトしようとするたびに「QUOTA_EXCEEDED」のエラーが返され、Podはずっとペンディングのまま積み上がり続けた。
事前の負荷試験では想定最大同時接続数の半分程度でしか試していなかった。その規模ではvCPUクォータの上限に達しなかった。本番のキャンペーンでは予想を上回るトラフィックが来て、必要なvCPU数がクォータを超えた。GCPのvCPUクォータはデフォルトでかなり保守的な値に設定されている。それ以上使いたい場合はGCPサポートにクォータ引き上げを申請する必要があり、申請から承認まで数時間〜数日かかることもある。当日に緊急申請したが承認が来たのはキャンペーンが終わってからだった。
緊急対応として非重要なバックグラウンド処理のPodを手動でスケールダウンし、そのvCPUをWebサービスのPodに回すことで乗り切った。エンジニア全員が対応に追われ、当日の数時間は緊張が続いた。事後にクォータの引き上げ申請をして翌日には承認された。教訓は「スケールアウトの最大値からクォータ必要量を計算する」こと。ピーク時に必要なノード数とvCPU数を計算して現在のクォータと比較する。大きなイベントの1〜2週間前にはクォータを確認して、不足していれば事前申請する。GCPコンソールの「IAMと管理 > クォータ」から現在の使用量と上限が確認でき、申請もそこから行える。これを怠ったことを強く後悔した。