AppEngineに対する負荷テストの失敗から学んだこと
結論
AppEngineに対する負荷テストを行う際は、AppEngineが発行するエンドポイントに対して行いましょう。
失敗から学んだこと
対象のAppEngineは、前段にCloud Load BalancerとCloud CDNが設置されている構成です。
対象のエンドポイントはキャッシュをしないエンドポイントであるため、何も考えずCloud CDNのエンドポイントに対して負荷をかけていました。はじめは何も問題がありませんでしたが、秒間のリクエスト数が10を超えたあたりから、急激にレイテンシが大きくなり始めました。
1リクエスト/秒
5リクエスト/秒
10リクエスト/秒
問題の切り分けのために、Cloud Load BalancerのIPアドレスとAppEngineのエンドポイントに対してもそれぞれ負荷をかけてみたところ、Cloud Load BalancerはCloud CDNと同様の結果でしたが、AppEngineはレイテンシが上がることはありませんでした。このことから、Cloud Load Balancerがボトルネックになっていると推測しました。
Cloud Load Balancerのドキュメントを見てみると、以下の記述が見つかりました。
Google Cloud プロキシベース外部ロードバランサはすべて、Google の本番環境インフラストラクチャの一部である Google Front End（GFE）から DDoS 保護を自動的に継承します。
こちらがGFEの説明です。
GFE の背後で動作しているサービスに対する DoS の影響のリスクを大幅に低減するマルチティアでマルチレイヤの DoS 防御が施されています。
今回のケースでは、に単一のホストから負荷をかけていたため、ある程度の段階で不正なリクエストであると判断され、スロットルされたものと考えられます。
ではAppEngineはこのような防衛機能はないのかなと思い調べたところ、こちらはAppEngineのファイアウォールで設定をするか、もしくは本記事の構成のようにCloud Load Balancerを前段に配置する構成にする、というポリシーのようです。
Cloud Load Balancerを使うことで、GFE、つまりGoogleのインフラストラクチャの防衛機能の恩恵を受けられるというのは非常に心強いですね！
Discussion