AWS re:Invent 2021 Peter DeSantis Keynote – Infrastructure

re:Invent 2021 第三場 Keynote 由 AWS Utility Computing SVP – Peter DeSantis 主持，帶領各位一探 AWS 如何優化自身的 Global Infrastructure ，帶給使用者最佳的效能體驗並幫助客戶做帶來競爭優勢。

從發布第一個 AWS Service 以來已經過了十五年，十五年前在看文章的你可能還在念小學，那是一個沒有智慧型手機、可能還在 Apple Store 排隊買 iPod 的時候。

在那時候 AWS 發佈了 EC2 這個服務，提出了「Elasticity」彈性使用的概念，儘管當時只有一個 Instance Type，一個 Region，也沒有任何的 Availability Zone、Storage 為 ephemeral 關機後就會被 purge 掉。

EC2 發布幾天後 Jeff 發了一封信出來，當中問了「如何確保 EC2 的效能與穩定？」

從十五年前至今，AWS 在談論的都是對客戶最重要的幾個面向：

• Security 資訊安全
• Availability 服務可用性
• Elasticity 使用彈性
• Performance 效能
• Cost 成本
• Sustainability 永續發展

“Still important today!” 從以前至今，所在談論、優化、發布的 Features 都不會脫離這些領域。

Storage

Peter 帶大家從 Storage 開始看起，回顧雲端服務如何依據效能、用量做 Storage Scale ，試圖解決 IT 人的痛點，這也是打造 Amazon S3 的初衷；時至今日 S3 上面放了超過 100 兆的檔案，平均每一位地球上的居民都擁有一萬個以上的檔案放在 S3 上面。

如同 EC2 剛發佈時僅支援一種 Instance Type，S3 剛推出時也僅僅支援一種 Storage Class，來讓使用者上傳、下載與分享任意大小的檔案。S3 這種特性也讓使用者為之驚豔，並開始上傳檔案分享、把 VM Snapshot 上傳至 S3 當作是備份的空間、把過往搜集的資料上傳 S3 作為 Datalake 以利做資料分析等等，不同的使用需求都進而觸發 S3 打造不同的 Storage Class，根據不同使用狀況提供符合時間、用量的儲存模式。

而隨著時間的流逝，針對像是過期的新聞資訊、賽事資訊等，這一類曾經很熱門、短時間內不太會被存取，但需要時要能夠「立即」取得的資料，S3 提供了 Standard-IA (Infrequently Access) 來滿足這類需求。

如醫療影像、access log、歸檔文件等需要被長時間的保存、但在短時間內不會被存取的資料，也有 S3 Glacier 的選項做封存。根據使用者回饋，Amazon S3 Glacier 的存取很慢，當我們要存取時需要時間解凍檔案。為了解決這一個問題，AWS 發布 Amazon S3 Glacier Instant Retrieval，使用 S3 Glacier Instant Retrieval 去拿取 S3 Glacier 中的資料時，其吞吐量和回覆時間與 S3 Standard 和 S3 Standard-IA 相同。同時 S3 Glacier 也更名為 S3 Glacier Flexible Retrieval，使用者在使用 S3 上，也更加彈性了。

新聞來源：Announcing the new Amazon S3 Glacier Instant Retrieval storage class – the lowest cost archive storage with milliseconds retrieval

而需要了解到這些不同的 S3 Storage Classes 是怎麼被實現的，我們要回到過去從 Hard Drive 開始講起。

硬碟簡史

第一個硬碟的誕生可以追朔到 1956 年，當時硬碟非常昂貴的，雖然在過去 4 年 SSD 已經占據大多數硬碟的 workload，但以資料儲存量以及大數據時代，硬碟還是有不可取代的地位。

當今的硬碟內部機些結構基本為一個磁頭加一個快速旋轉的碟盤，透過電機的帶動碟盤，此時磁頭上的速度跟飛機一樣快!

一般 HDD 可以提供大約 120 IOPS ，但是這幾年其實一直都沒有改進，硬碟廠商更多改善的是利用新的材料、新的技術讓硬碟的儲存密度增加，並降低硬碟容量的成本。

但我們知道要增加硬碟的讀寫速度（吞吐量）或是容量的話必須是多個硬碟做並行處理(Raid 0)，這邊 Peter DeSantis 提出兩個極端的例子，需要高吞吐量的使用情境會讓很多的容量閒置，需要高容量的使用情境會閒置很多讀寫效能，這都是一種浪費。

