Rút ngắn thời gian khởi động EC2

• Có thể giảm thời gian khởi động của một EC2 instance từ 40 giây xuống 5 giây
• Điều này đặc biệt quan trọng khi cần một EC2 instance mới để xử lý một tác vụ cụ thể

Vì sao thời gian khởi động lại lâu

• Khi yêu cầu một EC2 instance mới, AWS phải thực hiện nhiều bước:
  • Tạo root EBS volume từ AMI đã chọn
  • Gán địa chỉ IP riêng cho instance
  • Chọn host cho instance
  • Thực sự khởi động máy
• Ngay cả sau khi phần cứng được bật, bootloader, kernel và các tiến trình user space vẫn phải khởi chạy.

Cách né tránh vấn đề

• Vận hành một pool compute chờ sẵn để định tuyến các yêu cầu build đến những EC2 instance đã chạy sẵn.
• Tuy nhiên, cách này không khả thi về mặt chi phí cho mọi loại công việc.
• Với GitHub Actions runner, mỗi job được định tuyến đến một EC2 instance chuyên dụng.
• Việc giữ 50 EC2 instance luôn online để xử lý 50 job song song là không thực tế.

Thời gian khởi động nhanh hơn

• Với các tác vụ cụ thể, luôn nhanh hơn nếu không làm những việc không cần thiết.
• Từng bước trong quá trình tạo instance, khởi động và chạy ứng dụng được tối ưu một cách có hệ thống.
• Cách làm là khởi động instance một lần, tắt nó đi, rồi khởi động lại khi cần.

Streaming root volume EBS

• Việc chuẩn bị root EBS volume ảnh hưởng lớn đến thời gian khởi động EC2 instance và hiệu năng ứng dụng.
• Khi tạo EBS volume từ AMI, các khối dữ liệu phải được lấy từ S3 tại thời điểm chúng được truy cập lần đầu.
• AWS khuyến nghị nạp trước toàn bộ các khối dữ liệu.

Khởi động instance chỉ một lần

• Có thể stop rồi start lại các instance dùng EBS.
• Instance đã dừng chỉ giữ lại cấu hình, và bạn chỉ phải trả chi phí cho root EBS volume.
• Khởi động instance một lần để thực hiện khởi tạo ban đầu rồi dừng lại sẽ tạo ra một root EBS volume đã được "làm ấm".

Warm pool của Auto Scaling

• AWS cung cấp warm pool cho EC2 Auto Scaling.
• Tuy nhiên, Auto Scaling Group cần thời gian để phản ứng với yêu cầu.
• Để có hiệu năng tốt nhất, họ khởi chạy trực tiếp EC2 instance bằng các lệnh gọi API LaunchInstances và StartInstances.

Điều chỉnh kích thước instance

• Thời gian khởi động được tối ưu bằng cách thay đổi loại của instance đã được làm ấm.
• Dùng loại instance giá rẻ cho bước khởi tạo, rồi đổi sang loại hiệu năng cao hơn khi chạy tác vụ thực tế.

Toàn bộ luồng

• GitHub Actions runner instance đi qua luồng sau:
  • Tạo bằng instance t3.large
  • Gán địa chỉ IP riêng trong VPC đích
  • Khởi chạy kernel và các tiến trình user space một lần
  • Dừng instance
  • Khi có yêu cầu job, cập nhật loại instance sang m7a rồi khởi động
  • Nếu không có dung lượng m7a, cập nhật sang loại dự phòng rồi khởi động lại
• Với luồng này, thời gian chuẩn bị instance cho job giảm từ 40 giây xuống 5 giây.

[GN⁺]

Ý kiến trên Hacker News

Tóm tắt

• Thời gian khởi động: Yếu tố cốt lõi của việc auto scaling thành công; thời gian khởi động càng ngắn thì cửa sổ dự đoán càng nhỏ, từ đó độ chính xác dự đoán càng cao. Để tiết kiệm chi phí, việc chuẩn bị sẵn volume EBS trước có thể là hợp lý.
• Tối ưu hóa của Amazon: Amazon đã hiện thực hóa khả năng khởi động siêu nhanh với các công nghệ như Firecracker và có khả năng cung cấp tính năng tương tự trên EC2.
• Cấu hình bất biến: Có thể tối ưu bằng cách chia sẻ volume EBS thông qua cấu hình bất biến/nguyên tử và sử dụng AMI khởi động tối thiểu.
• Đo thời gian khởi động: Thời gian khởi động instance EC2 xuất hiện theo phân bố hai đỉnh, ở mức 15-20 giây hoặc 80 giây. Cần xác định nguyên nhân.
• GitHub Actions: Dù đã tối ưu việc khởi động runner của GitHub Actions, thời gian chuyển giao job vẫn dài nên cần tiếp tục tối ưu.
• So sánh với AWS: So sánh thời gian khởi động giữa AWS và các nhà cung cấp cloud khác. Hetzner tạo instance chỉ trong vài giây.
• Auto Scaling của EC2: Đề cập đến các hạn chế của bộ auto scaler EC2 và nhu cầu cải thiện. Bộ auto scaler do AWS cung cấp chậm và bị giới hạn.
• Lý do dùng EBS: EBS đánh đổi chi phí và hiệu năng để lấy độ bền. Đây là volume gắn qua mạng nên chậm. Cài đặt Linux tối thiểu cùng local storage tốc độ cao sẽ phù hợp hơn.
• Thiếu hỗ trợ Copy-On-Write của EBS: EBS không hỗ trợ Copy-On-Write, và snapshot được lưu trên S3 nên việc cấp phát IOPS bị chậm trễ.
• Chuyển sang phần cứng on-premise: Depot có thể tối ưu hiệu năng và giảm chi phí bằng cách chuyển sang phần cứng on-premise. Việc khởi động trực tiếp các tác vụ CI của khách hàng trên hypervisor có thể là cách tiếp cận tốt hơn.