EC2 açılış süresi nasıl kısaltılır

• EC2 instance'larının açılış süresini 40 saniyeden 5 saniyeye düşürmek mümkün
• Bu, belirli bir işi işlemek için yeni bir EC2 instance'ına ihtiyaç duyulduğunda çok önemli

Açılış süresi neden uzun sürer

• Yeni bir EC2 instance'ı istendiğinde AWS birden fazla işlem gerçekleştirir:
  • Seçilen AMI'den kök EBS volume'ünü oluşturma
  • Instance'a özel IP adresi atama
  • Instance için host seçme
  • Makineyi fiilen başlatma
• Donanım açıldıktan sonra da bootloader, kernel ve user-space süreçlerinin başlaması gerekir.

Sorunu aşma yöntemi

• Beklemede duran bir compute pool işletip build isteklerini zaten çalışmakta olan EC2 instance'larına yönlendirmek.
• Ancak bu, her iş için ekonomik olarak uygulanabilir değil.
• GitHub Actions runner'ları söz konusu olduğunda her iş özel bir EC2 instance'ına yönlendirilir.
• 50 paralel işi karşılamak için 50 EC2 instance'ını çevrimiçi tutmak gerçekçi değil.

Daha hızlı açılış süresi

• Belirli işler için gereksiz işlemleri yapmamak her zaman daha hızlıdır.
• Instance oluşturma, açılış ve uygulama başlatmanın her adımı sistematik olarak optimize edilir.
• Bunun için instance bir kez açılır, durdurulur ve ihtiyaç olduğunda yeniden başlatılır.

EBS kök volume streaming

• EBS kök volume'ünün hazırlanması, EC2 instance açılış süresi ve uygulama performansı üzerinde büyük etkiye sahiptir.
• AMI'den EBS volume oluşturulurken veri bloklarının ilk erişimde S3'ten getirilmesi gerekir.
• AWS, tüm veri bloklarını önceden yükleme yöntemini önerir.

Instance'ı bir kez açmak

• EBS destekli instance'lar durdurulduktan sonra yeniden başlatılabilir.
• Durdurulan instance'lar yalnızca yapılandırmayı korur ve sadece kök EBS volume için ücret ödenir.
• Instance bir kez açılıp ilk kurulum işleri yapıldıktan sonra durdurulursa "ısıtılmış" bir EBS kök volume'ü oluşur.

Auto Scaling warming pool

• AWS, EC2 Auto Scaling için warming pool sağlar.
• Ancak Auto Scaling gruplarının isteklere tepki vermesi zaman alır.
• En iyi performans için EC2 instance'ları doğrudan LaunchInstances ve StartInstances API çağrılarıyla başlatılır.

Instance boyutlandırma

• Isıtılmış instance'ın türü değiştirilerek açılış süresi optimize edilir.
• İlk kurulum işleri için ucuz bir instance türü kullanılır, gerçek iş sırasında ise daha yüksek performanslı bir instance türüne geçilir.

Uçtan uca akış

• GitHub Actions runner instance'ı şu akıştan geçer:
  • t3.large instance'ı olarak oluşturulur
  • Hedef VPC'ye özel IP adresi atanır
  • Kernel ve user-space süreçleri bir kez başlatılır
  • Instance durdurulur
  • İş isteği geldiğinde instance türü m7a olarak güncellenir ve başlatılır
  • m7a instance kapasitesi yoksa yedek türe güncellenir ve yeniden başlatılır
• Bu akış sayesinde işler için instance hazırlama süresi 40 saniyeden 5 saniyeye iner.

[GN⁺]

Hacker News görüşü

Özet

• Açılış süresi: Otomatik ölçeklendirme başarısının temel unsurlarından biridir; açılış süresi ne kadar kısa olursa tahmin penceresi o kadar küçülür ve tahmin doğruluğu artar. Maliyeti azaltmak için EBS volume'lerini önceden hazırlamak mantıklı olabilir.
• Amazon'un optimizasyonu: Amazon, Firecracker gibi teknolojilerle ultra hızlı açılış gerçekleştirdi ve EC2'de de benzer özellikler sunuyor olabilir.
• Değişmez yapılandırma: Değişmez/atomik yapılandırma sayesinde EBS volume'leri paylaşılabilir ve minimum açılış AMI'si kullanılarak optimizasyon yapılabilir.
• Açılış süresinin ölçümü: EC2 instance açılış süresi iki modlu görünüyor; dağılım 15-20 saniye veya 80 saniye olarak ortaya çıkıyor. Nedeninin anlaşılması gerekiyor.
• GitHub Actions: GitHub Actions runner'ının açılışı optimize edilse bile iş teslim süresi uzun kalıyor; ek optimizasyon gerekiyor.
• AWS ile karşılaştırma: AWS ile diğer bulut sağlayıcılarının açılış süreleri karşılaştırılıyor. Hetzner, instance'ları birkaç saniye içinde oluşturuyor.
• EC2 otomatik ölçekleyici: EC2 otomatik ölçekleyicisinin sınırlamaları ve iyileştirme ihtiyacı belirtiliyor. AWS'nin sunduğu otomatik ölçekleyici yavaş ve kısıtlı.
• EBS kullanım nedeni: EBS, dayanıklılık için maliyet ve performanstan ödün veriyor. Ağa bağlı volume olduğu için yavaş. Minimum Linux kurulumu ve hızlı yerel depolama kullanmak daha uygun.
• EBS'de Copy-On-Write desteği eksikliği: EBS, Copy-On-Write'ı desteklemiyor ve snapshot'lar S3'te depolandığı için IOPS tahsisi gecikiyor.
• On-premise donanıma geçiş: Depot, on-premise donanıma geçerek performansı optimize edip maliyetleri azaltabilir. Müşteri CI işlerini doğrudan hypervisor üzerinde başlatmak daha iyi bir yaklaşım olabilir.