インフラストラクチャのスケーリング: 水平対垂直、負荷分散と自動スケーリング

Netflix は、リアルタイムの需要に基づいて数千のインスタンスを動的にスケーリングすることで、190 か国の 2 億 6,000 万人の加入者にサービスを提供しています。 ほとんどの企業は Netflix の規模で運営していませんが、スケーリングの原則は同じです。つまり、インフラストラクチャの容量をトラフィック需要に合わせて自動的に調整し、手動介入やアイドル状態のリソースに料金を支払う必要はありません。水平スケーリングと垂直スケーリング、L4 と L7 ロード バランサー、リアクティブおよび予測自動スケーリングの間で行う選択によって、プラットフォームが順調に成長するか壁にぶつかるかが決まります。

重要なポイント

• 簡単にするために垂直型 (より大きなマシン) から開始し、高可用性が必要な場合や単一マシンの制限を超える場合は、水平方向 (より多くのマシン) に切り替えます。
• L7 ロード バランサーは最新のアプリケーションに不可欠なコンテンツ ベースのルーティングを提供し、L4 バランサーは単純な TCP 配布用の生のスループットを提供します。
• 自動スケーリング ポリシーでは、メトリックベースのトリガー (CPU、メモリ) と既知のトラフィック パターンの予測スケーリングを組み合わせる必要があります。
• データベースのスケーリングはアプリケーションのスケーリングとは異なるルールに従います -- 読み取りの多い負荷にはリードレプリカ、書き込みの多い負荷にはパーティショニング

---

水平スケーリングと垂直スケーリング

基本的なスケーリングの決定は、既存のマシンを大きくするか (垂直)、マシンを追加するか (水平) するかどうかです。各アプローチには明確なトレードオフがあります。

垂直方向に拡大縮小する場合

垂直スケーリングは、いくつかの理由から正しい最初の選択肢です。アプリケーションの変更、ロード バランサーの構成、分散状態の管理は必要ありません。特にデータベースの場合、垂直スケーリングにより、シャーディング、レプリケーションの遅延、分散トランザクションの複雑さが回避されます。

次の場合に垂直方向にスケーリングします。

• アプリケーションはまだステートレスではありません (セッションはメモリに保存され、ファイル システムは書き込みます)
• 単一のデータベースを実行していて、接続または CPU の制限に達していない
• 次のインスタンスのサイズアップは、水平化するためのエンジニアリング時間よりも安価です
• アーキテクチャを変更せずにすぐに拡張する必要がある

次の場合は垂直方向のスケーリングを停止します。

• 高可用性が必要 (単一インスタンス = 単一障害点)
• 利用可能な最大のインスタンスでは十分ではありません
• 90% の時間アイドル状態にあるピーク容量に対して料金を支払っていることになります。
• レイテンシのために地理的な分散が必要

水平方向に拡大縮小する場合

水平スケーリングでは、アプリケーションがステートレスであることが必要です。どのリクエストもどのインスタンスでも処理できます。これは次のことを意味します:

• セッションはメモリ内ではなく、Redis またはデータベースに保存されます
• ファイルのアップロードはローカル ディスクではなくオブジェクト ストレージ (S3) に保存されます
• インスタンス固有の構成やレプリケーションを使用しないローカル キャッシュはありません
• インスタンス終了の適切な処理 (ヘルスチェック、接続のドレイン)

次の場合に水平方向にスケーリングします。

• 高可用性が要件です (ビジネスは数分間のダウンタイムを許容できません)
• トラフィックは変動し、自動スケールは静かな期間にスケールダウンすることでコストを節約できます。
• ダウンタイムなしでデプロイする必要がある (インスタンス間でのローリング デプロイ)
• パフォーマンス要件が単一マシンの能力を超えている

---

ロード バランシングの詳細

ロード バランサーは、受信トラフィックを複数のバックエンド サーバーに分散します。ロード バランサーのタイプによって、どのようなルーティングの決定が可能かが決まります。

L4 (トランスポート層) ロードバランシング

L4 ロード バランサーは TCP/UDP レベルで動作します。パケットの内容を検査せずに、IP アドレスとポートに基づいて接続をルーティングします。これらは高速かつシンプルで、あらゆる TCP ベースのプロトコルを処理します。

最適な用途: Raw TCP ディストリビューション、データベース接続プロキシ (PgBouncer)、非 HTTP プロトコル、非常に高いスループット要件

制限事項: URL パス、ヘッダー、または Cookie に基づいてルーティングを決定することはできません。 SSL を終了できません (バックエンドで行う必要があります)。

L7 (アプリケーション層) ロードバランシング

