Mempercepat Waktu Boot EC2

• Waktu boot instance EC2 dapat dikurangi dari 40 detik menjadi 5 detik
• Ini sangat penting ketika instance EC2 baru diperlukan untuk menangani tugas tertentu

Alasan waktu boot lama

• Saat meminta instance EC2 baru, AWS melakukan beberapa tugas:
  • Membuat volume root EBS dari AMI yang dipilih
  • Menetapkan alamat IP privat ke instance
  • Memilih host untuk instance
  • Benar-benar mem-boot mesin
• Bahkan setelah perangkat keras menyala, bootloader, kernel, dan proses ruang pengguna masih harus dimulai.

Cara menghindari masalah

• Menjalankan pool komputasi siaga dan merutekan permintaan build ke instance EC2 yang sudah berjalan.
• Namun, ini tidak layak secara ekonomis untuk semua pekerjaan.
• Untuk runner GitHub Actions, setiap pekerjaan dirutekan ke instance EC2 khusus.
• Menjaga 50 instance EC2 tetap online untuk menangani 50 pekerjaan paralel adalah hal yang tidak realistis.

Waktu boot yang lebih cepat

• Selalu lebih cepat jika tidak melakukan pekerjaan yang tidak perlu untuk tugas tertentu.
• Setiap tahap pembuatan instance EC2, booting, dan peluncuran aplikasi dioptimalkan secara sistematis.
• Metode yang digunakan adalah mem-boot instance sekali, menghentikannya, lalu menyalakannya kembali saat dibutuhkan.

Streaming volume root EBS

• Kesiapan volume root EBS sangat memengaruhi waktu boot instance EC2 dan performa aplikasi.
• Saat volume EBS dibuat dari AMI, blok data harus diambil dari S3 ketika pertama kali diakses.
• AWS merekomendasikan metode untuk memuat semua blok data terlebih dahulu.

Mem-boot instance sekali

• Instance berbasis EBS dapat dihentikan lalu dijalankan kembali.
• Instance yang dihentikan hanya mempertahankan konfigurasinya, dan Anda hanya membayar biaya untuk volume root EBS.
• Dengan mem-boot instance sekali untuk melakukan pekerjaan inisialisasi lalu menghentikannya, akan tercipta volume root EBS yang sudah "di-warm up".

Warm pool Auto Scaling

• AWS menyediakan warm pool untuk EC2 Auto Scaling.
• Namun, Auto Scaling Group memerlukan waktu untuk merespons permintaan.
• Untuk performa terbaik, instance EC2 dijalankan secara langsung menggunakan panggilan API LaunchInstances dan StartInstances.

Mengubah ukuran instance

• Waktu boot dioptimalkan dengan mengubah tipe instance yang sudah di-warm up.
• Tipe instance yang murah digunakan untuk pekerjaan inisialisasi, lalu diubah ke tipe instance berperforma lebih tinggi saat pekerjaan sebenarnya dijalankan.

Alur keseluruhan

• Instance runner GitHub Actions melalui alur berikut:
  • Dibuat sebagai instance t3.large
  • Alamat IP privat ditetapkan pada VPC target
  • Kernel dan proses ruang pengguna dijalankan sekali
  • Instance dihentikan
  • Saat permintaan pekerjaan datang, tipe instance diperbarui ke m7a lalu dijalankan
  • Jika tidak ada kapasitas instance m7a, diperbarui ke tipe cadangan lalu dijalankan ulang
• Dengan alur ini, waktu persiapan instance untuk pekerjaan berkurang dari 40 detik menjadi 5 detik.

[GN⁺]

Opini Hacker News

Ringkasan

• Waktu boot: faktor kunci keberhasilan penskalaan otomatis; semakin singkat waktu boot, semakin kecil jendela prediksi sehingga akurasi prediksi meningkat. Demi menghemat biaya, menyiapkan volume EBS terlebih dahulu bisa menjadi langkah yang masuk akal.
• Optimasi Amazon: Amazon telah mewujudkan boot supercepat dengan teknologi seperti Firecracker, dan ada kemungkinan EC2 juga dapat menyediakan kemampuan serupa.
• Konfigurasi immutable: dengan konfigurasi immutable/atomik, volume EBS dapat dibagikan dan optimasi bisa dilakukan dengan memakai AMI boot minimal.
• Pengukuran waktu boot: waktu boot instance EC2 tampak memiliki distribusi bimodal, yaitu 15–20 detik atau 80 detik. Perlu dicari penyebabnya.
• GitHub Actions: meskipun boot runner GitHub Actions telah dioptimalkan, waktu pengiriman job masih panjang sehingga perlu optimasi lebih lanjut.
• Perbandingan dengan AWS: perbandingan waktu boot antara AWS dan penyedia cloud lain. Hetzner dapat membuat instance hanya dalam beberapa detik.
• Autoscaler EC2: disebutkan adanya keterbatasan pada autoscaler EC2 dan perlunya perbaikan. Autoscaler bawaan AWS lambat dan terbatas.
• Alasan penggunaan EBS: EBS mengorbankan biaya dan performa demi durabilitas. Karena berupa volume yang terhubung melalui jaringan, performanya lambat. Instalasi Linux yang minimal dan penggunaan penyimpanan lokal yang cepat lebih cocok.
• Kurangnya dukungan Copy-On-Write di EBS: EBS tidak mendukung Copy-On-Write, dan snapshot disimpan di S3 sehingga alokasi IOPS menjadi tertunda.
• Beralih ke perangkat keras on-premise: Depot dapat beralih ke perangkat keras on-premise untuk mengoptimalkan performa dan mengurangi biaya. Menjalankan boot job CI pelanggan langsung di hypervisor mungkin merupakan pendekatan yang lebih baik.