リソースのスケール
クラウドの重要な利点の 1 つは、需要に応じてシステムのリソースをスケーリングできることです。 スケールアップ (より大きなリソースのプロビジョニング) またはスケールアウト (追加のリソースのプロビジョニング) を使用すると、容量の増加またはワークロードの分散の拡大の結果として、使用率が低下するため、1 つのリソースの負荷を軽減できます。
より多くの要求を処理できるようになるため、スケーリングによってスループットを向上させ、パフォーマンスを改善するために役立ちます。 これにより、負荷がピークのときに 1 つのリソースでキューに格納される要求の数が少なくなるため、ピーク負荷発生時の待機時間を短縮することもできます。 また、リソースのブレーク ポイントからさらに離れるようにリソースの使用率を減らすことにより、システムの信頼性を向上させるために役立ちます。
クラウドを使用すると、新しいリソースやより優れたリソースを簡単にプロビジョニングできますが、対立要因としてコストを常に考慮しなければならないことに注意することが重要です。 そのため、スケールアップまたはスケールアウトするのが有益な場合でも、コストを節約するためにスケールダウンまたはスケールインするタイミングを認識することが重要です。 n 層アプリケーションでは、ボトルネックの場所と、スケールが必要な層 (データ層かサーバー層か) を特定する必要があります。
リソースのスケーリングは、(前述のとおり) 負荷分散によって促進されます。これは、一貫性のあるエンドポイントの背後にシステムを隠すことで、システムのスケーリングの側面をマスクするために役立ちます。
スケーリング戦略
水平スケーリング (スケールアウトとスケールイン)
水平スケーリングは、システムにリソースを追加することや、システムから不要なリソースを削除することができる戦略です。 この種のスケーリングは、システムの負荷が予測不可能で変動が一貫していない場合のサーバー層に有益です。 変動する負荷の性質上、負荷を常に処理するために適切な量のリソースを効率的にプロビジョニングすることが不可欠になります。
これが困難なタスクになるいくつかの考慮事項があります。インスタンスのスピンアップ時間、クラウド サービス プロバイダーの価格モデル、および時間内にスケールアウトしないことによるサービス品質 (QoS) の低下による収益損失の可能性です。 例として、次のロード パターンについて考えてみましょう。
図 6: 要求ロード パターンのサンプル
アマゾン ウェブ サービスを使用しているとしましょう。 また、時間の各単位は実際の時間の 3 時間に相当し、1 つのサーバーで 5,000 件の要求を処理する必要があるとします。 時間単位 16 から 22 の負荷と考慮した場合、負荷に大きな変動があります。 時間単位 16 前後で需要の低下が検出され、割り当てられたリソースの数を減らし始めることができます。 3 時間で約 50,000 件の要求からほぼ 0 件の要求に移行するため、学術的には、時間 16 に発生した 10 個のインスタンスのコストを節約できます。
代わりに、各時間単位が実際の時間の 20 分に等しい場合を考えてみましょう。 この場合、時間単位 16 ですべてのリソースをスピンダウンして、20 分後に新しいリソースをスピンアップすると、実際には節約されず、コストが増加します。AWS では各コンピューティング インスタンスに時間単位で課金されるためです。
上記 2 つの考慮事項に加えて、サービス プロバイダーは、100,000 件の要求ではなく 90,000 件の要求しか処理できない場合、時間単位 20 の間に QoS を低下させることで発生する損失も評価する必要があります。
スケーリングは、トラフィックの特性と、その後に Web サービスで生成される負荷によって異なります。 トラフィックが予測可能なパターンに従っている場合 (たとえば、夜間に Web サービスから映画をストリーミングするといった人間の行動に基づく場合)、QoS を維持するために予測に基づいてスケーリングを行うことができます。 それに対し、多くの場合はトラフィックを予測できず、さまざまな条件に基づいて対応するスケーリング システムにする必要があります (前の例を参照してください)。
垂直スケーリング (スケールアップとスケールダウン)
サービス プロバイダーには、他よりも予測可能性が高い特定の種類の負荷があります。 たとえば、要求数が常に 10,000 件から 15,000 件であることが履歴パターンからわかっている場合、サービス プロバイダーの目的には、20,000 件の要求を処理できる 1 台のサーバーで十分であると想定できます。 これらの負荷は将来増加する可能性がありますが、一定の方法で増加する限り、より多くの要求を処理できるより大きなインスタンスにサービスを移行できます。 これは、トラフィック量が少ない小規模なアプリケーションに適しています。
垂直スケーリングの課題は、ダウンタイムと見なすことができるある程度の切り替え時間が常に存在することです。 これは、小さいインスタンスから大きいインスタンスにすべての操作を移動するためであり、切り替え時間がわずか数分であっても、その間は QoS が低下します。
さらに、ほとんどのクラウド プロバイダーは、リソースのコンピューティング能力を 2 倍にしてコンピューティング能力を向上させるコンピューティング リソースを提供しています。 したがってスケール アップの粒度は水平スケーリングほど細かくありません。 そのため、サービスの人気が高まるにつれて負荷が予測可能で着実に増加する場合でも、多くのサービス プロバイダーは垂直スケーリングではなく水平スケーリングを選択しています。
スケーリングに関する考慮事項
監視
監視は、リソースを効果的にスケーリングするうえで最も重要な要素の 1 つです。システムのどの部分をスケーリングする必要があるか、またいつスケーリングする必要があるかの解釈に使用できるメトリックを持つことができるためです。 監視によってトラフィック パターンやリソース使用率を分析できるようになり、QoS と利益が最大限になるように、リソースをスケーリングするタイミングと量を、情報に基づいて評価できます。
リソースのスケーリングをトリガーするために監視されるリソースには、いくつかの側面があります。 最も一般的なメトリックは、リソース使用率です。 たとえば、監視サービスでは、各リソース ノードの CPU 使用率を追跡し、使用量が多すぎたり少なすぎたりする場合は、リソースをスケーリングすることができます。 たとえば、各リソースの使用率が 95% を超える場合は、システムの負荷が高いため、おそらく、リソースを追加するのが適切な対応です。 通常、サービス プロバイダーは、リソース ノードの限界点を分析し、障害が起き始めるときを判断し、さまざまな負荷レベルでの動作を明らかにすることによって、これらのトリガー ポイントを決定します。 コスト上の理由から、各リソースを最大限に活用することは重要ですが、オーバーヘッド アクティビティに対応できるよう、オペレーティング システム用にある程度の余裕を残しておくことをお勧めします。 同様に、使用率が非常に低い場合 (たとえば 50% 未満)、すべてのリソース ノードが必要ではなく、一部をプロビジョニング解除できる可能性があります。
実際、サービス プロバイダーは、通常、リソース ノードの複数の異なるメトリックの組み合わせを監視して、リソースをスケーリングするタイミングを評価しています。 そのようなものには、CPU 使用率、メモリ消費量、スループット、待機時間などが含まれます。 Azure には、Azure リソースを監視し、そのようなメトリックを提供できる追加サービスとして Azure Monitor が用意されています。
ステートレス
ステートレス サービスの設計は、スケーラブルなアーキテクチャに適しています。 ステートレス サービスは基本的に、サーバーで要求を処理するために必要なすべての情報が、クライアント要求に含まれていることを意味します。 サーバーでは、クライアント関連の情報はインスタンスに格納されず、サーバー インスタンスにはセッション関連の情報が格納されます。
ステートレス サービスを使用すると、リソースを自由に切り替えることができ、後続の要求のためにクライアント接続のコンテキスト (状態) を維持するように構成する必要はありません。 ステートフルなサービスでリソースをスケーリングする場合は、既存のノード構成から新しいノード構成にコンテキストを転送する戦略が必要です。 ステートフル サービスを実装する手法があることに注意してください。たとえば、Memcached を使用してネットワーク キャッシュを維持して、コンテキストをサーバー間で共有することができます。
スケーリングする対象を決定する
サービスの性質によっては、要件に応じてさまざまなリソースをスケーリングする必要があります。 サーバー層の場合、アプリケーションの種類によっては、ワークロードが増加すると、CPU、メモリ、ネットワーク帯域幅、またはそのすべてのリソースの競合が増加する可能性があります。 トラフィックを監視することで、制約を受けているリソースを特定し、その特定のリソースを適切にスケーリングすることができます。 クラウド サービス プロバイダーは、必ずしも計算またはメモリをスケーリングできるスケーラビリティの粒度を提供するわけではありませんが、特にコンピューティングの負荷やメモリ使用量の負荷が高い場合に対応するさまざまな種類のコンピューティング インスタンスを提供しています。 そのため、たとえば、メモリを集中的に使用するワークロードがあるアプリケーションでは、リソースをメモリ最適化インスタンスにスケールアップすることをお勧めします。 必ずしもコンピューティングやメモリの負荷が高くない多数の要求を処理する必要があるアプリケーションでは、複数の標準的なコンピューティング インスタンスをスケールアウトする方が適切な戦略の場合があります。
ハードウェア リソースを増やすことが、サービスのパフォーマンスを向上させるための常に最適な解決策であるとは限りません。 サービス内で使用されるアルゴリズムの効率を上げることでも、リソースの競合が減り、使用率が向上して、物理リソースのスケーリングの必要がなくなる場合があります。
データ層のスケーリング
データベースやストレージ システムに対する読み取りと書き込み (またはその両方) が多いデータ指向アプリケーションでは、各要求のラウンドトリップ時間が、ハード ディスクの I/O の読み取り時間と書き込み時間によって制限されることがよくあります。 インスタンスが大きいほど、読み取りと書き込みの I/O パフォーマンスが向上します。これにより、ハード ディスクのシーク時間が改善され、サービスの待機時間が大幅に改善されます。 データ層に複数のデータ インスタンスがあると、フェールオーバーの冗長性を実現できるので、アプリケーションの信頼性と可用性が向上します。 複数のインスタンス間でデータをレプリケートすると、物理的にデータセンターに近いデータセンターからクライアントがサービスを提供されている場合に、ネットワークの待機時間を短縮できるという利点があります。 シャーディング (複数のリソースにまたがるデータのパーティション分割) は、もう 1 つの水平データ スケーリング戦略であり、データを複数のインスタンスに単にレプリケートするのではなく、データは複数のパーティションに分割されて、複数のデータ サーバーに格納されます。
データ層のスケーリングに関する固有の課題は、整合性 (読み取り操作がすべてのレプリカで同じであること)、可用性 (読み取りと書き込みが常に成功すること)、パーティションの許容性 (障害によってノード間の通信が妨げられたときに、システムで保証された特性が維持されること) の維持です。 多くの場合、これは CAP 法則と呼ばれます。分散型データベース システム内では、3 つの特性すべてが完全に達成されることは非常に困難であり、システムの特性のうちの 2 つの組み合わせが実現されればよい方であることを示します。 データベースのスケーリング方法と CAP 定理の詳細については、後のモジュールを参照してください。