容量計画のためのアーキテクチャ戦略

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

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

定義

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

容量データを収集する

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

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

キャパシティ プランニングのために既存のワークロードを理解するには、ワークロードがリソースをどのように利用しているかに関する履歴データを分析する必要があります。 これには、リソース使用率、パフォーマンス データ、ワークロード パターンなどのメトリックが含まれます。 これを理解することで、効率的なリソース割り当てが保証され、ビジネス目標が技術要件に変換され、潜在的なボトルネックを特定するのに役立ちます。

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

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

• 主要な指標を特定する: キャパシティ プランニングに関連するメトリックを特定します。 メトリックには、CPU 使用率、メモリ使用量、ネットワーク スループット、応答時間が含まれます。

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

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

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

キャパシティ プランニングのための新しいワークロードを理解するということは、履歴データなしで将来の タスク のリソース要件を予測することを意味します。 履歴データなしで新しいワークロードの将来のニーズを予測することは、より困難な場合があります。 このプロセスにより、ワークロードが導入されたときに、リソースを効率的に割り当て、ワークロード目標に合わせて 位置を合わせる 割り当てを行うことができます。 次の推奨事項を検討してください。

• 市場調査: 類似の製品やサービスの需要を把握するための市場調査を実施することで、新しいワークロードに対する潜在的な需要に関する貴重な洞察を得ることができます。 この研究には、市場動向の分析、アンケートの実施、競合他社の製品・サービスの調査が含まれます。

• 専門家の判断: 業界経験のある専門家やプロフェッショナルからの意見は、新しいワークロードの需要を見積もるのに役立ちます。 彼らの専門知識と分析情報は、予測のための貴重な情報を提供することができます。

• パイロット プロジェクトまたはプロトタイプ: 小規模なパイロット プロジェクトまたはプロトタイプは、リアルタイムのデータとフィードバックを収集するのに役立ちます。 このデータを使用して、キャパシティ プランニング プロセスに情報を提供し、予測される需要を調節することができます。

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

需要の予測

需要予測には、ワークロード データを使用してサービスまたは製品の将来のニーズを予測することが含まれます。 キャパシティ プランニングでは、効率的なリソース割り当てを確保し、成長パターンを予測し、潜在的な需要の急増に備えることが不可欠です。 将来の需要を予測するときは、データを使用して将来のニーズを把握します。 将来の需要を予測するには、統計分析、傾向分析、または予測モデリング手法をデータに適用します。 これらの方法では、過去のパターンや予測されるパターンを考慮に入れて将来を予測し、予想される作業負荷の需要を推定します。 需要を予測するには、次の戦略を検討します。

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

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

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

予測手法の使用

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

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

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

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

位置を合わせる ワークロード目標による予測

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

リソース要件を決定する

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

ワークロードには多くのリソースが含まれる可能性があるため、リソース要件を決定するために監視する単一のメトリックは存在しません。 有意義な結果を得るには、リソース レベルで容量を測定する必要があります。 履歴データ、市場動向、ビジネス予測に基づいて、リソースの予想される需要を見積もります。 トランザクション数、同時ユーザー数、その他の関連する指標を考慮してください。

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

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

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

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

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

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

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

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

トレードオフ: キャパシティ プランニングの誤った判断は、リソースの過剰または不足につながる可能性があります。 過剰プロビジョニングにより、コストが高くなります。 プロビジョニングが不足すると、パフォーマンスが低下する可能性があります。 適切なバランスを見つけるようにしてください。

Azure ファシリテーション

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

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

大規模な履歴データセットを含む複雑な分析ワークロードの場合、 Log Analytics 検索ジョブ を使用すると、リアルタイムの監視パフォーマンスに影響を与えることなく、長期保有期間にわたってデータの非同期クエリを実行できます。 検索ジョブでは、結果用の専用の分析テーブルが作成されるため、分析ワークロードを運用監視から分離できます。 この機能は、傾向分析や予測などの詳細な履歴分析を必要とする容量計画アクティビティに特に価値があり、日々の監視操作に最適なパフォーマンスを維持します。

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

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

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

ワークロード間で 仮想ネットワーク フロー ログ を有効にして、ネットワーク アクティビティに関するデータをキャプチャします。 トラフィック分析を使用してこれらのログを分析および強化し、ユーザー フローの動作とパフォーマンスを可視化します。 トラフィック分析は、上位の話者、帯域幅のホットスポット、ルーティングの非効率性を特定することで、ネットワーク リソースの割り当てを最適化し、よりスマートな容量計画を実現するのに役立ちます。

関連リンク

• Azure Monitor
• Application Insights
• Log Analytics
• ネットワーク監視サービス

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

完全なレコメンデーションのセットを参照してください。