スケーラビリティの基本

スケーラビリティとは何か

スケーラビリティとは、 利用者数やデータ量、リクエスト数が増加しても、性能を維持したままシステムを拡張できる性質のことです。

拡張の方向には大きく分けて2つのアプローチがあります。それぞれ得意なことと限界が異なるため、 両者の違いを理解することがシステムデザインの出発点になります。

スケールアップとスケールアウト

Scale Up (垂直スケーリング)
+-------------------+       +-----------------------+
|   Server (small)  |  -->  |   Server (bigger CPU,  |
|   CPU 2 / RAM 4GB |       |   more RAM, more disk) |
+-------------------+       +-----------------------+

Scale Out (水平スケーリング)
+-------------------+       +--------+  +--------+  +--------+
|   Server (1台)     |  -->  | Server |  | Server |  | Server |
+-------------------+       +--------+  +--------+  +--------+
                              (同じ性能のサーバーを複数台並べる)

ボトルネックの見つけ方

スケーリングを検討する前に、まず「何が限界を迎えているのか」を計測することが重要です。 CPU・メモリ・ディスクI/O・ネットワーク帯域・データベースの接続数など、限界の現れ方はシステムごとに異なります。

例えば、アプリケーションサーバーをいくら水平にスケールしても、背後のデータベースが1台のままでは データベースが先に限界を迎え、全体の性能は頭打ちになります。ボトルネックはシステム全体を通して 最も弱い箇所に現れるため、部分的な増強だけでは解決しないことがあります。

ステートレス設計の重要性

水平スケーリングを機能させるには、アプリケーションサーバーが「状態を持たない(ステートレス)」ことが前提になります。

// NG: サーバーのメモリにセッション情報を保持(ステートフル)
function login(request):
    inMemorySessionStore[request.userId] = sessionData
    // このサーバー以外にリクエストが振られると情報が失われる

// OK: セッション情報を外部の共有ストアに保持(ステートレス)
function login(request):
    sharedSessionStore.save(request.userId, sessionData)
    // どのサーバーインスタンスがリクエストを受けても同じ結果になる

セッションのような状態は、Redisなどの共有ストアやクライアント側のトークンに持たせることで、 ロードバランサーが自由にどのインスタンスにでもリクエストを振り分けられるようになります。