Cara Menjalankan Image Container Sebelum Selesai Diunduh: Menelusuri AWS SOCI

Tulisan ini mengulas cara kerja internal AWS SOCI (Seekable OCI) yang memungkinkan image container "dijalankan sebelum semuanya selesai diunduh", dari sudut pandang HTTP Range Request/FUSE/zTOC (indeks).

Latar belakang pengantar (insight dari paper Slacker)

• Slacker: Fast Distribution with Lazy Docker Containers (USENIX FAST ’16) terlebih dulu mengukur kenapa cold start container lambat
• Mereka membuat benchmark bernama HelloBench, lalu mengukur waktu pada 57 workload container dari “mulai distribusi → bisa melakukan pekerjaan bermakna (layanan siap)”
• Observasi 1) Sebagian besar waktu startup dipakai untuk ‘pull image/paket + penyalinan’
  • pulling packages (penyalinan data paket/image) menyumbang 76% dari waktu startup container
• Observasi 2) Namun data yang benar-benar dibaca segera setelah startup hanyalah sebagian kecil dari keseluruhan
  • Dari data yang di-pull/disalin, rata-rata hanya 6.4% yang benar-benar dibaca “sebelum container mulai melakukan pekerjaan bermakna”
• Observasi 3) Ternyata image memiliki cukup banyak “sharing/duplikasi”
  • Dilaporkan bahwa dibanding kompresi gzip per image, block-level dedup sederhana yang mencari blok umum antar-image memberi efek kompresi yang lebih baik
• Kesimpulan (rumusan masalah): pendekatan “unduh semuanya dulu baru jalankan” sangat boros,
  dan pendekatan yang mengambil dulu hanya yang diperlukan untuk startup (eksekusi prioritas), lalu mengambil sisanya saat dibutuhkan (lazy), bisa efektif
• Berdasarkan observasi tersebut, dirancanglah storage driver Docker bernama Slacker
• Semua Docker worker/registry berbagi storage terpusat, dan biaya provisioning filesystem dikurangi dengan memanfaatkan snapshot/clone pada storage backend
• Data container di-fetch secara lazy “saat dibutuhkan”, dan sebagai hasilnya dilaporkan bahwa siklus push/pull serta pengembangan/deployment menjadi jauh lebih singkat

SOCI Snapshotter (AWS)

• README SOCI snapshotter juga secara langsung mengutip observasi “76% vs 6.4%” dari Slacker (FAST ’16) sebagai dasar mengapa lazy loading efektif
• Jika Slacker adalah pendekatan yang sangat bergantung pada “driver Docker + fitur storage (server) tertentu”,
  maka SOCI menggeneralisasikannya menjadi bentuk “lazy loading dari registry (ECR, dll.)” agar bisa digunakan di ekosistem OCI
• Alih-alih menerima seluruh image saat container dijalankan,
  SOCI lebih dulu memperoleh informasi posisi file/span melalui indeks terpisah (zTOC/Index Manifest), lalu mengambil terlebih dulu hanya potongan yang dibutuhkan (on-demand) untuk mempercepat startup,
  sementara sisanya terus di-prefetch di latar belakang sebagai strategi hibrida

Komponen inti SOCI

• HTTP Range Request: hanya mengambil rentang byte yang dibutuhkan dari registry (ECR) sebagai 206 Partial Content
• zTOC: offset/metadata file + checkpoint kompresi (zInfo) sehingga dekompresi bisa dilakukan “mulai dari tengah”
• FUSE: me-mount layer seperti filesystem, mencegat open/read, lalu mengambil span yang diperlukan (default 4MB) secara on-demand

Alur kerja (berdasarkan ECS Fargate)

• Periksa indeks (manifest) → unduh zTOC → mount FUSE → jalankan container
• Saat file diakses, hanya span terkait yang langsung diunduh lewat Range Request lalu didekompresi dan diberikan
• Secara bersamaan, seluruh image tetap terus diunduh di latar belakang sebagai strategi “hibrida”

Batasan/trade-off

• Karena ada overhead indeks/mount, image kecil (mis. di bawah 250MB) bisa justru merugi
• Efeknya lebih sensitif terhadap “pola akses file awal” daripada ukuran image itu sendiri
• Masih ada ruang tuning untuk ukuran span (jumlah request vs unduhan yang tidak perlu), dan arah perbaikan seperti LOD (Load Order Document) juga disebutkan