L7 ロード バランサーは HTTP レベルで動作します。リクエスト ヘッダー、URL、Cookie、さらにはリクエスト本文を検査してルーティングを決定します。これらは SSL 終了、圧縮を処理し、リクエストと応答を変更できます。

最適な用途: Web アプリケーション、API ゲートウェイ、コンテンツベースのルーティング、SSL 終端、A/B テスト、カナリア デプロイメント

負荷分散アルゴリズム

ヘルスチェックと正常な機能低下

ヘルスチェックは、バックエンドサーバーがトラフィックを受信する必要があるかどうかを決定します。慎重に設定してください。

• 浅いヘルスチェック -- 専用エンドポイントでの単純な TCP 接続チェックまたは HTTP 200。サーバーのクラッシュは検出しますが、アプリケーション レベルの障害は検出しません。
• 詳細なヘルスチェック -- データベース接続、Redis の可用性、外部サービスの到達可能性を検証します。より多くの問題を検出しますが、重要ではない依存関係がダウンしている場合は偽陰性のリスクがあります。
• 猶予期間 -- 新しいインスタンスはウォームアップする時間が必要です (JIT コンパイル、キャッシュの作成)。ロード バランサーが完全なトラフィックを送信する前に、起動猶予期間を設定します。
• ドレイン -- インスタンスを削除するとき、新しいリクエストの送信を停止しますが、既存のリクエストは完了します (接続のドレイン)。通常は 30 ～ 60 秒です。

---

自動スケーリングポリシー

自動スケーリングは、需要に基づいてインスタンスの数を調整し、手動介入なしで容量をトラフィックに合わせます。

メトリックベースのスケーリング

最も一般的なアプローチは、メトリクスがしきい値を超えたときにスケーリング アクションをトリガーします。

予測スケーリング

トラフィックが予測可能なパターン (毎日のピーク、週ごとのサイクル、季節的なイベント) に従っている場合、予測スケーリングはトラフィックが到着する前に容量をプロビジョニングします。 AWS Auto Scaling は、過去のパターンから学習してプロアクティブにスケーリングする予測スケーリングをサポートしています。

予測と事後対応の組み合わせ: 既知のパターン (朝のトラフィック増加、ブラック フライデーの事前プロビジョニング) には予測スケーリングを使用し、予期しない急増には事後対応スケーリングを使用します。

スケーリングのベスト プラクティス

1. スケールアウトは速く、スケールインはゆっくり -- インスタンスを積極的に追加しますが (1 ～ 2 分のクールダウン)、バタつきを避けるために徐々に削除します (10 ～ 15 分のクールダウン)。
2. 複数のメトリックを使用 -- トリガーとなる最初のメトリックを使用して、CPU またはメモリまたはリクエスト数でスケールします。
3. 最小値と最大値の制限を設定します -- ゼロへのスケーリング (可用性なし) や無期限のスケーリング (コストの爆発) を防ぎます。
4. 負荷テスト中にスケーリングをテストします -- 自動スケーリングが正しくトリガーされ、新しいインスタンスが予想される時間枠内でトラフィックを処理することを確認します。
5. スケーリング イベントを監視 -- 頻繁なスケーリングについてアラートを発し、構成の問題や根本的なパフォーマンスの問題を検出します。

---

データベースのスケーリング戦略

データベースは、アプリケーション サーバーと同じように水平方向に拡張しません。書き込み操作にはコンセンサスが必要であり、強力な整合性により配布オプションが制限されます。

リードレプリカ

リードレプリカはプライマリ データベースからデータをコピーし、読み取りクエリを処理します。これらは読み取りスループットを線形にスケールしますが、書き込みスループットには役立ちません。

実装に関する考慮事項:

• レプリケーション ラグ -- レプリカは最終的に一貫性があります。書き込み直後のクエリでは変更が確認できない場合があります。書き込み後の読み取りにはプライマリを使用します。
• 接続ルーティング -- アプリケーションには、読み取りをレプリカにルーティングし、書き込みをプライマリにルーティングするロジックが必要です。 ORM と接続プロキシ (ProxySQL、PgBouncer) はこれを自動化できます。
• フェイルオーバー -- プライマリに障害が発生した場合、レプリカを昇格させることができます。自動フェイルオーバー (AWS RDS マルチ AZ、AWS Aurora) により、ダウンタイムが数秒に短縮されます。

テーブルのパーティショニング

大きなテーブルに対する書き込み負荷の高いワークロードの場合、パーティショニングにより、単一の論理インターフェイスを維持しながら、テーブルをより小さな物理チャンクに分割します。パーティション分割戦略の詳細については、データベース最適化ガイド を参照してください。

接続プーリング

