クラウドコンピューティング拡張性インフラストラクチャーデブオプス建築パフォーマンス

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

水平スケーリングはワークロードを分散するためにマシンを追加するのに対し、垂直スケーリングは既存サーバーの処理能力を向上させます。どちらのアプローチもパフォーマンスのボトルネックを解消しますが、アーキテクチャ、コスト構造、運用上の複雑さにおいて根本的に異なります。

ハイライト

水平スケーリングは設計上、単一障害点を排除する一方、垂直スケーリングはリスクを1台の機械に集中させる。
データベースのワークロードは水平分散に抵抗することが多く、そのため多くのチームにとって垂直スケーリングが事実上のデフォルトとなっている。
オートスケーリンググループを使用すると水平スケーリングが瞬時に実現するように見えるが、アプリケーションアーキテクチャへの事前の投資が必要となる。
垂直スケーリングは利用可能な最も強力なサーバーに達すると限界に達するが、水平スケーリングは理論上限界に達することはない。

水平方向のスケーリングとは？

需要の増加に対応し、ワークロードを分散するために、サーバーまたはインスタンスを追加する。

スケールアウトとも呼ばれるこのアプローチは、ロードバランサーを使用して複数のマシンにトラフィックを分散します。
AWS、Azure、GCPなどのクラウドプロバイダーは、オートスケーリンググループによって水平スケーリングをほぼ瞬時に実現します。
このアプローチを効果的に機能させるには、アプリケーションはステートレスに設計するか、共有ストレージを使用する必要がある。
水平スケーリングは、1台のサーバーが故障した場合でもトラフィックを再ルーティングできるため、組み込みの冗長性を提供します。
この方法は通常、使用量に応じて料金を支払うモデルを採用しており、コストは実際の使用量に直接連動します。

垂直スケーリングとは？

既存のサーバーリソース（CPU、RAM、ストレージなど）をアップグレードしてパフォーマンスを向上させる。

一般的にスケールアップと呼ばれるこの手法は、サーバーをより高性能なマシンに交換したり、コンポーネントをアップグレードしたりすることを含みます。
垂直スケーリングは、複数のサーバーで実行するように設計されていないモノリシックアプリケーションには適しています。
単一のマシンがどれだけ強力になれるかには通常上限があり、それが拡張性の限界を生み出す。
リレーショナルデータベースの分散化は大きな複雑さを伴うため、データベースサーバーは垂直スケーリングをよく利用する。
このアプローチでは、仮想化環境でライブマイグレーション技術を使用しない限り、ハードウェアのアップグレード中にダウンタイムが発生します。

比較表

機能	水平方向のスケーリング	垂直スケーリング
建築	多数のノードに分散	強力な単一マシン
最大容量	十分な数のノードがあれば、事実上無制限	ハードウェアの上限によって制限される
スケーリング中のダウンタイム	通常、ダウンタイムはゼロです。	多くの場合、再起動または移行が必要となる。
コストパターン	インスタンスごとの課金、線形的に増加	初期費用または段階的なコスト増加が大きい
複雑	より高いレベルには、負荷分散と分散設計が必要です。	より低く、より簡単に実装できる
耐障害性	組み込み冗長性	単一障害点
典型的な使用例	ウェブアプリケーション、マイクロサービス	データベース、レガシーモノリス

詳細な比較

それぞれの手法が成長にどのように対応するか

トラフィックが急増すると、水平スケーリングは追加のサーバーを起動して負荷を分散することで対応します。これは、スーパーマーケットでレジのレーンを増やすようなものです。一方、垂直スケーリングは、レジ係をより速い担当者に交代させるか、レジをアップグレードすることで対応します。どちらも処理能力は向上しますが、運用方法は大きく異なります。

アプリケーション設計要件

水平スケーリングでは、アプリケーションを分散処理を念頭に置いて構築する必要があります。セッションデータは単一のサーバー上に存在できず、リクエストは個別に処理されなければなりません。一方、垂直スケーリングは既存のアーキテクチャに対してはるかに寛容です。従来の3層アーキテクチャのアプリケーションは、より高性能な基盤サーバーの恩恵を受けるために、コードの変更を必要としない場合がほとんどです。

時間の経過に伴うコストへの影響

水平スケーリングは、支出を多数の小規模な購入に分散させるため、予算管理は容易になりますが、大規模になると総コストが高くなる可能性があります。一方、垂直スケーリングは、より少数の高価なマシンに投資を集中させます。極めて高いパフォーマンスが求められる場合、数百台の小型サーバーを運用するよりも、高性能サーバー1台の方がコスト効率が良い場合もあります。

障害耐性