需要高吞吐量	需要高容量

AWS 的解法就是將每個 S3 Object 分成很多個 Data shard，將他們分在在各個實體的硬碟中，當使用者要拿回資料時在將那些 Shard 組合起來，變成 Object 回傳給使用者。

當然這樣的設計也花很多心思才能同時確保速度跟安全性，引此 S3 在設計時使用了 Formal Method 方法開發，以確保 S3 的性能指標的可驗證性。

Use Case – Brandon Pulsipher from Adobe

現今的社會，每天民眾都在透過網路資訊來互動，工作、學習、聯絡，甚至娛樂方式都會以數字方式紀錄，而 Adobe 面對使用者大量的創作，開始遇到一個問題：儲存空間。

而 Adobe 需要一個可以保存、存取短期性（hot data）及長期性（cold data）資料的解決方案。過往，人們在沖洗了一段照片後，一開始會常常打開來看，但往後就放進了閣樓裡保存著，時隔多日又再想起，從閣樓裡再度拾起，回憶起與 80 歲年邁父親的回憶，同時開始組織、數位化這些照片。而現在，Adobe 就面臨了類似的需求，但規模大得多。

在這種場景，像是婚禮、全家福、公司活動、商品型錄…等等，都會有數百張照片、數百個好幾小時的影片產生，而在 2022 年，預計會有 1.5 兆張照片存在於 Adobe 的儲存空間，且可能會持續上升。

而接下來的挑戰是：要如何讓使用者隨時搜尋、存取在一段歷史上的某一份影像？

往往雲端儲存方案是在光譜的兩端，一個給予良好的儲存方案，一個給予低延遲、高可用性的存取，但 Adobe Creative Cloud 需要的是位居中間儲存方案，讓成本更貼存儲存方案，而讀取資料卻更像是一般硬碟的讀取效能。

S3 Glaicer Instant retrieval 便是 Adobe 目前重要的選擇，它讓 Adobe 的用戶隨時上傳想要的任何內容，並在需要的時候快速回覆。同時，其容納大量資料的性能更是優化 Adobe 競爭優勢，因為它幫助驅動了 Adobe Sensei – Adobe 上的 AI 和 ML 功能。讓使用者可以在數百 GB 的照片和數小時的視頻中，找到使用者目標的項目。

Block Storage

Peter DeSantis 一開始花了很多時間在描述 SSD 底層所遇到的問題：有讀取次數的限制，更多 Detail 請參閱 SSD廠商沒有告訴你的真相：SSD 資料難以完全刪除

而文中提到的 Flash Translation Layer (FTL)，在一般使用情境下，它可以幫助 SSD 延伸壽命、抽象化 SSD 底層運作，方便一般使用者使用 SSD。但是，AWS 為一家雲端提供商，不同廠牌的 SSD 有不同的 FTL，這也意味在 Scale 時，要結合不同 FTL 的底層邏輯是 AWS 所面臨最大的問題。

AWS 要提供固定的效能給客戶，而不同的 FTL 意味著有更多的硬體屬性可能是不符合預期的。雖然大同小異，但是使用量大的話，每個細節都會造成大問題，因此 AWS 花很多時間在研發 Nitro controller

Nitro controller 幫助的不僅只有在 Storage，Hypervisor 之下的網路介面及其他硬體監控也大大的受益於 Nitro controller。 Nitro controller 帶來 4 大好處：

所有的硬體架構都構建在 Nitro controller 之上

這樣的架構帶來的新服務：

io2 Block Express 對於 SQL 的效能也有所提升

Still building Graviton

AWS 也整合 Graviton 在許多服務上，以達到最好的 CP 值，包含 serverless 的服務。

以 AWS Lambda 來說就有 34% 效能上的提升。

也有以 Graviton2 為基底的 Instance Type。

而目前也有許多企業已經開始採用新型的 Instance Type 或是以 Graviton2 為基底運算服務。

而目前 Graviton3 處理器也進入 Preview 階段，它的效能提升可以達到 25%，比起 Graviton2 來說，有更好的表現。

且 18 個月前 Graviton 2 已經領先業界！

但這個 Graviton3 的時脈只有 2.6GHz，怎麼會有好的效能呢？

以往 CPU 的性能指標都是以時脈來評定，而越高的時脈意味需要越多的能量，越多的能量代表產生的廢熱也會比較多，廢熱多代表能耗比率不好，也代表需要更大的散熱空間，這對 data center 都是不好的！

