容量計画に関する推奨事項

  • [アーティクル]

この Azure Well-Architected Framework パフォーマンス効率チェックリストの推奨事項に適用されます。

PE:02 容量計画を実施する。 容量計画は、使用パターンに予測される変更がある前に行う必要があります。 予測される変更には、季節変動、製品の更新、マーケティング キャンペーン、特別なイベント、または規制の変更が含まれます。

このガイドでは、容量計画に関する推奨事項について説明します。 容量計画とは、ワークロードのパフォーマンス目標を満たすために必要なリソースを決定するプロセスを指します。 これには、ワークロードのパフォーマンス要件をサポートするために必要な CPU、メモリ、ストレージ、ネットワーク帯域幅などのコンピューティング リソースの量を見積もる必要があります。 容量計画は、プロビジョニング不足を回避するのに役立ち、パフォーマンスの低下やボトルネックを経験することなく、予想されるワークロードの需要に対応するための十分なリソースがワークロードに確保されます。 また、過剰プロビジョニングや不要なコストを防ぐのにも役立ちます。 容量計画が不足すると、パフォーマンスの問題、リソースのボトルネック、コストの増加、非効率的な割り当て、スケーラビリティの課題、予測できないワークロードのパフォーマンスが発生する可能性があります。

定義

期間 定義
容量計画 ワークロードがパフォーマンス目標を満たす必要があるリソースを予測するプロセス。
機能の要件 ワークロードが目的を達成するために必要な機能と機能。
技術的な要件 機能要件を満たすために必要なコードとインフラストラクチャ。
傾向分析 将来の需要を予測するための履歴データ分析。

主要な設計戦略

容量計画は、予想されるワークロードの需要とパターンに基づいて意思決定を行う、将来を見据えたプロセスです。 その目標は、継続的な負荷とピーク時の両方の負荷シナリオでワークロードのパフォーマンスを最適化することです。 季節シフトや製品リリースなどの使用状況の変化を理解することで、リソースを戦略的に割り当てることで、需要の高い期間中のシステムの負担を防ぐことができます。 このプロアクティブ戦略により、中断が軽減され、パフォーマンス効率が向上します。 過去の使用状況の傾向と成長データを分析することで、短期および長期的なニーズを予測できます。 潜在的なボトルネックとスケーリングの問題を特定し、一貫性のある効率的なワークロード パフォーマンスを確保できます。

容量データを収集する

ワークロード使用率データを収集するには、ワークロードでのリソースの使用方法に関する情報の収集と分析が必要です。 既存のワークロードの履歴パターンと、新しいワークロードの予測メジャーに関するデータを収集する必要があります。 このプロセスは、ビジネス目標を技術的な要件に変換するのに役立ち、容量の予測に不可欠です。 次の推奨事項を検討してください。

既存のワークロードを理解する

容量計画のための既存のワークロードを理解するには、ワークロードがリソースを利用する方法に関連する履歴データを分析する必要があります。 これには、リソース使用率、パフォーマンス データ、ワークロード パターンなどのメトリックが含まれます。 この理解により、効率的なリソース割り当てが保証され、ビジネス目標が技術的な要件に変換され、潜在的なボトルネックを特定するのに役立ちます。

  • データを理解する: 使用可能な履歴データを確認し、その構造、形式、容量計画との関連性を理解します。 レビューには、リソース使用率メトリック、ワークロード パターン、パフォーマンス メトリック、およびその他の関連データ ポイントが含まれる場合があります。 ビジネス プロセスとアプリケーションの重要度を理解します。 ピーク使用時間、ユーザー負荷、トランザクションレート、およびその他の関連メトリックを特定します。

  • データをクリーンアップして前処理する: 不整合、エラー、または外れ値を削除して、分析用にデータを準備します。 データの準備には、データ補完、欠損値の処理、正規化などのデータ クリーニング手法が含まれる場合があります。

  • 主要なメトリックを特定する: 容量計画に関連するメトリックを特定します。 メトリックには、CPU 使用率、メモリ使用量、ネットワーク スループット、応答時間が含まれます。

  • ボトルネックの特定: スループットと応答時間を測定して、ワークロードの増加に伴ってボトルネックになる可能性があるシステムの特定のコンポーネントを特定します。 1 秒あたりの要求数とデータベースの CPU 使用率は、容量の適切なインジケーターになる可能性があります。

  • データを視覚化する: グラフやプロットなどの視覚化を作成して、履歴データに関するより良い分析情報を得ることができます。 視覚化は、データのパターン、傾向、異常を特定し、ワークロードの動作をより明確に理解するのに役立ちます。

