スケーリング コストを最適化するための推奨事項
次の Azure Well-Architected フレームワークのコストの最適化チェックリストの推奨事項に該当します。
| CO:12 | スケーリングのコストを最適化する。 スケール ユニット内の代替スケーリングを評価します。 代替のスケーリング構成を検討し、コスト モデルに合わせます。 考慮事項には、すべてのインスタンス、リソース、スケール ユニット境界の継承制限に対する使用率を含める必要があります。 需要と供給を制御するために戦略を使用します。 |
|---|
このガイドでは、スケーリング コストを最適化するための推奨事項を示します。 コストを最適化するスケーリングは、ワークロードのスケーリングにおける非効率性を取り除くプロセスです。 目標は、すべての非機能要件を満たしたままで、スケーリング コストを削減することです。 支出を減らして同じ結果を得ます。 スケーリングを最適化することで、不要な費用、オーバープロビジョニング、無駄を回避できます。 また、需要を制御し、供給を制限することで、コストの予期せぬ急増を防ぐのにも役立ちます。 非効率的なスケーリング プラクティスは、ワークロードと運用コストの増加につながる可能性があり、ワークロードの全体的な財務状態に悪影響を与える可能性があります。
定義
| 相談 | 定義 |
|---|---|
| 自動スケール | 一連の条件が満たされたときにリソースを自動的に追加または削除するスケーリング アプローチ。 |
| コスト メトリック | ワークロード コストに関連する数値データ。 |
| スケールダウン | ワークロードに提供するリソースを減らすためにより低い SKU に移行する垂直スケーリング戦略。 |
| スケールイン | ワークロードに提供するリソースを減らすためにインスタンスを削除する水平スケーリング戦略。 |
| スケール アウト | ワークロードにより多くのリソースを提供するためにインスタンスを追加する水平スケーリング戦略。 |
| スケール ユニット | 同時に比例スケーリングするリソースのグループ。 |
| スケールアップ | ワークロードにより多くのリソースを提供するためにより高い SKU に移行する垂直スケーリング戦略。 |
| Stock Keeping Unit (SKU) | Azure サービスのサービス レベル。 |
| 使用状況データ | 使用状況データは、タスク、サービス、またはアプリケーションがどれだけ使用されているかに関する、直接的な情報 (実際) または間接的または代表的な情報 (プロキシ) のいずれかです。 |
主要な設計戦略
スケーリングのコスト最適化の目標は、最終責任時点でスケール アップおよびスケール アウトし、実行可能になり次第スケール ダウンおよびスケール インすることです。 ご利用のワークロードのスケーリングを最適化するには、スケール ユニット内の代替スケーリング オプションを評価し、それらをコスト モデルと合致させます。 スケール ユニットは、個別に、または同時にスケーリングできるリソースの特定のグループを表します。 特定の負荷量に対応できるようにスケール ユニットを設計します。また、スケール ユニットは、複数のインスタンス、サーバー、またはその他のリソースで構成できます。 ワークロードのスケール ユニットとモデル代替のコスト効率を評価する必要があります。
スケーリングを使用しない場合は、「ワークロードのスケーリング」に関するガイダンスを参照してください。 アプリケーションがスケーリングできるかどうかを判断する必要があります。 ステートレス アプリケーションは複数の要求を同時に処理できるため、スケーリングが容易になります。 また、分散システムの原則を使用してアプリケーションが構築されているかどうかを評価します。 分散システムでは、ワークロードを複数のノードに分散することで、負荷の増加に対応できます。 しかし、シングルトン アプリケーションは、特定の時点で 1 つのインスタンスのみを実行するように設計されています。 そのため、スケーリングはすべてのワークロードには適していない場合があります。
スケールアウトとスケールアップを比較評価する
スケールアウトとスケールアップを評価するには、価格、ワークロード要件、許容されるダウンタイムなどのさまざまな要因に基づいて、既存のシステム内のリソースを増やす (スケールアップする) か、そのシステムのインスタンスを追加する (スケールアウトする) のどちらが最もコスト効率の高いアプローチであるかを決定する必要があります。 適切なスケーリング アプローチを選択すると、大幅な節約につながる可能性があり、必要な分だけ支払いながらパフォーマンスと信頼性の標準を満たすことができます。
目標は、サービス レベルの価格、ワークロードの特性、許容されるダウンタイム、コスト モデルに基づいて、最もコスト効率の高い選択肢を判別することです。 場合によっては、より少ない数のより高価なインスタンスを選択する方が経済的な場合があります。 逆に、他の場合では、インスタンス数が多い低いレベルの方が適している可能性があります。 情報に基づいた意思決定を行うには、お使いのセットアップの実際のデータまたは代表的なデータを分析し、各戦略の相対的なコスト メリットを評価する必要があります。 最もコスト効率の高いアプローチを評価するには、次の推奨事項を検討してください。
"使用状況データを収集する": ワークロードの使用パターンとリソース使用率を表す実際の運用データまたはプロキシ データを収集します。 このデータには、CPU 使用率、メモリ使用量、ネットワーク トラフィックなどのメトリック、および、スケーリングのコストに影響を与えるその他の関連メトリックが含まれている必要があります。
"コスト メトリックを定義する": 1 時間あたりのコスト、トランザクションあたりのコスト、リソース使用量の単位あたりのコストなど、ワークロードに関連するコスト メトリックを特定します。 これらのメトリックは、さまざまなスケーリング オプションのコスト効率を比較するのに役立ちます。
"使用状況データを収集する": ワークロードの使用パターンとリソース使用率を表す実際の運用データまたはプロキシ データを収集します。 このデータには、CPU 使用率、メモリ使用量、ネットワーク トラフィックなどのメトリック、および、スケーリングのコストに影響を与えるその他の関連メトリックが含まれている必要があります
"コスト メトリックを定義する": 1 時間あたりのコスト、トランザクションあたりのコスト、リソース使用量の単位あたりのコストなど、ワークロードに関連するコスト メトリックを特定します。 これらのメトリックは、さまざまなスケーリング オプションのコスト効率を比較するのに役立ちます。
"要件を参照する": スケールアウト戦略とスケールアップ戦略のどちらを選択するかを決定する場合は、ワークロードの信頼性、パフォーマンス、スケーリングの要件を考慮してください。 スケールアウトすると、冗長性によって信頼性が向上します。 スケールアップすると、リソースの容量が増えますが、スケールアップできる容量に制限がある可能性があります。
"リソースの制限を考慮する": スケーリング オプションを評価するときは、すべてのインスタンス、リソース、スケール ユニット境界に固有の制限を考慮することが重要です。 各リソースのスケーリングの上限に注意し、それに応じて計画してください。 さらに、サブスクリプションやその他のリソースの制限に注意してください。
"スケーリングをテストする": スケールアウトやスケールアップのオプションなど、さまざまなスケーリング シナリオのテストを作成します。 使用状況データを適用し、さまざまなスケーリング構成でワークロードの動作をシミュレートします。 モデル化されたスケーリング シナリオを使用して、実際のテストを実施します。
"コストを計算する": 収集されたデータとコスト メトリックを使用して、各スケーリング構成に関連するコストを計算します。 インスタンスの価格、リソース使用率、スケーリングに関連する追加コストなどの要因を考慮してください。
自動スケールの最適化
自動スケーリング ポリシーを最適化するには、ワークロードの非機能要件に基づいて負荷の変更に対応するように自動スケーリングを調整することが必要です。 しきい値を調整し、適切なクールダウン期間を使用することで、過剰なスケーリング アクティビティを制限できます。 自動スケーリングを最適化するには、次の推奨事項を検討してください。
"現在の自動スケーリング ポリシーを分析する": 既存のポリシーと、さまざまな負荷レベルに対応しての動作について理解します。
"非機能要件を参照する": 応答時間、リソース使用率、コストなど、考慮する必要がある特定の非機能要件を特定します。
"スケーリングのしきい値を調整する": ワークロードの特性と非機能要件に基づいてスケーリングのしきい値を調整します。 時間の経過に伴う CPU 使用率、ネットワーク トラフィック、キューの長さなどの要因に基づいて、スケールアップまたはスケールダウンのしきい値を設定します。
"クールダウン期間を調整する": 一時的な負荷の急増によってトリガーされる過剰なスケーリング アクティビティを防ぐために、クールダウン期間を調整します。 クールダウン期間では、イベントのスケーリング間に遅延を導入し、さらなるスケーリング アクションの前にシステムが安定するようにします。
"監視と微調整を行う": システムの動作とパフォーマンスを継続的に監視します。 スケーリング アクティビティを分析し、必要に応じてポリシーを調整してコストを最適化し、目的の非機能要件を達成します。
トレードオフ: スケーリング イベントの数を減らすと、スケーリングに関連する問題が発生する可能性が高くなります。 これは、潜在的な問題やスケーリングによる遅延を管理するのに役立つ可能性のある追加のクッションやバッファーが排除されることを意味します。
イベントベースのスケーリングを使用する
イベント ドリブンの自動スケーリングを使用すると、アプリケーションは、CPU やメモリの使用率などの従来のメトリックではなく、特定のイベントまたはトリガーに基づいてリソースを動的に調整できます。 たとえば、Kubernetes イベント ドリブン自動スケーリング (KEDA) では、Kafka トピックの長さなどのスケーラーに基づいてアプリケーションをスケーリングできます。 精度は、不要なスケーリングの変動やリソースの無駄を防ぐのに役立ちます。 高い精度によって、最終的にコストが最適化されます。 イベントベースのスケーリングを使用するには、次の手順に従います。
"イベント ソースの選択": スケール ユニットのスケーリングをトリガーするイベント ソースを決定します。 ソースには、メッセージ キュー、ストリーミング プラットフォーム、またはその他のイベント ドリブン システムを指定できます。
"イベント インジェストを設定する": 選択したイベント ソースからのイベントを使用するようにアプリケーションを構成します。 これには、通常、接続の確立、関連するトピックまたはキューのサブスクライブ、受信イベントの処理が含まれます。
"スケーリング ロジックを実装する": 受信イベントに基づいてスケール ユニットをスケーリングするタイミングと方法を定めるロジックを記述します。 このロジックでは、イベントの数、受信イベントのレート、その他の関連メトリックなどの要因を考慮する必要があります。
"スケーリング メカニズムと統合する": アプリケーションのランタイム環境に応じて、さまざまなスケーリング メカニズムを使用して、アプリケーションに割り当てられているリソースを調整できます。
"スケーリング ルールを構成する": イベントに応じてスケール ユニットをスケーリングする方法を指定するスケーリング ルールを定義します。 これらのルールは、しきい値、パターン、またはアプリケーションの要件に合ったその他の条件に基づいて行うことができます。 スケーリングのしきい値は、ビジネス メトリックに関連している必要があります。 たとえば、さらに 2 つのインスタンスを追加した場合、ショッピング カート処理においてさらに 50 人のユーザーをサポートできます。
"テストと監視を行う": さまざまなイベント シナリオでテストすることで、イベントベースのスケーリング実装の動作を検証します。 スケーリング アクションを監視し、アクションが期待に沿っていることを確認します。
需要と供給を最適化する
供給に対する需要を制御します。 使用量によってスケーリングが決定されるワークロードでは、コストはスケーリングと関連します。 スケーリングのコストを最適化するには、スケーリングの支出を最小限に抑えることができます。 需要を他のリソースに分散することで需要をオフロードすることや、優先順位キュー、ゲートウェイ オフロード、バッファリング、レート制限を実装することで需要を減らすことができます。 どちらの方法でも、スケーリングとリソース消費による望ましくないコストを防ぐことができます。 スケーリング限度に上限を設けることで、供給を制御することもできます。 ワークロードの需要と供給を最適化するには、次の推奨事項を検討してください。
需要をオフロードする
需要のオフロードとは、リソースの需要を他のリソースまたはサービスに、分散または転送する慣習を指します。 さまざまなテクノロジや戦略を使用できます。
"キャッシュ": キャッシュを使用して、頻繁にアクセスされるデータまたはコンテンツを保存し、バックエンド インフラストラクチャの負荷を軽減します。 たとえば、コンテンツ配信ネットワーク (CDN) を使用して静的コンテンツのキャッシュと提供を行って、バックエンドのスケーリングの必要性を減らします。 ただし、すべてのワークロードでデータをキャッシュできるわけではありません。 取引やゲームのワークロードなど、最新でリアルタイムのデータを必要とするワークロードでは、キャッシュを使用しないでください。 キャッシュされたデータは古く、ユーザーには関係ありません。
トレードオフ。 キャッシュでは、キャッシュの無効化、整合性、キャッシュの有効期限の管理に関する課題が生じる可能性があります。 潜在的なトレードオフを回避するために、キャッシュ戦略を慎重に設計し実装することが重要です。"コンテンツ オフロード": インフラストラクチャのワークロードを減らすために、外部サービスや外部プラットフォームにコンテンツをオフロードします。 たとえば、プライマリ サーバーにビデオ ファイルを保存するのではなく、プライマリ サーバーから独立した別のストレージ サービスでこれらのファイルをホストできます。 これらの大きなファイルを、ストレージ サービスから直接読み込むことができます。 この方法により、サーバー上のリソースが解放され、小規模なサーバーを使用できるようになります。 大きなファイルを別のデータ ストアに保存する方が安価な場合があります。 CDN を使用してパフォーマンスを向上させることができます。
"負荷分散": 負荷分散を使用して、受信要求を複数のサーバーに分散します。 負荷分散によってワークロードが均等に分散され、単一のサーバーが負荷過剰になるのを防ぐことができます。 ロード バランサーはリソース使用率を最適化し、インフラストラクチャの効率を向上させます。
"データベース オフロード": データベース操作を別のデータベース サーバーまたは専用サービスにオフロードすることで、メイン アプリケーション サーバーの負荷を軽減します。 たとえば、静的コンテンツ キャッシュには CDN を使用し、動的コンテンツ (データベースからのデータ) キャッシュには Redis Cache を使用します。 データベース シャーディング、読み取りレプリカ、マネージド データベース サービスの使用などの手法でも、負荷を軽減できます。
トレードオフ: 特定のタスクを代替リソースにオフロードすることは、追加のスケーリングとスケーリング関連コストの削減または回避に役立ちます。 ただし、オフロードすることによって発生する可能性のある運用上およびメンテナンス上の課題を考慮することが重要です。 自分のワークロードに最適なオフロード手法を選択する際には、包括的なコスト メリット分析を行う必要があります。 この分析により、予想される節約と運用の複雑さに関連して、選択した方法が効率的かつ実行可能であることが保証されます。
需要を削減する
リソースの需要を減らすことは、ワークロードでのリソース使用率を最小限に抑えるのに役立つ戦略を実装することを意味します。 需要をオフロードすると、需要が他のリソースにシフトします。 需要を減らすと、ワークロードに対する需要が減少します。 需要を減らすと、リソースの過剰なプロビジョニング、および未使用や使用率が低い容量に対する支払いを回避することができます。 コード レベルの設計パターンを使用して、ワークロード リソースに対する需要を減らす必要があります。 設計パターンを使用して需要を減らすには、次の手順に従います。
"設計パターンを理解する": リソースの最適化を促進するさまざまな設計パターンについて理解します。
"ワークロードの要件を分析する": 予想される需要パターン、ピーク時の負荷、リソースのニーズなど、ワークロードの特定の要件を評価します。
"適切な設計パターンを選択する": ワークロードの要件と目標に合った設計パターンを選択します。 たとえば、ワークロードで需要が変動する場合、イベント ドリブンのスケーリングと要求調整パターンは、リソースを動的に割り当てることでワークロードを管理するのに役立ちます。 選択した設計パターンをワークロード アーキテクチャに適用します。 ワークロード コンポーネントの分離、アプリケーションのコンテナー化、ストレージ使用率の最適化などが必要になる場合があります。
"継続的な監視と最適化を行う": 実装された設計パターンの有効性を定期的に評価し、必要に応じて調整します。 リソースの使用状況、パフォーマンス メトリック、コスト最適化の機会を監視します。
これらの手順に従って適切な設計パターンを使用することで、リソースの需要を削減し、コストを最適化し、ワークロードの効率的な運用を確保できます。
需要を減らすには、次の設計パターンを使用します。
"キャッシュ アサイド": パターンはキャッシュをチェックして、データが既にメモリに保存されているかどうかを確認します。 キャッシュ内にデータが見つかった場合、アプリケーションはデータをすばやく取得して返すことができるので、永続的なデータ ストアに対してクエリを実行する必要が減ります。
"要求チェック": このパターンでは、メッセージング フローからデータを分離することでメッセージのサイズが小さくなり、よりコスト効率の高いメッセージング ソリューションがサポートされます。
"競合コンシューマー": このパターンは、分散処理と同時処理を適用することで、キュー内の項目を効率的に処理します。 この設計パターンでは、キューの深さに基づいてスケーリングし、同時コンシューマー インスタンスの最大数に制限を設定することで、コストを最適化します。
"コンピューティング リソースの統合": このパターンでは、共有インフラストラクチャ上の複数のアプリケーションまたはコンポーネントを組み合わせることで、密度が向上し、コンピューティング リソースが統合されます。 リソース使用率を最大化し、未使用のプロビジョニング済み容量を回避し、コストを削減します。
"デプロイ スタンプ": デプロイ スタンプの使用では、デバイスのグループの地理的分散、特定のスタンプへの新機能の展開、デバイスあたりのコストの監視など、いくつかの利点があります。 デプロイ スタンプを使用すると、スケーラビリティ向上、フォールト トレランス、および効率的なリソース使用率が可能になります。
"ゲートウェイ オフロード": このパターンは、ゲートウェイ デバイスでの要求処理をオフロードし、ノードごとのリソースからゲートウェイの実装にコストをリダイレクトします。 この設計パターンを使用すると、一元化された処理モデルにおける保有コストが低くなる可能性があります。
"パブリッシャー/サブスクライバー": このパターンにより、アーキテクチャ内のコンポーネントが分離され、直接通信が中間メッセージ ブローカーまたはイベント バスに置き換えられます。 これにより、イベント ドリブンのアプローチと消費ベースの課金が可能になり、オーバー プロビジョニングを回避できます。
"キューベースの負荷平準化": パターンは、キュー内の受信要求またはタスクをバッファーします。 バッファリングによってワークロードがスムーズになり、ピーク時の負荷を処理するためのリソースのオーバープロビジョニングの必要性が軽減されます。 受信要求は、コストを削減するために非同期的に処理されます。
"シャーディング": このパターンは、特定の要求を論理宛先に転送し、データ コロケーションを使用した最適化を可能にします。 シャーディングは、低スペックのコンピューティング リソースまたはストレージ リソースの複数のインスタンスを使用することで、コスト削減につながる可能性があります。
"静的コンテンツ ホスティング": このパターンは、この目的のために設計されたホスティング プラットフォームを使用して、静的コンテンツを効率的に配信します。 より高価な動的アプリケーション ホストの使用を回避し、リソース使用率を最適化します。
"要求調整": このパターンでは、リソースまたはコンポーネントへの受信要求のレート (レート制限) またはスループットに制限が設定されます。 これはコスト モデリングの通知に役立ち、アプリケーションのビジネス モデルに直接関連付けることができます。
"バレット キー": このパターンにより、より多くのコンポーネントを必要とせずに、リソースへの安全で排他的なアクセスが許可され、中間リソースの必要性が減り、効率が向上します。
電源を制御する
特定のリソースまたはサービスに費やす金額の上限を定義することは、供給を制御する 1 つの方法です。 これは、コストを制御し、経費が一定のレベルを超えないようにするための重要な戦略です。 予算を設定し、支出を監視して、定義された金額内に収まるようにします。 コスト管理プラットフォーム、予算アラート、または使用状況と支出パターンの追跡を使用できます。 一部のサービスでは、供給レートを調整してレートを制限できます。これらの機能は役に立つ場合に使用する必要があります。
供給の制御とは、特定のリソースまたはサービスに費やす金額の上限を定義することを指します。 これは、コストを制御する、および経費が一定のレベルを超えないことを保証するのに役立つため、重要な戦略です。 予算を設定し、支出を監視して、その定義されたしきい値内に収まることを保証します。 コスト管理プラットフォーム、予算アラート、または使用状況と支出パターンの追跡を使用できます。 一部のサービスでは、供給レートを調整してレートを制限できます。これらの機能は役に立つ場合に使用する必要があります。
Azure ファシリテーション
スケールアウトとスケールアップの評価: Azure には、さまざまなスケーリング構成をデプロイしてテストできるテスト環境が用意されています。 実際のワークロード データまたはプロキシ データを使用して、実際のシナリオをシミュレートし、コストへの影響を測定できます。 Azure には、パフォーマンス テスト、ロード テスト、監視用のツールとサービスが用意されています。これは、スケールアウト オプションとスケールアップ オプションのコスト効率を評価するのに役立ちます。
Azure では、Azure Advisor など、さまざまなツールとサービスを通じてコスト管理に関する推奨事項が提供されます。 これらの推奨事項は、使用パターン、リソース使用率、スケーリング構成を分析してコストを最適化するための分析情報と提案を提供します。
Azure Load Testing は、大規模な負荷を生成できるフル マネージドのロード テスト サービスです。 サービスは、アプリケーションがどこにホストされているかにかかわらず、そのトラフィックをシミュレートします。 開発者、テスト担当者、品質保証 (QA) エンジニアは、ロード テストを使って、アプリケーションのパフォーマンス、スケーラビリティ、または容量を最適化できます。
自動スケールの最適化: 多くの Azure コンピューティング サービスでは、複数の同一インスタンスのデプロイと、スケーリングのしきい値とポリシーの迅速な調整がサポートされています。 Azure には自動スケーリング機能が用意されています。これにより、ワークロードの需要に基づいてインスタンスまたはリソースの数を自動的に調整できます。 スケーリング規則としきい値を定めて、スケールアウト アクションまたはスケールイン アクションをトリガーできます。 自動スケーリングを使用すると、実際の需要に基づいてリソースを動的にスケーリングすることにより、リソースの割り当てとコスト効率を最適化できます。
Azure では、サブスクリプションとサービスの制限の一覧が管理されています。一部の例外を除き、各リソース グループにデプロイできるリソースのインスタンスの数には一般的な制限があります。 詳細については、「リソース グループあたりのリソース インスタンスの制限」を参照してください。
需要と供給の最適化: Azure Monitor は、アプリケーションとインフラストラクチャのパフォーマンスと正常性に関する分析情報を提供します。 Azure Monitor を使用して、リソースの負荷を監視し、時間の経過に伴う傾向を分析できます。 Azure Monitor によって収集されたメトリックとログを使用して、スケーリングの調整が必要な領域を特定できます。 この情報は、機能以外の要件とコスト最適化の目標に合わせて自動スケーリング ポリシーを調整するためのガイドとなります。
"供給のオフロード": Azure には、 Azure Front Door と呼ばれる最新のクラウド コンテンツ配信ネットワーク (CDN) とキャッシュ サービス (Azure Cache for Redis と Azure HPC Cache) があります。 CDN はエンド ユーザーに近いコンテンツをキャッシュし、ネットワーク待ち時間を短縮し、応答時間を向上させます。 キャッシュでは、データのコピーがメイン データ ストアの前に保存されるため、バックエンドへの要求を繰り返す必要が減ります。 CDN とキャッシュ サービスを使用すると、パフォーマンスを最適化し、潜在的なコスト削減のためにサーバーの負荷を軽減できます。
"供給の制御": Azure では、クラウド ワークロードのリソース制限を設定することもできます。 リソースの制限を定義することで、ワークロードが割り当てられたリソース内に留まっていることを確認し、不要なコストを回避できます。 Azure には、クォータ、ポリシー、予算アラートなどのリソース制限を設定するためのさまざまなメカニズムが用意されています。 これらのメカニズムは、リソースの使用状況を監視および制御するのに役立ちます。
API Management では、要求のレート制限と調整を行うことができます。 受信要求のスロットルは、Azure API Management の重要な役割の 1 つです。 要求のレートや転送される要求/データの合計を制御できるため、API プロバイダーは API Management を使用して、さまざまな API 成果物階層に対する値の不正使用や作成から API を保護できます。
関連リンク
- ワークロードをスケーリングする
- Azure Advisor のコストに関する推奨事項
- Azure のロード テストとは
- Azure サブスクリプションとサービスの制限、クォータ、制約
- リソース グループあたり 800 インスタンスに制限されないリソース
- Azure Front Door とは
- Azure Cache for Redis とは
- Azure HPC Cache とは
- Azure API Management を使用した高度な要求スロットル
コスト最適化チェックリスト
レコメンデーションの完全なセットを参照してください。