當(dāng)Amazon Web Services在2018年發(fā)布其AWS Graviton Arm處理器時，它的目標(biāo)是松散耦合的橫向擴(kuò)展工作負(fù)載，比如Web服務(wù)器、日志處理和緩存，這些實(shí)例吸引了SmugMug這樣的客戶，他們覺得自己在高級計(jì)算上付出的代價太高了，而一個較小的內(nèi)核就可以完成這項(xiàng)工作?；贏rm的計(jì)算實(shí)例可以替代絕大多數(shù)云巨頭客戶使用的基于x86的服務(wù)。

　　亞馬遜EC2的副總裁、David Brown,在接受New Stack采訪時表示，從很多方面來說，這都是為了啟動生態(tài)系統(tǒng)?！拔覀兿胂蛏鷳B(tài)系統(tǒng)發(fā)出信號，Arm服務(wù)器芯片將成為現(xiàn)實(shí)，我們將把它們推出市場?！?/p>

　　準(zhǔn)備好生態(tài)系統(tǒng)意味著，Graviton2不僅可以快速支持EC2實(shí)例，還可以支持越來越多的AWS服務(wù)，包括Amazon RDS、Amazon ElastiCache（其中Graviton2實(shí)際上是默認(rèn)的）和像Amazon EKS這樣的容器服務(wù)。

　　只有在客戶選擇處理器架構(gòu)的時候，Graviton才會顯現(xiàn)出來；在“絕大多數(shù)服務(wù)”中，客戶將永遠(yuǎn)不會看到該服務(wù)是在Arm上運(yùn)行的，但他暗示很多客戶將會看到。

　　Brown指出，將AWS服務(wù)遷移到Arm還有助于使生態(tài)系統(tǒng)為客戶的工作負(fù)載做好準(zhǔn)備?！斑@為我們提供了很多內(nèi)部經(jīng)驗(yàn)，涉及客戶將會經(jīng)歷的事情，以及確保我們在生態(tài)系統(tǒng)中能夠接觸到各個參與者，并通過我們可以構(gòu)建的工具和可以幫助您的事情來解決問題?！?/p>

　　Graviton2甚至可以作為一個擁有64個vcpu、128GiB內(nèi)存和4TB本地NVMe存儲來運(yùn)行Amazon EC2和EKS的1U服務(wù)器（盡管AWS建議將其用于受限制的位置，如蜂窩基站而不是主流數(shù)據(jù)中心）?！拔覀儚目蛻裟抢锫犝f，他們很希望在前哨站安裝Graviton2，就支持生態(tài)系統(tǒng)而言，并確保我們能在客戶需要的時候提供他們想要的硬件，ARM處理器并不意味著不能在前哨站安裝?！?/p>

　　AWS還將添加更多基于AWS Graviton2的實(shí)例-最新的是計(jì)算和網(wǎng)絡(luò)密集型C6gn，以及為大型內(nèi)存數(shù)據(jù)集或計(jì)算密集型工作負(fù)載而設(shè)計(jì)的實(shí)例，帶有或不帶有本地NVMe存儲。

　　從卸載到整合

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

　　一定比例的處理器（不管它是什么）被虛擬化堆棧和需要在機(jī)器上運(yùn)行的大量其他管理軟件所使用。我們注意到的是，除了降低效率之外（因?yàn)槟褂昧吮究梢蕴峁┙o客戶的10 - 20%的核心用于您自己的工作和管理程序），我們還無法獲得我們認(rèn)為客戶需要的那種性能。

　　AWS使用Nitro將越來越多的開銷轉(zhuǎn)移到單獨(dú)的處理器上，以提高性能并使其更加一致?！拔覀冏龅牡谝患戮褪且瞥W(wǎng)絡(luò)并將其卸載到Arm處理器上。我們卸下了所有的管理控制職能，最終在2017年，我們的CPU使用率達(dá)到了零?！?/p>

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

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

　　CPU綁定應(yīng)用程序的核心

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

　　”Arm核心消耗的能量只有可選核心的一半?？蛻艨吹搅?0%的原始性能改進(jìn)；如果你在同一個基準(zhǔn)測試中運(yùn)行，在Graviton2和最新的英特爾處理器上，Graviton2大約快20%，“Brown說。它還便宜20%左右。因此，你可以得到40%的價格性能改進(jìn)，Brown說。

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

　　Brown說，客戶通常在移動更多堆棧之前就開始在他們的應(yīng)用程序?qū)邮褂肎raviton。“它不需要大量的計(jì)算密集型；它只是一些CPU受限的最通用的工作負(fù)載，如果可用的話，它們會使用更多的CPU。很多云本地工作負(fù)載，無論是運(yùn)行在EC2上的本地工作負(fù)載，還是運(yùn)行在我們的容器堆棧上的工作負(fù)載，都將看到顯著的性能優(yōu)勢?！?/p>

