スケーリング コストを最適化するための推奨事項

この Azure Well-Architected Framework のコスト最適化チェックリストの推奨事項に適用されます。

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 キャッシュを使用します。 データベース シャーディング、読み取りレプリカ、マネージド データベース サービスの使用などの手法を使用すると、負荷を軽減することもできます。

    トレードオフ: 特定のタスクを代替リソースにオフロードすると、スケーリングに関連する追加のスケーリングとコストの削減または回避に役立ちます。 ただし、オフロードによって発生する可能性のある運用とメンテナンスの課題を考慮することが重要です。 ワークロードに最適なオフロード手法を選択する場合は、包括的なコストメリット分析を実施することが重要です。 この分析により、選択した方法は、予想される節約と運用の複雑さに関連して効率的かつ実行可能であることが保証されます。

需要の削減

リソースの需要を減らすことは、ワークロードでのリソース使用率を最小限に抑えるのに役立つ戦略を実装することを意味します。 需要をオフロードすると、需要が他のリソースにシフトします。 需要を減らすと、ワークロードに対する需要が減少します。 需要を減らすと、リソースのプロビジョニングが過剰になり、未使用または使用率の低い容量に対する支払いを回避できます。 コード レベルの設計パターンを使用して、ワークロード リソースの需要を減らす必要があります。 設計パターンを使用して需要を減らすには、次の手順に従います。

  • 設計パターンを理解する: リソースの最適化を促進するさまざまな設計パターンについて理解します。

  • ワークロードの要件を分析する: 予想される需要パターン、ピーク時の負荷、リソースのニーズなど、ワークロードの特定の要件を評価します。

  • 適切な設計パターンを選択する: ワークロードの要件と目標に合った設計パターンを選択します。 たとえば、ワークロードの需要が変動する場合、イベント ドリブンのスケーリングと調整パターンは、リソースを動的に割り当てることでワークロードを管理するのに役立ちます。 選択した設計パターンをワークロード アーキテクチャに適用します。 ワークロード コンポーネントの分離、アプリケーションのコンテナー化、ストレージ使用率の最適化などが必要になる場合があります。

  • 継続的な監視と最適化: 実装された設計パターンの有効性を定期的に評価し、必要に応じて調整します。 リソースの使用状況、パフォーマンス メトリック、コスト最適化の機会を監視します。

これらの手順に従い、適切な設計パターンを使用することで、リソースの需要を削減し、コストを最適化し、ワークロードの効率的な運用を確保できます。

次の設計パターンを使用して、需要を減らします。

  • キャッシュアサイド: パターンはキャッシュをチェックして、データが既にメモリに格納されているかどうかを確認します。 キャッシュ内にデータが見つかった場合、アプリケーションはデータをすばやく取得して返すことができるので、永続的なデータ ストアに対してクエリを実行する必要が減ります。

  • 要求チェック: このパターンでは、メッセージング フローからデータを分離することで、メッセージのサイズを小さくし、よりコスト効率の高いメッセージング ソリューションをサポートします。

  • 競合コンシューマー: このパターンでは、分散処理と同時処理を適用することで、キュー内の項目を効率的に処理します。 この設計パターンでは、キューの深さに基づいてスケーリングし、同時コンシューマー インスタンスの最大数に制限を設定することで、コストを最適化します。

  • コンピューティング リソースの統合: このパターンでは、共有インフラストラクチャ上の複数のアプリケーションまたはコンポーネントを組み合わせることで、密度が向上し、コンピューティング リソースが統合されます。 これにより、リソース使用率が最大化され、未使用のプロビジョニング容量が回避され、コストが削減されます。

  • デプロイ スタンプ: デプロイ スタンプを使用すると、デバイスのグループの地理的分散、特定のスタンプへの新機能の展開、デバイスあたりのコストの監視など、いくつかの利点があります。 デプロイ スタンプを使用すると、スケーラビリティ、フォールト トレランス、および効率的なリソース使用率を向上させることができます。

  • ゲートウェイ オフロード: このパターンは、ゲートウェイ デバイスでの要求処理をオフロードし、ノードごとのリソースからゲートウェイの実装にコストをリダイレクトします。 この設計パターンを使用すると、一元化された処理モデルの保有コストが低くなる可能性があります。

  • パブリッシャー/サブスクライバー: このパターンは、アーキテクチャ内のコンポーネントを分離し、直接通信を中間メッセージ ブローカーまたはイベント バスに置き換えます。 これにより、イベントドリブンアプローチと消費ベースの課金が可能になり、オーバープロビジョニングを回避できます。

  • キューベースの負荷平準化: パターンは、キュー内の受信要求またはタスクをバッファーします。 バッファリングによりワークロードがスムーズになり、ピーク時の負荷を処理するためのリソースのオーバープロビジョニングの必要性が軽減されます。 受信要求は、コストを削減するために非同期的に処理されます。

  • シャーディング: このパターンは、特定の要求を論理宛先に送信し、データコロケーションを使用した最適化を可能にします。 シャーディングは、より低い仕様のコンピューティングまたはストレージ リソースの複数のインスタンスを使用することで、コスト削減につながります。

  • 静的コンテンツ ホスティング: このパターンでは、この目的のために設計されたホスティング プラットフォームを使用して、静的コンテンツを効率的に配信します。 より高価な動的アプリケーション ホストの使用を回避し、リソース使用率を最適化します。

  • 調整: このパターンでは、リソースまたはコンポーネントへの受信要求のレート (レート制限) またはスループットに制限が設定されます。 これは、コスト モデリングを通知するのに役立ち、アプリケーションのビジネス モデルに直接関連付けることができます。

  • バレー キー: このパターンにより、より多くのコンポーネントを含めることなく、リソースへの安全で排他的なアクセスが許可され、中間リソースの必要性が減り、効率が向上します。

