昔のプログラミングでは無駄なループでタイミング調整をしたっけ

小俣さんが負荷ブログについて書いていらっしゃいます。私も開発に携わっていた際には負荷テストが好きでした。簡単に思いのほどを書きたいと思います。

負荷テストというとシナリオですが、どのようなシナリオを描けばよいでしょうか。まずはお客様の絵描く利用シーンに合わせたシナリオが思い浮かびます。それに加えて技術者の視点から「こういう事態も発生するはずでは」というようなところを加えていくと良いでしょう。

例えば最近ではスマートフォンの利用率が上がっています。業務系でもインターネットVPNを介して末端にスマートフォンがぶら下がる構成があるかもしれません。PCですと「圏外」ということがあり得ませんのでだいたいの利用シナリオというのは描けますが、スマートフォンだと地下鉄の駅と駅の間をまたいでの接続ということもありそうです。セッションを長く維持しなくてはいけないとか、再接続が多いのでセッションのゴミがたまりやすいとか、そんな特徴があるかもしれません。

学生さん向けのシステムですと講義と講義の間だったり、講義の真っ最中だったりにピークが来たりしますし、会社のシステムでも全社で決まった時刻に朝礼や休憩を取る習慣があるとその最中か前後にピークが来たりします。食堂で例えれば「相撲取りが押し寄せる」状態だけでなくコーヒー1杯で長時間ねばる人、食事を残す人、離席して用事を済ませて戻ってくる人、等々考えなくてはなりません。相撲取りが押し寄せてきてもチャーハン1杯作るのも10杯作るのも意外と変わらなかったりします。それよりは女性が10人来て少しずつ食べたいから10通りの料理を注文されたほうが店が忙しくなるかもしれません。

また、全体が組みあがった所で「高負荷時にこの画面が何秒以内に」というシナリオを検証しても良いのですが、そこで全然ダメだとパーツに分解しながら後退を繰り返さなくてはなりません。可能ならばある程度まとまったところでプチ負荷テストを繰り返していけると良いと思います。特にWeb系のシステムではブラウザからの負荷をかけるのに何らかのツールを必要とする場合が多いです。ツールは無料のものもありますが高価なものもありますので、共有資産になっていることもあります。となるとやってみてダメだった場合にトラブルシューティングに時間がかかると別の部署が持っていってしまうということもあります。ブラウザからの負荷を検証する前にサブシナリオを作り、自分自身の手で検証できるところをチェックするのがやりやすいと思います。

更にIPS/IDSやロードバランサーなどいかにも悪さをしそうな機器がある場合には表からの負荷もチェックしたいところです。こういった機器は設定を少し変えると影響が大きいのですが、設定画面のインターフェースがわかりやすいこともあり、「負荷が大きくなるように設定して検証しておけば安心だろう」という軽い気持ちで設定を変更したくもなります。また、実際に負荷試験ツールとの相性で一時的に設定変更せざるを得ない場合もあります。しかしテスト用のセッティングのままで本番を迎えるということがないよう注意が必要です。

負荷テストというと「●●で何分間の負荷をかける」といったシナリオをクリアすることが目標になってしまいがちです。時間や資源の制約の中でそれがゴールになることも多々あると思われますが、良いものを作る思いがあるならばそこをスタートラインとして、資源を見ながら「シナリオのどこを変えると何が変化するのか」というのも見極めたいところです。

好きな人にとっては非常に楽しい作業ですので開発の全体のバランスを見失うほどのめりこんでしまう危険もあります。自転車の整備をするときにブレーキ、チェーン、ギアあたりをいじっていたら2時間くらいが一瞬で過ぎてしまったという経験がある方は危ないかもしれません。しかしプログラミングで大切なことはこのあたりの作業にのめりこんでいた間に学べたように感じます。

昔のPC-98でゲームを作る際にはシューティングにせよパズルにせよスピードを調整するのに初級者でも簡単にできるというやり方がなく、様々な処理の間にまったく無駄なループを回すという構造でした。（高度なやり方はいくらでもあったのでしょうが）自らボトルネックを作っていくという作業をしつつ、そのゲームで遊んでいるとキャラの動きで「たぶんあのへんだな」と見当をつけてループの回数を増減させることができたものです。ほんのわずかな挙動の違いからボトルネックの見当をつける能力というのはゲーム作りの経験が活かせるところかもしれません。