為了在不增加能耗的前提之下，為了增加運算效能，Graviton3 採用的是 更寬 的核心！

簡單來說 更寬 的核心，意味著 CPU 在一個 clock 可以處理更多條指令，所以在低時脈的情況下效能也會有所提升。

Graviton3 不僅僅在 CPU 指令處理上有明顯的效能提升，因為現在雲端服務的 workload 更多是傾向於記憶體存取效能，而不是像以往的 CPU 越多越好，所以 Graviton3 記憶體也使用 DDR5 記憶體，在記憶體延遲上也有顯著降低很多。

因此使用 Graviton3 的 C7g Inatance Type 成了下一個期望擁有更好效能的使用者的目標。

Use Case – Fannie Mae

Shared by Kimberly Johnson, EVP & COO of Fannie Mae.

Fannie Mae 是世界上最大的金融機構之一，有 4 萬億美元的資產負債表。而在去年，美國每四個家庭就有一個是通過 Fannie Mae 購買或融資的，Fannie Mae 也是多戶租賃市場上最大的融資供應商之一。

而隨著時間的推移，消費者期望整個借貸流程能夠更簡單、快速、安全，且數位化，Fannie Mae 也致力於促進公平的房屋買賣交易，因此 Fannie Mae 希望可以建立一個住房融資系統，讓所有人，包括中階收入的人們，都有優質、負擔得起的房子可以選擇。因應這些需求，需要一個「智能風險管理」系統。

而為了要良好的評估風險並掌控風險的大小，系統必須了解借方的信用歷史、房價的變動、宏觀經濟的趨勢…等等任何有價值的資訊，而這也意味著非常龐大的資料量；除此之外，也會保存許多使用者的個人敏感資訊，所以總結來說，Fannie Mae 需要建構一個安全、有效率的智能風險管理系統。

幾年前，Fannie Mae 透過 AWS Lambda 及 Amazon RDS on Graviton2 來幫助建構這套系統，而效果相當顯著！不僅效能增強了 54%，在成本面，也優化了 11% 之多。

一直到了 2020 年，AWS 仍在持續的幫助 Fannie Mae 度過許多難關，例如：Covid-19 所帶來的影響。而這是第一個 Kimberly 想特別強調的故事。

在 Covid-19 剛開始的兩個月，美國產生非常劇烈的經濟恐慌，突然有 2 千 5 百萬人失業，而這對 Fannie Mae 是前所未有的狀況：接下來借貸雙方會有什麼行為？

為了解決時下的突發狀況，Fannie Mae 需要研發解決方案，透過找到更多資料來源，並了解資料背後隱藏的模式才能幫助改善各個家庭（借方）的困境。而這可能要花很多時間，但 Fannie Mae 利用 Amazon Kinesis 來即時串流資料，並存放上無總容量上限的 Amazon S3，最後使用 Amazon SageMaker 來分析、產生即時的解決方案給這些家庭。

最後結果是，Fannie Mae 幫助多達 1 千 1 百萬的家庭，克服了困難，保住了房子。

從這個例子中，可以發現資料分析幫助提升了買房市場的品質，另外也幫助 Fannie Mae 更好的評估一個人的信用。而這也是第二個 Kimberly 要分享的故事。

在過去，金融機構在評估一個人是否有良好的信用來決定貸款的額度，甚至決定這個人能不能貸款時，往往看的因素不外乎是就學貸款、信用卡繳款狀況，或是監護人的信用狀況，但卻有一個重要的現金流卻不在評估的因素裡：租屋的付款紀錄，一種人們定期、定額繳交的付款行為。

而這種租屋的付款行為其實與償還貸款行為非常相似，因此 Fannie Mae 認為這也應該被列入考量，所以 Fannie Mae 開始研發「Desktop underwriting」系統，期望透過資料處理的技術，可以在眾多的現金流的紀錄中，判斷出哪些是定期、定額的繳款行為；但仍有一個重大的挑戰：繳交租金的方式不只一種，人們可以匯款、開支票、現金，甚至交給代收的室友，假設這些繳款方式都可以被記錄，那這些結構化、非結構化的資料，又該如何有效、低延遲的處理呢？

