スケールするサーバー・システムとは、拡張性を考慮した作りのこと

IT システムの用語として「スケール」と呼ばれる言葉があります。

大まかな意味としては、拡張性を考慮した作りのことを指しており、
将来的にシステム負荷が増大しても耐えられるような仕組み・構成のことを意味します。

システムをスケールさせる意味・必要性

必ずしも全てのシステムでスケールを考慮する必要はありません。
負荷が固定化されているシステムであれば、想定負荷に耐える設計で十分です。

ただし、利用者数が増え続けるシステム・データを蓄積していくシステムにおいては、
将来的な拡張を見越した「スケール可能な構成」とする必要があります。

可能であれば、設計当初の段階でスケールを考慮して置けるとベストです。
仮にユーザーやデータが100倍になっても耐えられる？といった観点で考えてみましょう。

システムの処理能力を拡張する方法としては、
「スケールアップ」と「スケールアウト」の2種類が存在します。

スケールアップはサーバーの性能を強化すること、
スケールアウトはサーバーの台数を増やすことで、性能の向上を図るものです。

両者の違いや使い分けについて、以下の記事で詳しく解説しています。

スケールアップ・スケールアウトの違い、サーバー強化の手法を解説

システムをスケールさせるためには、様々な点で考慮が必要です。
システムの用途や構成によっても大きく異なりますが、一般的には次の項目が考えられます。

利用ユーザー数や、同時接続数が増えるにつれて CPU 負荷も上昇していきます。
サーバーの CPU に限界が来ると、性能を引き上げるか台数を増やすしかありません。

集計処理やソート処理を行う場合、データが増えても問題ない作りとしましょう。
全てのデータをメモリ上で処理する作りでは、メモリ不足に陥る可能性もあります。

画像を大量に格納したり、データを貯め続ける場合はストレージにも注意が必要です。
クラウドを利用する場合は S3 などのオブジェクトストレージも活用しましょう。

サーバーなどのインフラ面の拡張に頼るだけではなく、
アプリケーション自体の処理を軽くする・SQL クエリを見直すといった改善も非常に重要です。

Web アプリケーションは、比較的スケールアウト（サーバーを複数台にする）が容易です。
複数台のサーバーで Web アプリを動かす際は、以下の点に注意しましょう。

Web サーバーが複数台に分散しても、データベースは基本的に共同利用となります。
Web サーバーとデータベースを同居させている場合は、DB サーバーへ切り出しましょう。

ログインを伴うシステムの場合は、セッション情報のサーバー間共有が必要となります。
memcached・Redis・DB などにセッション情報を格納することで、他サーバーと共有できます。

各サーバーにアクセスログが分離してしまうため、障害調査などで手間が掛かります。
fluentd などを活用して、各サーバからのログを一括管理する仕組みがあると便利です。