新しいワークロードを理解する

容量計画の新しいワークロードを理解することは、履歴データなしで将来のタスクのリソース要件を予測することです。 履歴データのない新しいワークロードの将来のニーズを予測することは、より困難な場合があります。 このプロセスにより、リソースを効率的に割り当て、ワークロードの導入時にワークロード目標に合わせて割り当てを調整できます。 次の推奨事項を検討してください。

  • 市場調査: 同様の製品またはサービスの需要を把握するための市場調査を実施すると、新しいワークロードの潜在的な需要に関する貴重な分析情報を提供できます。 この調査には、市場動向の分析、調査の実施、競合他社のオファリングの調査が含まれます。

  • 専門家の判断: 業界での経験を持つ分野の専門家または専門家からの入力は、新しいワークロードの需要を見積もるのに役立ちます。 彼らの専門知識と分析情報は、予測のための貴重な入力を提供できます。

  • パイロット プロジェクトまたはプロトタイプ: 小規模なパイロット プロジェクトまたはプロトタイプは、リアルタイムのデータとフィードバックを収集するのに役立ちます。 その後、このデータを使用して容量計画プロセスに通知し、予測需要を調整できます。

  • 外部データ ソース: 業界レポート、市場調査、顧客調査などの外部データ ソースは、新しいワークロードの需要を見積もるための追加情報を提供できます。 これらのソースは、顧客の好み、市場の傾向、潜在的な需要要因に関する貴重な分析情報を提供できます。

需要の予測

需要の予測には、ワークロード データを使用して、サービスまたは製品の将来のニーズを予測することが含まれます。 容量計画では、効率的なリソース割り当てを確保し、成長パターンを予測し、需要の急増の可能性に備えるために不可欠です。 将来の需要を予測するときは、データを使用して将来のニーズを理解します。 統計分析、傾向分析、または予測モデリング手法を、将来の需要を予測するために必要なデータに適用します。 これらの方法では、履歴または予想されるパターンが考慮され、予想されるワークロード需要の見積もりを提供するために将来に予測されます。 需要を予測するには、次の戦略を検討してください。

さまざまなシナリオを考慮する

容量計画を実行する場合は、発生する可能性のあるさまざまなシナリオを計画する必要があります。 この計画には、予測可能な成長パターンと予期しない需要の急増の両方が含まれている必要があります。 使用パターンは拡大または縮小できます。 有機 (多かれ少なかれユーザー) または無機 (イベントまたはセキュリティ インシデント) にすることができます。 使用変更の前に、重要な時点で容量計画を実行する必要があります。

  • 設計 (予測)
  • 通常のスパイク (8:00 AM サインイン ラッシュ)
  • 起動 (予測検証)
  • ビジネス モデルの変更
  • 買収または合併
  • マーケティング プッシュ
  • 季節的な変化
  • 機能の起動
  • 定期的

予測手法を使用する

