當Amazon Web Services在2018年發布其AWS Graviton Arm處理器時，它的目標是松散耦合的橫向擴展工作負載，比如Web服務器、日志處理和緩存，這些實例吸引了SmugMug這樣的客戶，他們覺得自己在高級計算上付出的代價太高了，而一個較小的內核就可以完成這項工作。基于Arm的計算實例可以替代絕大多數云巨頭客戶使用的基于x86的服務。

　　亞馬遜EC2的副總裁、David Brown,在接受New Stack采訪時表示，從很多方面來說，這都是為了啟動生態系統。“我們想向生態系統發出信號，Arm服務器芯片將成為現實，我們將把它們推出市場。”

　　準備好生態系統意味著，Graviton2不僅可以快速支持EC2實例，還可以支持越來越多的AWS服務，包括Amazon RDS、Amazon ElastiCache（其中Graviton2實際上是默認的）和像Amazon EKS這樣的容器服務。

　　只有在客戶選擇處理器架構的時候，Graviton才會顯現出來；在“絕大多數服務”中，客戶將永遠不會看到該服務是在Arm上運行的，但他暗示很多客戶將會看到。

　　Brown指出，將AWS服務遷移到Arm還有助于使生態系統為客戶的工作負載做好準備。“這為我們提供了很多內部經驗，涉及客戶將會經歷的事情，以及確保我們在生態系統中能夠接觸到各個參與者，并通過我們可以構建的工具和可以幫助您的事情來解決問題。”

　　Graviton2甚至可以作為一個擁有64個vcpu、128GiB內存和4TB本地NVMe存儲來運行Amazon EC2和EKS的1U服務器（盡管AWS建議將其用于受限制的位置，如蜂窩基站而不是主流數據中心）。“我們從客戶那里聽說，他們很希望在前哨站安裝Graviton2，就支持生態系統而言，并確保我們能在客戶需要的時候提供他們想要的硬件，ARM處理器并不意味著不能在前哨站安裝。”

　　AWS還將添加更多基于AWS Graviton2的實例-最新的是計算和網絡密集型C6gn，以及為大型內存數據集或計算密集型工作負載而設計的實例，帶有或不帶有本地NVMe存儲。

　　從卸載到整合

　　Brown建議考慮開發類似Graviton的硬件微服務，它可以比整個單片硬件系統更快地建立起來。Brown說，所有的云服務提供商都希望降低在同一個CPU上運行云服務的開銷，而AWS Nitro計算核心的運行效率遠不止于此。

　　一定比例的處理器（不管它是什么）被虛擬化堆棧和需要在機器上運行的大量其他管理軟件所使用。我們注意到的是，除了降低效率之外（因為您使用了本可以提供給客戶的10 - 20%的核心用于您自己的工作和管理程序），我們還無法獲得我們認為客戶需要的那種性能。

　　AWS使用Nitro將越來越多的開銷轉移到單獨的處理器上，以提高性能并使其更加一致。“我們做的第一件事就是移除網絡并將其卸載到Arm處理器上。我們卸下了所有的管理控制職能，最終在2017年，我們的CPU使用率達到了零。”

　　由于Arm授予IP許可而不是出售處理器的方式，Arm SoC通常是CPU，GPU和加速器的自定義程序包，并且Amazon添加了許多AWS特定功能。

　　“Graviton2的三分之一是Arm核心，其余部分是我們設計的定制硅，”Brown說。這包括加密內存和提高內存性能。很多工作是確保糾錯，并確保內核確實非常正確，并且可以處理可能無法正常工作的內存模塊，并保護客戶工作負載免受此類故障的影響。“

　　CPU綁定應用程序的核心

　　Arm以移動芯片起家，常常被視為一種降低功耗的方法，而高核心數量使Arm系統很適合并行化，但最近幾代Arm也提供了強大的核心。這一組合帶來了AWS所關注的性價比。

　　”Arm核心消耗的能量只有可選核心的一半。客戶看到了20%的原始性能改進；如果你在同一個基準測試中運行，在Graviton2和最新的英特爾處理器上，Graviton2大約快20%，“Brown說。它還便宜20%左右。因此，你可以得到40%的價格性能改進，Brown說。

　　”我們已經看到客戶使用支持ARM64的最新版本的Java獲得了巨大的性能優勢。我們看到客戶也從數據庫應用程序中獲得了這一好處。他說，只要看到核心的性能，價格就可以了。

