Como executar uma imagem de contêiner antes de baixá-la por completo: uma análise detalhada do AWS SOCI

Este é um texto que explica o funcionamento interno do AWS SOCI (Seekable OCI), que permite “executar antes de baixar tudo” uma imagem de contêiner, sob a perspectiva de HTTP Range Request/FUSE/zTOC (índice).

Contexto de introdução (insights do artigo Slacker)

• Slacker: Fast Distribution with Lazy Docker Containers (USENIX FAST ’16) começa medindo por que o “cold start” de contêineres é lento
• Foi criado um benchmark chamado HelloBench, e para 57 workloads de contêiner foi medido o tempo desde o “início da implantação → possibilidade de trabalho significativo (serviço pronto)”
• Observação 1) A maior parte do tempo de inicialização é gasta em ‘pull + cópia de imagem/pacote’
  • pulling packages (cópia de dados de pacote/imagem) representa 76% do tempo de inicialização do contêiner
• Observação 2) Mas logo após a inicialização, os dados realmente lidos são apenas uma fração mínima do total
  • em média, apenas 6,4% dos dados puxados/copiedos foram realmente lidos “antes de o contêiner começar um trabalho significativo”
• Observação 3) As imagens têm mais “compartilhamento/duplicação” do que se imagina
  • foi relatado que uma simples deduplicação em nível de bloco, encontrando blocos comuns entre imagens, teve efeito de compressão melhor do que compressão gzip em nível de imagem
• Conclusão (formulação do problema): a abordagem de “baixar tudo e só depois executar” desperdiça muito, e
  uma estratégia de buscar primeiro apenas o necessário para iniciar (execução prioritária) e trazer o restante quando necessário (lazy) pode ser eficaz
• Com base nessas observações, foi projetado um storage driver do Docker chamado Slacker
• Todos os workers/registries do Docker compartilham armazenamento central, e o custo de provisionamento do sistema de arquivos é reduzido usando snapshot/clone do armazenamento de backend
• Os dados do contêiner são buscados de forma lazy “quando necessário”, e foi relatado que isso reduziu bastante os ciclos de push/pull e de desenvolvimento/implantação

SOCI Snapshotter (AWS)

• O README do SOCI snapshotter também cita diretamente a observação “76% vs 6,4%” do Slacker (FAST ’16) como base para justificar que o lazy loading funciona
• Se o Slacker era uma abordagem fortemente dependente de “driver do Docker + recursos específicos de armazenamento (servidor)”,
  o SOCI generaliza isso, para uso no ecossistema OCI, como “lazy loading a partir de um registry (como o ECR)”
• Em vez de receber a imagem inteira no momento da execução do contêiner,
  o SOCI usa um índice separado (zTOC/Index Manifest) para obter informações de posição de arquivos/spans e antecipar a inicialização buscando primeiro apenas os fragmentos necessários (on-demand),
  enquanto continua fazendo prefetch do restante em segundo plano, adotando uma estratégia híbrida

Componentes principais do SOCI

• HTTP Range Request: busca no registry (ECR) apenas o intervalo de bytes necessário, com 206 Partial Content
• zTOC: com offsets/metadados de arquivo + checkpoints de compressão (zInfo), permite descompressão “a partir do meio”
• FUSE: monta a layer como se fosse um sistema de arquivos, intercepta open/read e busca on-demand o span necessário (padrão de 4 MB)

Fluxo de funcionamento (com base no ECS Fargate)

• Verificação do índice (manifest) → download do zTOC → montagem via FUSE → execução do contêiner
• Ao acessar um arquivo, apenas o span correspondente é baixado imediatamente via Range Request, descomprimido e então entregue
• Ao mesmo tempo, a imagem inteira continua sendo baixada em segundo plano, em uma estratégia “híbrida”

Limitações/trade-offs

• Devido ao overhead de índice/montagem, imagens pequenas (por exemplo, abaixo de 250 MB) podem sair perdendo
• O efeito é mais sensível ao “padrão de acesso inicial aos arquivos” do que ao tamanho da imagem
• Há espaço para ajuste do tamanho do span (número de requisições vs. downloads desnecessários), e são mencionadas direções de melhoria como LOD (Load Order Document)