構築中。

名古屋のITインフラお守り係です。ITイベントへの参加記録などを残していきます。

本の紹介/Amazon Web Services負荷試験入門

もうかなり前に発売された本なので、いまさらですが…

gihyo.jp

発売とほぼ同時に入手したものの、通勤時間を中心に読んでいたら、読み終えるまでに意外と時間が掛かってしまいました。

これ以外の負荷試験本を読んだことがないので他との比較はできないのですが、狭い意味での「負荷試験」の正しいやり方を理解する上ではとても良い本だと思います。

たまたま後で知ったのですが、職場の後輩もほぼ同じタイミングで購入して読み始めていて、「わかりやすいて良い」と言っていました。

 

ただ、私としては、「限界を把握した上で様々な対処を考える」「意図通りスケールすることを確認する」という目的ではなく、「実環境で問題が出ない構成であることを確認する」目的では、少し足りていない部分があると感じています。

というのも、この本では、しきりに「攻撃サーバは負荷試験対象のシステムのすぐそばに配置する」ことを強調しており、それはこの本の文脈の上では正しいのですが、「実環境で問題が出ない」ことの確認にはかえって逆効果になることもあるからです。

クライアントは、接続してくる場所や回線の種類によってレイテンシがかなり変わります。モバイルであれば特にレイテンシは大きくなります。そこで問題になるのは、大きく言うと2点。

 

・回線まで含めるとシステムの性能が十分出ない→ユーザにとって「もっさり」した「使いにくい」システムになっている可能性がある

・クライアントからの通信のレイテンシの変化により、システムの個々の要素が必要とするリソースの量や配分が変化する可能性がある

 

前者は、割とイメージしやすいと思いますが、「アプリケーションを含むシステム内部の性能は十分だったが、外部回線(インターネット)経由で利用したらレイテンシが大きくなり過ぎて動作が「カクカク」ぎこちなくなってしまうようなケースです。

「同時利用ユーザが少ないうちは問題がなかったが、増えてきたらそのような現象が発生するようになってしまった」という事象が考えられますが、これについては「回線分のレイテンシを上乗せして、性能が十分か」をある程度シミュレーションできますしそれを思いつくことも容易なので、そんなに問題ではないと思います。

※「レイテンシが大きくなって実質的な帯域が制限されてしまい、結果としてユーザが使いづらくなる」ケースはもう少し注意が必要です(机上計算でシミュレーションは可能ですが)。TCPのウィンドウ制御と同じような、レイテンシが帯域に制限を与えにくい仕組みをより上位のレイヤに実装しないといけなくなる(あるいはTCPのウィンドウ制御を生かす実装にしないといけない)可能性がありますので。

 

問題は後者です。「システムの個々の要素に最大の負荷を与えて限界を確認しておけば大丈夫」だと思いがちですが、例えばロードバランサ/リバースプロキシのクライアント側コネクション/セッションの同時利用数は、接続クライアントの数と接続間隔が同じなら(rpsが同じなら)、クライアントとの通信が遅いほど多くなります。

システムの構成、例えば使用するミドルウェアの種類や設定、あるいはアプリケーションの処理方法によっては、より「後方」の部分(DB、ストレージ側)の必要コネクション数に影響を与える可能性があります。

ELB(ALB・CLB)を使えばコネクション数など気にしなくても良さそうに思えますが、同時コネクション数が変わればELBがスケールするタイミングに影響を与えますし(暖機申請の要否などに影響)、適切なタイムアウト時間設定値も変わってくる可能性があります(ELBを調整したら、接続先のWebサーバのコネクション数やタイムアウト時間、場合によってはOSで設定する利用可能ポート番号範囲やタイムアウト時間などの調整まで必要になることもあります)。

クラウドだからといってこの点を軽く見ると、痛い目にあいます(実際、過去にあいました!)。

※「クラウド環境なので意図通りスケールすればそこは問題にならない」と考えられているのかもしれませんが。実際は、そんなにお行儀の良いアプリが走っているとは限らないので、コトはそれほど簡単ではありませんし、仮に障害なくスケールしたとしても、「意図通り」のスケールではないはずです(リソースの無駄遣いになったり、とか)。

 

というわけで、この点について明確に触れていない点がとても気になりました(Chapter 5の外部システム連携の話で、せっかく近いところに触れているのに…)。

特に、(経験の浅い)後輩が「わかりやすい」と言って読んでいたので、そのような前提知識を持たない人がこの本だけ読んで「正しいやり方」を「完全に把握した気」になって痛い目にあわなければいいのですが。

とりわけ、レガシーシステムを「とりあえず一旦EC2中心の構成でAWSに持ってくる」ケースなどにハマりそうです…。

 

…と、なんだかけなしているように受け取られそうですが、この点を除けば(あともう1つ、負荷試験なのに「CPU使用率」について深く突っ込んでない点…といってもあまり深く突っ込むとページ数が増える上にかえって読者が混乱しそうですし、クラウドだからスケールする前提で「こまけぇこたぁいいんだよ!」かもしれませんが)、非常に参考になる本だと思います。

 

参考情報:

yakst.com