Câu chuyện
Tiếp tập 1
Ối giời ơi thằng SRE đâu rồi, mày quản lý infra thế nào mà có 3 ngày, lamba cost tăng tới 7k, lúc trước cả tháng có 1-200 ,giờ x70 lần, tao có chơi coin cũng không x lắm thế này, mày không setup AWS budget alert à
Dạ có chứ anh, em có implement budget alert như architect dưới
E code lambda xài code3 API để extract cost detail từ explore. Hệ thống của mình xài AWS Organization multiple account, lambda nó extract cost của từng account, collect thành reports rồi gửi vào slacks. Nếu cost vượt quá budget THRESH là nó notice em ngay
Có alert sao mày còn không nhận ra cost bị đổi lên
Dạ lỗi em, lúc đó em đang đi massage, đang phê nên em tắt slack alert, trời đánh tránh bữa ch*ch mà anh
Rồi, giờ mày tính sao
Anh yên tâm, ngã ở đâu, gấp đôi ở đó, anh cho em 1K, em all in con NEAR, dưới 10$ là một mòn quà
Được món quà của mày, anh bán công ty luôn. Mày điều tra nguyên nhân vì sao cost nó tăng ngay
Đi tìm nguyên nhân
Trước tiên, hãy bắt đầu bằng architect của hệ thống, công ty X cung cấp dịch vụ xử lý audio call bằng AI. Khi khách hàng call tới trung tâm, cuộc gọi sẽ được record lại dưới dạng audio files, rồi một hệ thống phức tạp chạy EC2 g4dn.xlarge dùng GPU để xử lý audio file như redaction, extract thông tin như tâm trạng của khách, giới tính người gọi etc… dưới đạng json file rồi upload vào S3 bucket . S3 bucket setup even notification fire khi có file upload send vào SNS, một loại SQS subscribe SNS này để trigger lambda để xử lý business logic, kết quả lưu vào RDS để BI phân tích dữ liệu. Số lượng files upload này lên tới vài chục K mỗi ngày
Giờ phân tích xem AWS charge cái cost lambda này thế nào
Như guideline của AWS
Lambda service charges for the total amount of gigabyte-seconds consumed by a function
Đại loại một giây Lambda sử dụng bao nhiêu computing resources thì tính tiền bấy nhiêu theo công thức sau
The công thức trên thì 3 nhân tố ảnh hưởng để cost của lambda là Memory, Request, Durations (Thời gian lambda running) .
Ngoài ra còn tính theo Architect mà lambda dùng ví dụ ARM thì cost rẻ hơn x86. do ARM sử dụng Graviton processor cost và performance tốt hơn. Tuy nhiên muốn xài thì phải xem function code sử dụng libary có compatible ARM hay không, cái này thì phải review code và testing. Tóm lại là dùng ARM càng nhiều càng tốt
Default các thanh niên cứ tiện tay phệt luôn x86 mà quên mất chi tiết này, trong đó có ông SRE trên
Phần memory có liên quan đến computing cost, memory allocate cho lambda càng cao thì cost càng lớn, cái này tùy thuộc vào code logic của lambda.
Ví dụ, lambda chỉ transform hay route event sang service khác thì chỉ cần 128M là ổn, tuy nhiên nếu lambda import càng nhiều library, sử dụng nhiều layer thì càng tốn bộ nhớ, nhất là những lambda sử dụng bộ code python của machine learning như tensorflow… Lamba consume memory nhiều hay ít là phụ thuộc vào trình độ của ông dev, xem có optimize memory đến đâu.
Tuy nhiên lambda memory cao lại giúp duration execution giảm --> cost giảm, performance tăng. Ví dụ
Thế nên mới đẻ ra hẳn một tool gọi là AWS Lambda Power Tuning để trade off giữa memory và lambda execution time, gọi là profilling funtions
Tool này generate ra đồ thị giá và speed của lambda để SRE tính toán chọn setting memory và execution time thế nào cho tối ưu
Ví dụ điểm giao cắt trên hình là tối ưu nhất giữa cost và performance
Nhân tối cuối cùng là number of executions, là số lần invoke lambda, gọi càng lắm thì càng tốn tiền, với số lượng voice all lên tới hàng chục K mỗi ngày, nên trigger lambda liên tục (tương ứng với số instance được tạo) thì tiền cứ gọi là xmcnd. Cho nên có 1 setting nữa là Lamba conccurrency limit, để scaling lambda khi có high requests.
Số instance giới hạn sẽ tùy thuộc vào từng khu vực, tuy nhiên con số này giao động từ 500 -> 3000(Con số này có thể tăng thêm nếu chúng ta contact vs AWS). Việc scale up sẽ có hai giai đoạn, giai đoạn chưa chạm ngưỡng burst limit thì số instance sẽ tăng theo số mũ, sau khi chạm ngưỡng burst limit, số instance sẽ tăng theo tuyến tính.
Các requests đầu tiên tới lambda instances, sẽ mất một khoảng thời gian để load code như hình dưới
Ông nào viết code xài thư viện tá lả, deployment package càng nặng thì thời gian cold start càng lâu, và tất nhiên performance hệ thống sẽ bị giảm.
Vì thế để giảm thời gian cold starts, cần phải keep function “warmup” ,lên google đọc khó hiểu, đại loại là load sẵn 1 số lượng instances lambda , gọi là provisioned concurrency, sẵn sàng phục vụ requests ngay và luôn
Còn reserved concurrency là set maximum số lượng conccurence instances cho phép chạy.
Trong trường hợp này anh SRE ở trên do hiểu sâu về lambda nên đã setting mọi thứ chuẩn chỉ
Optimizing AWS Lambda Cost
Bây giờ sau khi hiểu rõ các thông số, thì rõ ràng để tối ưu cost Lambda phải tính đến những yếu tố sau từ viết code, caching để optimize memory cho hợp lý
Kiến thức thì thuộc nằm lòng, thế thì
Tóm lại là mày tìm được nguyên nhân chưa?
HU hu, lỗi tại em, hôm trước em vác Lap vào quán massage, tại cái đầu dưới nó phê quá nên cái đầu trên của em nó lú, em tiện tay copy paste trong terraform code nên copy cái setting memory 4096M cho mấy con lambda mới. Mặc dù nó chỉ cần 128M là đủ. Ai ngờ mấy hôm nay, số lượng calling nó lên đến cả triệu nên cost nó explosion
Ông CTO thở dài,
Chết vì gái là cái chết tê tái, đúng là xạo loz hết cỡ
0 Nhận xét