# 從 SRE 與非 SRE 視角，探討大型長期專案如何面對與評估技術轉折 - 許榮倫 (Minimum)

###### tags: `2023`
{%hackmd @sre-conf/H1pCafrG3 %}

主題：KKCompany採用線上影音24hr服務，今天來討論在技術轉換時需要評估技術如何更替

## 以情境題作為範例說明，並用現存專案與新專案的六大面向作為比較
### 1. 現有已存在專案，使用EC2、RDS、CloudFormation

- IAC
- 原有CF進維護
- 新的用TF
- 權限與基礎設施分開
- 系統開發
- PHP -> Golang (AWS PHP SDK僅支援7.2.5+)
- 會影響軟體、log、CPU之類的監控
- CI/CD
- 原本用OpsWorks (EC2) -> 容器化(ECS) + CodeDeploy
- DB
- MySQL版本需要升級，要處理CPU、memory -> Aurora
- 網路
- 將Classic Load Balancer轉換為ALB/NLB
- 監控的metrics不同，因此要調整
- 告警監控
- EC2跟據CPU、記憶體和硬碟來監控
- 換技術 -> 有效的監控項目、處置步驟、工具也要換 -> 也要滿足非技術人員(客戶、PM)

### 2. 新專案，使用Aurora、Terraform、容器化

- IAC
- 直接使用TF
- 系統開發
- Golang每半年淘汰一個版本
- CI/CD
- 優先選擇ECS或EKS等雲端原生服務，容器較EC2容易擴展
- DB
- 直接使用Aurora，並使用RDS Proxy來改善連線
- 會需要注意讀寫分離、高可用性、擴充性
- 網路
- 直接用Application/Network LB
- 告警監控
- 不需要監控單一POD或container的資源，而是監控POD是否頻繁運行失敗
- 換技術 -> 有效的監控項目、處置步驟、工具也要換 -> 也要滿足非技術人員(客戶、PM)

---
## 從六大面向討論新舊專案、不同角色間的 Concern

### 1. 基礎設施管理
- 目標：IaC 工具採用 Terraform

- 現有存在專案
* 公司在基礎設施管理的技術策略推行Terraform
* 模組化&再利用

- 新專案
* 線上透過介面調整系統組態，並同步更新回Terraform
* 權限管理與基礎設施管理分開

### 2. 系統開發
- 目標：改用 Go 為主

- 現有存在專案
- PHP -> Golang (AWS PHP SDK僅支援7.2.5+)

- 新專案
- Golang 每半年淘汰一個版本

- RD角度：
1. 程式執行效能

- SRE角度：
1. 軟體更新
2. 日誌如何監控
3. CPU mem disk 需求
4. mem leak

### 5. CI/CD
- 目標：服務架構改用 container

- 已存在專案
- 原本是 EC2 使用 OpsWorks 佈署

- 新專案
- ECS 使用 CodeDeploy 的藍綠部署方式，透過 Container Image 的方式建置與部署

- RD 角度
- 公司在服務架構推行 Container
- 共用 Cluster
- 容易擴展
- SRE 角度
- 優先選擇雲端原生 ECS, EKS → 減少自架的effort
- 更新維護如何操作 → 資源需要做版本更新的SOP都是考量的點

### 6. 資料庫：
- 目標：RDS 用 Aurora，改善資料庫的使用率
* autoscale up → disk 跟 instance 會自動增長

- 已存在專案
- MySQL 版本需要升級，Instance type 需要因應 CPU 或記憶體使用的需求調整。考慮更換成 Aurora。

- 新專案
- 使用 Aurora。搭配 RDS Proxy 改善資料庫使用率，增加可擴充性。(新的replica 開出來，連線過不去，所以搭配 RDS proxy)

- RD 角度
1. 使用一樣的資料庫系統
2. 共享開發資源
3. 共享遭遇的問題與解決方案

- SRE角度：
1. Cluster與讀寫分離
2. 高可用性
3. 高擴充性
4. CPU&Memory需求

### 網路：
- 目標：Load Balancer -> Application 或 Network LB

- 已存在專案
- 現有專案的 classic 不支援了
- 新專案
- ECS 或 EKS 使用 Application 或 Network Load Balancer

- RD 角度
- 配應用程式需要的通訊設定

- SRE 角度
- 留意技術演進與汰換
- 伺服器端的自動擴展策略
- 監控項目

### 告警監控
- 目標：配合技術，調整監控方式與策略

- 已存在專案
- CPU 需要因應 CPU mem disk → 搭配告警 與調整 ASg

- 新專案
- 配合技術調整
- 不需監控單一 Pod 的資源使用，但監視是否頻繁運行失敗（部署問題 or 資源不足）

- RD 角度(PM or 監控團隊 or 客戶):
- 問題資訊
- 操作記錄
- 問題修復時辰

- SRE 角度:
- 有效的監控項目
- 問題發生的處理步驟
- 解決問題的工具或人

