AWS Study Note
Amazon RDS Performance Insights (Part 1)
內容大多從網路上找到的資料整理出來的筆記，只有悲慘的故事是原創，純粹是記錄，錯誤的還請大家幫忙更正錯誤。
一切的開始是來自一個悲劇：
我做了一個 ECS 的 container，在這個 container 裡面執行了一個 script，是用來對 RDS 資料庫做 mysqldump 備份，原本都執行得好好的。但最近團隊做了 RDS 的重新調整，也把 RDS 放在 private VPC 內之類的搬遷。在搬遷後，第一次執行這個 container 進行備份時，container 執行超久、然後網站整個連不上（資料庫無回應），只好停掉 container 並且重新啟動 RDS，當然這其中還有其他因素湊在一起，才造成這場悲劇。
悲劇發生的當下有注意到，RDS 有一個 Database Load 的指標飆高到數百，而在關掉 container、重啟 RDS 後，這個指標恢復到 0 或 0.2 之類，總之很低的數字。
經觀察 container 的 log 發現，在 mysqldump 這裡卡超久的，為了要有比較基準，找了一台 EC2 來執行一樣的 mysqldump 命令。在這台 EC2 (2 vCPU 4GB memory)中執行，大約 12 秒可以 dump 出 700M 左右的資料，且對系統沒有什麼影響。但在 ECS (fargate) 中，也一樣調整成是 2 vCPU 4GB Memory 時，container 卻要 3 分鐘多才能跑完（只看 mysqldump 的時間），DB load 有明顯上升，不過大約是十幾，網站運作仍可以正常。
後來我對 mysqldump 的命令加上一些參數的調整，讓它在 container 中執行時，DB Load 可以維持在 Max CPU 以下，但時間仍然是要花費 3 ~ 4 分鐘。測試用 EC2 與 container 都放在一樣的 VPC 中，又 EC2 執行一樣的命令都沒有問題，所以推測原因應該是出在 ECS 這邊，但目前沒有找到為什麼 ECS 執行 mysqldump 特別慢的原因(備註)，但從這個悲劇中，我開始注意到 DB load 這個指標。
（之前沒注意到一部分原因也是因為在測試環境開啟的 RDS instance type 也不支援，在 production 啟動了規格比較高的 instance，同事也無意中開啟了 Performance Insights 這個設定。）
備註：後來諮詢了我們公司合作的 AWS 顧問，他說不該在 container 裡做 mysqldump 這類的工作，有其他更好的方式，這個等我實驗過後，再來當作之後分享的題材好了。
基本介紹
Amazon RDS Performance Insights 是 AWS 在 2018 年開始提供的一個工具，它是在現有的監控功能上做擴展，其中央指標為 DB Load。
Performance Insights 可以協助我們監控資料庫效能，它跟其他的指標一樣，都會統整至 cloudwatch，也就一樣都可以設定 alarm 來警示管理人員。
例如有一個很簡單的規則：
而除了監控外，它也可以協助我們診斷和解決效能問題，這很重要，知道有問題了，還要知道怎麼解決它。
基本名詞定義
以下針對後續會多次提及的名詞先做個基本解釋：
- DB Load: 代表資料庫引擎啟用中(Active)工作階段的平均數量，每秒會收集一次 SQL, State (CPU, I/O, commit log wait, and more), Host, User。
- 啟用中工作階段 (Active Session): 為已提交至資料庫引擎的連線，且正在等待來自該引擎的回應。
- 最高 CPU 值 (Max CPU): 由資料庫執行個體的 vCPU (虛擬 CPU) 核心決定。
- 平均使用中工作階段 (Average Active Sessions):
啟用 Performance Insights
在建立 RDS instance 時可以設定，已建立的也可以設定啟動，不過要注意，不是所有的 RDS intance types 跟 DB version 都有支援。
Amazon RDS Performance Insights is not supported for MariaDB version 10.0, 10.1, or 10.3, or for MySQL version 5.5 or 8.0.
For Amazon RDS for MariaDB and MySQL, Performance Insights is not supported on the following DB instance classes: db.t2.micro, db.t2.small, db.t3.micro, and db.t3.small.
Performance Insights Dashboard
在 RDS 的 intacne 列表中，會看到如果有啟動 Performance Insights 的，Current activity 那一欄就會出現 N sessions（顯示了過去五分鐘內平均作用中工作階段的資料庫負載）， 當進度條為空的時候，代表資料庫閒置中。隨著負載增加，進度條會填入藍色，當負載超過 instance 的 vCPU 數時，進度條就會轉紅，指出可能遇到了瓶頸。
從 N sessions 這邊可以點擊進入儀表板中：
儀表板中可以顯示 5分鐘、1小時、5小時、24小時、一週的資料，儀表板會自動以新資料進行重新整理，但顯示不同的資料量時，重新整理的速度也不同。
Dashboard Components
- Counter Metrics chart 計數器指標
- Database Load (Average Active Sessions chart 平均使用中工作階段圖)
- Top load item table 最高負載項目表格
Counter Metrics chart
顯示一些效能計數器，可以自行設定要顯示哪些計數器，細節可以參考這裡 https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights_Counters.html
Database Load
其實就是 Average Active Sessions chart (AAS chart)
這個圖表是用來顯示資料庫的負載，預設是用 wait states 來分組顯示（另外可以以 SQL 查詢、主機或使用者來分組），圖表上也會把這台 DB instance 的 Max CPU 畫成一條固定的線，讓我們可以用來做比較。
在 AAS chart 上，可以拖曳選擇區間顯示，這功能很好用，可以選擇某一段特別負載特別高的區間、放大來看，對診斷問題很有幫助。
Top load item table
顯示哪些項目對資料庫負載的「貢獻」最大，會從高排到低，如果我們選擇用 SQL 來看，那可以很容易就找到負載最大的 SQL 語法是哪一句。
而它彙整的方式是將多個結構相似但參數不同的 query 給彙整摘要起來，點開也能看到細節。
以上圖為例，如果 AAS chart 選擇以 wait states 來分組顯示，而 Top load item table 是以 SQL 來顯示，那在 Top load item table 表中的 Load by Waits 欄位就是顯在這個 SQL 語法帶來了多少 wait states 程度，同時他也呈現了 wait states 是怎麼影響了這個 query。
以圖中圈起來的那一列來說，可以看到 delete from authors… 這句，其中有一半是 IO:XactSync，另外近 1/4 是 CPU、近 1/4 是 Lock:transactionid。
成本
說到這裡，是不是看起來很好用啊～（什麼都還沒講，到底哪裡好用…嗯，請見 part 2）
這麼好用的工具，那需要付出多少代價呢？
來看看他的定價方案 https://aws.amazon.com/tw/rds/performance-insights/pricing/
免費方案：
- 7 天的歷史資料
- 每個月 1 百萬次 API requests
如果要儲存超過 7 天（最長是 2 年），就會要收費，費用會按照 RDS instance type 而有所不同，也會跟 vCPU 數量成倍數成長。
API requests 如果超過免費次數的話，每 1,000 個 requests 的費用為 $0.01。
通常應該免費方案就夠用了，所以等於是一個免費功能，這真的是佛心來著，大家手邊有可以開來看看的，記得去 enable 一下喔，我們來互相分享美麗的 Dashboard。
到這邊為止，都是很基本的介紹，全部的內容在 AWS 的官方文件都能看到，單純只是筆記。
預計下一個 part 2 來記錄怎麼用這個 Dashboard 來分析資料庫的負載。