サービスまたは製品の将来の需要を予測するには、統計分析、傾向分析、予測モデリングなどの手法を使用する必要があります。 これらの手法を使用する方法の概要を次に示します。

  • 統計分析: 統計メソッドを使用すると、履歴データ内のパターンとリレーションシップを明らかにするのに役立ちます。 これらのパターンを使用して、将来の需要を予測できます。 時系列分析、回帰分析、移動平均などの手法を使用して、データの傾向、季節性、その他のパターンを特定できます。

  • 傾向分析: 傾向分析では、履歴データを調べて一貫したパターンを特定し、それらのパターンを将来に推定します。 たとえば、過去 1 年間にワークロードの需要が 10% 増加した場合、この傾向の継続を予測できます。 過去の需要データを一定期間にわたって分析する場合は、増加または減少の傾向を特定できます。 これらの傾向は、将来の需要を予測するための基礎として使用します。 傾向分析では、トラフィックの急激なシフト (無機) を引き起こす 1 回限りのイベントの影響を特定することもできます。 たとえば、機能リリースによって需要が一貫して 5% 増加する可能性があります。 年に 4 つのメジャー リリースがある場合は、毎回 5% の成長を計画する必要があります。

  • 予測モデリング: 予測モデリングは、履歴データやその他の関連変数を使用して将来の需要に関する予測を行う数学モデルを構築するプロセスです。 機械学習アルゴリズム、ニューラル ネットワーク、デシジョン ツリーなどの手法を使用できます。 これらのモデルでは、複数の要因と変数を考慮して、より正確な予測を提供できます。

ワークロードの目標に合わせて予測を調整する

予測をワークロードの目標に合わせるには、特定のワークロードの特定の目標と要求を満たすように予測容量モデルを調整する必要があります。 この配置により、リソースが適切にプロビジョニングされ、過小使用と潜在的なワークロードのオーバーロードの両方が防止されます。 たとえば、100 万人のユーザーが 1 MB のファイルを 1 秒でアップロードするための API をサポートすることを目的としていても、現在のデータの書き込み速度が遅い場合は、システムを調整する必要があります。 ワークロードの要件を把握するには、利害関係者と話し合う必要があります。 プランがサービス プロバイダーの Promise (SLA) と一致していることを確認します。 この配置により、容量が予想される需要を満たし、変更が必要になる可能性があるシステムの領域を特定するのに役立ちます。

リソース要件を決定する

容量計画のリソース要件を決定するには、予測される需要を満たすために必要なリソースを評価する必要があります。 たとえば、プロモーション キャンペーン中にアプリケーションでユーザーの数が 50% 増加すると予想される場合は、より多くのクラウド インスタンスを割り当てるか、負荷の増加に対応するように自動スケーリング パラメーターを調整する必要があります。

ワークロードには多くのリソースを含めることができるため、リソース要件を決定するために観察するメトリックは 1 つもありません。 意味のある結果を得るには、リソース レベルで容量を測定する必要があります。 過去のデータ、市場の傾向、およびビジネス予測に基づいて、リソースに予想される需要を見積もります。 トランザクションの数、同時ユーザー、またはその他の関連メトリックを検討します。

予測された需要に基づいて、その需要を満たすために必要なリソースを計算します。 サーバー容量、ネットワーク帯域幅、ストレージ容量、担当者などの要因を考慮してください。

  • サーバー容量: 同時ユーザーまたはトランザクションの推定数に基づいて、必要なサーバー容量を決定します。 サーバーが予想されるワークロードを確実に処理できるように、CPU、メモリ、ディスク領域の要件などの要因を考慮してください。

  • ネットワーク帯域幅: 予想されるトラフィック レベルをサポートするために必要なネットワーク帯域幅を評価します。 サーバーとクライアント間の円滑で効率的な通信を確保するために、受信と送信の両方のデータ転送速度を含める必要があります。

  • ストレージ容量: 予測される需要の間にワークロードによって生成または処理されるデータの量を見積もります。 データベース サイズ、ファイル ストレージの要件、およびアプリケーションに固有のその他のデータ ストレージのニーズなどの要因を考慮してください。

  • 担当者: インフラストラクチャの管理と保守、カスタマー サポートの処理、システム メンテナンスの実行、円滑な運用の確保に必要な人材を評価します。 ワークロードの分散、スキル セット、必要な専門知識などの要因を考慮します。

