OneDegree SRE 架構大揭秘
這次 OneDegree SRE Team 想來跟大家分享在各個產品的系統架構，上一篇文章 OneDegree SRE 團隊大揭秘中有提到 OneDegree 的事業體有三個，分別是 ODHK、IXT 以及 Cymetrics，但礙於篇幅，本篇僅介紹 ODHK 和 IXT。
ODHK
首先，我們從網路層開始，外部流量首先會抵達啟用了 Web Application Firewall 的 Application Gateway，接下來根據 Domain 分別流向坐落在不同 Subnet 的 Front End 以及 Back End 的 Azure Kuberentes Service（以下稱 AKS）實體，在實際接觸到應用程式（以下稱 AP）之前，會先流經 Nginx Ingress，通過 Rate Limit 和 Whitelist IP 之後，最後才會觸碰到 AP。
從 AKS 本身出去的流量會分成兩個方向，一個往外部網路，一個往 SaaS 服務，往外部網路走 NAT Gateway，往 SaaS 服務的部分，我們採取 Zero Trust 原則，將服務提供的 Password、Secret Key 和 Token 存放在 Key Vault，每次請求都須經過驗證，而且只信任來自特定網路的請求，這裡稍微提一下環境的拆分，我們有 DEV、SIT、UAT 和 PROD 四個環境，前後端又分別用 AKS 實體分開，也就是說我們可以很明確的限制 Key Vault 只接受來自特定環境而且是 Back End 的請求。
圖的最下方我們可以看到一些第三方服務，像是 New Relic 效能調校、Sentry 錯誤追蹤、Cloudinary CDN 和圖像處理等。適當地使用第三方服務，不僅可以讓開發人員更有效率，也能夠減少 SRE 人天的耗損，能夠更專注在問題解決、架構優化或減少成本等更具價值的事情上。
再來講部署的部分，我們建立了一個專門用來部署的 GitLab Repo（以下稱為 Deploy Repo），裡面會存有部署的相關資訊以及腳本，除了不會跟產品原始碼混在一起之外也方便管理，但開發人員要怎麼去部署呢？我們在對應產品的 GitLab Repo（以下稱 Service Repo）預先建置了 Deploy Job，Service Repo 的 GitLab CI 會在 Merge Request 合併回 Develop 分支的時候產生 Pipeline，開發人員觸發 Deploy Job，Service Repo 便會對 Deploy Repo 發起部署請求，由 Deploy Repo 去執行部署行為，同時 Service Repo 也會追蹤執行結果，因此即便是開發人員也能順利完成部署。
IXT
IXT 為了因應各地市場規範，將現有的架構分成雲端和地端，上圖為 IXT 的雲端架構，基本上與 ODHK 的架構並無太大不同。而地端架構主要是因應客戶需求，分成有前台和沒有前台兩種架構，這裡所謂的前台就好比我們平常購買保險的網路投保平台，包含網站的首頁以及購買流程，如果客戶已經有自己的前台，也可以直接藉由 IXT 提供的標準化 API 做整合。
客戶如果希望於地端部署，流程上我們會先提供系統架構以及硬體清單，客戶或與客戶配合的廠商會準備好硬體，然後我們會同時在 Azure 建置開發環境，然後協助客戶建置生產環境，生產環境的建置主要會碰到三個難點，第一是網路環境，第二是作業系統，第三是服務整合。網路環境的部分，最好的情況是客戶能夠給 Diagram，如果沒有就只能相信對面的工程師了，當然也會有要我們 On Site 去蓋生產環境的情況。作業系統的部分，我們透過撰寫 Ansible 腳本去減少原本的手動建置環境的不一致性。而服務整合則是相對花最多時間的地方，因為除了要同時確保上述兩項正常運作之外，還有我們的 AP 以及對方的 AP。
Monitoring
最後來談談監控和告警的部分，目前的 Monitoring Stack 分成 Health Checking、Routine Failure、Resource Health 和 Application Error。
- Health Checking 由 Uptime Kuma 負責，它會定期對生產環境的服務做 Health Check 和 SSL Check。
- Routine Failure 會在我們內部的 Routine Job 執行失敗時發出告警。
- Resource Health 主要是由 Azure Monitor 在發生 Incident 或有即將到來的 Planned Maintenance 時去發出告警。
- Application Error 是由 Grafana 和 Elastic Cloud 一同建立的告警機制，目前 Grafana 主要是監控 Node 和 Container Metrics，而 Elastic Cloud 則是比對 AP Log 是否有 HTTP Error。
結語
今年參加了 Taiwan Cloud Summit 2022，看到今年的議題已經大多是 Kubernetes 的形狀了，所以我們也有在思考地端方案使用 Kubernetes 的可行性，但… 實際上也是要考量客戶能不能接受以及後續維護。其他還有很多坑像是 Security、IaC 或 Service Mesh 等等，完成到一個階段之後再來跟大家分享吧。
（題外話）原先一直想不到標題要怎麼下才好，後來乾脆延續之前的名稱，所以之後可能會變成「大揭秘」系列吧？