　　這也可以削減其他虛擬機(jī)的成本。Duckbill Group首席云經(jīng)濟(jì)學(xué)家Corey Quinn告訴New Stack，許多IaaS實(shí)例的使用率極低?！叭绻铱匆幌麓笠?guī)模客戶運(yùn)行良好的大型機(jī)隊(duì)，在某些情況下我們正在談?wù)摂?shù)以萬計(jì)的節(jié)點(diǎn)或更多，那么這些方面的CPU利用率是可笑的：平均個位數(shù)百分位數(shù)?！?/p>

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

　　切換到Graviton2可使公司工程師在40個實(shí)例上運(yùn)行相同的入口工作負(fù)載（接收J(rèn)SON對象并將它們放入Kafka），而不是X64上需要的70個實(shí)例，并且性能沒有明顯變化。他們還可以將CPU利用率提高到更高（50-60％，而不是之前設(shè)置的45％），而不會出現(xiàn)使用率高峰時使CPU飽和的風(fēng)險。Fong-Jones推測這是因?yàn)镚raviton2內(nèi)核不是超線程的?！懊總€核心都是真正的核心，它不是共享的執(zhí)行單元?！?/p>

　　為了獲得更好的性能，Honeycomb還將查詢引擎工作負(fù)載（它是IO和CPU綁定的，并且需要NVMe存儲）從Intel Xeon上的存儲優(yōu)化的i3實(shí)例轉(zhuǎn)移到Graviton2 M6GD，盡管成本要高出大約10%。她說：“實(shí)際上速度是它的兩倍?！?/p>

　　該公司正在繼續(xù)將工作負(fù)載轉(zhuǎn)移到Arm。前端服務(wù)基礎(chǔ)架構(gòu)（不占用大量CPU）現(xiàn)在可以在Graviton1上運(yùn)行，而Fong-Jones計(jì)劃純粹出于成本原因計(jì)劃切換其Kafka工作負(fù)載。對于持續(xù)的工作量，該公司使用Compute Savings Plan，并且她希望通過Graviton2的試驗(yàn)?zāi)軌蚪档椭С鏊健?/p>

　　Arm準(zhǔn)備做什么？

　　當(dāng)開發(fā)人員社區(qū)開始評估Apple的新型基于Arm的Mac時，有關(guān)在ARM64客戶端上可以使用哪些工具的問題一直存在疑問，但是ARM64服務(wù)器軟件生態(tài)系統(tǒng)已經(jīng)準(zhǔn)備就緒，可以在幾天或幾周內(nèi)完成一些遷移，Brown建議。

　　“在很大程度上，如果人們在構(gòu)建應(yīng)用程序，那么這些應(yīng)用程序的運(yùn)行時很有可能是為ARM處理器構(gòu)建的。例如，Python或Java運(yùn)行時提供支持ARM的運(yùn)行時，”Gartner研究總監(jiān)Raj Bala告訴New Stack?！斑@一挑戰(zhàn)將涉及可能利用ARM無法提供的處理器特定功能的框架?！保ㄉ虡I(yè)的、現(xiàn)成的）應(yīng)用程序可能是最大的挑戰(zhàn)——或者可能是Docker容器不是用ARM支撐構(gòu)建的。“

　　Fong-Jones告訴我們，內(nèi)部代碼肯定不太可能準(zhǔn)備就緒?！蹦憧梢缘玫揭粋€可以運(yùn)行的Ubuntu圖像，這已經(jīng)相當(dāng)大了。同樣，不僅僅是Java和PHP是解釋語言，golang也是。如果沒有g(shù)olang對ARM64的支持和交叉編譯的支持，我們不可能做到這一點(diǎn)?！?/p>

　　但她說，那是比較容易的部分。我們必須做一些準(zhǔn)備工作，以驗(yàn)證我們沒有任何硬依賴于x86匯編。我們確實(shí)有一些相當(dāng)優(yōu)化的存儲部分，有一些使用AMD64組裝，但他們有常規(guī)的Go等效物。但挑戰(zhàn)在于所有的底層系統(tǒng)架構(gòu)?！?/p>

　　Honeycomb的安全入侵系統(tǒng)是建立在osquery上的，osquery最近才引入了ARM64支持（部分是由于Honeycomb對端口的贊助）?！叭绻覀儾渴鹆艘欢堰@樣的服務(wù)器，而沒有對它們進(jìn)行適當(dāng)?shù)娜肭謾z測，我們的安全審核員會對我們非常不滿?！?/p>

　　該公司依賴于Chef配置管理軟件。Chef 15支持ARM64，但Honeycomb使用Chef 13。“Chef 13，至少是由Chef公司提供的，不是為ARM64設(shè)計(jì)的。所以我們不得不將一些Ubuntu包向后移植，然后轉(zhuǎn)換架構(gòu)。有些東西需要重新調(diào)整，因?yàn)槿绻\(yùn)行的是舊的LTS軟件，有些軟件并不是為Arm而構(gòu)建的；您必須將其后置?！?/p>

　　Fong Jones曾研究過將MySQL轉(zhuǎn)換為Arm以提高性能，“因?yàn)楦鞣N元數(shù)據(jù)的數(shù)據(jù)庫擴(kuò)展是一個瓶頸?！钡瑯?，AWS支持MySQL 8、MariaDB 10和最新版本的PostgreSQL；“我們使用的是MySQL 5.6，我們的語義不允許直接升級到MySQL 8。我們可以使用MariaDB 10，但AWS不允許您在零停機(jī)的情況下這樣做，因?yàn)樗徽J(rèn)為是一個不同的數(shù)據(jù)庫引擎。”

