はじめに
こんにちは。re:Invent2023のWerner先生のKeynoteでThe Frugal Architectというコスト指向で持続可能なモダンなアーキテクチャを構築するための指針が7つ紹介されました。
前述のリンクに記載されている内容はあくまで概要レベルにとどまるので、備忘を兼ねて整理してみます。（時間があればYoutubeぜひ見てください）
ちなみにFrugalという単語は倹約という意味なんですね。知らなくてその場で調べました笑。更に調べてみるとFrugalであることはAmazon社の社是の一つなんですね。
指針
Ⅰ.コストを非機能要件として扱う（Make Cost a Non-functional Requirement）
（概要）システムを設計、開発、運用する際には、市場投入までの期間と効率性のバランスをとるため、コストの影響を早期かつ継続的に考慮する。
プロダクトやサービスを継続していくうえでコストはとても重要な要素です。その一方でセキュリティなどのほかの一般的な非機能要件と比べると軽視されがちな要素でもあります。
クラウドではコストを改善できる余地が多く存在します。例えば負荷の変動があるシステムでリソースを買い切るのではなく都度調達したりだとか、これまで自前で作っていた機能を新しく出たマネージドサービスに乗り換えたりだとかです。
コストを非機能要件として、他の非機能要件と同じレベルで継続的に考えていくことが大事になってきます。
Ⅱ.コストをビジネスに合わせる（Systems that Last Align Cost to Business）
（概要）ビジネスモデルの利益水準に合わせてアーキテクチャを設計し、収益が許す限り規模の経済を実現する。利益がないまま無制限に成長すると価値が低下する。
私たちはビジネスを支えるためのアーキテクチャを構築しています。なのでビジネス上の決定とアーキテクチャ上の決定の調和がとれていることが何より大事です。
どのような方法で収益を得ようとしていて、コストはどのくらいかかりそうなのか。見通しが正しければ規模の経済で利用者増に伴って利益が増えていくことが期待できます。ビジネス部門だけでも技術部門だけでも精度の良い見通しを立てることは難しいため両部門の緊密なコミュニケーションが大事です。
なおビジネスを取り巻く環境は常に変化しています。また、新しいサービスでは精度の良い見通しが立てられないことも普通にあるでしょう。このことから進化的アーキテクチャの考え方に基づいて環境の変化にアーキテクチャが適応できる仕組みの整備が重要です。
Ⅲ.アーキテクティングはトレードオフの連続である（Architecting is a Series of Trade-offs）
（概要）すべての設計にはトレードオフがつきもの。技術とビジネスのトレードオフを定期的に再評価し、ビジネスニーズに合わせたリソースに投資することが重要。
アーキテクチャ特性はAvailability, Scalability, Agilityなど沢山ありますが、全ての特性が10点満点の銀の弾丸的なアーキテクチャはありません。
また、時間やフェーズの経過によって優先すべきアーキテクチャ特性は変化します。例えばサービスイン時は新機能をリリースするスピード重視だったが、安定期に入ったので継続性を重視したいといった具合です。その場合、最適なアーキテクチャの形は当然変わります。エンジニアリング上のあらゆる決定は購入の決定につながるため、ビジネス部門と協力して特性の優先順位を調整する必要があります。
Ⅳ.モニタリングされていないシステムが隠れたコストを生む（Unobserved Systems Lead to Unknown Costs)
（概要）タフな監視システムには先行投資が必要だが、それによって組織は無駄な業務を特定し、ワークフローを合理化し、優先事項に戦略的にリソースを割り当てることができる。
未来は現在の連続です。なので現在を適切に観測することで行動を変え、未来を変えることができます。コストにおいてもそれは同じです。
マイクロサービスにおいては機能が分散してネットワーク越しに協調する都合上、観測は従来よりも難しくなります。ROIを考える上では各マイクロサービス毎のコストだけでなく、システム全体のコストも理解する必要があります。もちろんこれはとても大変なことです。でもやらなければなりません。どうやってコストを計測するかをステークホルダーと事前に合意し、計測し、行動を変えていく必要があるのです。
Ⅴ.コスト指向のアーキテクチャはコストを制御できる（Cost Aware Architectures Implement Cost Controls）
（概要）監視をきちんと行えていれば、改善の余地があると特定した領域に手を打つことができる。きめ細かな制御を実施することで、コストとユーザー・エクスペリエンスの両方を最適化することができる。
一つのアプリケーションは異なる複数の機能で構成されていると思います。そして機能によって重要度が異なるはずです。各機能を重要度によって階層分けしましょう。階層分けした上で重要度にあったアーキテクチャを構築しましょう。
加えて、各々の機能についてスロットリングしたり、より詳細を表示したり、場合によっては機能をオフにするような制御を実装しビジネス部門がそのスイッチを利用できるようにしましょう。そうすればアプリケーションのどこかが限界を迎えた場合でも柔軟に対処できます。
Ⅵ.コスト最適化は継続的である（Cost Optimization is Incremental）
（概要）コスト効率の追求は現在進行形の旅である。システムを監視してパターンを理解し、非効率を削減する。継続的な最適化には、システムを再訪してさらなる改善を見つける必要がある。
アプリケーションを監視して本当に必要な量のリソースを用意しましょう。たとえば、このストリームはそこまでビットレート必要でしょうか？コードのプロファイリング結果は想定の範囲内でしょうか？といった具合です。継続的にシステムを監視して非効率な部分を発見していきましょう。
Ⅶ.挑戦なき成功が思い込みを生む（Unchallenged Success Leads to Assumptions）
（概要）過去にうまくいったことを問い続ける。過去の成功にかかわらず方法やツールを再検討する。グレース・ホッパーの有名な言葉にあるように、英語で最も危険な言い回しのひとつがある： "私たちはいつもこのやり方でやってきた"
私たち技術者は非常に環境の変化が激しい世界に住んでいます。なので継続的に学び、常に自分自身の信念を否定する覚悟を持つ必要があります。Javaプログラミングの達人であるというエゴは捨て、実際のコストやガベージコレクションの複雑さを考えはじめてください。プラットフォームに応じて適切な技術選択が行えているかは継続的に精査する必要があります。自分の信念を裏切る覚悟をもってください。
まとめ
ここまで読んでいただきありがとうございました。Werner先生のKeynoteはリモートで見ていた時点で非常に面白かったのですが、文字として改めて整理してみると新たな発見もありました。まだ見てない方はぜひYoutube見てみてください！来年は現地で見たいなぁ。