Armazenamento de objectos compatível com S3 para programadores africanos: sem surpresas na factura de egress

A avaliar alternativas ao Amazon S3? A API S3 é o padrão de facto para armazenamento de objectos: praticamente todas as ferramentas de programador trazem integração compatível com S3, e pegar em boto3 ou s3cmd é memória muscular para a maioria. Mas para as cargas que os programadores africanos tipicamente correm, o modelo de preços do fornecedor dominante é difícil de viver.

Uma biblioteca multimédia WordPress para um site a servir leitores nigerianos. Um backup de Postgres a ser restaurado para uma máquina de staging em Joanesburgo. Um serviço de vídeo on-demand para audiências no Quénia. Em todos os três, o custo dominante é o egress: largura de banda a sair do bucket para o consumidor ou o destino do restauro: e o preço de egress dos grandes fornecedores é genuinamente punitivo. As tarifas típicas situam-se entre 0,08 e 0,12 $/GB para os primeiros terabytes, descendo a escala petabyte, e mais altas a partir de deployments em regiões africanas. Uma página de produto e-commerce popular com algumas imagens pode perder centenas de dólares por mês em egress sem ninguém reparar até a factura chegar.

É esta a lacuna que uma alternativa compatível com S3 pode preencher: a mesma API que os programadores já conhecem, com um modelo de preços que não sangra na largura de banda.

O que uma verdadeira alternativa compatível com S3 precisa de entregar

Três requisitos técnicos e um comercial:

1. Compatibilidade com a API S3. Não «temos um object store com uma API diferente»: compatibilidade real com a API S3. O objectivo é que todos os SDKs, todos os pipelines CI/CD, todas as ferramentas de backup falem nativamente. Se tem de reescrever código para adoptar uma API diferente, o custo de transição anula as poupanças.
2. Durabilidade da mesma ordem de grandeza. O serviço líder anuncia 99,999999999 % (onze noves) de durabilidade via replicação multi-AZ. Uma alternativa não precisa de igualar isso exactamente: nove noves chegam para a maioria das cargas: mas precisa de estar na mesma conversa. Um NAS de uma única máquina com RAID-6 não qualifica.
3. Consistência leitura-após-escrita. O incumbente oferece consistência forte leitura-após-escrita desde 2020. Alternativas ainda em consistência eventual vão mordê-lo em qualquer workflow em que um objecto acabado de carregar é lido imediatamente: que é a maioria dos workflows.
4. Preço de largura de banda previsível. É todo o ponto. Se a alternativa medir a largura de banda a preços de hyperscaler, não há razão para mudar. Largura de banda incluída a preço fixo, ou um modelo por escalões claro, é o que faz as contas bater certo para cargas com audiência africana.

O armazenamento de objectos da AFRICLOUD como alternativa

O armazenamento de objectos da AFRICLOUD já está disponível em Lisboa (região eu-lis-1). Os buckets são criados a partir do painel de controlo da AFRICLOUD e cada bucket tem a sua própria chave de acesso e o seu próprio segredo. O endpoint s3.africloud.com fala a API S3, pelo que as ferramentas que já utiliza se ligam sem alterações: aws-cli com o endpoint redefinido, s3cmd e rclone.

Os preços foram pensados para o problema de egress descrito acima. O armazenamento custa 0,02 USD por GB por mês, facturado diariamente com base no volume efectivamente armazenado. O egress está incluído até três vezes o volume armazenado em cada mês; a partir daí, custa 0,02 USD por GB. Cada conta pode ter até 10 buckets e 500 GB no total.

Onde o serviço líder continua a vencer

Três casos genuínos para ficar com o incumbente:

• Integração profunda do ecossistema. Se o seu pipeline depende de eventos de object-store a disparar funções serverless ou jobs de treino ML no mesmo ecossistema do fornecedor, migrar apenas o armazenamento de objectos cria egress cross-cloud que anula as poupanças.
• Entrega edge global. Um CDN fortemente integrado mais um object store dão-lhe presença edge continental com um clique. Se a sua audiência é globalmente distribuída e precisa de edge em todas as regiões, uma alternativa com menos PoPs é genuinamente mais lenta.
• Preço de arquivo frio. Para dados genuinamente frios acedidos menos de uma vez por ano, os níveis de deep-archive à volta de 0,001 $/GB/mês são difíceis de bater. Uma alternativa de armazenamento de objectos sem nível frio custa mais para este caso específico.

Caminho de migração

Para a maioria dos buckets de audiência africana, a migração é um único comando rclone sync e uma actualização de configuração ao nível da aplicação. Três passos:

1. Configurar rclone com ambos os endpoints S3-compatíveis, origem e destino. Um ~/.config/rclone/rclone.conf padrão com dois remotos.
2. Sincronizar o bucket. rclone sync origem:o-seu-bucket destino:bucket-destino --progress. O encargo de egress da origem é real (uma última factura à saída), portanto para buckets grandes, orce-o.
3. Actualizar a sua aplicação. Altere o URL do endpoint na sua configuração para apontar para o novo fornecedor. Para a maioria dos SDKs isto é uma única variável de ambiente ou uma linha de código (boto3.client("s3", endpoint_url=...)).

Teste primeiro com um bucket pequeno só-leitura, verifique que os padrões de acesso correspondem, e depois migre produção. Se estiver a usar URLs pré-assinados para downloads, verifique que funcionam contra o novo endpoint: devem funcionar, já que é a mesma API, mas a rotação de credenciais vale a pena verificar antes do corte.

Consulte a nossa página de Object Storage para conhecer os preços e limites actuais, ou contacte-nos para discutir os detalhes da migração da sua carga de trabalho.