こういう本が出ているのご存知ですか？
AWS環境におけるWebサーバの負荷試験測定についてケーススタディ方式と技術説明をうまく織り交ぜて、負荷測定のイロハを非常に詳しく説明した本です。
話の基本は、負荷測定とはなんぞや？という話から、ツールとして紹介しているのが、
Apache Bench（ab）
Apache JMeter
Locust （Pythonでシナリオ記述ができる負荷測定ツール）
Tsung （Erlangで書かれたツール）
その他、XHProf、NewRelic、Cloud Watchなども活用した負荷測定のテクニックが解説されていたり、PHPやNode.jsなどの個別の処理系の問題への踏み込みもしていたり、MySQLやAurora、memeche等のミドルウエアへの言及、外部APIへのアクセスへの考慮など、ツールの使い方や表面的な負荷検査だけではなく、Webサービスで実際に使っている環境での実践的なレベルまで踏み込んでいるのが特徴です。
abなどの負荷測定ツールを使ったことがある人は多いかもしれませんが、そこに書かれているパラメータが何を示しているのか？がイマイチ自信なかったり、ボトルネックが何か？についての構成要素がわからないまま使っているというケースも少なくないかと思います。この本では、そのような不明点がなくなるように詳しく紹介してくれています。
また、AWSらしいところで面白いなというか、改めて、なるほどと思ったのが、負荷をかける側のサーバを増やして測定するというクラウドらしい手段を使うという考え方。言われみればその通りなんですが、クラウド環境は柔軟につかえてナンボだし、開発環境も柔軟に構築してナンボだなと思いました。
また、負荷をかける側も設定を正しく行わないと、負荷をかける側のボトルネックの存在に気が付かず、不適切な結果を導く可能性があります。そのようなことにならないように、何に注意していけば良いのか？をケーススタディ形式で記述してくれているのも良いです。
本書は、個人的には名著の予感がしてます。特にパフォーマンスチューニングの試行錯誤の様子がケーススタディとして説明されているのが非常に大きいかなと思っています。
特にSRE、インフラチームだけじゃなく、アプリケーションエンジニアやDBエンジニアにも是非読んでおいて欲しい一冊かと思います。
AWSで適切に負荷分布を測る重要性として、適切なコスト設計ができるようになるというのが大きいですよね。データベースが悪いのか、Webサーバをスケールアウトすることが良いのか。何かをスケールアップで対処するのか？無意味にWebサーバを不安ベースでいたずらに増やしたあげく、実は何も意味がなかったということもありえます。
特に、「エンジニアの不安を、インスタンスを増やすという手段、すなわち金で解決したくなる」というのがAWSの特徴で、これはエンジニアの適切な仕事とは言い難いですが、でも、多々、そういうケースは多いハズで、こりゃエンジニアのよくない怠惰のせいでAWSが儲かるよなと思ったわけです。
それ故に、まだAWSが市場評価される前からアマゾン株を買って、それなりに儲けさせてもらいました。
逆に言えば、エンジニアが適切にサーバを管理することで、事業利益に結びつけることができます。これは、オンプレで設備投資してしまうと投資設備の範囲内で収まる間においては、パフォーマンスを工夫したところで特に利益に繋がるわけではなく、あまり評価されないのとは大きな違いで、ガンガン自慢できるハズです。（もちろんパフォーマンスを向上させて、UXを高めて利益を産むというのは共通にあります）
みなさん、Amazonに無駄に利益を渡さないように、ちゃんとサーバ管理しましょうね！
そのためにも適切な負荷測定から！
