Webサイトのアクセス負荷を軽減する仕組みを考えた話

ホームページでも、Webシステムやサービスでも、アクセス数が増える事は嬉しい反面、サーバー負荷が高まる事が心配になりますよね。 サーバー負荷が高くなると、パフォーマンスが落ちるどころか、最悪の場合、サーバーダウンしてしまいます。 そうならないために、監視を行い、アクセスが増えた時を想定して負荷対策をしておく運用をしなければいけません。 これまで、Web系のシステム開発などをお手伝いしてきた会社さんは、AWSのインメモリ系のキャッシュサービスをお金を出してやっているパターンが多かったんですが、 コスト軽減につながるお手製の負荷軽減する仕組みを出し惜しみせずに解説したいと思います。

サーバーダウンの要因

サーバーダウンする原因は、次のようなモノがあります。

- アクセス集中 - ハードウェア障害 - サイバー攻撃 - 人為的ミス - 自然災害 - 停電

これらを一通り経験してきたエンジニアは、それぞれに対する対策方法を心得ているかと思いますが、 実際に体験した事がないサーバーダウンって、おぼろげにしかイメージできないエンジニアも多いでしょう。

アクセス障害

Webサイトの閲覧者がサーバーのキャパを超えた場合に、サーバーの処理が追いつかず、一時停止またはダウンしてしまいます。 これの解決法は、アクセスするユーザーのキャパに合わせたサーバーのバランシングによる、アクセスを分散させる必要があります。 他にも、次のような方法で、アクセスに対する負荷分散をする方法があるので、どれが適しているかを考えるのもエンジニア作業になりますね。

- ラウンドロビン方式： 順番にサーバーにリクエストを振り分けます。 - 最小接続数方式： 現在の接続数が最も少ないサーバーに振り分けます。 - IPハッシュ方式： ユーザーのIPアドレスに基づいてサーバーを選択します。

ハードウェア障害

アクセス負荷が高まってサーバーが壊れるという以外に、経年劣化によるマシントラブルも起こり得ます。 クラウドサーバーを使っていると、対策の立てようがないのですが、クラウドだろうが、オンプレだろうが、実際は世界のどこかにサーバーの実機が存在します。 コンピュータは使い続けると必ずどこかしらにハードウェア障害が発生するものです。 昭和家電のように、半世紀以上も使い続けられるコンピュータは、無いと考えた方がいいですよ。 この対策は、使っているコンピュータをミラーリングさせるためのもう一台をホットスタンバイ（起動状態で保持）または、コールドスタンバイ（電源を落とした状態で保持）しておく事で、 いざという時に入れ替えてサービスを止めないという策をとっているケースが多いですね。 もちろん、バックアップをする必要はありますけどね。

サイバー攻撃

たまにニュースで見かける、サイバー攻撃です。 ウィルスもそうですが、DDOSアタックなどは、サーバーをログを見ていると日常頻繁に行われています。（もちろん海外からが多数） 人気のあるフレームワークなどは、特定のモジュールを狙って、頻繁にアクセスされて、最悪の場合パスワード解析をされて乗っ取られたり、 アクセス負荷によってダウンしてしまう場合もあります。 対策としては、Wafなどを導入して、単一IPからの回数制限を設けたりするのが一般的ですね。

人為的ミス

実は最も多いサーバートラブルは、操作ミス（またはコードバグ）です。 意図的なものは、犯罪に繋がりますが、多くの場合は見落としのバグだったり、コマンド操作の打ち間違い、オペレーション操作ミスなどが大半ですね。 エンジニアでの飲みネタとしては、「データ消しちゃった」です。 気軽にログデータをrmしようと思ったら、削除するフォルダの名前やパスを間違っていた・・・ これは、多くの場合リターンキーを押した後に気がつくので、直後は本人は顔が青ざめてしまいます。 経験者であれば、そうならないためのDRY操作や、石橋を叩く方法をたくさん学習する事になります。

自然災害

災害によってデータセンターや、クラウドサービスが倒壊してしまう危険性は、世界ではどこでも起こり得ます。 AWSなどでは、別リージョンにインスタンスをコピーしておくと言うバックアップをする手もありますが、 企業運用するWebサービスであれば、DRP（Disaster Recovery Plan : 災害対策プラン）というのを検討しておくと、より安定したサービス提供ができるでしょう。

