搶救 IT 失傳技藝，亞馬遜技術長倡議節約架構 （Part 1 設計篇）

在雲端運算服務尚未問市之前，評估資訊系統的成本效益是資訊人員必備能力，身為全球最大電商亞馬遜（Amazon）技術長的Werner Vogels說：「在當時採購資料庫這類大型系統，都得先評估足以使用五年的規格，才能達到最佳成本效益。」然而，在雲端運算資源垂手可得的今日，雖然傳統硬體的限制越來越少了，軟體開發人員可以更聚焦在功能創新與更快推出上市，但也因此忽略成本效益的重要性，Vogels指出，重視成本效益幾乎已成失傳的技藝，為此他在re:Invent 2023的主題演講提出「節約架構（Frugal Architect）」設計法則，呼籲將成本意識納入軟體架構設計，進而達成永續目標。

節約架構可謂亞馬遜過去二十多年軟體開發經驗的總和，特別是打造具有成本意識與永續發展的系統架構，Vogels回憶道，「在還很難買得到PlayStation的年代，只要有人貼文說亞馬遜明天會開賣，許多消費者就會在開賣前五分鐘開始狂按電腦的F5按鍵更新網頁，以在第一時間讀取到販售網頁，不過這也導致網站流量瞬間爆增。」然而，當時可沒有調度自如的雲端運算資源可用，因此考驗著資訊人員如何有創意地解決刺手問題。

還有一次，在黑色星期五購物節來臨前，亞馬遜的業務團隊興高采烈地提出許多可衝高業績的新點子，接著就輪到技術團隊苦惱如何在既有系統架構與有限資源下達成業務目標。不過Vogels指出，過往資訊人員就是因為突破種種硬體上的限制而練就一身技藝，然而隨著雲端運算普及，在限制越來越少的情況下，這些技藝也逐漸失傳。

Vogels提出的節約架構由三大類、七項軟體架構設計法則所組成，他表示，之所以稱之為法則，代表是過往諸多經驗的心得，並非硬性規定；而區分成「設計（Design）」「量測（Measure）」與「最佳化（Optimize）」三個部分，則有助於形成框架式的思考架構。

第一項法則是將成本納入非功能性（Non-functional）需求。傳統上非功能性需求包含資安（Security）、法規遵循（Compliance）、無障礙設計（Accessibility）、效能（Performance）、可用性（Availability）、擴充性（Scalability）與可維護性（Maintainability）等項目，Vogels指出，在過去資安、法遵與無障礙設計是無法妥協的三個項目，然而現在光這三項並不足夠，還需要納入成本（Cost）與永續性（Sustainability），成為必要的非功能性需求。

以Amaozn設計S3物件儲存服務的經驗為例，Vogels指出，由於雲端運算服務必須提供明確的價格，因此必須先分析運算成本，以訂定合理計價模式。一開始他們認為S3儲存服務的成本不外乎傳輸檔案與儲存檔案，然而，在先期客戶試用S3的過程中，他們才發現之前忽略了使用者讀取（Request）物件資料其實也會有相對應的成本。

上述經驗隨後也運用在DynamoDB無伺服器資料庫服務，由於此服務提供兩種讀取一致性（Consistency）選項，包括最終一致讀取（Eventually Consistency）與強烈一致讀取（Strong Consistency），而由於強烈一致讀取的讀取次數是最終一致讀取的2倍，因此計價也就必須多一倍才合理。

成本考量必需落實在系統設計的每一個環節，Vogels說：「我們開發軟體，終究是為了幫公司獲利，而不是展現自己的技能。」因此，除了考量軟體架構必要的功能性、擴充性與穩定性，還要評估軟體成本對公司獲利的影響。在設計軟體系統架構前，必須先確定營收模式，並確保系統的設計能夠支持獲利，他說：「系統架構設計一定要跟著公司獲利的方向發展，如果不幸走反了，最終你一定會完蛋。」這也就是節約架構的第二項法則：「系統成本必須與公司獲利保持一致。」

AWS知名的無伺服器運算服務Lambda，其實背後也有一段鮮為人知的成本與架構重構的故事。在S3、DynamoDB等物件儲存與資料庫無伺服器化服務陸續推出之後，AWS的客戶開始期待運算服務也可以無伺服器化，好擺脫繁重的伺服器管理工作。Vogels表示，因為之前有設計S3物件儲存服務的經驗，在訂價方面他們很快確定無伺服器運算服務需從兩個面向計價：每微秒的處理器運算量，以及記憶體使用量，在功能方面也確定必須兼顧安全性、強化隔離與成本效益等三項非功能性需求，但是接下來他們卻察覺缺乏足夠的技術，以達成上述三項必備的非功能性需求。

眼看推出無伺服器運算服務勢在必行，但在缺乏相對應技術，以致於無法兼具成本效益的情況下，Vogels說：「所以我們一開始就先確定了，在成本效益上得有所犧牲……而未來一定得為此付出相對應的技術債與經濟債。」於是，他們成立了兩個團隊，第一個團隊先在既有技術下動手開發，第二個團隊則負責開發無伺服器運算服務所需要的關鍵技術。

為了確保無伺服器運算服務的每一個用戶程式碼都有安全隔離，第一個團隊選擇將每一個Lambda服務以EC2最小規格的T2執行個體來運行，然而，由於Lambda函數程式碼通常都很小，即便已經採用最小執行個體T2，但大多數的運算利用率都不到一半，也就是說AWS得多付出多一倍的運算成本來提供Lambda服務，而這也就是Vogels所說的，在決定開發的第一天就已經知道未來必須承擔的經濟債。

AWS在2014年推出Lambda後，事隔四年，第二個團隊以Linux KVM為基礎開發出微型虛擬機器Firecracker，讓單一主機可以承載更多的Lambda服務，終於解決運算利用率的問題。Vogels指出，其實當初如果沒有開發Firecracker，接下來的無伺服器容器運算服務Fargate也難以實現。

回首從Amazon S3至AWS Lambda的開發歷程，Vogels打趣地說，這個過程就像一邊開飛機還要一邊換引擎，而且還不能讓乘客察覺異狀。這段經歷也讓他觀察到節約架構的第三項法則：「架構設計是一連串的權衡與取捨」。他建議開發人員要打造可持續進化又不影響業務營運的架構，因為改變一定會發生。

繼續閱讀 → Part 2 節約架構量測篇

節約架構 Frugal Architect

設計

I. 成本是必要的非功能性需求
II. 系統成本必須與公司獲利保持一致
III. 架構設計是一連串的權衡與取捨

量測

IV. 無法量測的系統必有隱藏的成本
V. 有成本意識的架構必有成本控制措施

最佳化

VI. 成本最佳化是漸進的
VII. 無庸置疑的成功必將導致錯誤的臆斷