コスト最適化のトレードオフ
財務上の制約の下で投資収益率 (ROI) を最大化するようにワークロードを設計する場合、最初に明確に定義された機能要件と非機能要件が必要です。 作業と労力の優先順位付け戦略は不可欠です。 基盤は、財政的責任感が強いチームです。 チームは、使用可能なテクノロジとその課金モデルについて深く理解している必要があります。
ワークロードの ROI を理解したら、その改善を開始できます。 ROI を向上させるには、 コスト最適化の設計原則と、コスト最適化 の 設計レビュー チェックリスト の推奨事項に基づく決定が、他の Azure Well-Architected Framework の柱の目標と最適化にどのように影響するかを検討します。 コストの最適化のためには、より安価なソリューションに重点を置かないようにすることが重要です。 支出の最小化のみに重点を置く選択は、ワークロードのビジネス目標と評判を損なうリスクを高める可能性があります。 この記事では、コストの最適化のためにターゲット設定、設計、および操作を検討するときにワークロード チームが発生する可能性があるトレードオフの例について説明します。
信頼性を備えたコスト最適化のトレードオフ
サービス中断のコストは、サービス中断の防止または復旧のコストに対して測定する必要があります。 中断のコストが信頼性設計のコストを超える場合は、中断を防止または軽減するためにより多くの投資を行う必要があります。 逆に、信頼性の取り組みのコストは、コンプライアンス要件や評判などの要因を含め、中断のコストを超える可能性があります。 信頼性設計では、このシナリオでのみ戦略的な分割を検討する必要があります。
トレードオフ: 回復性が低下しました。 ワークロードには、特定の種類と量の誤動作を回避し、耐えうる回復性対策が組み込まれています。
コストを節約するために、ワークロード チームはコンポーネントのプロビジョニングを下げるか、スケーリングを過剰に制約する可能性があるため、需要の急激な急増時にコンポーネントが失敗する可能性が高くなります。
コストの最適化のためにワークロード リソースを統合 (密度の向上) すると、需要の急増や更新などのメンテナンス操作中に個々のコンポーネントが失敗する可能性が高くなります。
メッセージ バスなどの回復性設計パターンをサポートするコンポーネントを削除し、直接依存関係を作成すると、自己保持機能が低下します。
冗長性を減らすことでコストを節約すると、ワークロードの同時誤動作を処理する機能が制限される可能性があります。
予算 SKU を使用すると、ワークロードが到達できる最大サービス レベル目標 (SLO) が制限される可能性があります。
ハード使用制限を設定すると、ワークロードが正当な需要を満たすようにスケーリングできなくなる可能性があります。
信頼性テスト ツールやテストがないと、ワークロードの信頼性は不明であり、信頼性の目標を満たす可能性は低くなります。
ワークロードのディザスター リカバリー計画のテストまたはドリルの削減は、復旧操作の速度と有効性に影響を与える可能性があります。
バックアップを作成または保持する数を減らすと、復旧ポイントが減少し、データが失う可能性が高くなります。
低コストのサポート契約では、技術的なサポートの遅延が発生する可能性があるため、ワークロードの復旧時間が長くなる可能性があります。
コスト最適化クラウド パターンを使用すると、コンテンツ配信ネットワーク (CDN) などの新しいコンポーネントを追加したり、ワークロードで信頼性のターゲットを提供する必要があるエッジデバイスやクライアント デバイスに職務をシフトしたりすることができます。
イベントベースのスケーリングは、リソースベースのスケーリングよりも調整と検証が複雑になる場合があります。
データ ライフサイクル アクションを通じてデータ量を減らし、データの階層化を行い、場合によってはライフサイクル イベントの前に集計データ ポイントを実装することで、ワークロードで考慮すべき信頼性要因が導入されます。
異なるリージョンを使用してコストを最適化すると、管理、ネットワーク、監視がより困難になる可能性があります。
セキュリティを使用したコスト最適化のトレードオフ
ワークロードの機密性、整合性、可用性に対する侵害のコストは、その侵害を防ぐための作業のコストと常にバランスを取る必要があります。 セキュリティ インシデントは、幅広い財務および法的影響を及ぼし、企業の評判を損なう可能性があります。 セキュリティへの投資は、リスク軽減アクティビティです。 リスクを経験するコストは、投資とバランスを取る必要があります。 原則として、責任を負うポイントを下回り、リスク軽減に合意したコストの最適化を得るために、セキュリティを侵害しないでください。 ソリューションを権利化してセキュリティ コストを最適化することは、重要な最適化プラクティスですが、その場合は次のようなトレードオフに注意してください。
コスト最適化の方法の 1 つは、ユニットまたは運用コストを計上するコンポーネントまたはプロセスを削除する方法を探す方法です。 コストを節約するために次の例のようなセキュリティ コンポーネントを削除すると、セキュリティに影響することに注意してください。 この影響に関するリスク分析を慎重に実行する必要があります。
認証と承認の手法を減らすか簡略化すると、ゼロ トラスト アーキテクチャの 明示的な 原則の検証が損なわれます。 これらの簡略化の例としては、業界の OAuth アプローチを学習するための時間を費やすのではなく、事前共有キーなどの基本的な認証スキームを使用する方法や、管理オーバーヘッドを減らすために簡素化されたロールベースのアクセス制御割り当てを使用する方法などがあります。
転送中または保存時の暗号化を削除して、証明書とその運用プロセスのコストを削減すると、データは潜在的な整合性または機密性の侵害にさらされます。
関連するコストと時間の投資により、セキュリティ スキャンまたは検査ツールまたはセキュリティ テストを削除または削減すると、ツールとテストが保護することを目的とした機密性、整合性、または可用性に直接影響を与える可能性があります。
カタログ化とパッチ適用の実行に投資される運用時間のためにセキュリティパッチ適用の頻度を減らすことは、進化する脅威に対処するワークロードの能力に影響します。
ファイアウォールなどのネットワーク制御を削除すると、悪意のある受信トラフィックと送信トラフィックをブロックできない可能性があります。
コストを最適化するクラウド設計パターンでは、追加のコンポーネントの導入が必要になることがあります。 これらの追加コンポーネントにより、ワークロードの領域が増加します。 コンポーネントとその中のデータは、システムでまだ使用されていない方法でセキュリティ保護する必要があります。 これらのコンポーネントとデータは、多くの場合、コンプライアンスの対象となります。 コンポーネントを導入できるパターンの例を次に示します。
静的コンテンツ ホスティング パターンを使用して新しい CDN コンポーネントにデータをオフロードする。
バレット キー パターンを使用して処理をオフロードし、クライアント コンピューティングへのリソース アクセスをセキュリティで保護します。
Queue-Based 負荷平準化パターンを使用して、メッセージ バスを導入することでコストを滑らかにします。
マルチテナントの状況や共有アプリケーション プラットフォーム上の複数のアプリケーションの併置などのリソースの共有は、密度を高め、管理面を減らすことでコストを削減するためのアプローチです。 この密度の増加により、次のようなセキュリティ上の問題が発生する可能性があります。
リソースを共有するコンポーネント間の横方向の移動が簡単です。 アプリケーション プラットフォーム ホストまたは個々のアプリケーションの可用性を侵害するセキュリティ イベントも、より大きな爆発半径を持っています。
併配置されたリソースは、ワークロード ID を共有し、アクセス ログにあまり意味のない監査証跡がない可能性があります。
ネットワーク セキュリティ制御は、すべての併配置されたリソースをカバーするのに十分な広さである必要があります。 この構成は、一部のリソースの最小特権の原則に違反する可能性があります。
共有ホスト上の異なるアプリケーションまたはデータを併置すると、コンプライアンス要件とセキュリティ制御が、範囲外のアプリケーションやデータに拡張される可能性があります。 このように範囲を広げるには、併置されたコンポーネントに対するセキュリティの調査と監査の追加作業が必要になります。
オペレーショナル エクセレンスによるコスト最適化のトレードオフ
テスト担当者、リソース、ツールに関連する時間とコストを節約するためにテスト作業を削減すると、運用環境のバグが増える可能性があります。
技術的負債の返済を遅らせ、新しい機能に人員を集中すると、開発サイクルが遅くなり、全体的な機敏性が低下する可能性があります。
製品開発に人員を集中させるためにドキュメントを使い果たすと、新入社員のオンボーディング時間が長くなり、インシデント対応の有効性に影響を与え、コンプライアンス要件が損なわれる可能性があります。
トレーニングへの投資が不足すると、スキルが低下し、新しいテクノロジとプラクティスを採用するチームの能力が低下します。
自動化ツールを削除してコストを節約すると、自動化されなくなったタスクにより多くの時間を費やすことができます。 また、エラーや不整合のリスクも高まります。
スコーピングやアクティビティの優先順位付けなどの計画作業を削減して経費を削減すると、あいまいな仕様や実装が不十分なため、手直しの可能性が高くなる可能性があります。
振り返りや事後レポートなどの継続的な改善活動を回避または削減して、ワークロード チームが配信に集中し続けると、ルーチン、計画外、緊急プロセスを最適化する機会が見逃される可能性があります。
ストレージと転送コストを節約するためにログとメトリックの量を減らすと、システムの監視性が低下し、次の可能性があります。
- 信頼性、セキュリティ、パフォーマンスに関連するアラートを作成するためのデータ ポイントが少なくなります。
- インシデント対応アクティビティのカバレッジ ギャップ。
- セキュリティまたはコンプライアンスに関連する相互作用や境界に対する観測性が制限されています。
コスト最適化の設計パターンでは、ワークロードにコンポーネントを追加できるため、複雑さが増します。 ワークロード監視戦略には、これらの新しいコンポーネントを含める必要があります。 たとえば、一部のパターンでは、複数のコンポーネントにまたがるフローや、サーバーからクライアントへのプロセスのシフトが導入される場合があります。 これらの変更により、情報の関連付けと追跡の複雑さが増す可能性があります。
監視ツールへの投資を減らし、効果的なダッシュボードのメンテナンスを行うと、運用環境から学習し、設計の選択を検証し、製品設計に通知する能力が低下する可能性があります。 この削減により、インシデント対応アクティビティが妨げられる可能性があり、目標復旧時間と SLO の達成が困難になります。
ツール ベンダーとのメンテナンス 契約を期限切れにすると、最適化機能、バグ解決、セキュリティ更新プログラムが見逃される可能性があります。
システムパッチ間の時間を長くして時間を節約すると、バグ修正が見逃されたり、進化するセキュリティ脅威に対する保護が不足したりする可能性があります。
パフォーマンス効率によるコスト最適化のトレードオフ
コストの最適化とパフォーマンス効率の両方の柱は、ワークロードの価値を最大化することに優先順位を付けます。 パフォーマンス効率は、必要以上に費やすことなく、パフォーマンス目標を達成することが強調されます。 コストの最適化では、パフォーマンス 目標を超えることなく、ワークロードのリソースによって生成される価値を最大化することを強調します。 その結果、コストの最適化によってパフォーマンス効率が向上することがよくあります。 ただし、コストの最適化に関連するパフォーマンス効率のトレードオフがあります。 これらのトレードオフにより、パフォーマンス目標への到達が困難になり、継続的なパフォーマンスの最適化が妨げられる可能性があります。
リソースをダウンサイズしてコストを削減すると、リソースのアプリケーションが奪われる可能性があります。 アプリケーションでは、大幅な使用パターンの変動を処理できない場合があります。
スケーリングを制限または遅延して上限を設定したり、コストを削減したりすると、需要を満たすために供給が不十分になる可能性があります。
コストを削減するために積極的にスケールダウンする自動スケーリング設定では、需要の急激な急増に対するサービスの準備ができていないか、頻繁なスケーリングの変動 (フラッピング) が発生する可能性があります。
配信に優先順位を付けるためにパフォーマンス最適化の専門知識を開発することに重点を置くことにより、リソースの使用効率を向上させる機会が見逃される可能性があります。
アクセス パフォーマンス テストまたは監視ツールを削除すると、検出されないパフォーマンスの問題のリスクが高くなります。 また、ワークロード チームがメジャー/改善サイクルで実行する機能も制限されます。
データ ストアなどのパフォーマンスが低下しやすい領域を無視すると、クエリのパフォーマンスが徐々に低下し、システム全体の使用率が向上する可能性があります。
関連リンク
他の柱のトレードオフを調べる:
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示