停電

サーバーは、電気が通ってなければ、ただの鉄の塊です。 停電対策は、無停電装置や、災害対策と同じように別場所でのミラーリングサーバー設置しかありません。 オンプレの場合、データセンターなどで、自家発電装置を持っているケースもありますが、24時間ぐらいが限度なので、災害による停電の場合は、別リージョンでのデータセンター運用を考えた方がいいかもですね。

サーバーエンジニアの考えるべき負荷軽減

落ちないサービスを作って運用するのは非常に大変な設計と労力と運用コストが必要ですが、 エンジニアが最初に考えるべきなのは、負荷軽減です。 1秒間に100人のユーザーが同時アクセスしただけで、ダウンするサービスと、 200人アクセスしてもダウンしないサービスは、 単純なサーバーコストは、倍以上違う事になります。 もちろん、サーバーダウンした場合に、有料サービスなどであれば、機会損失などのコスト以外の損失を伴う事になります。 エンジニアは、設計の時に、以下のことを頭に置いておくだけで、アクセス負荷に強いパフォーマンスのいいサービスを構築できるようになります。

- 無駄にデータベースにアクセスしない（書き込みも読み込みも） - ページ更新毎に、無駄なサーバーモジュールへのアクセスをさせない。（ブラウザキャッシュなどをうまく使う） - サーバー負荷の高いフレームワークを使わない。 - レンダリングにおける表示容量をできる限り軽量にする。（画像や各種データのサイズを極力圧縮する） - ページの外部読み込みの量（個数）をできる限り減らす。

上記に対応しているフレームワークも最近増えてきていますが、 単一機能のためのトレードオフで、結果的にサーバー負荷が同じであったり、増えたりすることもあるので、 自分でちゃんと負荷計測をしたり、理論的に負荷削減できる方法は模索し続けるしかありません。

サーバー負荷の対応パターン

サーバー負荷対策をする事は、ページの読み込み速度をアップさせる事にも繋がります。 要するに、Webサービスにとって、いい方向になる事は間違いありません。 というわけで、個人的によくやる対策方法を列挙しておきます。

CSSとJSファイルは、できる限り１つにまとめる

サイトのページ数が少ない場合に有効な手段で、読み込みモジュールを減らす事で、サーバートラフィックと、無駄なモジュールヘッダの容量を削減できます。 SSR系の機能を持っているフレームワークでは、ここからさらに、モジュール圧縮技術を行う場合もあり、 テキストモジュールの、改行やコメント、改行コードなど、1バイトでも少なくする事で、サーバー負荷を軽減させる事ができます。

データベースアクセスを極力減らす

ログデータなどを、ユーザーがアクセスしたタイミングで、そのままデータベースに書き込んでいる場合、 サーバーダウンの前にデータベースダウンしてしまうでしょう。 ログ系のデータは、よほど必要がない限り、テキストデータの行追記方で保持して、それを定期バッチ処理などで、データベースに登録するという方法が、 同時アクセスが増えた時のデータベースダウンを阻止する事が可能になります。 ちなみに、データベースのデータは、ログデータとマスターデータの2種類に分類しておくと、この辺のデータ運用がわかりやすくなりますよ。

CGIよりもHTML

phpなどのCGIにアクセスするよりも、HTMLファイルをそのまま表示した方が、サーバー負荷は倍以上変わってきます。 アクセスユーザーキャパも倍以上と考えると、単一ページであれば、いちいちCGIアクセスではなく、HTMLアクセスをした方が圧倒的にサーバーコスパがいいという事を理解してみましょう。

あとがき

Webサービスの構築でのサーバー負荷は、サーバーエンジニアのみの担当ではなく、サービスで扱われるモジュールに携わる全ての人が気にしなくてはいけない領域です。 できる事なら、これらを一括して設計できるCTOレベルのエンジニアが必要になる事もよくわかりますね。 もし、今現在、サーバー負荷でお悩みの人がいたら、壁打ちしますよ。