水平スケーリングの隠れた利点の1つは、自然な耐障害性です。1つのノードが故障しても、他のノードがリクエストの処理を継続します。一方、垂直スケーリングでは、1台のマシンに重大な依存が生じます。そのマシンがダウンすると、高価なスタンバイシステムを導入していない限り、すべてが停止してしまいます。

実世界におけるハイブリッドアプローチ

高度な組織は、どちらか一方だけを選択することはめったにありません。データベースマスターを垂直方向に拡張しつつ、ステートレスなWebサーバーを水平方向に拡張するといった具合です。このような実用的な組み合わせによって、各コンポーネントはそれぞれの制約やアクセスパターンに合ったスケーリングモデルを利用できるようになります。

長所と短所

水平方向のスケーリング

長所

+ 優れた耐障害性
+ 柔軟でオンデマンドな成長
+ ハードウェアの上限なし
+ コストを使用量に合わせる
+ 地理的な分布を可能にする

コンス

− より高度な建築的複雑性
− ステートレスな設計が必要
− ノード間のネットワーク遅延
− より難易度の高いデバッグ
− 潜在的なデータ整合性の問題

垂直スケーリング

長所

+ 実装がより簡単
+ 分散システムの煩わしさは一切なし
+ レガシーコードと連携します
+ ネットワークオーバーヘッドの削減
+ セキュリティと監査が容易

コンス

− 単一障害点
− ハードウェアアップグレードの制限
− 多くの場合、ダウンタイムが必要となる
− 変動する業務量に対しては正当化が難しい
− 地理的集中

よくある誤解

神話

垂直スケーリングは、購入する機器の数が少なくて済むため、常にコストが安くなります。

現実

請求書の件数は少なくなるものの、エンタープライズグレードのサーバーは高額なプレミアム価格となる。大規模な運用においては、数百台の小規模インスタンスが1台のスーパーコンピュータよりも優れた性能を発揮し、かつ低価格で利用できる場合もある。実際のところ、最適な選択は、具体的なワークロードパターンと各リソースの利用効率によって決まる。

神話

水平スケーリングとは、アプリケーションの信頼性が自動的に向上することを意味します。

現実

分散システムは、正しく設計されて初めて信頼性を向上させる。設計が不適切な水平スケーリングシステムは、すべてのノードが単一のデータベースボトルネックを共有したり、ロードバランサー自体が脆弱性になったりすると、壊滅的な障害を引き起こす可能性がある。

神話

一つの方法を選び、それを永久に貫き通さなければなりません。

現実

ほとんどの運用環境では、両方の戦略が動的に組み合わされます。ステートレスなコンポーネントは水平方向にスケーリングされ、永続データストアはシャーディングが必要になるまで垂直方向にスケーリングされます。システムの進化に伴い、その境界は変化します。

神話

クラウド時代においては、垂直スケーリングは時代遅れである。

現実

クラウドプロバイダーは水平スケーリングを強く推奨していますが、垂直スケーリングも依然として不可欠です。多くのマネージドデータベースサービスは、スケールアウトよりも先にスケールアップを行い、特定の計算ワークロードは、通信オーバーヘッドの削減という理由だけで、より少ない数の高性能インスタンスの方がパフォーマンスが向上します。

神話

水平スケーリングは、あらゆるパフォーマンス問題を即座に解決します。

現実

サーバーを追加するのは、ボトルネックが計算能力にある場合にのみ有効です。非効率なクエリ、メモリリーク、ブロッキング操作などが原因でアプリケーションの動作が遅い場合、サーバーを増やしても問題は悪化するだけです。スケーリングの決定を下す前に、プロファイリングと最適化を行う必要があります。

よくある質問

水平スケーリングと垂直スケーリングの違いを簡単に説明するとどうなりますか？

水平スケーリングとは、工場で従業員を増やすように、コンピュータープールにコンピューターを追加して処理能力を向上させることを意味します。垂直スケーリングとは、従業員に高性能なツールやステロイドを与えるように、既存のコンピューターの性能を向上させることを意味します。どちらも処理能力を向上させますが、実装と維持管理の感覚は大きく異なります。

水平方向の拡大縮小ではなく、垂直方向の拡大縮小を使うべきなのはどのような場合ですか？

垂直スケーリングは、従来のリレーショナルデータベースやレガシーエンタープライズソフトウェアなど、分散処理を想定して設計されていないステートフルアプリケーションにおいて真価を発揮します。また、ノード間のネットワーク通信によって許容できない遅延が発生する場合や、分散システムの複雑さを管理する専門知識がチームに不足している場合にも適しています。

水平スケーリングには特別なアプリケーション設計が必要ですか？

概ねその通りです。アプリケーションは、ローカルサーバーの状態に依存しずにリクエストを処理する必要があります。ユーザーセッションはRedisのような共有キャッシュに保存し、ファイルアップロードにはS3のような集中型ストレージを使用し、データベースは複数のアプリケーションサーバーからの接続を処理できなければなりません。これらは不可能な要件ではありませんが、開発の初期段階から計画を立てる必要があります。

