前幾天在一個服務在凌晨突然發生異常緩慢，然後在一個沒睡飽的狀態下開啟了一連串的踩坑之旅 …
話說這個服務是以 EC2 建立起來的 WordPress 服務，為了讓他可以 Autoscaling 所以在 wp-content 的部份掛上了 AWS EFS 然而悲劇正要開始 …
在這個 case 中，事先並沒有閱讀 EFS 有 Burst Credit 的問題，只是傻傻的直接用 AWS 建議的 Bursting mode (((說明看起來寫的蠻厲害的啊！！
上面這張圖就是 Read/Write Throughput 已經超出用量，而開始吃掉 Burst Credit 的 2.1TiB，然後 EFS 的效能就會遇到瓶頸，這個跟 EC2 t-family type 的 CPU Credit 是一樣的情境。
吃掉 Burst Credit 的兇手可以從 CloudWatch Metric 看 MetadataIOBytes、DataWriteIOBytes、DataReadIOBytes 這三個指標
在看 EFS Metrics 記得要把 Statistic 改成 Sum 預設是 Average 會看不出來真實的 Read/Write Throughput。
AWS EFS Throughput Modes 有分為兩種：
- Bursting： 基於「檔案系統容量」的 Read/Write Throughput (參考 Throughput Scaling with Bursting Mode)，如果超過最多可以有 2.1 TiB 的 Burst Credit。
- 價格：只需收費 Standard Storage 的儲存容量費用
- Provisioned：固定的 Read/Write Throughput。
- 價格：除 Standard Storage 費用外，需額外收 Provisioned Throughput 的費用
官方建議 EFS 採用 Bursting mode 會比較彈性，其原因是當遇到突波性的 I/O，Bursting mode 會有 Burst Credit 2.1 TiB 可以應急使用，但是相對的 Burst Credit 就必須要時時監控，否則就會遇到 Production 出現效能低落的問題。
使用 Provisioned mode 也有必須負擔的費用風險，每個月要額外負擔的 Provisioned Throughput 費用頗可觀，簡單試算一下就知道是有錢人在用的。
另外小提醒一下，當修改 Provisioned Throughput 後下次修改要等 24 小時。
最後只能說 … AWS 的服務使用前請先詳閱公開說明書。
References