法則１ コストを非機能要件にする。
LAW I.
Make Cost a Non-functional Requirement.
A non-functional requirement specifies criteria that can be used to judge the operation of a system, rather than specific features or functions. Examples are accessibility, availability, scalability, security, portability, maintainability, and compliance. What often goes overlooked is cost.Companies can fail because they don’t consider cost at every stage of the business – from design to development to operation – or because they’re not measuring it properly. The math is simple: if costs are higher than your revenue, your business is at risk.
By considering cost implications early and continuously, systems can be designed to balance features, time-to-market, and efficiency. Development can focus on maintaining lean and efficient code. And operations can fine-tune resource usage and spending to maximize profitability.
非機能要件とは、特定の特徴や機能ではなく、システムの動作を判断するために使用できる基準を指定するものです。例えば、アクセシビリティ、可用性、スケーラビリティ、セキュリティ、移植性、保守性、コンプライアンスなどです。コストは見落とされがちです。
設計から開発、運用に至るまで、ビジネスのあらゆる段階でコストを考慮しない、あるいは適切に測定していないため、企業は失敗することがあります。計算は簡単です。収益よりコストが上回ればビジネスは失敗する可能性があります。
早い段階から継続的にコストの影響を考慮することで、機能、市場投入までの時間、効率のバランスが取れたシステムを設計することができます。開発チームは無駄のない効率的なコードを保守することに集中できます。そして運用チームは収益性を最大化するためにリソースの使い方と金額を微調整することができます。
法則２ 存続するシステムはコストをビジネスに合わせる。
LAW II.
Systems that Last Align Cost to Business.
The durability of a system depends on how well its costs are aligned to the business model. When designing and building systems, we must consider the revenue sources and profit levers. It’s important to find the dimension you’re going to make money over, then make sure the architecture follows the money.For example, in e-commerce, that dimension might be the number of orders. When orders go up, infrastructure and operation costs rise. And that’s okay, because if your system is architected well, you can start to exploit economies of scale. What’s important is that infrastructure costs have a measurable impact on the business.
As builders, we need to think about revenue – and use that knowledge to inform our choices. Because growth at all costs leads to a trail of destruction.
システムの耐久性は、そのコストがビジネスモデルにどれだけ整合しているかにかかっています。システムを設計・構築する際には、収益源と利益のかじ取りを考慮しなければなりません。重要なのは利益をだせる側面を見つけ、アーキテクチャーがお金に沿うようにすることです。
例えば、eコマースの場合、その側面は注文数かもしれません。注文が増えれば、インフラや運営コストも上昇します。システムをうまく設計するということは、規模の経済を利用することができてよいということです。重要なのは、インフラ・コストがビジネスに測定可能な影響を与えられるということです。
何かを作るものとして、私たちは収益について考え、その知識を選択に役立てる必要があります。なぜなら、どのようなコストをかけて成長することも、破壊の道をたどることになるからです。
法則３ 設計とはトレードオフの連続である
LAW III.
Architecting is a Series of Trade-offs.
In architecture, every decision comes with a trade-off. Cost, resilience, and performance are non-functional requirements that are often at tension with each other.As the saying goes, “Everything fails, all the time.” Being able to defend against failure means investing in resilience, but performance may pay the price.
It’s crucial to find the right balance between your technical and business needs – to find the sweet spot that aligns with your risk tolerance and budget. Remember, frugality is about maximizing value, not just minimizing spend. And to do that, you need to determine what you’re willing to pay for.
アーキテクチャーの世界では、すべての意思決定がトレードオフを伴います。コスト、回復力、パフォーマンスは、しばしば互いに鋭い影響を与え合う非機能要件です。
例えば、「形あるものはいつか壊れる」とはよく言いますが、サービスのダウンタイムを減らすために回復力を増やすことに投資するということは、パフォーマンスを代償にしているかもしれません。
技術的ニーズとビジネスニーズの適切なバランスを見つけること、つまり許容できるリスクと予算に見合った最適な点を捉えることが極めて重要です。倹約とは単に支出を最小化することではなく、価値を最大化することであることを覚えておいてください。そのためには、何を支払っていいのかを見極める必要があります。
法則４ システムを観察しないことはコストを無視することにつながる
LAW IV.
Unobserved Systems Lead to Unknown Costs.
Without careful observation and measurement, the true costs of operating a system remain invisible. Like a utility meter tucked away in a basement, lack of visibility enables wasteful habits. Making meters more visible can profoundly shift behaviors.Though observation requires investment, not implementing adequate monitoring is shortsighted. The adage warns, “If you can’t measure it, you can’t manage it.” Tracking utilization, spending, errors, and more, is crucial for cost management.
When critical cost metrics are placed front-and-center before engineers and their business partners, more sustainable practices emerge organically. Ongoing inspection lets you spot excess spend and tune operations to trim expenses. The return on investment in observability typically far outweighs the expense.
Most importantly, keeping costs in the forefront encourages sustainable practices.
注意深い観察と測定がなければ、システム運用の真のコストは見えないままです。地下にひっそりと置かれた光熱費メーターのように、目に見えないというのは予算を無駄にしてしまう習慣を作りがちです。メーターをもっと見えるようにすれば、行動を大きく変えることができます。
観測するには投資が必要ですが、だからといって適切なモニタリングを実施しないのは目先のことしか見えてません。「測定できなければ管理できない」です。利用率、支出、エラーなどを追跡することは、コスト管理にとって極めて重要です。
重要なコスト指標をエンジニアとそのビジネス・パートナーの目の前に置くことで、より持続可能なやり方が組織的に浮かび上がってきます。継続的な検査により、過剰な支出を発見し、経費を削減する運用方法にもっていくことができます。観測可能性への投資対効果は、通常、費用をはるかに上回ります。
最も重要なことは、コストを常に最前線に置くことで持続可能な実践を促します。
法則５ コストを意識したアーキテクチャーはコスト管理を可能にする。
LAW V.
Cost Aware Architectures Implement Cost Controls.
The essence of frugal architecture is robust monitoring combined with the ability to optimize costs. Well-designed systems allow you to take action on opportunities for improvement. For this to work, decompose applications into tunable building blocks.A common approach is tiering components by criticality. Tier 1 components are essential; optimize regardless of cost. Tier 2 components are important but can be temporarily scaled down without major impact. Tier 3 components are “nice-to-have”; make them low-cost and easily controlled.
Defining tiers enables trade-offs between cost and other requirements. Granular control over components optimizes both cost and experience. Infrastructure, languages, databases should all be tunable. Architect and build systems with revenue and profit in mind. Cost optimization must be measurable and tied to business impact.
フリューガルアーキテクチャの本質は、コストを最適化する能力と組み合わされた強固なモニタリングです。うまく設計されたシステムは改善する機会を与えます。これをうまく使うには、アプリケーションを調整可能な構成要素に分解すます。
一般的には重要度によってコンポーネントを階層化する方法を取ります。
第1層、コンポーネントは必須であり、コストに関係なく最適化します。
第2層、コンポーネントは重要だが、一時的に縮小しても大きな影響はない。
第3層、コンポーネントは「あればいい」ものであり、低コストで容易に制御できるようにする。
層を定義することで、コストとその他の要件のトレードオフを可能にします。コンポーネントをきめ細かくコントロールすることはコストとエクスペリエンスの両方を最適化します。インフラ、言語、データベースはすべて調整可能でなければなりません。収益と利益を念頭にシステムを設計・構築しましょう。コストの最適化は測定可能で、ビジネスインパクトに結びつくものでなければなりません。
法則６ コストの最適化は漸進的
Cost Optimization is Incremental.
The pursuit of cost efficiency is an ongoing journey. Even after deployment, we must revisit systems to incrementally improve optimization. The key is continually questioning and diving deeper. Programming languages provide profiling tools to analyze code performance, and while these require setup and expertise, they enable granular analyses that can lead to changes that shave milliseconds. What may seem like small optimizations accumulate into large savings at scale.In operations, most time is spent running existing systems. There are opportunities to profile resource usage and identify waste reduction. At Amazon, we continuously monitor services in production to understand patterns and trim inefficiencies. Frugality takes persistence – by incrementally reducing latencies and infrastructure costs, we can optimize the cost to serve.
There is always room for improvement… if we keep looking. The savings we reap today fund innovation for tomorrow.
コスト効率の追求は終わらない旅に出かけるようなものです。施策実行後も最適化を続けるためにシステムを見直さなければなりません。重要なのは絶えず疑問を持ち、深く掘り下げることです。プログラミング言語には、コード・パフォーマンスを分析するためのプロファイリング・ツールが用意されており、セットアップと専門知識が必要ですが、ミリ秒単位での変更につながるきめ細かな分析が可能です。小さな最適化の積み重ねが、大規模なら大きな節約になります。
運用では、ほとんどの時間が既存システムの運用に費やされます。リソースの使用状況をプロファイリングし、無駄の削減を特定する機会はあります。例えばアマゾンでは、本番稼動中のサービスを継続的に監視し、パターンを把握し、非効率な部分を削減しています。倹約には粘り強さが必要です。レイテンシーとインフラコストを段階的に削減することで、サービス提供コストを最適化することができます。
探し続ければ、改善の余地は常にあります。私たちが今日得た節約は、明日のイノベーションのための資金となります。
法則７ 挑戦なき成功は思い込みを生む。
Unchallenged Success Leads to Assumptions.
When software teams achieve significant success without facing major failures or roadblocks, complacency can set in. There is a dangerous tendency to become overconfident in the methods, tools, and practices that led to those wins.Software teams often fall into the trap of assuming their current technologies, architectures, or languages will always be the best choice, simply because they have worked in the past. This can create a false sense of security that discourages questioning the status quo or exploring new options which could be more efficient, cost-effective, or scalable.
You see this frequently when it comes to programming languages. “We’re a Java shop” is a phrase I’ve heard too often – and it can stifle innovation. Unchallenged success breeds complacency through assumptions. We must always look for ways to question, optimize and improve.
As Grace Hopper famously stated, one of the most dangerous phrases in the English language is: “We’ve always done it this way.”
ソフトウェアチームが大きな失敗や障害に直面することなく大きな成功を収めると、自己満足に陥ることがあります。成功に導いた方法、ツール、プラクティスを過信する危険な傾向があります。
ソフトウェアチームはしばしば、過去にうまくいったからという理由だけで、現在のテクノロジー、アーキテクチャ、言語が常に最良の選択であると思い込む罠に陥ります。これは誤った安心感を生み、現状に疑問を持ったり、より効率的でコスト効率や拡張性の高い新しい選択肢を探したりすることを妨げます。
プログラミング言語に関しては、このようなことがよくあります。「うちはJava屋だから」というのは、私がよく耳にするフレーズで、イノベーションを阻害します。挑戦のない成功は、思い込みによる自己満足を生みます。私たちは常に疑問を持ち、最適化し、改善する方法を探さなければなりません。
アリとキリギリスに出てくる最も危険なセリフのひとつは「私たちはいつもこうしてきた」です。