水平方向と垂直方向の拡大縮小を組み合わせることはできますか？

まさにその通りで、ほとんどの組織がまさにこの方法を採用しています。一般的なパターンとしては、Webサーバーを水平方向に拡張し、データベースを垂直方向に拡張していき、最終的にシャーディングが必要になるまで拡張するというものです。このハイブリッドアプローチにより、各レイヤーはそれぞれの制約とアクセスパターンに最適なスケーリングモデルを使用できます。

どちらの規模拡大手法がより費用対効果が高いか？

どちらが最適かは、ワークロードの特性と成長軌道によって大きく異なります。安定した予測可能な成長であれば、垂直スケーリングのシンプルさが有利となるでしょう。一方、変動が激しい、あるいは急速に成長するワークロードの場合は、水平スケーリングによるきめ細かなコスト管理の方がコスト効率が良い場合が多いです。導入を決定する前に、実際のリソース使用パターンを詳細に分析してください。

オートスケーリングは水平スケーリングとどのように連携するのですか？

オートスケーリングは、CPU使用率、リクエストキューの深さ、カスタムビジネスメトリクスなどの指標を監視します。しきい値を超えると、自動的に新しいインスタンスがプロビジョニングされ、ロードバランサーに追加されます。需要が減少すると、インスタンスが削除されてコストが削減されます。この柔軟性こそが、クラウド環境における水平スケーリングの最大の特長です。

垂直展開における主なリスクは何ですか？

最大のリスクは、利用可能なハードウェアの限界に達してしまうことです。最高性能のサーバーを購入してしまうと、それ以上の選択肢はなくなります。また、アップグレードに必要なダウンタイム、1台のマシンにリスクが集中すること、そして予測不能な負荷の急増に対応するために高価なハードウェアを導入することの正当性を説明するのが難しいといった問題もあります。

水平スケーリングは大規模企業だけのものだろうか？

もはやそうではありません。クラウドコンピューティングによって、水平スケーリングへのアクセスが民主化されました。スタートアップ企業でも、フォーチュン500企業と同じように、Infrastructure as Codeでオートスケーリングを簡単に設定できます。真の障壁は、予算や組織規模ではなく、アーキテクチャに関する専門知識なのです。

ロードバランサーは水平スケーリングにどのように組み込まれるのでしょうか？

ロードバランサーは、水平スケーリングを可能にするトラフィックディレクターです。受信リクエストをサーバー群全体に分散し、状態を監視し、障害が発生したノードを自動的に削除します。ロードバランサーがなければ、ユーザーは個々のサーバーに直接アクセスすることになり、複数のマシンを用意する意味がなくなってしまいます。

水平方向にスケールすると、データはどうなりますか？

それが重要な点です。データベース内のアプリケーションデータは、通常は中央集中型データベースまたはデータベースクラスタを介して、すべてのノードからアクセス可能である必要があります。ユーザーがアップロードしたファイルは共有ストレージに移動します。セッションデータはRedisなどのデータベースに移行します。アプリケーションコードはステートレスになり、データは専用の、多くの場合垂直方向に拡張可能なデータレイヤーに格納されます。

垂直スケーリングは、水平スケーリングのパフォーマンスに匹敵するようになるのだろうか？

特定のワークロードにおいては、確かにそうです。CPU、メモリ、高速なローカルストレージを大量に搭載した単一のマシンは、プロセス間通信が頻繁に行われるタスクや、データの局所性が求められるタスクにおいて、分散システムよりも優れたパフォーマンスを発揮することがあります。科学計算、ビデオレンダリング、および特定のデータベース分析では、大規模な場合でも垂直スケーリングが有利になる場合があります。

どのスケールアップ戦略から始めるべきか、どのように判断すればよいでしょうか？

まずは制約条件を明確にしましょう。既存アプリケーションがあり、開発時間が限られている場合は、垂直スケーリングが最も迅速な解決策となります。クラウドネイティブな新規ソフトウェアを開発する場合は、最初から水平スケーリングを念頭に置いて設計しましょう。最も重要なのは、あらゆる要素を計測し、理論的な予測ではなく、実際のパフォーマンスデータに基づいて進化していくことです。

評決

弾力的な成長と高い可用性を必要とする最新のクラウドネイティブアプリケーションを構築する場合は、水平スケーリングを選択してください。レガシーシステム、従来のデータベースのような複雑なステートフルワークロードを扱う場合、または無制限の拡張性よりもシンプルさが優先される場合は、垂直スケーリングを選択してください。成熟したアーキテクチャのほとんどは、最終的に両方のアプローチを融合させます。