雲就像一個神奇的盒子－你問你需要什麼，資源就會憑空出現。 虛擬機器、資料庫、網路——這一切都只屬於你。 還有其他雲端租戶，但在您的宇宙中您是唯一的統治者。 您確信您將始終收到所需的資源，您不考慮任何人，並且您獨立確定網路是什麼樣的。 這種讓雲端能夠彈性分配資源並讓租戶之間完全隔離的魔力是如何發揮作用的呢？
AWS 雲端是一個超級複雜的系統，自 2006 年以來一直在持續演進。 這一發展的一部分發生了 瓦西里·潘秋欣 - 亞馬遜網路服務架構師。 身為架構師，他不僅可以深入了解最終結果，還可以了解 AWS 克服的挑戰。 對系統如何運作的了解越多，信任就越大。 因此，Vasily 將分享 AWS 雲端服務的秘密。 以下是實體 AWS 伺服器的設計、彈性資料庫可擴充性、自訂 Amazon 資料庫以及提高虛擬機器效能同時降低價格的方法。 了解 Amazon 的架構方法將幫助您更有效地使用 AWS 服務，並可能為您提供建立自己的解決方案的新想法。
關於講者：瓦西里·潘秋欣（Vasily Pantyukhin）（）最初在 .ru 公司擔任 Unix 管理員，在大型 Sun Microsystem 硬體上工作了 6 年，並在 EMC 宣揚以數據為中心的世界 11 年。 它自然地演變成私有雲，並於 2017 年轉移到公有雲。 現在，他提供技術建議來幫助在 AWS 雲端中生活和開發。
免責聲明：以下所有內容均為 Vasily 的個人觀點，可能與 Amazon Web Services 的立場不一致。 本文所依據的報告可在我們的 YouTube 頻道上找到。
我為什麼要談論亞馬遜設備？
我的第一輛車有手排變速箱。 感覺很棒，因為我可以駕駛汽車並完全控制它。 我還喜歡我至少大致了解了它的操作原理。 當然，我想像盒子的結構非常原始——就像自行車上的變速箱一樣。
一切都很好，除了一件事——塞車。 看起來你坐著什麼都不做，但你不斷地換檔、踩離合器、油門、煞車——這真的讓你很累。 當家裡有了自動擋汽車後，交通擁堵問題就得到了部分解決。 開車時，我有時間思考一些事情並聽有聲書。
我的生活中出現了另一個謎團，因為我完全不了解我的車是如何運作的。 現代汽車是一種複雜的設備。 該車同時適應數十種不同的參數：踩油門、煞車、駕駛風格、道路品質。 我不明白它是如何運作的了。
當我開始在亞馬遜雲端工作時，這對我來說也是一個謎。 只是這個謎團更大了一個數量級，因為車上只有一個司機，而在 AWS 中有數百萬個司機。 所有使用者同時轉向、踩油門和煞車。 令人驚訝的是他們可以去他們想去的地方 - 這對我來說是一個奇蹟！ 這個系統會自動適應、擴展和彈性調整每個用戶，讓他覺得自己在這個宇宙中是孤獨的。
當我後來在亞馬遜擔任架構師時，這種魔力逐漸減弱。 我看到了我們面臨的問題、我們如何解決這些問題以及我們如何開發服務。 隨著對系統運作原理的了解不斷加深，人們對服務的信心也隨之增強。 所以我想分享一下 AWS 雲端的幕後故事。
我們該談什麼
我選擇了多元化的方式——我選擇了4個值得談論的有趣服務。
伺服器最佳化。 具有實體體現的短暫雲端：實體資料中心，其中的實體伺服器會嗡嗡作響、發熱並閃爍燈光。
無伺服器功能 (Lambda) 可能是雲端中最具可擴展性的服務。
資料庫擴充。 我將告訴您我們如何建立自己的可擴展資料庫。
網路擴充。 最後一部分我將開啟我們網路的設備。 這是一件美妙的事——每個雲端用戶都相信自己在雲端是孤獨的，根本看不到其他租戶。
筆記。 本文將討論伺服器優化和資料庫擴充。 我們將在下一篇文章中考慮網路擴展。 無伺服器功能在哪裡？ 關於他們的單獨記錄被發表“」 它討論了幾種不同的擴充方法，並詳細討論了 Firecracker 解決方案 - 虛擬機器和容器最佳品質的共生。
服務器
雲是短暫的。 但這種短暫性仍然有一個物理體現——伺服器。 最初，他們的建築是古典的。 標準 x86 晶片組、網路卡、Linux、運行虛擬機器的 Xen 虛擬機器管理程式。
2012年，這個架構很好地應對了它的任務。 Xen 是一款出色的虛擬機器管理程序，但它有一個主要缺點。 他已經受夠了 設備模擬的高開銷。 隨著新的、更快的網路卡或 SSD 驅動器的出現，這種開銷變得過高。 如何處理這個問題呢？ 我們決定同時在兩個方面開展工作 - 優化硬體和管理程序。 任務十分艱鉅。
優化硬體和管理程序
一次性把所有事情都做完並把它做好是不行的。 最初也不清楚什麼是「好」。
我們決定採取漸進的方法 - 我們改變架構的一個重要元素並將其投入生產。
我們踩著每一把耙子，傾聽投訴和建議。 然後我們改變另一個組件。 因此，我們會根據使用者和支援的回饋，以小幅增量從根本上改變整個架構。
這場轉型始於 2013 年最複雜的事物—網路。 在 S3 例如，在標準網路卡上新增了特殊的網路加速卡。 它實際上是透過前面板上的短環回電纜連接的。 它不漂亮，但在雲中不可見。 但與硬體的直接互動從根本上改善了抖動和網路吞吐量。
接下來我們決定改進對區塊資料儲存 EBS（彈性區塊儲存）的存取。 它是網路和儲存的結合。 困難在於，雖然市場上有網路加速卡，但無法選擇簡單地購買儲存加速器硬體。 所以我們轉向一家新創公司 安納普爾納實驗室，他為我們開發了特殊的 ASIC 晶片。 它們允許將遠端 EBS 磁碟區安裝為 NVMe 設備。
在實例中 C4 我們解決了兩個問題。 首先，我們為未來有前景但當時是新技術的 NVMe 技術奠定了基礎。 其次，我們透過將 EBS 請求的處理轉移到新卡上，顯著減輕了中央處理器的負擔。 結果很好，所以現在安納布爾納實驗室成為亞馬遜的一部分。
到 2017 年 XNUMX 月，我們意識到是時候改變虛擬機器管理程式本身了。
新的虛擬機器管理程式是基於修改後的 KVM 核心模組開發的。
它可以從根本上減少設備模擬的開銷並直接與新的 ASIC 配合使用。 實例 S5 是第一批在背景執行新虛擬機器管理程式的虛擬機器。 我們給他取了個名字 硝基.
時間軸上實例的演變。
自 2017 年 XNUMX 月以來出現的所有新型虛擬機器都在該虛擬機器管理程式上執行。 裸機實例沒有虛擬機器管理程序，但它們也被稱為 Nitro，因為它們使用專門的 Nitro 卡。
在接下來的兩年裡，Nitro 實例的類型數量超過了數十種：A1、C5、M5、T3 等。
實例類型。
現代硝基機器的工作原理
它們具有三個主要組件：Nitro 管理程式（如上所述）、安全晶片和 Nitro 卡。
安全晶片 直接整合到主機板中。 它控制許多重要的功能，例如控制主機作業系統的載入。
硝基卡 - 它們有四種類型。 它們均由 Annapurna Labs 開發，基於通用 ASIC。 他們的一些韌體也是通用的。
四種類型的硝基卡。
其中一張卡的設計目的是與 網路專有網絡。 這就是虛擬機器中可見的網路卡 ENA - 彈性網路介面卡。 它還在透過實體網路傳輸流量時封裝流量（我們將在本文的第二部分討論這一點），控制安全群組防火牆，並負責路由和其他網路事務。
選擇與區塊儲存配合使用的卡 EBS 以及伺服器內建的磁碟。 它們在來賓虛擬機器中顯示為 NVMe 適配器。 他們還負責資料加密和磁碟監控。
Nitro 卡、管理程式和安全晶片的系統整合到 SDN 網路或 軟件定義網絡。 負責管理此網路（控制平面） 控制卡.
當然，我們會繼續開發新的 ASIC。 例如，他們在 2018 年底發布了 Inferentia 晶片，它可以讓您更有效地處理機器學習任務。
Inferentia 機器學習處理器晶片。
可擴展的資料庫
傳統的資料庫具有分層結構。 為了大大簡化，區分了以下層級。
- 的SQL — 客戶端和請求調度員正在處理它。
- 規定 交易 - 這裡一切都很清楚，ACID 等等。
- 緩存，由緩衝池提供。
- 記錄 — 提供重做日誌的工作。 在 MySQL 中，它們稱為 Bin Logs，在 PosgreSQL 中稱為 Write Ahead Logs (WAL)。
- 存儲 – 直接錄製到磁碟。
分層資料庫結構。
擴充資料庫有多種方法：分片、無共享架構、共享磁碟。
然而，所有這些方法都維護相同的整體資料庫結構。 這極大地限制了擴展。 為了解決這個問題，我們開發了自己的資料庫 - 亞馬遜極光。 它與 MySQL 和 PostgreSQL 相容。
亞馬遜極光
主要架構思想是將儲存和日誌層級與主資料庫分開。
展望未來，我會說我們也讓快取等級變得獨立。 這個架構不再是一個整體，我們在擴展各個區塊方面獲得了額外的自由度。
日誌記錄和儲存等級與資料庫是分開的。
傳統的DBMS以區塊的形式將資料寫入儲存系統。 在 Amazon Aurora，我們創建了會說話的智慧存儲 重做日誌。 在內部，儲存將日誌轉換為資料區塊，監控其完整性並自動備份。
這種方法允許您實現一些有趣的事情，例如 複製。 由於它不需要創建所有資料的完整副本，因此從根本上來說它的工作速度更快、更經濟。
儲存層實作為分散式系統。 它由大量的實體伺服器組成。 每個重做日誌同時處理和保存 六節。 這確保了資料保護和負載平衡。
可以使用適當的副本來實現讀取擴充。 分散式儲存消除了我們寫入資料的主資料庫執行個體與其餘副本之間的同步需求。 保證所有副本都可以使用最新資料。
唯一的問題是在只讀副本上快取舊資料。 但這個問題正在解決 傳輸所有重做日誌 透過內部網路複製。 如果日誌在快取中，則會被標記為不正確並被覆蓋。 如果它不在快取中，則將其簡單地丟棄。
我們已經整理好了儲存空間。
如何擴充 DBMS 層
在這裡，水平縮放要困難得多。 那麼讓我們沿著老路走吧 經典的垂直縮放.
假設我們有一個透過主節點與 DBMS 通訊的應用程式。
當垂直擴展時，我們分配一個具有更多處理器和記憶體的新節點。
接下來，我們將應用程式從舊的主節點切換到新的主節點。 問題就出現了。
- 這將需要大量的應用程式停機時間。
- 新的主節點將具有冷緩存。 只有在快取預熱後，資料庫效能才會達到最大。
如何改善這種狀況？ 在應用程式和主節點之間設定代理。
這會帶給我們什麼？ 現在所有應用程式都不需要手動重定向到新節點。 切換可以在代理下完成，並且速度更快。
看來問題已經解決了。 但不，我們仍然需要預熱快取。 此外，還出現了一個新問題——現在代理程式是一個潛在的故障點。
使用 Amazon Aurora 無伺服器的最終解決方案
我們是如何解決這些問題的？
留下代理。 這不是一個單獨的實例，而是一個完整的分散式代理程式佇列，應用程式透過它們連接到資料庫。 如果發生故障，任何節點幾乎可以立即更換。
增加了各種大小的暖節點池。 因此，如果需要分配一個更大或更小的新節點，它立即可用。 無需等待它加載。
整個縮放過程由特殊的監控系統控制。 監控不斷監控目前主節點的狀態。 例如，如果它偵測到處理器負載已達到臨界值，它會通知熱實例池需要指派新節點。
分散式代理、熱實例和監控。
具有所需功率的節點可用。 緩衝池被複製到其中，系統開始等待安全時刻切換。
通常，切換的時刻來得很快。 然後代理與舊主節點之間的通訊暫停，所有會話都切換到新節點。
繼續使用資料庫。
從圖中可以看出，暫停時間確實很短。 藍色圖顯示負載，紅色步驟顯示縮放力矩。 藍色圖表中的短期下降正是這種短暫的延遲。
順便說一句，Amazon Aurora 可以讓您完全省錢，並在不使用時（例如週末）關閉資料庫。 停止負載後，DB逐漸降低功率並關閉一段時間。 當負載恢復時，又會平穩上升。
在有關亞馬遜設備的故事的下一部分中，我們將討論網路擴展。 訂閱 請繼續關注，這樣您就不會錯過這篇文章。
上 瓦西里·潘秋欣將作報告“」 亞馬遜開發者使用什麼分散式系統的設計模式，服務失敗的原因是什麼，什麼是基於Cell的架構，Constant Work，Shuffle Sharding——這會很有趣。 距離大會召開還有不到一個月的時間—— 。 24月XNUMX日最終漲價。
來源： www.habr.com