はじめに
自己紹介
未経験からWEB系エンジニアへの転職を目指している者です。現在はRuby on Railsを学習中です。
この記事を書いたきっかけ
現在、プログラミング学習コミュニティでISUCONの勉強会に参加しています。
『達人が教えるWebパフォーマンスチューニング〜ISUCONから学ぶ高速化の実践』
を読みながら学習を進めているので、情報整理とアウトプットの練習を兼ねてQiitaで読書メモを作成することにしました。
要点
1章の要点を個人的にまとめました。
1.高速なWebサービスとは？
2.必要十分なキャパシティを用意するには?
3.パフォーマンスチューニングのきほん
高速なWebサービスとは？
高速なシステムはコスト対性能効率が良い
基本的にコストと性能はトレードオフなイメージがあるが、高速に処理できるということはサーバーのリソースを占有する時間が短いので、同じリソースでも単位時間あたりにたくさんの処理を実行できる。高速なシステムはムダがないということ。
レイテンシが低い
リクエストしてから、受信完了するまでの待機時間が短いということ。
スループットが高い
同時にたくさんのリクエストを処理できるということ。
必要十分なキャパシティを用意するには?
Webサービスにおけるキャパシティ
そのWebサービスがその時に利用可能な計算資源の量(CPU時間、メモリ容量、ネットワーク帯域など)のこと。
必要十分であるとは
需要に対してキャパシティが不足せず、過剰でない状態のこと。
需要側の調整
- 処理要求を順番待ちさせる(キューイング)
- 処理要求の受付を単位時間あたり一定数に絞る(レートリミット)
- 処理要求の発生にランダムな待ち時間を発生させる
供給側の調整
- 垂直スケーリング、水平スケーリングを事前に行う
- オートスケーリングでシステムリソース需要をもとにキャパシティを調整する
パフォーマンスチューニングのきほん
推測せず計測する
推測してやみくもに改善するのではなく、ベンチマークの計測結果をもとに改善すべき箇所を探す。
条件を揃えて公平に比較する
2つのデータを比較する時は条件を揃えることで、変更箇所と結果の関係が推察できる。
対策は1つづつ比較する
対策を複数思いついたとしても、基本的には可能な限り1項目づつ対策を適用して効果を検証する。
ボトルネックだけにアプローチする
ボトルネック以外の箇所を改善してもパフォーマンスチューニング的な効果は得られない。
用語
レイテンシ
- データをリクエストしてからクライアントにデータが送られてくるまでに生じる通信の遅延時間のこと
- 単位は[ms]
スループット
- コンピュータやネットワーク機器が単位時間あたりに処理できるデータ量のこと
- 単位は「bps」「kbps」「Mbps」で1秒あたりのデータ量をビット数で表す
パフォーマンスチューニング
- 高速なWebサービスを実現するための取り組み
垂直スケーリング
- サーバーの性能を向上させてシステムリソースの総量を変える手法
- 性能を上げることをスケールアップ、性能を下げることをスケールダウンと呼ぶ
水平スケーリング
- サーバーの数を変えることで供給側のキャパシティを調整する手法
- サーバーの数を増やすことをスケールアウト、減らすことをスケールインと呼ぶ
オートスケーリング
- サーバー負荷に応じて、自動的にクラウドサーバーの台数を増減させる機能のこと