最終 Fannie Mae 透過以下方式達成： – Amazon S3 & Amazon Redshift 來存放資料非結構化資料及結構化的資料。 – Amazon EMR 來轉換非結構化資料至結構化資料。 – 為了讓這些資料可使用在正式環境，使用 Amazon SageMaker 來開發適合的演算法，分析資料並推論最佳結果。

在列入租金支出後，現在讓許多民眾不再因為信用不足而被拒絕貸款，都能夠擁有自己的房子了。

而上述的兩個故事正式數位創新幫助改善人們生活的最佳例子。但未來的變化總是難以預測，例如：氣候。

而對於房市來說，氣候也是一個需要考量的因素，Fannie Mae 需要瞭解哪些房子容易遭受到洪水、火災、颱風…等氣候因素的影響而損害到房屋擁有者的利益，又或者是影響到房屋保險的保障。因此掌握氣候的狀況也才能夠保護家家戶戶人們的資產，進而有更好的生活環境。

這其中，Fannie Mae 利用 Amazon EMR auto scaling & geospark 來驅動地理位置上的分析；透過 Amazon RDS GIS extensions 來快速處理空間上的資料；接著利用 AWS 上的 Step Function & Lambda 來進行 ETL 資料處理，同時加快整體速度和可視性；最後，AWS Marketplace 也可幫助共享這些解決方案，達成更廣泛的利益。

“Helping with the pandemic, making housing fair and accessible, addressing climate change, for Fannie Mae, all of these challenges are within our responsibility. They require maximum effort, our best minds, our best technologies and partners, in and out of housing, who are strong capable and committed.” – Kimberly Johnson, EVP & COO of Fannie Mae.

ML

Peter 也聊到 ML 本身的進入門檻很高，但得力於 AWS 所提供的服務，越來越多企業使用 AWS 的 ML 服務幫助他們轉換業務模式，

ML 主要分為兩大部分 Training 跟 Inference：

• Training 藉由不斷疊代訓練資料來建構模型，模型可以被想像成一個有很多很多浮點變數的矩陣函數，而在每一次的迭代中不斷地調整矩陣的係數，而那些係數就是所謂的模型參數（Parameters）。
• Inference 利用訓練出來的模型去預測輸入資料。

這兩大部分在 infrastructure 面向要面對的問題是非常不同的，而且所使用的演算法在業界或在學術界都不斷更新。有些人要 Nvidia GPU；有些人要 Intel Habana，這也就是 AWS 為什麼要支援那麼多種 ML 基礎設施的原因。

Inference

這邊先從 Inference 開始，Inference 不像 Training，可能一個月執行一次就行，Inference 是隨時只要有請求就要服務的，因此 cost 是非常重要的，而 AWS 提供這幾種不同的 Inference Instance 以對應各種需求，像是需要 CUDA 加速的可以選擇 G5g。

但一般通用運算也很重要，所以 AWS 也一直在規劃這部分，像 Graviton 是 AWS 第一個支援 Bfloat16 的 CPU。Bfloat16 用 16 bit 來標示傳統 32 位元的浮點數，雖然犧牲了一些精準度，但有趣的是，較低的精準度在很多 ML workload 其實影響不大，但是使用 Bfloat16 CPU 可以運作得更快、更有效率。Graviton3 就有支援 Bfloat16，同時他又是一個更寬的 CPU，加上價格實惠，簡直是一般通用運算的首選。

Training

Training 的部分，AWS 提供 Tran1 的 Instance Type 可以使用，Trainium 的意思就如同字面上是專門用於模型訓練工作的。近三年AWS 陸續發布迭代的 Trainium 晶片，也看到在 ML 領域的需求增長，為了使用者 AWS 持續推陳出新。

ML 的模型在這幾年是越來越大的，越來越大的意思是模型的參數（Parameters）越來越多，整個模型架構越來越複雜，而越來越多的參數帶來的好處是模型輸出的結果越來越好。這幾年模型的增長來到了 10 倍，當然運算這些模型的硬體，也有做相應的提升。這些硬體效能只提升大約是 3 倍左右，這明顯跟不上模型複雜度的增長。

要解決這樣的問題只有適用更多的處理器才行，這也是為什麼那些 ML 科學家要開發分散式訓練技術的原因，分散式訓練最簡單的為 Data parallelism，Data parallelism 為將資料分在多個處理器訓練，再將各個結果整合到同一個模型。