　　Brown說，客戶通常在移動更多堆棧之前就開始在他們的應用程序層使用Graviton。“它不需要大量的計算密集型；它只是一些CPU受限的最通用的工作負載，如果可用的話，它們會使用更多的CPU。很多云本地工作負載，無論是運行在EC2上的本地工作負載，還是運行在我們的容器堆棧上的工作負載，都將看到顯著的性能優勢。”

　　這也可以削減其他虛擬機的成本。Duckbill Group首席云經濟學家Corey Quinn告訴New Stack，許多IaaS實例的使用率極低。“如果我看一下大規模客戶運行良好的大型機隊，在某些情況下我們正在談論數以萬計的節點或更多，那么這些方面的CPU利用率是可笑的：平均個位數百分位數。”

　　可觀測性服務提供商Honeycomb被更便宜、更具性能的實例的承諾所吸引。“我們是一家SaaS公司，尤其是基礎設施SaaS公司，因此我們的大部分運營費用是我們的AWS賬單，”首席開發律師Liz Fong Jones告訴New Stack。

　　切換到Graviton2可使公司工程師在40個實例上運行相同的入口工作負載（接收JSON對象并將它們放入Kafka），而不是X64上需要的70個實例，并且性能沒有明顯變化。他們還可以將CPU利用率提高到更高（50-60％，而不是之前設置的45％），而不會出現使用率高峰時使CPU飽和的風險。Fong-Jones推測這是因為Graviton2內核不是超線程的。“每個核心都是真正的核心，它不是共享的執行單元。”

　　為了獲得更好的性能，Honeycomb還將查詢引擎工作負載（它是IO和CPU綁定的，并且需要NVMe存儲）從Intel Xeon上的存儲優化的i3實例轉移到Graviton2 M6GD，盡管成本要高出大約10%。她說：“實際上速度是它的兩倍。”

　　該公司正在繼續將工作負載轉移到Arm。前端服務基礎架構（不占用大量CPU）現在可以在Graviton1上運行，而Fong-Jones計劃純粹出于成本原因計劃切換其Kafka工作負載。對于持續的工作量，該公司使用Compute Savings Plan，并且她希望通過Graviton2的試驗能夠降低支出水平。

　　Arm準備做什么？

　　當開發人員社區開始評估Apple的新型基于Arm的Mac時，有關在ARM64客戶端上可以使用哪些工具的問題一直存在疑問，但是ARM64服務器軟件生態系統已經準備就緒，可以在幾天或幾周內完成一些遷移，Brown建議。

　　“在很大程度上，如果人們在構建應用程序，那么這些應用程序的運行時很有可能是為ARM處理器構建的。例如，Python或Java運行時提供支持ARM的運行時，”Gartner研究總監Raj Bala告訴New Stack。“這一挑戰將涉及可能利用ARM無法提供的處理器特定功能的框架。”（商業的、現成的）應用程序可能是最大的挑戰——或者可能是Docker容器不是用ARM支撐構建的。“

　　Fong-Jones告訴我們，內部代碼肯定不太可能準備就緒。”你可以得到一個可以運行的Ubuntu圖像，這已經相當大了。同樣，不僅僅是Java和PHP是解釋語言，golang也是。如果沒有golang對ARM64的支持和交叉編譯的支持，我們不可能做到這一點。“

　　但她說，那是比較容易的部分。我們必須做一些準備工作，以驗證我們沒有任何硬依賴于x86匯編。我們確實有一些相當優化的存儲部分，有一些使用AMD64組裝，但他們有常規的Go等效物。但挑戰在于所有的底層系統架構。”

　　Honeycomb的安全入侵系統是建立在osquery上的，osquery最近才引入了ARM64支持（部分是由于Honeycomb對端口的贊助）。“如果我們部署了一堆這樣的服務器，而沒有對它們進行適當的入侵檢測，我們的安全審核員會對我們非常不滿。”

　　該公司依賴于Chef配置管理軟件。Chef 15支持ARM64，但Honeycomb使用Chef 13。“Chef 13，至少是由Chef公司提供的，不是為ARM64設計的。所以我們不得不將一些Ubuntu包向后移植，然后轉換架構。有些東西需要重新調整，因為如果您運行的是舊的LTS軟件，有些軟件并不是為Arm而構建的；您必須將其后置。”

