Saving Project BaoCaoSu - Go Live or We Die

Tiếp theo phần 2 

2h sáng, tại một địa điểm không xác định, trong một căn hầm bí mật, không có cửa sổ, một nhóm người vẫn đang miệt mài làm việc, không gian vắng lặng, chỉ có tiếng lách cách của bàn phím

Leader, tôi nhận được một thông điệp mã hóa từ Head Quarter

Thông điệp chỉ có 1 dòng chữ duy nhất hiện lên

---

Mọi người đều hiểu mức độ critical của dự án, nếu không giải quyết được performance issue, project sẽ bị cancel, tất cả hơn 30 con người sẽ mất việc….

Sir, ghi nhận trong 24h qua, số lượng request order đã tăng lên hàng triệu, gấp 5 lần hôm trước

Leader, phía bộ phận Customer care thông báo, liên tục những cuộc gọi điện claim từ phía end user, họ không thể truy cập hệ thống, các order không thể thực hiện được. Các máy của tổng đài viên đều đã cháy máy, đích thân CEO tập đoàn đã tổ chức họp báo để thông báo sự cố và xin lỗi end users

Bật hệ thống monitoring lên để kiểm tra, SumoLogic, CloudWatch, Db Performance insight, tất cả những gì chúng ta có.

Màn hình SumoLogic, hệ thống monitoring and visualizing mà dự án đang sử dụng hiện lên, những chart warning, red alert xuất hiện dày đặc, cloudwatch alert liên tục bắn về qua AWS SNS, mail box của admin dầy đặc những email warning, alert

CPU Utilization exceeded

Đây là warning khi các CPU của server đang hoạt động vượt quá điểm threshold cho phép. Ví dụ CPU utilization > 80%…

RDS maximum connection exceeded

“too many connections” error for new requests

Số lượng connection tối đa cho phép tới RDS instances. Số lượng này sẽ tùy thuộc vào lượng memory của DB instance class. Một DB instance class còn nhiều memory available sẽ cho phép nhiều connection hơn

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html

DB Performance insight đang cảnh báo quá tải

Average active sessions (AAS) một kết nối tới database, đã submit request nhưng chưa được response. Ví dụ một user muốn xem list các order. Backend open một connection tới database, rồi thực hiện lệnh query. Nếu database execute và trả về kết quả, connection sẽ được close.

Tuy nhiên nếu database vẫn chưa trả về kết quả, trạng thái active connection vẫn được duy trì. Số lượng active connection là limit tùy thuộc vào instance class

SqlConnection cnn ;

connetionString = "Data Source=ServerName;Initial Catalog=DatabaseName;User ID=UserName;Password=Password"
cnn = new SqlConnection(connetionString);
try
{
    cnn.Open();
    // execute query
    cnn.Close();
}
catch (Exception ex)
{
    MessageBox.Show("Can not open connection ! ");
}

Kí hiệu red line chỉ thị capacity của rds instances, khi vượt quá đường redline sẽ có cảnh báo

DB instance đang trong tình trạng heavy load.

Change db instance class lên đi, chọn loại db.m4.10xlarge đi

Như vậy thì cost sẽ tăng vọt đó

Just Do it now

Doesn’t work. CPU load tuy có giảm nhưng chỉ sau 30 phút lại overload như cũ.

Database load bottleneck, RDS instance đang running beyond CPU capacity.

Overload vẫn vượt quá Max CPU. CPU bottleneck. Instance RDS hiện tại đang có 4 vCPU cores.

Tức là chỉ có tối đã 4 session có thể run concurrently. Nếu có 5 session, 1 session sẽ được đưa vào queue. Nếu các session kia không được hoàn thành, CPU ko được release, session thứ 5 sẽ không được xử lý, dẫn tới CPU bottleneck, request từ user không được xử lý.

Thế là thế nào, không thể hiểu nổi.

