案例研究：為什麼我將 AWS 雲基礎設施用於我的產品
已發表: 2022-03-11作為運行複雜且要求苛刻的軟件產品的平台，AWS 通過在需要時以所需規模利用資源來提供靈活性。 它是按需和即時的，允許完全控制運行環境。 在向客戶提出這樣的雲架構解決方案時，配置的基礎設施及其價格在很大程度上取決於需要預先設置的要求。
本文將介紹一個這樣的 AWS 雲基礎架構架構，它是為 LEVELS 提出和實施的，LEVELS 是一個具有集成面部支付功能的社交網絡，可以發現並應用用戶可能從他們所在的卡程序、他們擁有的東西或地方獲得的所有好處他們住在。
要求
客戶提出的解決方案必須滿足兩個主要要求：
- 安全
- 可擴展性
安全要求是關於保護用戶的數據免受來自外部和內部的未經授權的訪問。 可擴展性要求是關於基礎設施支持產品增長的能力，自動適應不斷增加的流量和偶爾的峰值，以及在服務器發生故障時自動故障轉移和恢復，最大限度地減少潛在的停機時間。
AWS 安全概念概述
設置您自己的 AWS 雲基礎設施的主要好處之一是完全的網絡隔離和對您的雲的完全控制。 這就是您選擇基礎架構即服務 (IaaS) 路線的主要原因，而不是運行更簡單的平台即服務 (PaaS) 環境，後者提供可靠的安全默認設置，但缺乏完整、細粒度的控制。使用 AWS 設置您自己的雲。
儘管 LEVELS 在向 Toptal 尋求 AWS 諮詢服務時還是一個年輕的產品，但他們願意承諾使用 AWS，並且知道他們希望通過其基礎設施獲得最先進的安全性，因為他們非常關心用戶數據和隱私。 最重要的是，他們計劃在未來支持信用卡處理，因此他們知道他們需要在某個時候確保 PCI-DSS 合規性。
虛擬私有云 (VPC)
AWS 上的安全性始於創建您自己的Amazon Virtual Private Cloud (VPC) - 一個託管您的 AWS 資源並在邏輯上與 AWS 雲中的其他虛擬網絡隔離的專用虛擬網絡。 VPC 擁有自己的 IP 地址範圍、完全可配置的子網、路由表、網絡訪問控制列表和安全組（實際上是防火牆）。
使用 LEVELS，我們首先將生產環境與開發、測試和 QA 環境隔離開來。 第一個想法是將它們中的每一個都作為自己完全隔離的 VPC 運行，每個都運行應用程序所需的所有服務。 經過一番考慮，事實證明我們可以允許在三個非生產環境之間共享一些資源，這在一定程度上降低了成本。
因此，我們將生產環境作為一個 VPC，將開發、測試和 QA 環境作為另一個 VPC。
VPC 級別的訪問隔離
兩個 VPC 設置在網絡級別將生產環境與其餘三個環境隔離，確保意外的應用程序錯誤配置無法跨越該邊界。 即使非生產環境配置錯誤地指向生產環境資源，如數據庫或消息隊列，也無法訪問它們。
由於開發、測試和 QA 環境共享同一個 VPC，在配置錯誤的情況下可以進行跨界訪問，但是，由於這些環境使用測試數據，因此不存在真正的安全問題，因為那裡缺乏隔離。
Assets Store 安全模型
資產存儲在Amazon Simple Storage Service (S3)對象存儲中。 S3 存儲基礎設施完全獨立於 VPC，其安全模型也不同。 針對每個環境和/或資產類別，存儲被組織在單獨的 S3 存儲桶中，以適當的訪問權限保護每個存儲桶。
使用 LEVELS，確定了幾類資產：用戶上傳、LEVELS 製作的內容（宣傳視頻和類似內容）、Web 應用程序和 UI 資產（JS 代碼、圖標、字體）、應用程序和基礎架構配置以及服務器端部署包。
其中每一個都有一個單獨的 S3 存儲桶。
應用程序秘密管理
借助 AWS，有一個加密的AWS Systems Manager Parameter Store或AWS Secrets Manager ，它們是旨在保護機密安全的託管鍵值服務（您可以在 Linux Academy 和 1Strategy 了解更多信息）。
AWS 管理底層加密密鑰並處理加密/解密。 Secret 本身可以根據密鑰前綴為基礎設施和用戶（分別為服務器和開發人員）應用讀取和寫入權限策略。
服務器 SSH 訪問
完全不需要在完全自動化且不可變的環境中對服務器進行 SSH 訪問。 可以提取日誌並將其發送到專用的日誌記錄服務，監控也可以卸載到專用的監控服務。 儘管如此，可能仍需要偶爾進行 SSH 訪問以進行配置檢查和調試。
為了限制服務器的攻擊面，SSH 端口不會暴露給公共網絡。 通過堡壘主機訪問服務器，這是一台允許外部 SSH 訪問的專用機器，另外還通過在防火牆處僅將允許的 IP 地址範圍列入白名單來保護。 通過將用戶的公共 SSH 密鑰部署到相應的框（禁用密碼登錄）來控制訪問。 這樣的設置為惡意攻擊者提供了一個相當有彈性的門。
數據庫訪問
上面概述的相同原則適用於數據庫服務器。 有時可能還需要直接連接和操作數據庫中的數據，儘管這絕對不是推薦的做法，並且這種訪問需要以與服務器 SSH 訪問受到保護的方式相同的方式進行保護。
可以使用類似的方法，將相同的堡壘主機基礎設施與 SSH 隧道結合使用。 需要一個雙 SSH 隧道，一個到堡壘主機，通過那個，另一個到可以訪問數據庫的服務器（堡壘主機沒有數據庫服務器訪問權限）。 通過第二條隧道，從用戶的客戶端機器到數據庫服務器的連接現在可用。
AWS 可擴展性概念概述
當我們純粹談論服務器時，使用比 AWS 更簡單的平台很容易實現可擴展性。 主要缺點是平台的外部服務可能需要滿足某些要求，這意味著數據在公共網絡中傳輸並打破了安全邊界。 堅持使用 AWS，所有數據都保持私有，同時需要設計可擴展性以實現可擴展、有彈性和容錯的基礎設施。
借助 AWS，實現可擴展性的最佳方法是利用託管 AWS 服務，並在使用該平台的數千個客戶中進行監控和自動化測試。 將數據備份和恢復機制添加到組合中，僅依靠平臺本身就可以解決很多問題。
卸載所有這些可以讓運營團隊更小，在一定程度上抵消了平台託管服務的更高成本。 LEVELS 團隊很樂意盡可能選擇這條路。
亞馬遜彈性計算雲 (EC2)
與運行容器的額外開銷和復雜性或仍然非常年輕且快速變化的無服務器計算架構概念相比，依賴運行EC2 實例的經過驗證的環境仍然是一種相當合理的方法。
EC2 實例供應需要完全自動化。 自動化是通過針對不同類別的服務器的自定義 AMI 實現的，Auto Scaling 組通過根據當前流量在隊列中保留適當數量的正在運行的服務器實例來負責運行動態服務器隊列。
此外，自動擴展功能允許設置要運行的 EC2 實例數量的下限和上限。 下限有助於容錯，可能在實例失敗的情況下消除停機時間。 上限可以控製成本，在意外的極端條件下允許一些停機風險。 然後，自動縮放會在這些限制內動態縮放實例數量。
亞馬遜關係數據庫服務 (RDS)
該團隊已經在Amazon RDS for MySQL上運行，但尚未開發出適當的備份、容錯和安全策略。 在第一次迭代中，將數據庫實例升級為每個 VPC 中的雙實例集群，配置為 master 和 read-replica，支持自動故障轉移。
在下一次迭代中，隨著 MySQL 5.7 版引擎的推出，基礎設施升級到了Amazon Aurora MySQL服務。 儘管完全託管，但 Aurora 並不是一個自動擴展的解決方案。 它提供自動存儲擴展，避免容量規劃問題。 但是解決方案架構師仍然需要選擇計算實例的大小。
由於縮放導致的停機時間無法避免，但可以藉助自動修復功能將其減少到最低限度。 由於更好的複制功能，Aurora 提供了無縫的故障轉移功能。 通過創建具有所需計算能力的只讀副本，然後執行到該實例的故障轉移來執行擴展。 然後，所有其他只讀副本也會從集群中取出、調整大小並帶回集群。 它需要一些手動雜耍，但不僅僅是可行的。
新的 Aurora Serverless 產品還支持某種程度的計算資源自動擴展，這是未來絕對值得研究的功能。
託管 AWS 服務
除了這兩個組件之外，系統的其餘部分還受益於完全託管的 AWS 服務的自動擴展機制。 它們是 Elastic Load Balancing (ELB)、Amazon Simple Queue Service (SQS)、Amazon S3 對象存儲、AWS Lambda 函數和 Amazon Simple Notification Service (SNS)，架構師不需要進行特別的擴展工作。
可變與不可變基礎設施
我們認識到處理服務器基礎架構的兩種方法 - 一種可變的基礎架構，其中安裝了服務器並不斷更新和修改就地； 以及不可變的基礎架構，其中服務器在配置後永遠不會修改，並且任何配置修改或服務器更新都通過從通用映像或安裝腳本配置新服務器來處理，替換舊服務器。
使用 LEVELS，選擇是運行不可變的基礎架構，無需就地升級、配置更改或管理操作。 唯一的例外是應用程序部署，它確實發生在原地。
可以在 HashiCorp 的博客中找到有關可變與不可變基礎架構的更多信息。
架構概述
從技術上講，LEVELS 是一個移動應用程序和一個具有 REST API 後端和一些後台服務的 Web 應用程序 - 現在是一個相當典型的應用程序。 對此，提出並配置了以下基礎設施：
虛擬網絡隔離 - Amazon VPC
該圖可視化了其 VPC 中一個環境的結構。 其他環境遵循相同的結構（在其 VPC 中的非生產環境之間共享 Application Load Balancer (ALB) 和 Amazon Aurora 集群，但網絡設置完全相同）。
VPC 跨 AWS 區域內的四個可用區進行配置，以實現容錯。 具有網絡訪問控制列表的子網和安全組可以滿足安全和訪問控制要求。
在業務及其產品的早期階段，跨多個 AWS 區域擴展基礎設施以獲得額外的容錯能力過於復雜和不必要，但在未來是一種選擇。
計算
LEVELS 運行一個傳統的 REST API，其中包含一些後台工作程序，用於在後台發生的應用程序邏輯。 這兩者都作為普通 EC2 實例的動態隊列運行，通過 Auto Scaling 組完全自動化。 Amazon SQS託管服務用於後台任務（作業）分發，無需運行、維護和擴展您自己的 MQ 服務器。
還有一些實用程序任務沒有與應用程序的其餘部分共享業務邏輯，例如圖像處理。 此類任務在AWS Lambda上運行得非常好，因為 Lambda 具有無限的水平可擴展性，並且與服務器工作者相比提供了無與倫比的並行處理。
負載平衡、自動擴展和容錯
負載平衡可以通過 Nginx 或 HAProxy 手動實現，但選擇Amazon Elastic Load Balancing (ELB)可以增加負載平衡基礎設施本質上自動可擴展、高可用性和容錯的優勢。
使用 ELB 的 Application Load Balancer (ALB) 風格，利用負載均衡器上可用的 HTTP 層路由。 添加到隊列的新實例通過 AWS 平台的機制自動註冊到 ALB。 ALB 還始終監控實例的可用性。 它具有註銷和終止不健康實例的能力，觸發 Auto Scaling 以用新實例替換它們。 通過兩者之間的相互作用，實現了 EC2 隊列自動修復。
應用程序數據存儲
應用程序數據存儲是一個Amazon Aurora MySQL 集群，由一個主實例和多個只讀副本實例組成。 在主實例失敗的情況下，其中一個只讀副本會自動提升為新的主實例。 這樣配置，它滿足請求的容錯要求。
只讀副本，顧名思義，也可用於為數據讀取操作分配數據庫集群負載。
使用 Aurora 以 10GB 的增量自動擴展數據庫存儲，備份也完全由 AWS 管理，默認情況下提供時間點恢復。 除了在需要時擴展數據庫計算能力之外，所有這一切都將數據庫管理負擔減少到幾乎沒有——這項服務非常值得付費以無憂運行。
存儲和服務資產
LEVELS 接受用戶上傳的需要存儲的內容。 可以預見的是， Amazon S3對象存儲是負責該任務的服務。 還有一些應用程序資產（UI 元素 - 圖像、圖標、字體）需要提供給客戶端應用程序，因此它們也被存儲到 S3 中。 S3 通過其內部存儲複製提供上傳數據的自動備份，默認提供數據持久性。
用戶上傳的圖片大小和重量各不相同，通常對於直接提供服務來說太大而且超重，給移動連接帶來負擔。 生成不同大小的多個變體將能夠為每個用例提供更優化的內容。 AWS Lambda用於該任務，以及將上傳的圖像原件複製到單獨的備份存儲桶中，以防萬一。
最後，運行瀏覽器的 Web 應用程序也是一組靜態資產 - 持續集成構建基礎架構編譯 JavaScript 代碼並將每個構建存儲到 S3 中。
一旦所有這些資產都安全地存儲在 S3 中，它們就可以直接提供服務，因為 S3 提供了一個公共 HTTP 接口，或者通過Amazon CloudFront CDN。 CloudFront 使資產在地理上分佈，減少了對最終用戶的延遲，並且還啟用了 HTTPS 支持以提供靜態資產。
基礎設施供應和管理
預置 AWS 基礎設施是網絡、AWS 託管資源和服務以及裸 EC2 計算資源的組合。 託管 AWS 服務是託管的。 除了預置和應用適當的安全性之外，與它們沒有太多關係，而使用 EC2 計算資源，我們需要自己處理配置和自動化。
工裝
基於 Web 的 AWS 控制台使管理“樂高積木式”AWS 基礎設施絕非易事，而且與任何手動工作一樣，也很容易出錯。 這就是為什麼非常需要使用專用工具來自動化該工作的原因。
一種這樣的工具是AWS CloudFormation ，由 AWS 開發和維護。 另一個是 HashiCorp 的Terraform - 通過提供多個平台提供者，這是一種稍微靈活的選擇，但這裡很有趣，主要是由於 Terraform 的不可變基礎設施方法理念。 與 LEVELS 基礎設施的運行方式保持一致，Terraform 與提供基礎 AMI 圖像的 Packer 一起被證明是非常合適的。
基礎設施文檔
自動化工具的另一個好處是它不需要詳細的基礎架構文檔，這些文檔遲早會過時。 供應工具的“基礎設施即代碼”(IaC) 範例配音為文檔，其優點是始終與實際基礎設施保持同步。 有一個高層次的概述，不太可能被改變，並且隨著最終的改變相對容易維護，在旁邊記錄就足夠了。
最後的想法
提議的 AWS 雲基礎設施是一種可擴展的解決方案，能夠自動適應未來的產品增長。 近兩年後，它依靠云自動化，無需專門的系統運營團隊 24/7 值班，就設法將運營成本保持在較低水平。
在安全性方面，AWS Cloud 將所有數據和所有資源保存在同一云中的私有網絡中。 無需任何機密數據通過公共網絡傳輸。 外部訪問被授予對受信任的支持系統（CI/CD、外部監控或警報）的精細權限，將訪問範圍僅限於其在整個系統中的角色所需的資源。
這樣的系統架構和設置正確，靈活、有彈性、安全，並準備好滿足未來有關擴展產品增長或實施高級安全性（如 PCI-DSS 合規性）的所有要求。
它不一定比 Heroku 或類似平台的產品化產品便宜，只要您符合其產品所涵蓋的常見使用模式，這些產品就可以很好地工作。 通過選擇 AWS，您可以獲得對基礎設施的更多控制權、提供的 AWS 服務範圍的額外靈活性以及具有整個基礎設施微調能力的自定義配置。
進一步閱讀 Toptal 工程博客：
- 做好功課：7 個 AWS 認證解決方案架構師考試技巧
- Terraform 與 CloudFormation：權威指南
- 使用 AWS SSM 的 SSH 日誌記錄和會話管理
- 使用 TypeScript 和 Jest 支持：AWS SAM 教程