高可用架構例項：在多雲和多區域中穿行

Auth0為所有技術棧上的任一平臺（移動，Web，本機）應用程式提供身份驗證，授權和單點登入服務。身份驗證對絕大多數應用程式至關重要。我們從一開始就設計了Auth0，以便它可以在任何地方執行：在我們的雲上，在您的雲上，甚至在您自己的私有基礎架構上。

在這篇文章中，我們將更多地討論我們的公共SaaS部署，並簡要介紹auth0.com背後的基礎架構以及我們用於保持高可用性並保持執行的策略。

從那以後在Auth0中發生了很多變化。這些是一些亮點：

• 我們從每月處理數百萬次到每月15億次登入，為數千名客戶提供服務，包括FuboTV，Mozilla，JetPrivilege等。

• 我們實施了新功能，如自定義域，擴充套件的bcrypt操作，大大改進的使用者搜尋等等。

• 為了擴充套件我們的組織和處理日益增長，服務數量由原有的10個增加到30個。

• 雲資源的數量也大幅增長; 我們曾經在一個環境（美國）中擁有幾十個節點，現在我們在四個環境（美國，美國-2，歐盟，澳大利亞）上擁有超過一千個節點。

• 我們決定為每個環境使用單一雲提供商，並將所有公共雲基礎架構遷移到AWS。

核心服務架構

核心服務由不同的層組成：

核心應用層：自動擴充套件執行不同服務的伺服器組（身份驗證，管理API，多因素身份驗證API等等）。

資料儲存層：MongoDB，Elasticsearch，Redis和PostgreSQL的叢集，為不同的應用程式和功能儲存各種資料集。

傳輸/佇列層：Kinesis流和RabbitMQ，SNS和SQS佇列。

基本服務層：速率限制，bcrypt叢集，功能標誌等服務。

路由層：AWS負載均衡器（來自AWS的ALB，NLB和ELB）以及一些執行NGINX作為代理的節點。

高可用

2014年，我們使用了多雲架構（使用Azure和AWS，在Google雲上使用了一些額外的資源），並且多年來為我們提供了很好的服務。隨著我們的使用（和負載）迅速增加，我們發現自己越來越依賴AWS資源。

首先，我們將我們環境中的主要區域切換到AWS，將Azure保留為災備。當我們開始使用更多AWS資源（如Kinesis和SQS）時，我們開始難以在兩個提供程式中保留相同的功能集。 隨著我們的需求的日益增長，我們會繼續在Azure部署一些新功能。如果部署在AWS上的服務全部不可用，我們仍然可以使用Azure群集支援核心身份驗證功能。

（編者：多雲環境保持同步增加功能，複雜度問題）

在2016年發生一些故障後，我們決定最終融入AWS。我們停止了與保持服務和自動化平臺無關的所有工作，並聚焦於以下內容：

• 在AWS內部啟用主備，每個區域使用多個區域和至少3個可用區。

• 增加AWS特定資源的使用，例如自動擴充套件組（而不是使用固定的節點叢集），應用程式負載平衡器（ALB）等。

• 編寫更好的自動化：我們改進了自動化，完全採用基礎架構作為程式碼，使用TerraForm和SaltStack來配置新的Auth0環境（以及替換現有的環境）。這使我們能夠從每秒約300次登入的部分自動化環境發展到每秒執行超過3.4萬次登入的全自動環境; 使用新工具可以更容易地向上擴充套件（並且只要有意義就向下擴充套件）。我們實現的自動化水平並不完美，但允許我們以更加便捷的方式發展到新的地區並創造新的環境。

• 編寫更好的指令碼檔案：我們看到除了自動化之外，我們還需要更好的指令碼檔案，以便理解，管理和響應與我們不斷增長的服務網格相關的事件。這大大提高了可擴充套件性和可靠性，同時也允許我們讓新人可以更快的上手。