Hãy nhìn lên chart của DB performance insight. Có một số SQL statement đang contribute database load, những SQL này đang sử dụng nhiều lệnh JOIN nhiều bảng khác nhau, ảnh hưởng đến performance

Hệ thống BaoCaoSu đã hoạt động được trên 15 năm. Các table của BaoCaoSu project giờ chứa tới hàng triệu record. Việc query dữ liệu từ các bảng này hiện rất chậm

Lập tức thực hiện archive table, move những data cũ sang một table history. Chỉ lưu trữ dữ liệu trong vòng 3 năm gần đây. Optimize lại các SQL, hạn chế join quá nhiều bảng, cẩn thận trong việc sử dụng INNER JOIN và OUTER JOIN vì 2 lệnh này performance khác nhau.

Đội developer đang viết store procedure để move dữ liệu rồi ạ. SQL statement cũng đang được optimize 

Các câu lệnh Select * đã được thay đổi thành Select field cụ thể

Các table đều đã được indexing để tăng tốc độ query

INNER JOIN được sử dụng thay thế cho câu lệnh WHERE

Ví dụ

SELECT Customers.CustomerID, Customers.Name, Sales.LastSaleDate

FROM Customers, Sales
WHERE Customers.CustomerID = Sales.CustomerID

Ví dụ nếu table customer có 1000,000 record, Sale có 1000,000 record, câu lệnh Select trên sẽ gen ra 1000,000*1000,000 records, sau đó filter 1000,000 record của customer ở câu lệnh Where. Thực chất đây là một dạng CROSS JOIN

Nhưng nếu sử dụng INNER JOIN

SELECT Customers.CustomerID, Customers.Name, Sales.LastSaleDate

FROM Customers
   INNER JOIN Sales
   ON Customers.CustomerID = Sales.CustomerID

Database chỉ gen 1,000,000 record

Report, phát hiện nhiều table đang lưu binary data (document, image…) dưới dạng Blob type

Lưu trữ binary data trong SQL sẽ chiếm dụng diskspace của rds instance rất lớn, việc đọc ghi sẽ rất chậm. Tại sao lại lưu như vậy, chúng ta có thể lưu binary data lên S3, database chỉ cần lưu meta data của binary đó thôi, lưu path của binary trên database là được rồi

Toàn bộ binary đã được move lên S3

Cảnh báo, load balance hoạt động không như mong muốn, một EC2 đã bị overload nhưng ELB vẫn không hề switch request sang EC2 khác.

Phát hiện ra nguyên nhân rồi, ELB hiện tại đang sử dụng healtcheck dạng TCP:port. Trong trường hợp này, healthcheck đơn giản chỉ mở TCP connection tới instance tại port đó. Nếu failed connect trong khoảng timeout thì mới unhealthy, ELB mới switch sang ec2 khác. Mặc dù web app đã down nhưng connection tới ec2 vẫn bình thường nên ELB không switch

Thực hiện migrate sang ALB, chuyển healthcheck sang HTTP/HTTPs 

4 tiếng sau

Báo cáo, tất cả các biện pháp đã được thực thi

Không được, hệ thống vẫn down. Những thay đổi không có tác dụng. We cannot make it

Không khi căng thẳng bao trùm

We will die here

Bỗng….

Báo cáo, CPU utilization đang giảm xuống rất nhanh, các chỉ số đang trở về bình thường. 

Mọi người gần như nín thở, các alert không còn gửi tới, green indicators dần xuất hiện bao phủ toàn hệ thống

Chuyện gì xảy ra vậy. Không phải chúng ta làm, mà là người khác.

Phát hiện một bản code được commit lên repos, không phải developer của chúng ta làm.

Trên server IIS cũng xuất hiện một bản deployment mới, cũng không phải do ta deploy

Leader chợt tỉnh

Là Delta Fuck, họ không hack chúng ta, mà họ đang giúp đỡ. Nhưng họ đã làm cách nào??

…

(Đón đọc phần cuối)