WEBシステムのチューニングに関して(負荷対策と運用コスト)
2019.06.28
様々なWEBシステムがある現在、システムの利用が増えると必ず出てくる負荷問題。
システムを運営・運用されている方々は負荷対策とその為に増えていく運用コストにお悩みの方も多いのではないでしょうか?
サーバー負荷の原因
サーバー負荷の主な原因は以下の2つだと考えられます。
- アクセスが集中して単純に処理が追いつかなくなる
- DB(データーベース)からのデータの取得に時間がかかりレスポンスが悪くなる
どちらもサーバーの処理がリクエストに追いついていないことから発生しています。
単純にサーバーの処理能力を上げるか、台数を増やすことで問題は解決できます。
逆に、1回のリクエストでサーバーに処理してもらう量を減らすことで負荷の対策が出来、サーバーのスペックや台数を減らす事もできると言えます。
システム処理内の通信回数
システムを開発する上で一番処理時間がかかるのはDBからデータを取得したり、登録・更新をする場合が多いです。
頻繁に更新される情報でない場合はmemcached等によく使う情報を一時保存して使用することで格段に速度の向上が見込めます。
それは、DB(RDBMS)にSQLでやり取りをする際に
DBへの接続
↓(通信)
SQLの処理
↓(通信)
結果の取得
上記のように2度の通信が入っているからです。
memcached等を使う際はこの通信のウェイトが軽くなるため、速度が向上するわけです。
これはAPI等から情報を取得するタイプのシステムでも同じ事が言えます。
APIを提供しているWEBサーバーにアクセス
↓(通信)
APIの処理
↓(通信)
APIの戻り値を取得
上記の動作の順序になっている為です。
システムの中で行われている通信の回数を減らしていく事が一番分かりやすい対策ではないかと思います。
システム処理内の通信量
前項でシステム内の通信回数が多い場合は改善するべきであると述べましたが
では、多量の情報を1回の通信で取るようにすればよいのでしょうか?
いいえ、その場合も帰ってレスポンスが悪くなる場合があります。
多量の情報を1回の通信でDBから取得しようとする場合
1つのテーブルに沢山の情報を入れるか、複数のテーブルを連結してデータを取得する必要があります。
非常に多量の情報の入ったテーブルから情報を抽出する場合、DBにかなりの負荷がかかります。
また同様に、沢山のテーブルを結合してデータを取る際も、DBにかなりの負荷がかかります。
システム開発のテクニックで、テーブルそれぞれからデータを取得しシステム側で連結させた方が早い場合があるという位です。
チューニングされたシステム
データの通信回数を減らしたい、しかし1回のデータの通信量を増やせない。
そうなるとどの様にシステムを改修すればよいのかわからなくなると思います。
システムの負荷軽減は何か一つをやったら終わりというわけではないのです。
データの通信回数を減らしながら、使わない情報や重複している情報をなるべく削り
バランスを上手く取りながら開発していくことがシステムのチューニングをすることに繋がります。
そして、そのシステムで出せる限界の速度までチューニングをする事ができたなら
結果として必要とするサーバーのスペックや台数が減っているでしょう。
そうすることで、長期的な運用コストを下げることが可能になると思われます。
まとめ
サーバースペックや台数はWEBシステムの負荷対策としては即効性が高く、効果も高いです。
しかし、そのどちらも運用コストの増加が発生してしまいます。
これらの対策に比べると即効性は薄いですがシステムの軽量化を行う事で負荷対策を行っていき
システム内でのバランスを一番適した状態にする事で
運用をコストを減らしながら徐々に負荷を減らしていく方法も試す価値はあると思います。
関連