THE FRUGAL ARCHITECT を読んで非機能要件にコストを追加しました

この記事は AWS Community Builders Advent Calendar 2023 のシリーズ２ 14日目の記事です。

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

AWS re:Invnet 2023 の Amazon.com CTO Werner Vogels 氏の基調講演で取り上げられた THE FRUGAL ARCHITECT を読みました。
FRUGAL は質素な、倹約的なといった意味だそうです。発音記号は frúgəl で、カタカナで書くとフルガルあたりでしょうか。

THE FRUGAL ARCHITECT がなにかというのをサイトから引用します。

Simple laws for building cost-aware, sustainable, and modern architectures.

機械翻訳すると「コスト意識のある、持続可能な、モダンなアーキテクチャを構築するためのシンプルな法則」となります。

THE FRUGAL ARCHITECT とは

THE FRUGAL ARCHITECT には7つの法則があります。

1. Make Cost a Non-functional Requirement. (コストを非機能要件にする)
2. Systems that Last Align Cost to Business. (長持ちするシステムはコストをビジネスに合わせる)
3. Architecting is a Series of Trade-offs. (アーキテクチャはトレードオフの連続である)
4. Unobserved Systems Lead to Unknown Costs. (観測されないシステムは未知のコストにつながる)
5. Cost Aware Architectures Implement Cost Controls. (コスト意識のあるアーキテクチャはコストコントロールを実装する)
6. Cost Optimization is Incremental. (コスト最適化は段階的である)
7. Unchallenged Success Leads to Assumptions. (挑戦されない成功は思い込みにつながる)

コストは非機能要件です。見落としがちですが、他の非機能要件(セキュリティ、可用性、保守性など)と同一です。
設計〜運用までのあらゆる段階でコストを考慮して適切に測定します。

収益をあげているディメンションとインフラストラクチャのコストの関係性を理解します。
EC サイトであれば注文数がディメンションとなります。注文数が増えれば、それを処理するためのインフラストラクチャのコストも増えます。が、アーキテクチャが適切に設計されていれば、注文数の増加に対するインフラストラクチャのコストを抑えることができます。

アーキテクチャにはトレードオフがあります。コスト、パフォーマンス、復元力などお互いに緊張関係があります。
リスク許容度と予算に折り合いをつけることが重要です。FRUGAL は支出を抑えるだけはなく価値を最大化することだということを忘れてはいけません。

コストを測定していない場合、コストを管理することはできません。
継続的検査により過剰な支出を特定し、経費を削減するための運用を実現します。
ほとんどの場合、コスト可観測性の投資収益率はその費用を大きく上回ります。

上手に設計されたシステムはコスト改善の機会に対処できます。
一つのアプローチは、重要度によってコンポーネントを階層化することです。
階層を定義することで、コストと他の要件のトレードオフを可能にします。例えば、Tier1 はコストよりもパフォーマンスを重視、Tier3 は低コストで実装などといったものです。

コストの最適化は継続的かつ段階的なプロセスです。
現状に疑問を持ち深く掘り下げることが重要です。小さな最適化でも大規模なシステムでは大きな削減につながります。
FRUGAL には粘り強さが必要です。粘り強く探し続ければ改善の余地は必ずあります。

チームが成功を収めた場合、現状に満足してしまう可能性があります。その成功につながった方法、ツール、実践に過信することは危険です。
誤った安心感が生まれ現状に疑問を持つことを忘れると、より効率的な、費用対効果が高く、拡張性のある新しいオプションを模索することがなくなります。
Grace Hopper 氏が言ったように最も危険な言葉は『私たちはいつもこのようにしてきた (“We’ve always done it this way.”)』です。

非機能要件ヒアリングシートに追加

「コストは非機能要件」ということで、非機能要件ヒアリングシートにコストに関する質問を追加しました。
コストは後からついてくる、というよりクラウドの場合は動いてみないと実際のコストは見えないので、後回しにされてしまうことが多いと思います。
ただ、動いているアプリケーションをコスト起因で後から修正することは、少々抵抗がある可能性もあります。

質問	質問の意図	ご回答
毎月の予算を設定していますか？	コストの上限を意識したアーキテクチャを設計する。また、コストアラートを送信する際の基準となる。
月中の予算進捗を確認する方法はありますか？	予算を超過しないようにするためには、進捗を確認する必要がある。例えば、予算の nn% 消費時にアラートするなど。
毎月のコスト内訳はどの程度の詳細度が必要ですか？	請求額だけ分かればよい、サービスごとの料金が知りたい、さらに細かくリクエストごとの料金が知りたいなど。細かく知る場合は CUR 出力を考慮する。
システムの重要度に合わせたコストバランスを定義していますか？	重要度が高いシステムはコストより機能を優先する、低いシステムはコスト重視で設計する。
サービスが収益をあげていることを示すインジケーターはありますか？	EC サイトであれば注文数など収益を示すインジケーターが増加すると、コストがどのように増加するかを把握する。
定期的はコスト見直しスケジュールはありますか？	コストは定期的に見直し削減する。
請求単位で AWS アカウントを分割していますか？	社内のコスト按分を厳密に行う場合は、按分する組織/プロジェクトごとに AWS アカウントを分割する。厳密ではないがタグによる分割も可能。
アプリケーションログやデータ保持期間は定義されていますか？	データ保持期間を定義することで、不要なデータを削除しコストを削減することができる。
リソースの需要は予測可能でしょうか？	需要が予測可能な場合は、予測に合わせてリソースを増減することでコストを削減できる。また、開発環境は夜間停止するなどの削減方法もある。

参考

THE FRUGAL ARCHITECT
コスト最適化の柱 - AWS Well-Architected フレームワーク