DevOps đốt tiền Infra - tập 3

Tập 2

U cà na, một ngày hè đổ lửa

Tại một ngôi làng đổ nát vì chiến sự ở Donbas, mấy thanh niên ngồi gặm bánh mì uống trà đá tâm sự vỉa hè

Cuộc sống ngày càng khó khăn chú ạ, chiến tranh không biết bao giờ mới chấm dứt. Ông COO người U cà na thở dài

Vì tổ quốc thân yêu, mình phải tiết kiệm để giành tiền cho các chiến sĩ nơi tiền tuyến thôi anh. Chú DevOps manager nói to

Tiền cái loz, mày nhìn lại bill tháng này đi, gần X2 rồi. Tháng trước dính quả lambda cost x10, anh nghe lời mày NEAR dưới 10$ là một món quà, all in giá 8.5 để gỡ giờ gần chia đôi rồi. FINOPS, cost optimize, tiết kiệm éo gì mày, toàn mõm

Anh yên tâm, em đang tích cực điều tra và rút kinh nghiệm sâu sắc ạ

Rồi, mày cho tao cái cost analytics cái

Tập đoàn X nơi anh DevOps manager chuyên cung cấp dịch vụ hosting cho các khách hàng với hơn 10K nhân viên. Tất cả các internal tool cũng như website của khách hàng được deploy trên AWS multi-account landscape, dùng AWS organization

Mỗi account phục vụ cho một ban bệ khác nhau như tài chính kế toán, nhân sự, rồi cả dev, production, staging. Một số khách hàng lớn cũng có cả dedicated account riêng. Tổng cộng đội COE phải manage hơn 30 aws accounts, bao gồm quản lý cost, hạ tầng, maintaince …

Anh DevOps manager nắm giữ root account để manage các account còn lại

Làm thế nào để có thể cấp quyền access cho từng aws account. Ví dụ nhưng anh security chỉ access vào Audit Account, nhưng không vào được UAT hay production. Chị Kế Toán chỉ vào được AWS Core Unit, và anh DevOps manager có thể dễ dàng access vào từng account

Rõ ràng nếu làm theo kiểu truyền thống là tạo IAM user rồi phân quyền access trên từng AWS account là không tối ưu. Vì với số lượng 30 AWS account, công ty 10 nhân viên mà làm như thế thì việc quản lý IAM user sẽ là thảm hoạ.

Do đó anh DevOps manager sử dụng giải pháp gọi là AWS switch Roles

tức là user từ AWS admin account có thể access vào từng account còn lại như production, audit, testing …

Trên account management , anh DevOps manager (có account ADMIN) tạo 1 IAM user cho chị HR, ,

anh tạo Account Role Trust Policy như ở dươi

  {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "AWS": "arn:aws:iam::HR_ACCOUNT_ID:root"
          },
          "Action": "sts:AssumeRole"
        }
      ]
    }

Tức là cho chị HR quyền AssumeRole, permission cho chị HR thế nào thì tuỳ policy công ty, ví dụ chị HR chỉ được phép access vào billing, thì gán quyền Billing tương ứng

Trên account của chị HR, tạo Policy chỉ định user/group cho phép Assume role của tài khoản của ADMIN

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::ADMIN_ACCOUNT_ID:role/OrganizationAccountAccessRole"
    }
}

Như vậy, anh DevOps có thể từ account admin mà access vào HR account, Audit Account dễ dàng từ switch role

Đừng từ admin, hàng tháng anh DevOps dùng Cost Explore để xem chi phí của từng account để lập report báo cáo cho COO.

Trong FinOps reports, analyze cost của từng acccount để propose giải pháp tối ưu chi phí. Trong tình hình chiến sự căng thẳng ở U cà na, thì từng đồng chi phí đều phải được xem xét. Tối ưu càng nhiều càng tốt, thế nên anh nào làm việc trong môi trường này là thành trùm FinOps luôn

CloudWatch tháng này đắt vc, lên mấy trăm $$, tháng trước có mấy chục

Haizz, thì tháng này em build cái container insight monitoring cho EKS trên CloudWatch, dùng ổn áp lắm tính ra là ngon trong tầm giá mà anh, có alert, visual dash board đàng hoàng

Cái này AWS charge theo metrics, logs storage. Mày đã optimize chưa, config trong cloudwatch agent chỉ collect metrics nào cần thiết thôi, logs storage set retentions độ 1 tháng là đủ

Làm hết rồi anh, em customized metrics sent by Container Insights in Amazon EKS bằng cách setup AWS Distro for OpenTelemetry (ADOT) và filter metrics, metrics dimension các kiểu rồi

Éo, vẫn đắt, anh muốn không mất xu nào mà vẫn monitoring được

OK em chơi thằng này https://www.opencost.io/docs/ với kết hợp Grafana Prometheus, build monitoring from scratch luôn. Khỏi đẩy metrics vào cloudwatch, lại còn tracking được cost của từng namespace luôn

Uy tín đấy, good jobs

Data Transfer cost chiếm tới 40% total cost, các chú mở JAV live stream à, sao tốn thế

Cài này là Data trasfer out từ EKS container ra internet đấy anh. Hiện giờ mình có mấy con EKS node launch trên các zone khác nhau, có mấy app live stream và cá độ bóng đá của khách hàng deploy trên mấy con pod. Tháng này mùa cao điểm Euro, user truy cập nhiều để đánh bóng nên data transfer giữa các pod zone, data transfer out ra ngoài ALB cũng nhiều nữa nên tốn, cái này là do traffic từ khách hàng

Nhưng em có giải pháp rồi, em có cài VPC flow logs để tracking data transfer flow giữa các IP,

Em truy được là cái app đấy là nhà cái đến từ châu âu nó đấy transfer data ra ngoài, nên em move nó sang Light Sail, hàng mới của AWS uy tín lắm, low-cost solution

Có mấy gói package của nó cho Free 1 lượng data transfer luôn, ngon hơn hẳn việc xài EKS , thằng nào ăn data là em cho luôn sang đây cho rẻ

Đù thằng này khá, mà sao 2 con server nằm trong cùng 1 zone mà vẫn tốn cost data transfer, anh nhớ nó cho free cơ mà

Bỏ mẹ em rồi, lỗi em, mới check VPC flows logs, nếu nhiều ec2 data transfer qua private IP mới free, còn public IP thì nó vẫn phệt. Cái này phải chỉnh setting lại, đưa hết server vô private subnets

Rồi mấy cái khác thì sao, EBS snapshot retention setting chưa, chỉ lưu backup 1 tháng là được

Số lượng node của EKS, node size đã tính toán phân tích tối ưu chưa. EKS autoscale built in xàm lông lắm, thử nghiệm Karpenter hay KEDA chưa?

SQS metrics thấy số lượng requests tăng ác, tốn tiền các chú optimize chưa?

Mấy con RDS nó có autoscale được đâu, thử xài Aurora scaling chưa??

vlxx, phimmoi, abc, xyz chưa??

Anh DevOps manager xây xẩm mặt mày.

Tháng nào cũng phân tích optimize cost hết cỡ, hoá ra vẫn còn một mớ.

(Còn tiếp)