容量要件を満たすように設計する
 予想される需要に対応するために十分な供給を提供します。 |
|---|
パフォーマンスを事前に測定することが重要です。 パフォーマンスを測定するには、ベースラインを測定し、システムのどのコンポーネントで課題が発生する可能性があるかを事前に理解する必要があります。 これは、完全なパフォーマンス テストを実行したり、きめ細かな最適化を行ったりすることなく実現できます。 これらの初期の手順を実行することにより、開発ライフサイクルの早い段階で、効果的なパフォーマンス管理のための基礎が確立されます。
個々のコンポーネントに焦点を絞るのではなく、システムを全体として調べます。 この段階での微調整は避けます。 きめ細かなパフォーマンスの向上を行うと、他の領域でトレードオフが発生します。 ライフサイクルを進め、ユーザー受け入れテストを開始したり、運用環境に移行したりしていくうちに、さらに最適化が必要な領域をすばやく識別できるようになります。
サンプル シナリオ
Contoso Manufacturing は、その製造プロセスを監視および最適化するために使用される、社内で使用する Java Spring ベースのマイクロサービス アプリを開発しました。 ワークロード チームは、現在オンプレミスでホストされているアプリを Azure に移行中です。
Azure でホストされるアプリは、Azure Spring Apps、Azure Database for MySQL、Azure IoT Hub の上に構築されます。 Contoso には、Azure への ExpressRoute 接続が存在します。
ワークロードを効果的に設計する
テクノロジ スタック全体にわたる適切なリソースを選択します。これにより、パフォーマンス目標を満たし、システムと統合することが可能になります。 予期しないサージを効率的に処理するために、スケーラビリティの要件を満たすことができる機能を検討し、リソースの割り当てとシステム要件の間の適切なバランスを見つけます。
リソースのさまざまな機能を分析することによって、各コンポーネントがシステムの全体的な機能やパフォーマンスに寄与していることが確認されるため、利用できるスケーリング機能を識別できます。
リソースのサイズを適切に設定すると、オーバープロビジョニングなしに需要の変化を満たすことができるため、コスト削減につながります。
Contoso の課題
- 既存のオンプレミス アプリ環境インフラストラクチャは Contoso によって完全に管理されているため、チームに大きな負担がかかります。 現在は、サーバー、ネットワーク、ストレージなどをプロビジョニングして維持するだけでなく、Java Spring サービス ランタイムやすべての依存関係を構成および更新しています。
- チームは、Azure Spring Apps を使用して PaaS モデルに移行することを期待しています。これにより、チームはそのエネルギーのより多くを、アプリケーションが意図されたビジネス価値を確実に提供することに集中させ、インフラストラクチャの管理に費やす時間を減らすことができます。
- このアプリケーションは Contoso のビジネスにとってきわめて重要であり、厳格なパフォーマンス要件があるため、これらの要件が移行の一部として行うテクノロジの選択によって確実に満たされるようにする必要があります。
アプローチの適用と結果
- 利用可能なさまざまなプランを比較した後、チームは、運用トラフィック向けに最適化された Spring Boot アプリ用のフル マネージド サービスを提供する Azure Spring Apps Standard プランを選択しました。 Standard プランは、アプリあたり最大 500 インスタンスという、予想される最大使用量のための十分なコンピューティング容量を提供できます。
- さらに、このサービスは必要に応じてスケールアウトするように構成でき、追加の容量が必要なくなるとコンピューティング リソースをスケールインします。
- チームは、アプリあたり 1000 インスタンスにスケールアップできる Enterprise プランを検討しましたが、この時点でその容量までは必要ないと判断しました。 また、Enterprise プランが提供するサポートのレベルや、その他の専用機能も必要がないことを確信しています。
容量のニーズを適切に予測する
需要と選択されたリソースの機能に基づいて容量計画を行い、パフォーマンス モデルを強化します。 予測モデリング手法を使用して、予測可能な変更や予期しない変更で発生する可能性のある、容量の予想される変化を予測します。 技術的な要件に変換できるパフォーマンス ターゲットを定義します。
このアプローチを採用することにより、リソースを効率的に使用し、オーバープロビジョニングなしに需要を満たすことができ、それによって不必要なコストが回避されます。 さらに、設計の選択がパフォーマンスにどのような影響を与えるかを理解するのにも役立ちます。
Contoso の課題
- 生産機械の効率的な使用を最大化するために、Contoso の生産ラインは周期的なスケジュールで稼働し、1 日の中の異なる時間にさまざまな製品を生産しています。
- 各製品には異なる操作が必要であるため、制御アプリケーションにはさまざまなコンピューティング ニーズが発生します。 製品間の切り替え中に、制御アプリケーションは、以前の運用実行のデータの分析や機械の制御アルゴリズムの更新などの、コンピューティング容量の増加を必要とするさまざまなタスクを実行する必要があります。
アプローチの適用と結果
- 切り替え期間中のより高い需要を満たすために、チームはまず、切り替え機能を処理するフローを識別した後、それらのパフォーマンス要件を文書化し、オンプレミス バージョンのアプリケーションに基づいてトランザクションの量を見積もります。 このデータを利用して、チームは、ターゲット フローの一部であるマイクロサービスに必要なコンピューティング容量の見積もりに進みます。
- これらのコンポーネントに対して自動スケーリングが構成され、追加のリソースが確実に切り替え期間の前にプロビジョニングされ、タスクが完了した後に解放されるようになります。
- 自動スケーリングの設定は、新しい環境での実際のパフォーマンスに基づいて、アプリを運用環境にデプロイする前に調整されます。
概念実証デプロイ
技術的な要件と設計の選択を検証する概念実証 (POC) を実装します。
概念実証は、設計を検証して、システムがパフォーマンス ターゲットを満たすことができるかどうか、またそれらのターゲットが現実的であるかどうかを判定するのに役立ちます。 予想される負荷に基づいて、予想される容量がパフォーマンス ターゲットを満たすことができるかどうかを検証できます。
また、設計の選択のコストへの影響も確認します。
Contoso の課題
- 開発中に、チームは、デバイス シミュレーターを使用してアプリケーション機能の広範囲にわたる負荷およびパフォーマンス テストを実行しており、これらの情報を使用して自動スケーリング構成を最適化しています。
- 自動スケーリング構成の有効性に影響を与える可能性がある 1 つの側面として、Azure Spring Apps 環境から、ExpressRoute 経由で Azure に接続されている製造フロア内の IoT デバイスに通信しているときの潜在的なネットワーク待機時間があります。 チームは、オンプレミス バージョンのアプリの場合より Azure での方が待機時間は長くなること、またその待機時間が時刻やデバイスの場所などの他の要因にも影響を受ける可能性があると推測しています。
- 待機時間の増加は、各マイクロサービス インスタンスが処理できるトランザクションの量に影響を与える可能性があります。
アプローチの適用と結果
- チームは、POC を Azure にデプロイしてその仮説を検証し、構成を最適化するために使用できるメトリックを収集することを決定しました。 彼らは、製造フロア全体に分散した IoT デバイスと通信するためのテスト用の Azure Spring App を構築します。 IoT デバイスはオンプレミス ネットワークに接続され、Azure IoT Hub に登録されています。 テスト アプリケーションは、単純な ping を送信することによって 1 日中ランダムにデバイスに接続し、応答を受信するのにかかった時間を記録します。
- この POC 中にキャプチャされたデータをロード テストの結果と組み合わせると、チームは初期の運用立ち上げを準備するときに、必要なコンピューティング容量をより正確に見積もることができます。
- チームはまた、POC からの学習に基づいてより現実的な応答時間をシミュレートするために、ロード テストに使用されるテスト ケースをさらに改善する方法も検討しています。