我們來看看我們的美國環境架構。我們有這個總體結構：

這是單個AZ內部的結構：

在這種情況下，我們使用兩個AWS區域：us-west-2（主叢集）和us-west-1（備份叢集）。在正常情況下，所有請求都將轉到us-west-2，由三個單獨的可用區域提供服務。

這就是我們實現高可用性的方式：所有服務（包括資料庫）都在每個可用區（AZ）上執行例項。如果一個AZ由於資料中心故障而關閉，我們仍有兩個AZ來處理來自的請求。如果整個區域出現故障或出現錯誤，我們可以更新Route53以故障轉移到us-west-1並恢復操作。

我們透過在每個AWS可用區域上執行所有服務例項來實現高可用性

我們在服務故障轉移方面有不同的成熟度級別：某些服務，例如使用者搜尋v2（在Elasticsearch上構建快取）可能有效，但資料稍有延遲;另外，核心功能保持按預期工作。

在資料層中，我們使用：

• MongoDB的跨區域叢集。

• PostgreSQL的RDS複製。

• Elasticsearch的每個區域的群集具有自動快照和恢復，定期執行以解決缺少跨區域群集的問題。

我們每年至少進行一次故障演練，我們有手冊和自動化，以幫助新的基礎設施工程師快速瞭解如何做到這一點以及產生什麼影響。

（編者：每年至少一次故障演練，對於真正發生區域不可用的時候指導意義是否足夠？）

我們的部署通常由Jenkins節點觸發; 根據服務，我們使用Puppet，SaltStack和/或Ansible來更新單個節點或節點組，或者我們更新AMI併為不可變部署建立新的自動縮放組。 我們為新舊服務部署了不同型別的部署。維護文件和監控應該統一的內容，在我們需要維護自動化的同時，作用上很大程度上顯得微乎其微。

自動化測試

除了每個專案的單元測試覆蓋率外，我們還提供多個功能測試套件，可在各種環境中執行; 我們在部署到生產之前在預生產環境中執行它，並在完成部署後再次在生產環境中執行它們以確保一切正常。

亮點：

• 在不同的專案中有數千個單元測試。

• 每分鐘執行Pingdom來探測核心功能。

• 我們在每次部署之前和之後都使用Selenium和基於CodeceptJS的功能測試。 功能測試套件測試不同的API端點，身份驗證流程，身份提供程式等等。

除了每個專案的單元測試覆蓋率外，我們還有多個功能測試套件，可在各種環境中執行：在部署到生產之前進行分段，在完成部署後再次進行生產。

CDN

直到2017年，我們在多個地區使用NGINX，Varnish和EC2節點執行我們自己定製的CDN。從那時起，我們轉向CloudFront，這給了我們幾個好處，包括：

• 更多位置接入，這意味著我們的客戶延遲更少。

• 降低維護成本。

• 配置更簡單。

有一些缺點，比如我們需要執行Lambdas來執行某些配置（比如將自定義標頭新增到PDF檔案等等）。 不過，好處遠遠大於這些。

Extend

（譯者補充：Extend []是Auth0開發的一個平臺，用於實現SaaS的自定義和整合）

我們提供的功能之一是能夠透過身份驗證規則或自定義資料庫連線將自定義程式碼作為登入事務的一部分執行。 這些功能由Extend提供支援，Extend是一個可擴充套件性平臺，由Auth0開發，現在也被其他公司使用。 透過Extend，我們的客戶可以在這些指令碼和規則中編寫他們想要的任何內容，允許他們擴充套件配置檔案，規範化屬性，傳送通知等等。

我們專門為Auth0擴充套件了叢集; 他們使用EC2自動擴充套件組，Docker容器和自定義代理的組合來處理來自租戶的請求，每秒處理數千個請求並快速響應負載變化。 有關如何構建和執行它的更多詳細資訊，請檢視有關如何構建自己的無伺服器平臺的帖子。

監控

