Comment exécuter une image de conteneur avant qu’elle soit entièrement téléchargée : plongée dans AWS SOCI

Un article qui explique le fonctionnement interne d’AWS SOCI (Seekable OCI), qui permet d’« exécuter un conteneur avant qu’il soit entièrement téléchargé », sous l’angle de HTTP Range Request / FUSE / zTOC (index).

Contexte d’introduction (insights issus de l’article Slacker)

• Slacker: Fast Distribution with Lazy Docker Containers (USENIX FAST ’16) commence par mesurer pourquoi le « cold start » des conteneurs est lent
• Les auteurs ont créé un benchmark appelé HelloBench et mesuré, sur 57 workloads de conteneurs, le temps entre le « début du déploiement → la possibilité d’exécuter un travail utile (service prêt) »
• Observation 1) La majeure partie du temps de démarrage est consacrée au « pull/copie de l’image et des paquets »
  • pulling packages (copie des données de paquets/images) représente 76 % du temps de démarrage du conteneur
• Observation 2) Pourtant, juste après le démarrage, les données réellement lues ne représentent qu’une toute petite partie de l’ensemble
  • parmi les données pull/copiées, seulement 6,4 % en moyenne sont effectivement lues « avant que le conteneur ne commence un travail utile »
• Observation 3) Les images contiennent plus de « partage/doublons » qu’on pourrait le penser
  • il est rapporté qu’une simple déduplication au niveau bloc, qui trouve des blocs communs entre les images, a montré un meilleur effet de compression qu’une compression gzip au niveau image
• Conclusion (constat du problème) : l’approche consistant à « tout télécharger avant d’exécuter » est très gaspilleuse,
  et une méthode qui récupère d’abord uniquement ce qui est nécessaire au démarrage (exécution prioritaire), puis charge le reste à la demande (lazy), peut être efficace
• Sur la base de ces observations, un storage driver Docker appelé Slacker a été conçu
• Tous les workers Docker / registries partagent un stockage central, et les coûts de provisioning du système de fichiers sont réduits grâce aux fonctions de snapshot/clone du stockage backend
• Les données du conteneur sont récupérées de manière lazy, « quand c’est nécessaire », ce qui aurait permis de raccourcir fortement les cycles de push/pull ainsi que de développement/déploiement

SOCI Snapshotter (AWS)

• Le README de SOCI snapshotter cite lui aussi directement l’observation « 76 % vs 6,4 % » de Slacker (FAST ’16) comme fondement de l’intérêt du lazy loading
• Là où Slacker reposait fortement sur une approche « driver Docker + fonctions de stockage (serveur) spécifiques »,
  SOCI généralise cela, pour l’écosystème OCI, sous la forme d’un « lazy loading depuis le registre (ECR, etc.) »
• Au moment de l’exécution du conteneur, SOCI évite de télécharger l’image entière d’emblée ;
  il utilise à la place un index distinct (zTOC / Index Manifest) pour obtenir les informations de position/spans des fichiers, puis récupère d’abord uniquement les fragments nécessaires (on-demand) afin d’accélérer le démarrage,
  tandis que le reste continue d’être prefetched en arrière-plan : une stratégie hybride

Composants clés de SOCI

• HTTP Range Request : ne récupère depuis le registre (ECR) que la plage d’octets nécessaire, via 206 Partial Content
• zTOC : avec les offsets/métadonnées des fichiers et les checkpoints de compression (zInfo), permet une décompression « à partir du milieu »
• FUSE : monte la couche comme un système de fichiers, intercepte open/read, et récupère à la demande le span requis (4 MB par défaut)

Flux d’exécution (cas d’ECS Fargate)

• Vérification de l’index (manifest) → téléchargement du zTOC → montage FUSE → exécution du conteneur
• Lors d’un accès à un fichier, seul le span correspondant est immédiatement téléchargé via Range Request puis décompressé avant d’être renvoyé
• En parallèle, l’image complète continue d’être téléchargée en arrière-plan : une stratégie « hybride »

Limites / compromis

• À cause de l’overhead lié à l’index et au montage, les petites images (par ex. moins de 250 MB) peuvent y perdre
• L’effet dépend moins de la taille de l’image que du « pattern d’accès initial aux fichiers »
• Il reste de la marge pour ajuster la taille des spans (nombre de requêtes vs téléchargements inutiles), et des pistes d’amélioration comme LOD (Load Order Document) sont mentionnées