制御電源

特定のリソースまたはサービスに費やす金額の上限を定義することは、供給を制御する 1 つの方法です。 これは、コストを管理し、経費が特定のレベルを超えないようにするための重要な戦略です。 予算を設定し、支出を監視して、定義された金額内に収まるようにします。 コスト管理プラットフォーム、予算アラート、または使用状況と支出パターンの追跡を使用できます。 一部のサービスでは、供給を調整してレートを制限できます。これらの機能は役に立つ場合に使用する必要があります。

供給の管理とは、特定のリソースまたはサービスに費やす金額の上限を定義することを指します。 これは、コストの管理に役立ち、経費が特定のレベルを超えないようにするため、重要な戦略です。 予算を確立し、支出を監視して、定義されたしきい値内に収まるようにします。 コスト管理プラットフォーム、予算アラート、または使用状況と支出パターンの追跡を使用できます。 一部のサービスでは、供給を調整してレートを制限できます。これらの機能は役に立つ場合に使用する必要があります。

トレードオフ: 制限を厳しくすると、需要が増加したときにスケーリングする機会が見逃され、ユーザー エクスペリエンスに影響を与える可能性があります。 シャットダウンが発生したり、読み込みに応答できなかったりする可能性があります。 コストの最適化と、ビジネス ニーズを満たすのに十分なリソースを確保することのバランスを取つことが重要です。

Azure ファシリテーション

スケールアウトとスケールアップの評価: Azure には、さまざまなスケーリング構成をデプロイしてテストできるテスト環境が用意されています。 実際のワークロード データまたはプロキシ データを使用すると、実際のシナリオをシミュレートし、コストへの影響を測定できます。 Azure には、パフォーマンス テスト、ロード テスト、監視用のツールとサービスが用意されています。これにより、スケールアウトオプションとスケールアップ オプションのコスト効率を評価するのに役立ちます。

Azure では、 Azure Advisor など、さまざまなツールとサービスを通じてコスト管理に関する推奨事項が提供されます。 これらの推奨事項では、使用パターン、リソース使用率、スケーリング構成を分析して、コストを最適化するための分析情報と提案を提供します。

Azure Load Testing は、大規模な負荷を生成するフル マネージドのロード テスト サービスです。 サービスは、アプリケーションがどこにホストされているかにかかわらず、そのトラフィックをシミュレートします。 開発者、テスト担当者、品質保証 (QA) エンジニアは、ロード テストを使用して、アプリケーションのパフォーマンス、スケーラビリティ、または容量を最適化できます。

自動スケーリングの最適化: 多くの Azure コンピューティング サービスでは、複数の同一インスタンスのデプロイと、スケーリングのしきい値とポリシーの迅速な調整がサポートされています。 Azure には、ワークロードの需要に基づいてインスタンスまたはリソースの数を自動的に調整できる自動スケーリング機能が用意されています。 スケール ルールとしきい値を定義して、スケールアウトまたはスケールイン アクションをトリガーできます。 自動スケーリングを使用すると、実際の需要に基づいてリソースを動的にスケーリングすることで、リソースの割り当てとコスト効率を最適化できます。

Azure では、 サブスクリプションとサービスの制限 の一覧が保持されます。一部の例外を除き、各リソース グループにデプロイできるリソースのインスタンスの数には一般的な制限があります。 詳細については、「リソース グループごとのリソース インスタンスの制限」を参照してください。

需要と供給の最適化: Azure Monitor は、アプリケーションとインフラストラクチャのパフォーマンスと正常性に関する分析情報を提供します。 Azure Monitor を使用すると、リソースの負荷を監視し、時間の経過に伴う傾向を分析できます。 Azure Monitor によって収集されたメトリックとログを使用すると、スケーリングの調整が必要になる可能性がある領域を特定できます。 この情報は、自動スケーリング ポリシーの絞り込みをガイドして、機能しない要件とコストの最適化の目標に合わせて調整できます。

  • オフロード供給: Azure には、Azure Front Door とキャッシュ サービス (Azure Cache for RedisAzure HPC Cache) と呼ばれる最新のクラウド コンテンツ配信ネットワーク (CDN) があります。 CDN はコンテンツをエンド ユーザーの近くにキャッシュし、ネットワーク待機時間を短縮し、応答時間を短縮します。 キャッシュでは、データのコピーが メイン データ ストアの前に格納されるため、バックエンドへの要求を繰り返す必要が減ります。 CDN とキャッシュ サービスを使用すると、パフォーマンスを最適化し、潜在的なコスト削減のためにサーバーの負荷を軽減できます。

  • 供給の制御: Azure では、クラウド ワークロードのリソース制限を設定することもできます。 リソース制限を定義することで、ワークロードが割り当てられたリソース内にとどまり、不要なコストを回避できます。 Azure には、クォータ、ポリシー、予算アラートなどのリソース制限を設定するためのさまざまなメカニズムが用意されています。 これらのメカニズムは、リソースの使用状況を監視および制御するのに役立ちます。

    API Managementは、要求のレート制限とスロットルを行うことができます。 受信要求のスロットルは、Azure API Management の重要な役割の 1 つです。 要求のレートや転送される要求/データの合計を制御できるため、API プロバイダーは API Management を使用して、さまざまな API 成果物階層に対する値の不正使用や作成から API を保護できます。

コスト最適化チェックリスト

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