Container image는 한 service의 첫 몇 초가 아니라 distribution과 storage를 위해 organize합니다. Base image는 package manager, compiler, library, alternate entry point를 담지만 특정 deployment는 대부분을 사용하지 않습니다. 모든 layer를 pull하면 launch가 늦습니다. Lazy loading은 initial barrier를 없애지만 page fault sequence가 one large transfer를 수천 개의 small file, chunk, block request로 바꿀 수 있습니다.
Mismatch는 structural합니다. Application은 page를 읽고 conventional image service는 더 크고 alignment가 다른 storage object를 fetch합니다. 논문은 I/O amplification을 최대 3.1배로 측정했고 lazy-start overhead 중 network path가 최대 90%라고 분석했습니다[1]. Random access는 hundreds of thousands of packet도 만들어 available bandwidth를 request processing과 latency에 씁니다.
FlacIO는 named service의 page working set을 기록하고 contiguous runtime image를 만듭니다. Launch할 때 host는 compact object를 전송해 OverlayFS가 직접 쓸 kernel-managed cache에 page를 넣습니다. Missing page는 underlying lazy loader로 fallback합니다. Container image ecosystem을 대체하지 않고 expected memory state를 unit으로 하는 service-specific acceleration layer를 더하는 구조입니다.
Global layer view를 대체하는 service working set
Conventional image는 root filesystem을 재현하므로 storage-oriented이고 같은 artifact가 여러 entry point를 지원하므로 global합니다. Distribution과 reuse에는 유용하지만 registry가 한 service의 traffic accept 전에 필요한 byte를 알 수 없습니다. Lazy system은 online으로 set을 발견하고 miss마다 비용을 냅니다.
FlacIO는 readiness boundary 주변에 probe를 두고 service를 시작해 runtime image를 만듭니다. Root-filesystem page access를 trace하고 registry로 보내 base image에서 referenced 데이터를 extract하며 duplicate를 제거해 contiguous하게 배치합니다. File index와 page table이 compact 데이터를 container namespace로 mapping합니다. Generation은 asynchronous이고 original image는 authoritative source로 남습니다.
Readiness probe도 correctness contract입니다. Web daemon은 port가 request를 받을 때 trace를 끝낼 수 있고 framework image는 PyTorch 또는 TensorFlow core-library import가 끝날 때 멈출 수 있습니다. 너무 일찍 끝내면 startup page가 빠져 fallback traffic이 늘고, 너무 오래 trace하면 request-specific 데이터까지 저장해 sharing을 약화합니다. Runtime image는 단순 image digest가 아니라 service 버전과 defined readiness contract에 속합니다.
Flat transfer를 받는 kernel landing point
Compact object가 있어도 host가 amplification을 만든 same file and block stack으로 unpack하면 충분하지 않습니다. FlacIO는 OverlayFS 아래, ordinary VFS page cache 위에 runtime page cache(RTPC)를 추가합니다. New primitive가 runtime image를 kernel memory로 copy하고 page를 root namespace의 file과 associate합니다. Hit는 lazy filesystem request path를 피하고 miss는 정상적으로 redirect합니다.
RTPC는 second user-space cache 없이 같은 page를 여러 container가 사용하게 합니다. Existing lazy loader는 fetched 데이터를 internal cache에 두고 VFS도 file page를 cache해 memory에 double storage를 만들 수 있습니다. FlacIO는 startup page를 application이 consume하는 cache에 직접 둡니다. Reported test에서 Nydus combination은 comparison system memory의 1.1~24%를 사용했지만 exact ratio는 loader caching policy에 달려 있습니다.
같은 base를 공유한 service-specific image는 overlap이 큽니다. FlacIO는 incremental injection과 page deduplication을 지원해 second service가 missing working set만 추가합니다. Runtime image가 없거나 page를 trace하지 못했으면 fallback합니다. Trace가 모든 branch, locale, plugin, input-dependent file을 enumerate할 수 없기 때문에 이 compatibility boundary가 필요합니다.
Startup과 steady state를 분리한 evaluation
Test host는 24-core 2.30GHz x86 processor, 256GiB DRAM, openEuler 22.03과 Linux 6.5, Containerd 1.7.1, image registry까지 10Gb/s link를 사용했습니다. Full Containerd pull, CRFS와 Nydus file-oriented lazy loading, DADI block loading, collected trace를 쓴 DADI, CRFS 또는 Nydus 위 FlacIO를 비교했습니다.
Cold startup은 process creation이 아니라 service readiness까지 측정했습니다. Daemon은 HTTP port access success를, PyTorch와 TensorFlow는 core-library import completion을 기준으로 삼았습니다. Six service에서 FlacIO는 lazy system 대비 최대 4.5배, full-image loading 대비 23배 latency를 줄였습니다. TensorFlow startup은 CRFS, Nydus, DADI보다 각각 3.7배, 3.9배, 2.8배 짧았습니다.
Warm startup은 page가 이미 local이어서 lazy system끼리 비슷했습니다. FlacIO는 mount와 redirection path만 추가했고 reported warm latency를 materially 늘리지 않았습니다. Cold-start optimization을 cached case 성과로 잘못 credit하지 않은 평가입니다. Benefit은 host에 service working set이 없고 image에 scattered startup read와 many file이 있을 때 나타납니다.
Byte 수만큼 중요한 packet 수
Tracing alone은 정확도를 높여도 remote I/O fragmentation을 남깁니다. Factor analysis에서 probe-based selection은 Postgres와 PyTorch latency를 8.6%, 22.8% 넘게 줄였습니다. RTPC와 flat runtime object를 더한 contribution은 24.2%, 50.0%였습니다. Cache path는 total startup overhead의 평균 1.41%였습니다.
PyTorch에서 existing lazy loader는 full pull보다 데이터를 29배 적게, packet을 6.3배 적게 보냈지만 FlacIO보다 byte는 최소 1.6배, packet은 4.4배 많았습니다. DADI trace replay도 Postgres와 PyTorch에서 FlacIO보다 데이터를 각각 1.6배 전송했습니다. Request가 one contiguous object로 coalesce되지 않았기 때문입니다. Accurate selection과 collective transfer는 문제의 다른 부분을 해결합니다.
Runtime image는 nine service에 262.8MiB를 사용해 compressed CRFS base image의 6.0%, Nydus image의 4.7%였습니다. Registry capacity를 startup bandwidth 및 latency와 exchange합니다. 같은 service가 자주 start하면 약 5%가 favorable하지만 one-off 또는 rapidly changing image는 회수하는 이점보다 build와 storage work가 클 수 있습니다.
Escape path가 있는 prediction으로서의 trace
Service behavior는 application 버전, environment variable, plugin, CPU feature, input에 따라 바뀝니다. Determinant가 바뀌면 runtime image를 invalidate하거나 regenerate해야 합니다. Miss는 original lazy loader가 page를 공급해 correct하지만 miss가 많으면 performance benefit이 사라지고 small network request burst가 다시 생깁니다.
Security는 existing container boundary에 남습니다. RTPC는 kernel page-cache sharing을 사용하고 namespace와 cgroup이 runtime isolation을 계속 담당합니다. 논문은 current container semantic을 넘는 shared-page confidentiality를 주장하지 않습니다. Registry integrity, image signature, page-to-file mapping validation은 base layer처럼 derived runtime object도 cover해야 합니다.
Operational 계수기는 readiness 전 runtime-image hit ratio, fallback request, cold start당 byte 및 packet, trace age, incremental-page reuse, registry storage, launch 뒤 retained memory를 보여 줘야 합니다. Platform은 stale runtime image를 retire하고 behavior가 precomputation에 너무 variable한 service를 식별할 수 있습니다.
Ready service per transferred request라는 denominator
가장 강한 use case는 cache가 없는 node에 stable service를 반복 cold placement하는 환경입니다. Autoscaling, disaster recovery, batch worker는 같은 runtime image를 여러 번 reuse할 수 있습니다. FlacIO는 cluster scaling 최대 55% 개선과 object storage 2.25배, machine-learning training 1.7배까지 보고했지만 end-to-end result에는 workload별 startup frequency가 들어갑니다.
Long-lived container, warm pool, startup path가 tenant 데이터에 크게 의존하는 image에는 이점이 작습니다. Network speed도 balance를 바꿉니다. Faster registry link는 transfer time을 줄여도 per-request latency와 CPU overhead를 남길 수 있고 slower 또는 distant registry는 aggregation 가치를 키웁니다. One 10Gb/s host-to-registry setup의 result를 universal ratio로 쓰면 안 됩니다.
Procurement는 registry byte, packet, host-memory byte, stored runtime-image byte당 completed ready instance를 비교해야 합니다. Full image pull은 compatibility, lazy loading은 byte, FlacIO는 known service working set과 request granularity를 optimize합니다. Working set이 predictable하고 repeated일 때 유리합니다. Fallback은 prediction error를 correct하게 만들고 observability는 그 error가 economical한지 결정합니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 편집 분석으로 mechanism, measurement, limit을 우리 표현으로 다시 썼습니다. 원문의 문장, 표, 도판은 재수록하지 않았고 도판은 이 글을 위해 새로 만들었습니다. 전체 논문은 USENIX FAST 2025 발표 페이지에서 확인할 수 있습니다. 저작권은 저자에게 있습니다. 2025.