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