リソースの制限事項を理解する

ワークロード内のリソースには、パフォーマンスの制限があります。 パフォーマンスの制限は、各サービス内のサービスと SKU に適用されます。 ワークロード内のリソースの制限事項を理解し、それらの制限事項を設計上の決定に組み込む必要があります。 たとえば、リソースの制限で SKU を変更するか、リソースを完全に変更する必要があるかを把握する必要があります。

到達可能な制限も特定する必要があります。 これは、ワークロードの最大しきい値または境界を特定することを指します。 これらの制限は通常、インフラストラクチャ (コンピューティング、メモリ、ストレージ、ネットワーク)、アプリケーション (同時実行データベース接続、応答時間、可用性)、サービス (1 秒あたりの要求数)、スケーリングに適用されます。 容量計画で到達可能な制限が特定された場合は、制限によってパフォーマンスの問題が発生する前にワークロードを変更する必要があります。 パフォーマンス ベースライン、継続的監視、テストは、制限とソリューションを検証するために不可欠です。

トレードオフ: 容量計画を誤って判断すると、リソースの過剰プロビジョニングやプロビジョニング不足につながる可能性があります。 過剰プロビジョニングを行うと、コストが高くなります。 プロビジョニングが不足すると、パフォーマンスが低下する可能性があります。 適切なバランスを見つけよう。

Azure ファシリテーション

容量データの収集と需要の予測: Azure Monitor を使用すると、アプリケーションとインフラストラクチャからテレメトリ データを収集して分析できます。 仮想マシン、コンテナー、ストレージ アカウントなど、さまざまな Azure リソースの監視がサポートされています。 主要なツールには 、Application Insights と Log Analytics が含まれます。 データ収集を構成し、監視するメトリックとログを定義することで、分析のために貴重なワークロード データを収集できます。 ネットワーク監視の場合は、Azure Monitor と Azure Network Watcher、Azure Monitor ネットワーク分析情報、Azure ExpressRoute 監視を組み合わせます。

Azure Monitor を使用すると、履歴データを分析し、予測手法を適用して、将来のワークロードの傾向と容量要件を予測できます。 容量計画に役立つ予測を生成できます。 これらの予測は、予測された需要パターンを使用して、サーバー容量、ネットワーク帯域幅、ストレージ容量、およびその他のリソース ニーズを見積もるのに役立ちます。

リソース要件の決定: さまざまな構成が提供されるため、Azure のツールとサービスは技術的な要件を定義するのに役立ちます。 ワークロードの要件を使用可能な Azure リソースに合わせ、機能ニーズに合わせて適切なコンポーネントと設定を選択できます。

リソースの制限事項について: Azure には、さまざまな Azure サービスと SKU のパフォーマンス制限を理解するのに役立つドキュメントとリソースが用意されています。 これらの制限事項を考慮すると、情報に基づいた設計上の決定を行い、パフォーマンスとコスト効率のためにワークロード アーキテクチャを最適化するのに役立ちます。

Azure には、ワークロードの需要に基づいてリソースを自動的に調整できる自動スケーリングなどのスケーラビリティ オプションが用意されています。 より大きな仮想マシン サイズを使用してリソースの容量を増やして垂直方向にスケーリングしたり、リソースの新しいインスタンスを追加して水平方向にスケーリングしたりできます。 自動スケーリング機能を備える Azure サービスは、ワークロードのピーク時に容量を確保し、負荷が減少したときに正常に戻るために自動的にスケールアウトできます。 構成とサービスには、注意する必要があるスケーリング制限があります。 ドキュメントを読んだり、テストを実行したりできます。 Azure には、ワークロードに関する関連データを収集するのに役立つ読み込みとさまざまな使用パターンをシミュレートできる Azure Load Testing などのツールが用意されています。

パフォーマンス効率のチェックリスト

推奨事項の完全なセットを参照してください。

パフォーマンス効率チェックリスト