#### 技術時間軸
2015: EC2, AWS SWF 等 AWS 服務打造全雲端企業級 OTT 平台
2017: 使用 kOps 建立第一座 K8S 叢集供內部自動化 Pipeline 使用
2018: CloudFormation; 導入 AWS 原生 Container orchestration 機制 - AWS Fargate; PHP->Golang
2020: TF ;導入 AWS EKS，實驗微服務架構; 導入 Elasticsearch Cloud
2022: Cloud Native Container(淘汰ec2方式，而是改用容器化)

#### SRE角度
- 基礎設施：config一致
- 系統開發：語言定期更新、資源需求(e.g. 透過壓測等方式獲得)
- CI/CD：管理、更新、維護
- 資料庫：availability, scalability(e.g. 早晚使用量不同)
- 網路：LB & monitoring
- Alarm：有效的監控項目；告警觸發時的action item
- 沒有 action item 的告警項目就是沒用的告警

#### KK SRE 平常在做的事
- 告警監控：確保 prod 正常，監控重要設施與服務
- 系統更新與維護：AWS服務升級作業、排查服務運作
- 留意技術演進與汰換：頻估現用技術的適用性，提供建議與改善方向
- e.g. rds proxy，機器擴展連線數無法平均，所以需要此服務，由SRE引進
- 開發自動化程式：增加效率、減少人為失誤
- 帳號管理與使用者管理：管理 AWS identity Center(successor of AWSSSO)
- 當 Accounts 太多，需要記的帳密也太多，所以配合 AD 政策，只需要記住一組帳密
- 提供數據報表：匯出專案的 SLA 報表

---

=== 聊天室 ===

0
1

單純好奇，怎麼沒有b2C公司在conf發優惠碼（X

問問天瓏？

冷知識：kkday不是他們家的
-> 那KKTIX呢
-> 還有KKTV
-> kktv跟kkbox是同一家!
-> ~~kk* 滴血認親~~

好奇問個, 大家怎麼選 terraform / pulumi / 或其他?
-> TF 較悠久、支援較廣
-> terraform registry 優勢?
-> terraform 建sg不會自動設outbound 一直被同事雷
s
-> 如果把你不喜歡或不會hcl，請考慮pulumi

題外話，目前正在學Go，個人還蠻喜歡Go寫起來的感覺
但是目前公司用都用 .net framework 跟VB5/6開發
有點想知道，如果用Golang的話，能夠用多久，有在想要做新架構，但希望這個架構能撐久點...
-> k8s相關套件都是go寫的，但我比較愛node跟php :D
--> 其實最主要還是想問，這個技術或語言會不會很快就過時了，怕會變成像VB或coffeescript那樣，未來找不到人才寫

--> 可以從幾個面向去觀察一個語言的社群大小/會存活多久，但這些都不是絕對，想學都還是可以去學，多少都會有收穫
1. GitHub repository 數量 & 星星數
2. Stackoverflow 年度調查
3. Google Trend 關鍵字
4. 各大公司開的職缺
---> OK，感謝建議
小朋友才做選擇,直接全學
----> ~~ChatGPT 都會寫~~

會問就不要吧

--> 藉機詢問，如果現在主要是在學習 K8s 的話， 會推薦去學習 Golang 嗎？
---> 看個人，基本上K8s沒在看你是用啥語言，~~VB或舊.net除外~~
我自己是因為他的效能跟寫起來好玩而去學的:D
-> 學習k8s不需要會golang，除非你要去開發cluster用的軟體
--> 好的，感謝您的建議
-> .NET Core路過，我們是從.NET Framework慢慢爬上來的

--> ~~一年一框架，三年一語言~~

要自幹K8s？
學語言怕還沒成為主流就被替代，個人覺得喜歡就學吧
語言只是工具，為了達到目的本來就會一直換語言來寫
:+1:

想問多少人有auto scaling的需求? 公司的業務需求量都算穩定不太有突然爆量，所以都用不太到auto scaling

-> 開起來避免zone問題導致服務出問題
-> $$
-> 替代作法是在CDN上解決，cloudflare 有waiting room的功能，過多的流量，會叫使用者稍等，政府單位有些專案是這樣處理暴增的流量

題外話：請問有推薦的Golang學習資源嗎？

-> [這個是整理的](https://github.com/chieund/golang_learning)
-> [然後這個是中文(簡體)的](https://github.com/0voice/Introduction-to-Golang?fbclid=IwAR2-anx0jKGlaNiPGeMxhomx7CIgrufx2-ctu2Kp36FXFEAd7twhaobDV0I)
-> [超加速學習go語法](https://github.com/jaywcjlove/golang-tutorial)
-> [對岸的，看你會不會介意，但是也不錯]( https://www.bilibili.com/video/BV1tP4y1v7kW/?share_source=copy_web&vd_source=3f579409b5b419846890ad457ed32ebd)
-> [這個還沒看，但大略看了一下感覺還行](https://haren.medium.com/72小時學習golang-learn-go-in-72-hours-推薦資源-f810c70d9dd1)

-> 然後推薦一下，[Reddit上的gopher社群](https://www.reddit.com/r/golang/)，上面都有很多新鮮事