Webサービスなど、主にサーバーを利用するネットワークサービスにおいては、利用者の増加などの理由によって、サーバーの負荷が無視できないレベルになってきます。
そんなとき、サーバーの負荷を下げるための戦略について、考えてみます。
過負荷問題
利用者の少ない時期や、ある一定の利用しか見込んでいない場合、サーバーの負荷について考える必要はあまりありません。
現代では、安価で高スペックなサーバーを利用することができますから、かなりの負荷に耐えることが可能です。
しかし、利用者が徐々に、または爆発的に増えたとき、サーバーがダウンしたり、応答が極端に遅くなってしまったりといったことがどうしても起こってしまいます。
また、データベースサーバーでは、システムを長期運用すればするほどメモリやストレージを圧迫してしまい、最悪の場合、長期的なサービス停止となってしまうこともあります。
エンジニアは、これらの問題を予測し、「事前に」対応しておくことが必須です。
スケールアップか、スケールアウトか
アーキテクチャ設計時には、システムに応じて最も有効な手段を予め考えておく必要があります。
例えば、データベースひとつを取っても、クラスタ構成が得意なものもあれば、かなりの手間を要するデータベースもあります。データの移行やサービス停止時間（メンテナンス時間）なども考慮に入れておかなければなりません。
アプリケーションサーバーでは、セッション情報をサーバーのメモリに置いておくなど、スケールアウトにコストが掛かるシステムを作ってしまうこともあります。現在はステートレスアーキテクチャが主流なのであまりそういうことは起こらないにしても、意識しておかなければ思わぬコストが掛かってしまいます。
スケールアップとは
その名の通り、アプリケーションが格納されているサーバーのスペックを上げることです。CPUの換装、メモリの増設、ストレージの変更や増設など。
RDBMSではこの手法が主流でしたが、現在はNoSQLをメインのデータベースとして使用しているシステムも多く、一概には言えません。
スケールアウトとは
ロードバランサなどの仕組みを用いて、複数のアプリケーションサーバーにアクセスを振り分けることができます。
つまり、アクセス数に応じて、サーバーの台数自体を増やす方法を総称してスケールアウトと呼びます。スケールを「外側に増やす」という意味ですね。
どちらの手法が優れているのか？
ほかの話題でもそうなのですが、システムによって適した手法は異なりますから、仕様や要件に併せて柔軟に対応する必要があります。
ただ、スケールアウトを見据えた構成にしておくことはマイナスになることはありません。例えば、ログイン情報など、セッションに相当する情報はKVSなどの外部から参照可能なストレージエンジンに持っておくことで、アプリケーションサーバーの負荷が増大した場合に、スムーズにスケールアウトできます。
また、スケールアップを見越したシステムを予め組んでいたとしても、スケールアップには必ず限界がありますし、ある一定のスペックを越えると莫大なコストが掛かるようになります。
となれば、やはりスケールアウトに対応可能なシステム構成にしておくのが良いでしょう。
まとめ
アーキテクチャ設計時に、正確なアクセス数見積もりをすることは基本的に難しいです。思わぬ要因でユーザーが集まらなかったり、また逆に集まりすぎてしまう場合もあります。
不測の事態は常に起こり得るものですから、コストとの兼ね合いである程度のリスクは甘受するような場面もあるかもしれません。
そういったときに、迅速に対応できる態勢を予め作っておくことが大切です。サービス停止などでユーザーを逃がさないようにしたいものですね。