システムのスケーリング

すべてのシステムは、最初はシンプルで、たいていは1台のマシンで動作します。小規模な段階では、サーバーが受信リクエストの処理、ロジックの実行、データ管理を大きな負荷なく行えるため、これはうまく機能します。

アプリケーションが成長すると、需要も増加します。ユーザーが増えるということは、同時リクエストが増えるということであり、CPU、メモリ、ネットワークリソースに負荷がかかります。

データの増加は、さらに別の負荷を加えます。データセットが大きくなると、より多くのストレージが必要になり、クエリも遅くなるため、応答時間がさらに長くなります。

やがて、1台のマシンでは追いつけない段階に達します。パフォーマンスを維持し、遅延を防ぎ、負荷が増えてもシステムが信頼性高く動作し続けるようにするために、スケーリングが必要になります。

垂直スケーリングは、スケールアップとも呼ばれ、1台のサーバーをアップグレードすることでシステムの処理能力を向上させます。通常、より多くのCPUコアを追加したり、RAMを増やしたり、ストレージを拡張したりします。

この方法はシンプルです。システムアーキテクチャは変わらず、ネットワーク通信やデータ同期のような分散システムの複雑さを導入する必要もありません。

ただし、垂直スケーリングには明確な限界があります。物理マシンはある程度までしかアップグレードできず、高性能なハードウェアほどコストもどんどん高くなります。

そのため、垂直スケーリングは初期段階では有効ですが、大規模システムでは最終的に不十分になります。

水平スケーリングはスケールアウトとも呼ばれ、1台のサーバーを強化する代わりに、より多くのサーバーを追加することでシステム容量を向上させます。各サーバーは全体のワークロードの一部を処理します。

受信トラフィックはこれらのサーバーに分散されるため、単一マシン構成と比べて、システムははるかに多くのリクエストを並列に処理できます。

このアプローチは信頼性も向上させます。1台のサーバーが故障しても、他のサーバーがリクエスト処理を継続できるため、障害の影響を軽減できます。

ただし、水平スケーリングでは分散システムの複雑さが増し、調整、負荷分散、データ整合性の仕組みが必要になります。

システムが水平スケールすると、受信トラフィックを複数のサーバーに分散する必要があります。ロードバランサーはこれらのサーバーの前段に配置され、すべてのリクエストの入口として機能します。

すべてのトラフィックを1台のマシンに送るのではなく、ロードバランサーは round-robin や least connections などのアルゴリズムを使ってリクエストを均等に分散します。これにより、特定のサーバーがボトルネックになるのを防げます。

ロードバランサーはサーバーのヘルスも継続的にチェックします。サーバーが遅くなったり、クラッシュしたり、ヘルスチェックに失敗した場合、そのサーバーは自動的にプールから除外され、ユーザーが壊れたインスタンスにルーティングされないようにします。

さらに、ロードバランサーは SSL termination、パスに基づくリクエストルーティング、トラフィックシェーピングなどの処理も担当できます。Nginx、HAProxy、クラウド管理型ロードバランサーなどのツールは、現代のシステムでこのレイヤーを実装するために広く使われています。

Load balancer は単なるトラフィックの分割装置ではありません — トラフィックをどう分配するかが重要です。

最もシンプルな戦略は round-robin で、各リクエストを順番に次のサーバーへ送ります。これはサーバーが同一であれば有効ですが、ワークロードが異なると問題が起きます。

Least connections は、アクティブなリクエスト数が最も少ないサーバーへトラフィックを振り分けることでこれを改善し、過負荷を減らして応答時間を向上させます。

Sticky sessions はユーザーを同じサーバーに紐づけたままにします。セッションデータがローカルに保存されている場合に役立ちますが、柔軟性が下がり、負荷が偏る原因にもなります。

現代のシステムでは、戦略を health checks や weights と組み合わせます。より強力なサーバーはより多くのトラフィックを処理でき、障害が発生したサーバーは自動的に除外されます。

適切でない戦略を選ぶと、load balancer があっても負荷の偏り、レイテンシの増加、インフラの無駄につながります。

ステートレスなシステムでは、各リクエストは独立しています。サーバーは、以前のリクエストやユーザーセッションに関する情報をローカルメモリに保存しません。

その代わり、ユーザーセッションや認証データなど、必要な状態はデータベース、キャッシュ、専用のセッションストアといった外部システムに保存されます。

この設計により、水平スケーリングがはるかに容易になります。どのサーバーも固有のセッションデータを保持しないため、以前のリクエストがどこで処理されたかを気にせず、利用可能な任意のサーバーにリクエストをルーティングできます。

また、ステートレスアーキテクチャは信頼性と柔軟性も向上させます。サーバーを追加、削除、交換しても、ユーザーとのやり取りに影響を与えません。

実際のシステムにおけるトラフィックは一定ではありません。利用はピーク時間帯に急増し、オフピーク時には減少するため、固定的なインフラでは非効率になります。

オートスケーリングは、システム容量を自動的に調整することでこれを解決します。トラフィックが増加すると、新しいサーバーが追加されて負荷を処理します。トラフィックが減少すると、未使用のサーバーが削除されます。

このプロセスは通常、CPU 使用率、メモリ使用量、リクエスト率などのメトリクスによって制御されます。しきい値が定義されているため、システムは需要の変化に迅速に反応できます。

オートスケーリングは、パフォーマンスとコスト効率の両方を向上させます。システムは手動介入なしで突然の急増に対応でき、低使用時には不要なインフラコストを避けられます。

ユーザーがアプリケーションにアクセスすると、データは通常、地理的に遠いこともある中央サーバーを経由します。この距離がレイテンシを生み、応答時間を遅くします。

CDNは、画像、スクリプト、スタイルシートなどの静的コンテンツを、世界中に分散したエッジサーバーにキャッシュすることでこれを解決します。ユーザーがリクエストを送ると、最も近いエッジの場所から配信されます。

これにより、データが移動する距離が大幅に短くなり、読み込み時間が速くなってユーザー体験が向上します。

CDNはまた、トラフィックの大部分を処理することでオリジンサーバーへの負荷も軽減します。Cloudflare、AWS CloudFront、Fastly などのサービスは、このレイヤーをスケーラブルなシステムで実装するためによく使われます。

スケーラブルなシステムは単一のコンポーネントではなく、増加する需要に対応するために連携して動作する複数のレイヤーの組み合わせです。各レイヤーは、リクエストの流れの中で特定の機能を担当します。

ユーザーはまず CDN とやり取りし、CDN はキャッシュされたコンテンツを提供してレイテンシを削減します。動的な処理が必要なリクエストはロードバランサーに転送されます。

ロードバランサーはトラフィックを複数のアプリケーションサーバーに分散し、システムが多数のリクエストを並列に処理できるようにします。

アプリケーションサーバーは分散データベースと連携し、そこでは大規模なデータセットや高いクエリ量に対応するためにデータがパーティション分割またはレプリケーションされています。

このレイヤー化されたアプローチにより、システムの各部分を独立してスケールできるため、システム全体を再設計することなく、ユーザー数、トラフィック、データの増加に対応できます。