Konteyner imajını tamamen indirmeden çalıştırma: AWS SOCI'ye yakından bakış

Konteyner imajını “tamamen indirmeden çalıştırmayı” mümkün kılan AWS SOCI'nin (Seekable OCI) iç işleyişini, HTTP Range Request/FUSE/zTOC (indeks) perspektifinden açıklayan bir yazı.

Giriş arka planı (Slacker makalesinden çıkan içgörüler)

• Slacker: Fast Distribution with Lazy Docker Containers (USENIX FAST ’16), konteyner “cold start” süresinin neden yavaş olduğunu ölçümleyerek başlıyor
• HelloBench adlı bir benchmark oluşturulup, 57 konteyner iş yükü için “dağıtımın başlaması → anlamlı işin yapılabilmesi (servisin hazır olması)” arasındaki süre ölçülüyor
• Gözlem 1) Başlangıç süresinin büyük bölümü ‘imaj/paket pull + kopyalama’ya harcanıyor
  • pulling packages (paket/imaj verisinin kopyalanması), konteyner başlangıç süresinin %76'sını oluşturuyor
• Gözlem 2) Ancak başlangıçtan hemen sonra fiilen okunan veri, toplamın çok küçük bir kısmı
  • pull/kopyalama yapılan verinin ortalama yalnızca %6,4'ü, “konteyner anlamlı işe başlamadan önce” gerçekten read ediliyor
• Gözlem 3) İmajlarda beklenenden fazla “paylaşım/tekrar” var
  • İmaj bazında gzip sıkıştırmasındansa, imajlar arasında ortak blokları bulan basit block-level dedup yaklaşımının daha iyi sıkıştırma sağladığı raporlanıyor
• Sonuç (temel problem): “Önce her şeyi indirip sonra çalıştırma” yaklaşımı büyük ölçüde israf yaratıyor ve
  başlangıç için gerekenleri önce getirip (önce çalıştır), geri kalanı ise ihtiyaç oldukça getiren (lazy) yaklaşım etkili olabilir
• Bu gözlemlere dayanarak Slacker adlı bir Docker storage driver tasarlanıyor
• Tüm Docker worker/registry bileşenleri merkezi depolamayı paylaşıyor ve backend storage'ın snapshot/clone özellikleriyle dosya sistemi sağlama maliyeti azaltılıyor
• Konteyner verisi “gerektiğinde” lazy fetch ile alınıyor; bunun sonucunda push/pull ile geliştirme/dağıtım döngüsünün ciddi ölçüde kısaldığı belirtiliyor

SOCI Snapshotter (AWS)

• SOCI snapshotter README'si de Slacker (FAST ’16) çalışmasındaki “%76 vs %6,4” gözlemini, lazy loading'in neden işe yaradığını açıklamak için doğrudan alıntılıyor
• Slacker, “Docker driver + belirli storage (sunucu) özellikleri”ne güçlü biçimde dayanan bir yaklaşımken,
  SOCI bunu OCI ekosisteminde kullanılmak üzere “registry (ECR vb.) üzerinden lazy loading” olarak genelleştiriyor
• SOCI, konteyner çalıştırma anında imajın tamamını almak yerine,
  ayrı bir indeks (zTOC/Index Manifest) ile dosya konumu/span bilgisini edinip, yalnızca gerekli parçaları önce alarak (on-demand) başlangıcı hızlandırıyor;
  geri kalanını ise arka planda prefetch etmeye devam eden hibrit bir strateji izliyor

SOCI'nin temel bileşenleri

• HTTP Range Request: registry'den (ECR) yalnızca gereken bayt aralığı 206 Partial Content ile alınıyor
• zTOC: dosya offset/meta bilgisi + sıkıştırma checkpoint'leri (zInfo) sayesinde sıkıştırma açma işlemi “ortadan başlayarak” yapılabiliyor
• FUSE: layer'ları bir dosya sistemi gibi mount edip open/read işlemlerini yakalıyor ve gereken span'leri (varsayılan 4MB) on-demand fetch ediyor

Çalışma akışı (ECS Fargate ölçütünde)

• İndeksin (manifest) kontrolü → zTOC indirme → FUSE mount → konteyneri çalıştırma
• Dosyaya erişildiğinde ilgili span, Range Request ile hemen indirilip sıkıştırması açıldıktan sonra iletiliyor
• Aynı anda tüm imaj, arka planda indirilmeye devam eden “hibrit” bir strateji uygulanıyor

Sınırlar / trade-off'lar

• İndeks/mount overhead'i nedeniyle küçük imajlarda (ör. 250MB altı) dezavantaj oluşabilir
• Etki, imaj boyutundan çok “ilk dosya erişim paterni”ne duyarlı
• Span boyutunu ayarlama alanı (istek sayısı vs gereksiz indirme) ile LOD (Load Order Document) gibi iyileştirme yönlerinden de söz ediliyor