　　Fong Jones曾研究過將MySQL轉換為Arm以提高性能，“因為各種元數據的數據庫擴展是一個瓶頸。”但同樣，AWS支持MySQL 8、MariaDB 10和最新版本的PostgreSQL；“我們使用的是MySQL 5.6，我們的語義不允許直接升級到MySQL 8。我們可以使用MariaDB 10，但AWS不允許您在零停機的情況下這樣做，因為它被認為是一個不同的數據庫引擎。”

　　一如既往，問題的關鍵在于細節，“這些隨機的、奇怪的系統級依賴關系，您必須真正、真正地確定下來。”讓代碼運行起來——這很容易！“

　　Quinn認為，這些不匹配是并非所有人都喜歡躍上Graviton的一個原因，如果還沒有為Nitro移植必要的驅動程序，那么英特爾的最新例子也是如此。”在許多環境中，它需要一個OS更新；反過來，這意味著您需要重新驗證和遷移現有的工作負載，而公司在這方面總是很慢。同樣的問題阻礙了其他技術的應用，比如自動縮放。“他們還沒有更新他們的應用架構，以便在節點加入時無需重新配置一切就能動態伸縮。”

　　Brown指出：“對于一個數據庫來說，如果舊版本不支持Arm，而且將來也不會支持Arm，那么向新版本遷移就會有點困難。”

　　“這就是我們認為客戶需要權衡投資的地方。在這個行業中，40%的性價比提升并不常見。

　　他建議：”盡可能便宜、快速地嘗試對工作負載進行基準測試。“。”然后，您可以投資進行遷移，例如遷移到不同的數據庫版本或重寫特定于處理器的內核模塊，因為40%的性價比證明了這一點。“

　　客戶準備好使用Arm了嗎？

　　對于新的實例類型，有時存在可用性問題；因為沒有足夠的M6GD實例，Fong Jones不得不暫停查詢引擎遷移12個小時，為了獲得spot實例，她不得不接受M6實例（內存更多，時鐘速度稍高），以及C6實例，這些都是工作負載所需的。

　　Quinn同意，對可用性的擔憂可能是AWS客戶對轉向Graviton持謹慎態度的一個原因，但他們應該是短暫的。”我能在任何一個AWS地區獲得規模化運行的能力嗎？這方面的現貨供應情況如何，他們能盡快拿到嗎？答案顯然是肯定的，現在他們有了足夠的容量，可以開始將其作為托管服務提供。“

　　Quinn指出，Graviton可能不是企業降低AWS費用的早期選擇，也不是最重要的方式。”這是好管家，這絕對有好處但也不是最有效的他們可以做的事情。“

　　”我們的客戶群對Graviton和Nitro的了解程度較低，“ Bala證實。當他們打電話時，通常是考慮如何相對于傳統處理器來考慮它。”他的回答是，“客戶在考慮ARM與x86時，應該考慮到端到端工作負載的兼容性以及性價比。”

　　超越AWS的Arm

　　AWS不會是Arm云服務器的唯一選擇，但迄今為止，它是最重要的。

　　Oracle云基礎設施將在2021年初以虛擬機或裸機的形式提供Arm系統（使用Ampere公司的硅，帶兩個插座和160個核心），用于基礎設施任務，如代碼轉換以及運行容器和Kubernetes。

　　自2017年以來，微軟一直在為Azure構建帶有Arm處理器的Windows服務器系統。在Azure中使用的Project Olympus OCP機箱可以容納不同的Intel或Arm主板，微軟已經測試了運行在Arm硅上的Windows服務器，包括Ampere Altra、Fujitsu和Marvell ThunderX2。

　　當時，大多數云工作負載都是基礎設施即服務，由于客戶希望虛擬化的應用程序很少可用于Arm架構，因此微軟沒有計劃公開提供Arm上的Windows服務器。

　　相反，現在在Azure中運行的ThunderX2 Arm服務器被用來降低運行內部Azure基礎設施（如存儲、索引和搜索）的成本。在今年的armdevsummit大會上，技術研究員Arun Kishan（他在Windows內核團隊工作）指出：“今天，我們在ARM64上使用Windows服務器來探索微軟內部存儲和虛擬機托管服務。”

　　Bala建議，對于開發人員來說，在Arm硅上同時使用Windows和macOS可能是將來更廣泛地采用Arm服務器的轉折點。“開發人員將希望在本地計算機上迭代開發和構建，然后再推送到最終推送到prod的CI/CD平臺。”