データベース接続の作成にはコストがかかり、数も限られています。 PgBouncer のような接続プーラーは、多くのアプリケーション インスタンスからの接続を少数のデータベース接続にプールします。

プーリングなし: 20 アプリケーション インスタンス x それぞれ 20 接続 = 400 データベース接続 (PostgreSQL の制限を超える可能性があります)

PgBouncer の場合: 20 のアプリケーション インスタンスが PgBouncer に接続し、PostgreSQL への 50 ～ 100 の接続を維持し、リクエストを効率的に多重化します。

---

マイクロサービスの分解

モノリスが大きすぎて単一のチームが効率的に開発および展開できない場合、マイクロサービスの分解により、さまざまなコンポーネントを独立してスケーリングできます。

いつ分解するか

マイクロサービスから始めないでください。適切に構造化されたモノリスから始めて、次の場合に分解します。

• コンポーネントが異なれば、スケーリング要件も大幅に異なります (検索には 20 のインスタンスが必要、チェックアウトには 5 つのインスタンスが必要)
• リリース スケジュールを調整せずに、さまざまなチームが個別にデプロイする必要がある
• 特定のコンポーネントには異なるテクノロジー スタックが必要です (Python の機械学習、Node.js の API)
• コードベースのサイズにより、モノリスのデプロイ時間が 30 分を超える

最初に何を抽出するか

---

よくある質問

いつスケールする必要があるかをどのように判断すればよいですか?

CPU 使用率 (常に 70% 以上)、メモリ使用量 (80% 以上)、応答時間 P95 (SLO 以上)、およびエラー率 (0.1% 以上) の 4 つの主要な指標を監視します。いずれかのメトリクスが継続的にしきい値を超える場合は、スケーリングする必要があります。アラートによるプロアクティブな監視により、ユーザーが気づく前にこれらの傾向をキャッチします。 監視ガイド を参照してください。

自動スケーリングと事前プロビジョニングはどちらの方が費用対効果が高いですか?

自動スケーリングは、必要なときにのみ容量の料金を支払うため、予測できないトラフィックに対してよりコスト効率が高くなります。自動スケーリングでは容量を追加するのに 3 ～ 10 分かかるため、予測可能なピーク (ブラック フライデーや毎日のラッシュ) の場合は、事前プロビジョニングの方が適しています。最もコスト効率の高いアプローチは、予想されるピークに対する事前プロビジョニング、予期しないサージに対する自動スケーリング、ベースライン容量に対する予約インスタンスの使用の両方を組み合わせたものです。 クラウドコスト最適化ガイド をご覧ください。

コンテナー (Docker/Kubernetes) と従来の VM のどちらを使用する必要がありますか?

コンテナーは起動が速くなり (数分ではなく数秒)、リソースをより効率的に使用し (ホストあたりの密度が高く)、開発と運用全体で一貫した環境を提供します。 Kubernetes はオーケストレーション (自動スケーリング、自己修復、ローリング デプロイ) を追加しますが、運用は大幅に複雑になります。 Kubernetes を検討する前に、マネージド コンテナ サービス (AWS ECS、Google Cloud Run) から始めてください。

データを失わずにデータベースのフェイルオーバーを処理するにはどうすればよいですか?

データ損失ゼロのフェイルオーバーには同期レプリケーションを使用します。プライマリは、レプリカが書き込みを確認するまで書き込みを確認しません。これにより、書き込み遅延が増加します (通常、同じ領域内で 1 ～ 5 ミリ秒) が、フェイルオーバー中のデータ損失がないことが保証されます。 AWS RDS マルチ AZ と Aurora は、自動フェイルオーバーを備えたマネージド同期レプリケーションを提供します。

---

次は何ですか

成長予測に照らして現在のインフラストラクチャを評価します。単一サーバーを実行している場合は、アプリケーションがステートレスであり、水平スケーリングの準備ができていることを確認してください。すでに複数のインスタンスを実行している場合は、ロード バランサー構成を最適化し、自動スケーリング ポリシーを実装します。

パフォーマンス エンジニアリングの完全な観点については、[ビジネス プラットフォームのスケーリング] (/blog/scaling-business-platform-performance) に関する柱ガイドを参照してください。規模の拡大に応じてコストを最適化するには、クラウド コストの最適化 に関するガイドをお読みください。

ECOSIRE は、AWS およびマルチクラウド環境上のビジネス プラットフォーム用のスケーラブルなインフラストラクチャを設計および実装します。インフラストラクチャのスケーリング評価については、DevOps チームにお問い合わせください。

---

ECOSIRE によって発行 — Odoo ERP、Shopify eCommerce、OpenClaw AI にわたる AI を活用したソリューションで企業のスケールアップを支援します。