私たちがプロジェクトにおいてどのように THE FRUGAL ARCHITECT を活用すれば良いのか考えてみた

こちらの記事はJapan AWS Ambassadors Advent Calendar 2023の7日目の記事になります。

THE FRUGAL ARCHITECT とは

THE FRUGAL ARCHITECT は、2023/11/27 - 12/1 に開催された re:Invent 2023 において Amazon.com CTO Dr.Werner Vogels がキーノートの中で発表したドキュメントです。

thefrugalarchitect.com

コストを意識した持続可能な最新のアーキテクチャを構築するためのシンプルな考え方を７つの規則（それぞれ Law と表現されている）で分類し説明されています。

• LAW 1. Make Cost a Non-functional Requirement.
  (意訳：非機能要件にコストを加えること）
• LAW 2. Systems that Last Align Cost to Business.
  (意訳：システムにかけるコストがビジネスにマッチ状況を継続すること）
• LAW 3. Architecting is a Series of Trade-offs.
  (意訳：アーキテクチャを決断することはトレードオフの連続である）
• LAW 4. Unobserved Systems Lead to Unknown Costs.
  (意訳：観測できないシステムコストは青天井なコストである）
• LAW 5. Cost Aware Architectures Implement Cost Controls.
  (意訳：コストを意識したアーキテクチャがコスト管理を実現する）
• LAW 6. Cost Optimization is Incremental.
  (意訳：段階的なコスト最適化を適用する）
• LAW 7. Unchallenged Success Leads to Assumptions.
  (意訳：挑戦のない成功は思い込みにつながる）

本記事の内容

実際のプロジェクトにおいて THE FRUGAL ARCHITECT の各規則を適用するためには、どのようにすれば良いのか考えてみたことをメモとして記録しています。

本記事の目次

LAW 1. Make Cost a Non-functional Requirement. をプロジェクトに適用するには？

私は LAW 1 を「非機能要件にコストを加えること」と受け止めています。

LAW 1 の詳細に関する原文はこちらを参照ください。

国内のシステム開発プロジェクトでは IPA 非機能要求グレード を用いて非機能要件を整理することが多いかと思います。非機能要求グレードには「コスト」を主体とした大項目は存在せず、各小項目にコストに関する記述が触れられている形となります。

この場合、問題となりえるシーンを想定すると、システム設計と非機能要件の適合状況を確認するフェーズにおいて、コスト軸での適合状況を見分けるのが難しく、不適切なコストをかけていることを見落としてしまう可能性が想定されます。

非機能要求グレードの他、AWS Well-Architected Frameworkを併用し、コスト効率化の柱よりCOST1、COST5、COST6を非機能要件に加えるのが良いと考えます。

LAW 2. Systems that Last Align Cost to Business. をプロジェクトに適用するには？

私は LAW 2 を「システムにかけるコストがビジネスにマッチ状況を継続すること」と受け止めています。

LAW 2 の詳細に関する原文はこちらを参照ください。

LAW 2では、システムによってビジネスにもたらす収益とシステムに係るコストのバランスがとれている状況を維持することが求められます。

一般的にコスト(AWS利用料金の確認)は、コストエクスプローラーなどを用いることが多いと思います。コストエクスプローラーに関する利用計画は、AWS Well-Architected Framework コスト効率化の柱より、COST 3と現状を照らし合わせるのが良さそうです。

ただ、システムに関わるコストはAWS利用料金だけではなく、エンジニアリングコストも含める必要があります。自社サービスの場合はエンジニアの社内コストと稼働時間をもとに算出し、外部委託の場合は委託費用をもとに算出する形となります。

LAW 3. Architecting is a Series of Trade-offs. をプロジェクトに適用するには？

私は LAW 3 を「アーキテクチャを決断することはトレードオフの連続である」と受け止めています。

LAW 3 の詳細に関する原文はこちらを参照ください。

FRUGALはコストの最小化だけではなく価値を最大化する（コストを抑えることは価値を小さくするものではない）と記載されています。
また、アーキテクチャの選定において、コストと緊張関係にある要素を考え、そのトレードオフが選定段階で然るべきものであったかを記録していく必要があります。アーキテクチャの選定において、Architecture Decision Recordsを用いて選定における理由を記録します。その際、コストも含めて記録し、その選定理由を改めて見直す際に参照できるようにしておくのが良いと思います。

技術の変化、コスト構造の変化、ビジネスの変化により、その時に選定したアーキテクチャは最適なものではなくなる可能性を念頭に起くことも大切です。AWS Well-Architected Framework コスト効率化の柱より、COST 11でオペレーションコストの考え方を照らし合わせることも忘れないようにしたいですね。

LAW 4. Unobserved Systems Lead to Unknown Costs. をプロジェクトに適用するには？

私は LAW 4 を「観測できないシステムコストは青天井なコストである」と受け止めています。

LAW 4 の詳細に関する原文はこちらを参照ください。

直訳では、観測できないシステムコストは未知にコストにつながるという意味ですが、未知なコストが存在する以上、コスト試算は不可能だと考えています。気づいたらあらかじめ予算をしていたコストを超えてしまったというシチュエーションになることも十分に想定できます。 そのため、ビジネスの安定性を損なう「青天井なコスト」だと受けてめました。

LAW4は、コストの可観測性を実現すること、さらにエンジニア、ビジネスパートなー(スポンサー、ステークホルダーなど)がいつでも見えるようにしておくことが重要だとしています。

AWS Well-Architected Framework コスト効率化の柱より、COST 3においてコストの可視化方法とともに情報の時間的粒度、誰が可視化されたコストダッシュボードを確認する必要があるのか、など明示することが良さそうです。

LAW 5. Cost Aware Architectures Implement Cost Controls. をプロジェクトに適用するには？

私は LAW 5 を「コストを意識したアーキテクチャがコスト管理を実現する」と受け止めています。

LAW 5 の詳細に関する原文はこちらを参照ください。

システムの構成要素のうち、ビジネスに対する重要度により階層分けし、優先的にコストをかける箇所、コストをかけるべきではない箇所を制御できることという記載があります。システム設計段階において、ユーザージャーニーや業務要件をもとにスプレッドシート化が可能な粒度で実装するビジネスロジックそのロジックがビジネスにどのような影響を与えるか記録しするのが現実的かと考えました。ユーザージャーニーをもとに考えるという意味では、SRO、SRIとも密接に紐づく要素になりそうです。

業務要件の場合は、大きな粒度の階層分け（例えばバッチ種別による重要度分別など）は、非機能要件における業務継続性などからも洗い出しができるかと思います。

LAW 6. Cost Optimization is Incremental. をプロジェクトに適用するには？

私は LAW 6 を「段階的なコスト最適化を適用する」と受け止めています。

LAW 6 の詳細に関する原文はこちらを参照ください。

LAW 6 の詳細には、システムの導入後でもシステムを再検討して段階的に最適化を改善する必要がある。と記載されています。

LAW 6を実現するにはシステムの観測性が実装されていることが前提になります。インスタンスメトリクスからCPU、メモリなど適用しているコンピュートリソースが効率的であるかどうかの見直しを行うこと、Trusted Advisorによるコストの最適化ポイントの確認などは比較的用意に運用可能かと思います。

さらに多くの洞察を得てコスト最適化（価値最大化）につながあえる改善を継続的かつ段階的に加えるには、Amazon X-Ray、New Relicのようなトレーシングサービス、Amazon CodeGuru Profilerなどのプロファイラを用いて改善点や改善適用の効果確認可能な状況にする必要があります。

また、「LAW 5. Cost Aware Architectures Implement Cost Controls.」と組み合わせることで実際に改善を加えるときの影響度も考慮しながら適用を進めることができそうですね。

LAW 7. Unchallenged Success Leads to Assumptions. をプロジェクトに適用するには？

私は LAW 7 を「挑戦のない成功は思い込みにつながる」と受け止めています。

LAW 7 の詳細に関する原文はこちらを参照ください。

「私たちはいつもこのようにしてきた」は英語で最も危険なフレーズの１つと記載されていますが、日本語でも変わりはなさそうです。特に理由はないけど、今までもこうしてきたから今回も・・・という状況は往々にしてあるものだと思います。この結果、盲目的に手段を選択してしまい問題が発生することもあれば、コストにも悪影響を与える可能性を指摘しています。

これまでの慣習などに流されず、疑問を持ち、最適化するためには、プロジェクトにおけるレトロスペクティブを各フェーズで適用することが良さそうです。振り返りの過程で、プロジェクトチーム内で理由を明確にし、そして共有し、検討の余地がないかどうかを確認していくことが必要だと考えます。

レトロスペクティブを活用することは、プロジェクト初期に掲げたビジョンがプロジェクトが進むにあたり希薄になっていくことを防止し、プロジェクトにとって必要なことを継続して意識するというメリットもあります。

まとめ

この記事では、THE FRUGAL ARCHITECT を実際のシステム開発プロジェクトで活用するためにはどのようにすれば良いかを考え、記載しました。あくまでも私個人の経験をもとに書いていますので、みなさんの関わるシステムの種別、業界、立場によって考えに差があるかと思います。ぜひ、コミュニティなどで情報交換ができると嬉しいです。

明日の Japan AWS Ambassadors Advent Calendar 2023 8日目はシアトルで素敵な英語LTを行う実績を解除した山崎さんです。