這邊以 BERT-Large 自然語言模型為例，他有 340M 個參數，就如同它的名字，它是一個很大的模型，如果用現在最強的 GPU 需要 6 周的時間才能訓練出結果，而現在使用多個 GPU 即可將訓練時間降至一小時之內。但是連動越多個 Instances 意味著越多 communication overhead 需要被考慮，這也是在選擇多機器聯合訓練時候所需要面對的問題。

而現在又有一個更大的自然語言模型出現了：GPT-3。參數數量來到驚人的 175B，這時候記憶體的大小就很重要了，在訓練的時候必須要有足夠大的記憶體，才能將整個模型塞進去來調整參數，這時候更不可能單靠一台機器處理，這下該怎麼辦？

通常會將模型拆分到不同的處理器中處理，這個手法叫做 Model Parallelism，一般有兩種方法可以使用：Pipeline Parallelism 跟 Tensor Parallelism。Pipeline Parallelism 是將模型分成不同的 Layers，分別放到不同 server 做運算。但有些時候 Pipeline Parallelism 不能適用，這時候只能用 Tensor Parallelism，將模型分成多個小模型再依序運算。

總之，在隨著模型越來越大，需要的不只是算力，記憶體大小也是非常重要的一環，但萬一一部機器不夠，需要多台來聯合運算時，網路傳輸有更重要的地位了，AWS 在 infra 上也提供相對應的 solution 方便使用者訓練超大模型。

Trainium 不只在分散式訓練上更有效率，Trainium 還引入了 Systolic Array，讓大量的矩陣相乘在 CPU 內即可完成，大大增加了運算效率。

但 CPU 內運算雖然大幅度增加效率，但犧牲了一些靈活性，不過 AWS 的 Trainium 不僅有效率也要有靈活性。

所以 Trainium 提供 16 種 data processor 供使用者使用，如此一來就可以同時保有效率及靈活性。

這邊以四捨五入的 Round 作為例子，在一般情況下 Round(0.3) = 0, Round(0.6) = 1，一般電腦處理起來這個運算是非常容易的。

但科學家們更加偏好 stochastic rounding，stochastic rounding 與一般的 Round 函數不同的地方在於 stochastic rounding 會多參考機率分布，也就是說 stochastic_rounding(0.3) 並不一定都等於 0，而是他有 70 %會是 0， 30% 會是 1。這用在 Bfloat16 可以大幅度增加模型的精準度也降低運算成本。

但是 stochastic rounding 的運算是非常複雜的，每使用一次都需要產生一個亂數出來，一般處理器在這部分的效能就沒那麼好，Trainium 在這方面就有做優化。

只需要使用 AWS Neuron SDK 使用者幾乎不需要修改任何 code 就可以讓 Trainium 隊訓練工作最佳化。

AWS Neuron SDK 支援目前常用的 ML 框架 Pytorch Tensorflow 等

2025 減碳中和計畫

碳中和議題中雲端一直是趨勢浪尖的最佳選項，在 AWS 怎麼提供客戶？在 2019 年 Amazon 發起 The Climate Pledge，希望在 2040 年前達到碳排放 0，比巴黎協議的 2050 年提早 10 年完成，有超過 200 家企業支持

所以 AWS 致力於更有效率的 Infra，也一直研發夠有效率的晶片如 Graviton 等

當然原本預期在 2025 年時，將使用全綠能，來供給 Infra 所需要的電力，而在 2020 年，AWS 已經是世界上做大綠能的採購商

今天再度宣布 AWS 將啟用 18 個新的綠能項目，可以減少 1370 萬公噸的碳排放量，其中包含非洲地區的太陽能及海上風力發電

這些項目也包含能源儲存。以太陽能為例，白天發電，多餘的電要存起來，晚上才能用，這也才能確保 24 x 7 都有電可用。

同時間 AWS 也是利用自己的服務來監測、優化各種綠能項目，確保能夠最大化的提高電力輸出

AWS 的客戶也可以從 AWS Customer Carbon Footprint Tool 來監測、預測在 AWS 上的服務的碳排放量，大家一起守護地球

結語

今年可以說是 ARM 架構 CPU 大爆發的一年，除了蘋果 M1 晶片大發異彩之外，AWS 也從去年到現在不斷改進、研發新的處理器讓使用者有更 Cost Effective 的選擇，因為 ARM 架構的處理器能夠更有效率的執行每一項工作，因此也是 AWS 在能源計畫中不可或缺的一個元素之一，慢慢推動整體基礎建設全綠能化的偉大目標。