スケーラビリティーのための戦略の決定

スケーラビリティーとは、システムに処理能力を追加する能力です。 これは、通常はシステムリソースの追加によって行われ、配備アーキテクチャーの変更はスケーラビリティーの対象に含まれません。要件を分析するときに、通常は、ビジネス要件と使用パターンの分析に基づいて、システムの成長予測が立てられます。システムのユーザー数や、目的達成に必要なシステムの処理能力に関する予想は、配備されるシステムの実際の数値とは大きく異なることが珍しくありません。予想の不一致に対応できるだけの十分な柔軟性を設計に盛り込む必要があります。

スケーラブルな設計とは、システムが追加リソースでアップグレードされるまで、増大する負荷を処理できる、十分な潜在処理能力が含まれている設計です。スケーラブルな設計では、システムの設計を変更することなく、増大する負荷の処理に容易に対応できます。

潜在処理能力

潜在処理能力は、例外的なピーク負荷に容易に対応できるように、パフォーマンスと可用性のためのリソースをシステムに含めることで得られるスケーラビリティーです。また、配備されるシステムで潜在処理能力がどのように使用されるかを監視することも、リソースの追加によるシステムの規模拡大が必要となるタイミングを計る上で役立ちます。潜在処理能力は、設計に安全性を組み込む手法の 1 つです。

ユースケースの分析は、例外的なピーク負荷が発生するシナリオを特定する上で役立ちます。例外的なピーク負荷の分析と、予期せぬ急成長に対応するための方法を考慮して、システムに安全性をもたらす潜在処理能力を設計します。

システム設計は、想定される負荷を妥当な期間にわたって処理できる必要があります。 この期間は、通常、運用開始後の最初の 6 〜 12 か月です。定期的に行われる保守を通じて、必要に応じてリソースを追加したり、処理能力を向上します。システムの定期的なアップグレードをスケジューリングできれば理想的ですが、多くの場合、処理能力向上の必要性を予測することは困難です。システムをいつアップグレードするかは、リソースの慎重な監視と、ビジネス予測に頼ることになります。

ソリューションを段階的に実装する計画の場合は、各フェーズで予定されるその他の向上内容に合わせて、システムの処理能力の向上をスケジューリングする必要がある場合もあります。

スケーラビリティーの例

この節の例では、Messaging Server を実装するソリューションの水平方向のスケーリングおよび垂直方向のスケーリングを説明します。垂直方向のスケーリングの場合、CPU をサーバーに追加することで、増大する負荷を処理します。水平方向のスケーリングの場合、負荷の分散に使用するサーバーを追加することで、増大する負荷を処理します。

この例の基準は、ロードバランスのために分散された 2 つのメッセージストアインスタンスによってサポートされる 50,000 ユーザーベースを前提としています。各サーバーには 2 つの CPU があり、合計で 4 CPU です。次の図は、25 万人または 200 万人のユーザーに増大する負荷を処理するために、このシステムの規模をどのように拡大できるかを示しています。

「スケーラビリティーの例」は、垂直方向のスケーリングと水平方向のスケーリングの違いを示しています。この図には、ロードバランス、フェイルオーバー、使用パターンの変化など、スケーリング時に考慮するべきその他の要因は示されていません。

図 5–9 水平方向のスケーリングと垂直方向のスケーリングの例