我們使用不同工具的組合來監控和除錯問題：

• CloudWatch

• DataDog

• Pingdom的

• SENTINL

我們的絕大多數警報都來自CloudWatch和DataDog。

我們傾向於透過TerraForm配置CloudWatch警報，我們在CloudWatch上保留的主要監視器是：

• 來自主負載均衡器的HTTP錯誤。

• 目標組中的不健康例項。

• SQS處理延遲。

CloudWatch是基於AWS生成的指標（如來自負載均衡器或自動擴充套件組的指標）的最佳警報工具。 CloudWatch警報通常傳送給PagerDuty，從PagerDuty傳送到Slack / phones。

DataDog是我們用來儲存時間序列指標並採取行動的服務。 我們從Linux機箱，AWS資源，現成服務（如NGINX或MongoDB）以及我們構建的自定義服務（如我們的Management API）傳送指標。

我們有很多DataDog監視器。 幾個例子：

• $環境中$ service的響應時間增加。

• $ instance（$ ip_address）中$ volume的空間不足。

• $ environment / $ host（$ ip_address）上的$ process問題。

• $environment下$service的處理時間增加。

• NTP在$ host（$ ip_address）上漂移/關閉時鐘問題。

• MongoDB副本設定在$ environment上發生了變化。

從上面的示例中可以看出，我們監控了低階指標（如磁碟空間）和高階指標（如MongoDB副本集更改，例如如果主節點定義發生更改，則會提醒我們）。 我們做了很多，並在一些服務周圍有一些非常複雜的監視器。

DataDog警報的輸出非常靈活，我們通常會將它們全部傳送給Slack，只向那些應該“喚醒人們”的人傳送給PagerDuty（如錯誤峰值，或者我們確定會對客戶產生影響的大多數事情）。

對於日誌記錄，我們使用Kibana和SumoLogic; 我們使用SumoLogic來記錄審計跟蹤和許多AWS生成的日誌，我們使用Kibana來儲存來自我們自己的服務和其他“現成”服務（如NGINX和MongoDB）的應用程式日誌。

未來

隨著業務發展，我們的平臺增長了，而且我們的工程組織規模不斷擴大：我們有許多新團隊建立自己的服務，並且需要自動化，工具和可擴充套件性指導。 考慮到這一點，這些是我們不僅要擴充套件我們的平臺而且要擴充套件我們的工程實踐的舉措：

構建PaaS風格的平臺：正如前面所提到的，今天我們有不同的自動化和部署流程;這會造成混亂併為工程師設定了障礙，因為很難在沒有涉及太多儲存庫的情況下進行實驗和擴充套件。我們正在開發一個平臺的PoC（目前執行在ECS之上），工程師可以在其中配置YAML檔案並將其部署以獲取計算資源，監控，日誌記錄，備份等等。所有這些都無需明確配置。這項工作還處於早期階段，可能仍會發生很大變化（EKS？）。但是，鑑於我們不斷擴大的規模和可擴充套件性限制，我們認為我們正在採取正確的方向。

為每個新的PR（pull request）實施冒煙測試：除了單元測試（已經在每個新PR上執行），我們希望在可能的情況下在短暫環境中執行整合測試。

將我們的日誌記錄解決方案集中到一個提供商這可能意味著遠離Kibana並僅使用SumoLogic，但我們仍需要評估功能集，資料量等。

自動化指標：現在我們的指標資料太多是手動的：在部署時新增與程式碼相關的指標呼叫，並使用DataDog介面構建儀表板和監視器。如果我們使用標準格式和命名，我們可以自動構建儀表板/監視器，從日誌中提取度量而不是顯式新增對程式碼的呼叫等等。

原文地址：https://auth0.com/blog/auth0-architecture-running-in-multiple-cloud-providers-and-regions/

這篇文章是由Auth0的網站SER Dirceu Pereira Tiegs撰寫的，最初發表於Auth0。