はじめに
re:Invent2023に参加してきました！色々アウトプットしたいことが溜まっておりますが、もっとも感銘を受けたAmazon.comのCTODr.Warnerのキーノートについて考察を書いていきたいと思います。
THE FRUGAL ARCHITECTとは
THE FRUGAL ARCHITECT=倹約的なアーキテクト
コストを意識した持続可能なモダンアーキテクチャを構成するための法則のことです。
７つの法則が公開されていますので順番に考察を書いていきたいと思います。
ぜひ自身で読んでみてください。
THE FRUGAL ARCHITECTが生まれた背景
ワーナーのキーノートでは様々な背景が語られていました。Amazon.comの３０年の歴史の中で得られたものだと語られており、以下の観点がポイントだったようです。
・クラウドの進化
ハードウェアの制約が取り払われ、いつでも必要なリソースを手に入れることができる
制約が取り払われる一方で、コストを念頭に置くことが薄れてしまっている
・コストを減らすことはサスティナブルにつながる
・クラウドに移行するだけが最適なのではない
移行して、クラウドに最適化すること、コストを最適化することが主体である
7つの法則とは？
この７つです。翻訳は怪しいので参考程度に
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.
→挑戦を伴わない成功は思い込みにつながる
LAW1. Make Cost a Non-functional Requirement.
コストを非機能要件に入れることとは？
可用性、拡張性、セキュリティ、保守、コンプライアンス、移行など、非機能要件は様々もののコストは見落とされやすい。設計から開発、運用に至るまで、コストを適切に意識する必要があります。コストへの影響を早期かつ継続的に考慮することで、機能、開発期間などバランスの取れたシステムが設計できます。
考察
セキュリティやコンプライアンスなどコストをかけざるを得ないものはあるが、可用性や拡張性などはトレードオフ可能な部分です。担当するプロジェクトにおいて、どの程度コストがかかるのか、アーキテクチャとセットで考える必要があるのだと思います。どの部分にコストがかかるのか、それは本当に必要なものなのか、ビジネス上コストをかける必要があるのか、代替手段はないのかなどを要件を決める段階で検討していく必要があるということだと思いました。
LAW2. Systems that Last Align Cost to Business.
コストをビジネスにあわせて調整可能にすることとは？
ビジネス上の利益に沿ってコストが増減できるアーキテクチャとすることです。
例えば、Eコマースのビジネスを展開しているシステムにおいて、注文数が増えることにより、インフラコスト、運用コストが増えるようなアーキテクチャになっていれば問題ないということです。これは、注文数が増えることによって、コストが増加するが、売上も同時に上がるためです。
考察
従量課金というクラウドのメリットを最大限活かしているか、更にそれがビジネスの増減に自動でスケールする構成となっているかという点がポイントになるのだと思います。また、ビジネス上の決定と技術的な調整が常にできる状態でなければならないということもポイントです。これを実現するためには、進化可能なアーキテクチャを取ることが要求されます。技術的な制約がビジネスの発展を邪魔する（技術的負債）
事はできる限り避けること、これが、モダンアーキテクチャを構成すべき理由の一つだと思いました。
LAW3. Architecting is a Series of Trade-offs.
アーキテクチャはトレードオフの連続であるとは？
アーキテクチャにおいて、あらゆる要素はトレードオフが伴う。可用性や、パフォーマンスなどは相互に影響し合う関係性です。技術的なニーズとビジネス上のニーズの適切なバランス、リスク許容度と予算にあったポイントを見つけることが重要です。何に対してコストを支払う価値があるのかを見極める必要があります。
考察
可用性をとると、コストやパフォーマンスを犠牲にする、パフォーマンスを優先すると可用性、コストを犠牲にする、コストを優先すると、パフォーマンスや可用性を犠牲にするなど、あらゆる項目はトレードオフです。システムで提供するものがどのようなビジネス上の特性があるのかを常に考え、コンポーネントごとに非機能要件を検討し、何を優先し何をトレードオフするのかを考える必要があるということだと思います。例えば、システムダウンを引き起こすとビジネス上クリティカルな影響があるのであれば、複雑性やコストを犠牲にし、災対までつくりこむ、ビジネス上数分間ダウンしても特に売上に影響が出ないのであれば、可用性やパフォーマンスを多少落としコストを優先するなどの選択ができますよね。この選択ができるようにするには、機能ごとに分割したアーキテクチャをとっておき、選択、調整、変更が可能なアーキテクチャとする必要があり、非常に重要なポイントだと思いました。
LAW4: Unobserved Systems Lead to Unknown Costs.
観測と測定ができないシステムは未知のコストを生み出すとは？
システム上監視や測定を実施してない場合、実際に何にコストがかけられているのかが把握できません。
コストに関する指標をエンジニアとビジネス上の決定を下す人に見えるようにする必要があります。
考察
我々自身コストが見えていないと無駄に使ってしまう傾向がありますよね。たとえば、家計でも同じで、電気代、食費はどのくらいかけているのか、把握するだけで自身の行動が変わります。売上とコストを適切にモニタリングすることで、機能の改善や廃止を含めた適切な判断ができるため、モニタリングは非常に大事です。
システム全体のコストも重要ですが、機能単位で効果的な使い方ができているのか、ビジネス上の判断を行うために、指標を定義し、コスト、リクエスト数などの収集と確認をすべきということだと思います。
LAW5. Cost Aware Architectures Implement Cost Controls.
コストを意識したアーキテクチャはコスト管理を実現するとは？
コストを意識したアーキテクチャをとると、モニタリングに応じた調整や改善が常に可能な状態となるため、自然とコスト管理ができるようになります。これを実現するためには、コンポーネントを分解し階層化、層ごとにコストと非機能要件を検討し、トレードオフができるようになります。Amazon.comでは、アプリケーションを階層ごとに分離し、どのレベルなのかを必ず決めているそうです。例えば、レビュー、買い物かご、それぞれどの程度ダウンが許容されるのか、お客様の購買にどのように影響するのかを加味した上で、アーキテクチャをトレードオフできめているとのこと。
考察
コンポーネントごとに、ビジネス上の特性を理解し、要件とコストのトレードオフを図ることが大切だということがひしひしと感じました。本質は、そのコンポーネントに対してビジネス上の判断が下った際に、調整が容易にできること、それができるアーキテクチャ、モニタリングをしておくことが大切なのだと思います。機能レベルでアーキテクチャを自在に変更できるに要すること、これはあまり意識できていませんでした。システム全体でと考えがちですが、真にコストを最適化するのであれば、より細かいレベルまでブレークダウンして見るべきなのだと思います。
LAW6. Cost Optimization is Incremental.
コストの最適化は段階的に行うとは？
コストの最適化は、継続的に行う必要があります。導入後もシステム全体を再検討し、段階的な最適化が必要です。
考察
システムは設計開発が主体ではなく、運用が始まってからが本番です。そのため、運用が始まってからでも、継続的にシステムを分析モニタリングし、コストの削減箇所を常に探る必要があるのだと思います。そのためには、継続的なモニタリングと改善を設計から運用までサイクルとして取り込む必要があると感じました。
LAW7. Unchallenged Success Leads to Assumptions.
挑戦を伴わない成功は思い込みにつながるとは？
大きな失敗などを伴わずに収めた成功は、成功例として過信してしまう傾向があります。
過去にこの方法で成功した、やったことがあるだけでは、最適とは限りません。
考察
我々が陥りやすい罠だなと思いました。最も危険な言葉として語られた、“We’ve always done it this way.”、我々はいつもそれでやっているは残念ながらよく聞くセリフです。常に最良の選択がなにか、費用対効果、効率などさまざまな新しい選択肢を模索する必要があります。開発手法、開発言語、アーキテクチャ等々常に我々は最新の情報を把握し、最適なものを提供する事が重要だと感じました。
また、運用を強く意識する必要があることも改めて感じました。コストの殆どが運用のコストであるため、開発時のコストはもちろん意識する必要があるのですが、運用時のコストを常に念頭に入れて、アーキテクチャないし、開発言語等々すべての常識を疑ってかかることが重要なのだと思います。
まとめ
アーキテクチャの構成にはトレードオフが求められます。その機能において、何を優先し、何を犠牲にするのか。
そのためには、ビジネス上の需要な要素を理解し、最適なアーキテクチャを選択する必要があルノだと思います。その選択が適切なものかどうかは常にモニタリングし続け、改善し続けていくことが重要です。私の中で以下を意識しようと思いました。
１．お客様のビジネス特性を理解すること
２．ビジネスにおける売上と、システム上のメトリクスを常に関連付けてモニタリングすること
３．お客様のビジネス特性に合わせて、トレードオフな非機能要件を構成すること
４．進化可能なアーキテクチャをとること
５．モニタリングしたデータに基づき、ビジネス上の判断を行い、その判断を容易にシステムに反映できるようにすること
６．これまでの経験や常識を疑うこと
最後に
ワーナーは、すべてのエンジニアはAWSのサービスを購入する決定を下しているという意識をする必要があると述べていました。
システムを構成する技術要素やパラメータは、そのシステムによる問題解決やお客様への価値提供につながるべきです。
AWSは、様々なサービスや、サービスにおけるトレードオフな選択を用意しています。（例：様々な開発言語、コンテナワークロード、可用性や性能に関するオプション などなど）我々は、お客様が実現したいことを叶えるために、適切にサービスを構成し、トレードオフをしながら構成要素を決定していく必要があります。我々がコストにかかる決定の一貫を担っていること、そしてそのコストについては必ずビジネスの要素とシステム上のメトリクスをモニタリングし、改善し続けること、そのためには進化可能なアーキテクチャを取る必要があるのです。これを常に意識してお客様のビジネスに貢献できるような、開発者となっていこうと思います。