今日もWEB負荷テスト：ツールがあればいいってものでもない！

昨年に引き続き、今日もWEB負荷テストの依頼を受け、データセンターに籠もっていました。夏はデータセンターに入ると涼しいのですが、冬は寒いだけです・・・。

例によって、VM（仮想マシン）を20個起動し、背景負荷を生成し、別のPCで測定を行います。WEB負荷テストツールのSADEE2を開発した頃は、VMは一般的にはほとんど使われてませんでしたので、複数のVMでテストを行う際に便利なコントロール機能などはなく、手動でコントロールするので、まずはターミナルをたくさん並べます。。

こんな状態のPCを2台用意して、テストを行いました。

ここまでやるなら、統合管理ができる機能を作っても良いのですが、実はテストの要求がとても細かく、そう簡単にコントロールできるようなインターフェースは作れそうにありません。先にツールがどういう機能を持っているかを知った上でテストの仕様を考えれば良いのですが、お客さんはツールがどうこうではなく、単に希望のテストを実行し、結果が得たいだけです。

そんなことを書いていたら、昔、SADEE2でWEB負荷分散装置が存在する構成での試験で上手く行かなかったことを思い出しました。当時のSADEE2は、テストを行う際に、HTTPのヘッダ部を、細切れにして送信していたのです。テストを行う際には、Cookieをはじめとしてヘッダの加工が必要で、いったんバッファリングするより、そのまま送る方が楽ですし、処理も軽いだろうと思っていたのですが、WEB負荷分散装置は、ヘッダ部がまとめて得られないと、TCPのACKを返してくれず、そのまま捨てるような動きをしていました（設定によるようですが）。パケットをキャプチャして、お客さんに「TCPの仕様として、ACKも返さずに捨てるというのはおかしい」と説明したのですが、お客さんからは、「TCPの仕様など関係ない。ブラウザからだと普通に動くのだから、それと同じような試験をしたいだけだ」と冷たく言われました。まあ、今思えばその通りなのですが、慌てて修正して対応したのを思い出します。

最近は、自分でパケットを直接扱うようなシステムをいろいろと作っていますので、WEB負荷分散装置がヘッダがまとめて得られないときに捨てたくなる気持ちも良く理解できます。捨てればTCPの再送機能により、3秒後くらいにまとめてリトライされるので、都合よく受信できるのです。もっとも、私は当時、嫌な思いをしたので、そんな作りにはしませんが。。

話しが脱線しましたが、テストトールを使えば負荷テストは簡単、というわけではないのです。テストツールの機能をどう使えばテストの要求を実現できるかを、ほとんどその場で考えて実行しなければならず、SADEE2を使えるメンバーは当社にたくさんいますが、試験対象のシステムを多少理解していて、ネットワークに詳しく、その場でツールを自作してでもなんとかできるスキルが必要なので、結局私が毎回自分で対応しています。本当は開発している側が自分で日頃からツールを使い、常に確認しながら開発を進めるのが一番なのですけどね・・・。