はじめまして、コロナ太りと戦う「S」と申します。
よろしくおねがいします！！
今回はGCP上に構築したWebサーバにJmeterで負荷試験を行った体験談をお伝えしたいと思います。
JmeterもGCP上に構築しましたので、負荷試験環境を作る際の参考にもなりましたら幸いです。
大まかな構成はこちら。非常にシンプルな構成です。
WebサーバはLinux＋Apache＋PHPで構築しています。
JmeterのWindowsServerはGUIでテストシナリオを作成するためWindowsで、実際に負荷をかけるPrimaryServer及びSecondaryServerはLinuxで構築しています。
外部IPはCloud LoadBalancing（以下LB）にのみ設定します。Cloud NATの外部IPは一時的な外部IP（エフェメラル外部IP）を、Google Compute Engine（以下GCE）、Cloud SQLは内部IPのみの設定です。
WindowsServerでテストシナリオを作成し、正常なリクエストが返ってくることを確認してから本格的に試験を開始します。負荷試験を進める中で詰まった点を3点紹介します。
◇詰まった点その１：Webサーバのログに記録されるソースIPアドレス
Webサーバのログに記録されるソースIPアドレスがLBのIPアドレスになり、どこからのアクセスか判別できませんでした。（LBに設定した静的外部IPではなく、LBで使用されるアドレス帯のIPアドレスが記録されました）
Webサーバで使用しているApacheの設定ファイル（httpd.conf）でLogFormatに「X-Fowrarded-For」を追加し、アクセス元のIPアドレスがWebサーバのログに記録されるようになりました。（今回の負荷試験環境ではCloud NATのIPアドレスが記録されます）
◇詰まった点その２：Jmeterからの同時接続数
Jmeterからの同時接続数が一定数から増えない事象が発生しました。
Webサーバ側でコネクション数が増えていないので、Webサーバより手前の問題として調査しました。結果的にCloud NATの設定でVMごとの接続数の上限にかかっていることが分かりました。
この「VMインスタンスあたりの最小ポート数」を超えるコネクションは無条件で遮断されてしまいます。デフォルト値は「64」なので、テストシナリオに応じて変更しましょう。
VMインスタンス当たりの最小ポート数の設定は、環境の拡張時などに影響する場合がありますので、定期的に見直すことをお勧めします。
◇詰まった点その３：ボトルネックの調査
負荷試験中にレイテンシが遅くなる事象が発生しました。
GCP標準のモニタリングツール（Cloud OperationsのMonitoring）の標準設定で収集可能な指標を確認しましたが、GCEやCloud SQLのリソース使用状況はそれほど高くありませんでした。また、LBのバックエンドレイテンシがJmeterのログのスループットと同程度の時間でしたので、バックエンド側の問題と分かりました。
GCEやCloud SQLのリソースがひっ迫していない状態でも求める応答速度に満たない場合、オンプレミス環境と同じようにミドルウェアレベルでの調査が必要です。
Webサーバのログ、Cloud SQLのログを確認した結果、Webサーバでの処理時間が長いところまでは分かりましたが、原因がWebサーバなのかCloud SQLなのかまでは切り分けられませんでした。（Cloud SQLのログはCloud OperationsのLoggingで確認）
Cloud SQLのクエリ時間が分からないものかと思い調べたところ、「–slow_query_log」と言うオプション設定があり、設定した時間を超えたクエリのログが出力されるようになります。
これでCloud SQLのクエリ時間が長かったことが分かり、Cloud SQLのスケールアップすることでレイテンシが改善しました。
Cloud SQLのクエリログですが、切り分けを行う上では有用です。ただし、ログを出し続けるとログのサイズが増え、使用料に影響する可能性がありますので、問題発生時に切り分けしやすくするか使用料を抑えるかの検討が必要になります。
このように、標準設定では解決できない事象が多々発生しますので、初めて触るサービスについては公式ドキュメントなどで情報収集することをお勧めします。
GCP（パブリッククラウド）で負荷試験を行った感想として、プロジェクトは分けましたが同一リージョン間で負荷試験を行ったため、遅延はほとんど感じませんでした。
また、リソースを自由に変更できるので、設定の問題かリソースの問題かの切り分けが簡単に行えたのが良かったです。その他、LBのバックエンドインスタンスグループを切り替えることで、他の設定を変更せずに負荷試験対象のWebサーバを切り替えられる点はクラウドならではと思います。Jmeter環境では、1クライアントからの大量アクセスと複数クライアントからの同時アクセスのようなパターンの異なるアクセスをGCEのスケールアップ、スケールアウトで容易に実現できた点が便利でした。また、負荷試験終了後に永続ディスクを残しておくことで、低コストで環境を維持できる点も良いと思います。
クラウドでマネージドサービスを利用する場合、ブラックボックスな部分も多いためオンプレミスより難しい点が増えると思います。この記事がお役に立ちましたら幸いです。
最後までお読み頂きましてありがとうございました！