　　一如既往，問題的關(guān)鍵在于細(xì)節(jié)，“這些隨機(jī)的、奇怪的系統(tǒng)級依賴關(guān)系，您必須真正、真正地確定下來?！弊尨a運(yùn)行起來——這很容易！“

　　Quinn認(rèn)為，這些不匹配是并非所有人都喜歡躍上Graviton的一個原因，如果還沒有為Nitro移植必要的驅(qū)動程序，那么英特爾的最新例子也是如此?！痹谠S多環(huán)境中，它需要一個OS更新；反過來，這意味著您需要重新驗(yàn)證和遷移現(xiàn)有的工作負(fù)載，而公司在這方面總是很慢。同樣的問題阻礙了其他技術(shù)的應(yīng)用，比如自動縮放。“他們還沒有更新他們的應(yīng)用架構(gòu)，以便在節(jié)點(diǎn)加入時無需重新配置一切就能動態(tài)伸縮?！?/p>

　　Brown指出：“對于一個數(shù)據(jù)庫來說，如果舊版本不支持Arm，而且將來也不會支持Arm，那么向新版本遷移就會有點(diǎn)困難?！?/p>

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

　　他建議：”盡可能便宜、快速地嘗試對工作負(fù)載進(jìn)行基準(zhǔn)測試?！?。”然后，您可以投資進(jìn)行遷移，例如遷移到不同的數(shù)據(jù)庫版本或重寫特定于處理器的內(nèi)核模塊，因?yàn)?0%的性價比證明了這一點(diǎn)。“

　　客戶準(zhǔn)備好使用Arm了嗎？

　　對于新的實(shí)例類型，有時存在可用性問題；因?yàn)闆]有足夠的M6GD實(shí)例，F(xiàn)ong Jones不得不暫停查詢引擎遷移12個小時，為了獲得spot實(shí)例，她不得不接受M6實(shí)例（內(nèi)存更多，時鐘速度稍高），以及C6實(shí)例，這些都是工作負(fù)載所需的。

　　Quinn同意，對可用性的擔(dān)憂可能是AWS客戶對轉(zhuǎn)向Graviton持謹(jǐn)慎態(tài)度的一個原因，但他們應(yīng)該是短暫的。”我能在任何一個AWS地區(qū)獲得規(guī)?；\(yùn)行的能力嗎？這方面的現(xiàn)貨供應(yīng)情況如何，他們能盡快拿到嗎？答案顯然是肯定的，現(xiàn)在他們有了足夠的容量，可以開始將其作為托管服務(wù)提供?！?/p>

　　Quinn指出，Graviton可能不是企業(yè)降低AWS費(fèi)用的早期選擇，也不是最重要的方式?！边@是好管家，這絕對有好處但也不是最有效的他們可以做的事情?！?/p>

　　”我們的客戶群對Graviton和Nitro的了解程度較低，“ Bala證實(shí)。當(dāng)他們打電話時，通常是考慮如何相對于傳統(tǒng)處理器來考慮它?！彼幕卮鹗牵翱蛻粼诳紤]ARM與x86時，應(yīng)該考慮到端到端工作負(fù)載的兼容性以及性價比?！?/p>

　　超越AWS的Arm

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

　　Oracle云基礎(chǔ)設(shè)施將在2021年初以虛擬機(jī)或裸機(jī)的形式提供Arm系統(tǒng)（使用Ampere公司的硅，帶兩個插座和160個核心），用于基礎(chǔ)設(shè)施任務(wù)，如代碼轉(zhuǎn)換以及運(yùn)行容器和Kubernetes。

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

　　當(dāng)時，大多數(shù)云工作負(fù)載都是基礎(chǔ)設(shè)施即服務(wù)，由于客戶希望虛擬化的應(yīng)用程序很少可用于Arm架構(gòu)，因此微軟沒有計(jì)劃公開提供Arm上的Windows服務(wù)器。

　　相反，現(xiàn)在在Azure中運(yùn)行的ThunderX2 Arm服務(wù)器被用來降低運(yùn)行內(nèi)部Azure基礎(chǔ)設(shè)施（如存儲、索引和搜索）的成本。在今年的armdevsummit大會上，技術(shù)研究員Arun Kishan（他在Windows內(nèi)核團(tuán)隊(duì)工作）指出：“今天，我們在ARM64上使用Windows服務(wù)器來探索微軟內(nèi)部存儲和虛擬機(jī)托管服務(wù)?！?/p>

　　Bala建議，對于開發(fā)人員來說，在Arm硅上同時使用Windows和macOS可能是將來更廣泛地采用Arm服務(wù)器的轉(zhuǎn)折點(diǎn)?！伴_發(fā)人員將希望在本地計(jì)算機(jī)上迭代開發(fā)和構(gòu)建，然后再推送到最終推送到prod的CI/CD平臺。”