非機能的な要件としての持続可能性

ビジネス要件のリストに持続可能性を加えることで、より費用対効果の高いソリューションが実現できます。使用するリソースからより多くの価値を得ることに注力し、リソース量を減らすことは、使用した分のみ料金を支払うことになるため、AWS のコスト削減に直接つながります。

持続可能性の目標を達成するためには、アップタイム、可用性、応答時間など、他の 1 つまたは複数の従来のメトリクスにおいて同等のトレードオフを必要としないかもしれません。サービスレベルに重大な影響を与えることなく、持続可能性を大幅に高めることができるのです。軽微なトレードオフが必要な場合、このトレードオフによって得られる持続可能性の向上は、サービスの質の変化を上回ります。

機能要件を開発する際には、持続可能性の改善について継続的に実験を行うよう、チームメンバーに働きかけてください。また、チームは、目標を設定する際にプロキシ メトリクスを組み込み、ワークロードを開発する際にリソースの集約度を評価するようにする必要があります。

次は、消費するクラウドリソースを削減するためのトレードオフの例です。

結果の品質を調整する: 近似コンピューティングを利用して、結果の品質 (QoR) とワークロード強度の低減を交換することができます。近似コンピューティングの実践は、顧客が必要とするものと実際に作成するものとの間のギャップを利用する機会を探します。たとえば、データを セット データ構造にした場合、SQL の ORDER BY 演算子を削除して不要な処理を削除し、リソースを節約しながらも、満足の行く回答を得ることができます。

応答時間を調整する: 応答速度が遅い回答は、共有のオーバーヘッドを最小にすることで炭素を削減することができます。アドホックなエフェメラルタスクを処理すると、起動オーバーヘッドが発生する場合があります。タスクを受信するたびにオーバーヘッドを支払う代わりに、タスクをグループ化してバッチ単位で処理を行います。バッチ処理では、インスタンスのスピンアップ、ソースコードのダウンロード、プロセスの実行などの共有オーバーヘッドを削減するために、応答時間の増加をトレードオフします。

可用性を調整する: AWS では、わずか数回のクリックで、簡単に冗長性を追加し、高可用性ターゲットを達成することができます。常に利用率が低下するアイドル状態のリソースをプロビジョニングすることで、静的安定性のような手法で冗長性を高めることができます。目標設定時にビジネスのニーズを評価します。可用性のトレードオフは比較的小さくても、利用率の増加が大幅に向上します。たとえば、静的安定アーキテクチャのパターンでは、コンポーネントに障害が発生した後、直ちに負荷を引き受けるために、アイドル状態のフェイルオーバー能力をプロビジョニングします。可用性の要件を緩和することで、代替リソースをデプロイするためのオートメーション時間を確保し、アイドル状態のオンライン性能を不要にすることができます。フェイルオーバーキャパシティーをオンデマンドで追加することで、通常のオペレーション中にビジネスに影響を与えることなく、全体的な使用率を高め、コスト削減という二次的利点が生じます。