Você deve usar uma alternativa S3 para armazenamento de objetos?

Shutterstock / Gorodenkoff

O Simple Storage Service (S3) da Amazon oferece uma interface muito útil para armazenar objetos em armazenamento em nuvem redundante, onde você não precisa se preocupar com o hardware subjacente. Além de ser um serviço oferecido pela Amazon, é também uma API padrão do setor e há muitos serviços compatíveis com ela.

O que é compatível com o S3?

Em muitos casos, se você mudar para outro provedor de nuvem, terá que retrabalhar muito de seu aplicativo. Mas, se você estiver usando S3 como back-end de armazenamento de objetos, poderá mover-se facilmente para muitos outros serviços.

Isso ocorre porque S3 é um padrão de API aberto. O serviço de armazenamento simples da AWS é apenas uma implementação desse padrão; é nativo e, obviamente, terá o melhor suporte, mas existem outros serviços que oferecem desempenho e estabilidade aceitáveis, geralmente por um custo mais baixo.

Mudar para esses serviços é fácil — você simplesmente tem que alterar o endpoint de URL que seu aplicativo usa e geralmente é bom ir após alguns pequenos ajustes na tecla manuseio. Você terá que migrar seus dados com rclone, mas não é um processo difícil, apenas longo em alguns casos.

Não é segredo que a AWS é cara. O S3 não é diferente e, embora o armazenamento de arquivos seja muito barato, o acesso a esses arquivos não é. Em uma carga de trabalho pesada típica de leitura / gravação servindo arquivos ativos para usuários, armazenar os arquivos geralmente é barato; os custos mais altos são, na verdade, cobranças de transferência de dados da AWS e cobranças de solicitação S3:

Publicidade

Vendo uma análise do Explorador de custos como esta, você pode ficar tentado a considerar um serviço de terceiros que será mais barato nas taxas de transferência de dados para sua carga de trabalho.

Os dois principais concorrentes do AWS S3 são do Google e da Microsoft. O Google tem seu nome nada criativo “ Cloud Storage, ” e o Microsoft Azure tem o Azure Blob Storage. O armazenamento do Google é compatível com S3 e também é relativamente fácil de migrar. O Azure, por outro lado, não é compatível com o S3, embora existam ferramentas como o S3Proxy que podem corrigi-los juntos.

No entanto, todos os serviços de armazenamento dos três grandes provedores de nuvem cobrarão altas taxas pelos dados. Eles são projetados para clientes corporativos e, se você for uma pequena empresa que está tentando minimizar seus custos, deve procurar outro lugar. Existem outros provedores de nuvem alternativos, como Digital Ocean e Vultr, que oferecem modelos de preços mais simplificados com serviço de qualidade semelhante.

Oceano Digital

O Digital Ocean é um provedor de nuvem projetado para ser simples. Embora não ofereça tantos recursos quanto os principais provedores como a AWS, geralmente faz bem pelos serviços que oferece. Um desses serviços é o armazenamento de objeto, com intervalos sendo chamados de Spaces, e é o que recomendaremos se você estiver pensando em se afastar da AWS.

Os espaços são muito simples. A taxa básica é de US $ 5 por mês e inclui 250 GB de armazenamento junto com um TB inteiro de transferência de dados de saída. Este é um negócio incrivelmente bom — o mesmo uso custaria mais de US $ 90 no AWS S3.

O armazenamento de dados adicional custa US $ 0,02 por GB, bastante normal em comparação com S3 (embora mais alto se você planeja usar armazenamento de arquivo mais barato), e dados adicionais têm um preço razoável de US $ 0,01 por GB transferido, o que é 90% mais barato do que o preço da AWS.

Publicidade

Claro, isso vem com alguns limites e, infelizmente, há muito mais desvantagens e restrições associadas a esse grande negócio.

• 750 solicitações, por endereço IP, para todos os seus espaços.
• 150 operações combinadas por segundo para qualquer espaço, sem incluir solicitações GET.
• 240 operações no total incluindo solicitações GET.
• 5 solicitações PUT ou COPY por 5 minutos para qualquer objeto individual em um Espaço

Embora não seja muito bom ter esses limites de taxa, eles são bastante generosos e provavelmente você não vai atingi-los. Se você está perto de ultrapassar, você pode minimizar o efeito deles tendo vários Espaços. Se você não tiver certeza, pode ativar as métricas de bucket no S3 para verificar seu uso atual.

RELACIONADO: Como ativar e visualizar as métricas de solicitação para um intervalo AWS S3 no CloudWatch

Além disso, Spaces com mais de 3 milhões de objetos, ou 1,5 milhão com controle de versão habilitado, podem exigir “ períodos de manutenção intermitente ” para garantir um desempenho consistente. No entanto, eu pessoalmente tenho um intervalo com mais de 2 milhões de objetos versionados que não parecem ter passado por nenhum tempo de inatividade significativo ao longo de 6 meses, então isso pode não ser uma ocorrência comum.

Uma grande desvantagem do Spaces em comparação com o S3 é a interface. O Spaces é simples e se você deseja apenas fazer upload do conteúdo do seu site ou armazenar alguns arquivos básicos, a interface da web permitirá uploads, downloads e edição da maioria das configurações. No entanto, se você estiver armazenando muitos arquivos ou precisar de configuração avançada, francamente é muito ruim e você terá que trabalhar principalmente com ele por meio da API S3.

Por exemplo, o — Spaces nem mesmo tem um editor da web para selecionar a configuração do Lifecycle, que lida com o armazenamento de versões antigas de objetos usados ​​como backups em caso de exclusão do usuário. Isso também significa que não há como acessar ou excluir objetos com versão sem listar as versões por meio da API e acessá-las diretamente pelo ID da versão.

Eles também não têm muita documentação. Para ativar o controle de versão, por exemplo, tivemos que consultar a própria documentação do S3 para usar o ponto de extremidade PutBucketVersioning quase totalmente ignorado, que felizmente é compatível com o Spaces, apesar de ser ignorado nos documentos do DO &’ s. Você precisará habilitá-lo por meio deste endpoint:

 PUT? versioning < VersioningConfiguration xmlns = "http://s3. amazonaws. com/doc/2006-03-01/" > < Status > Ativado < / Status > < / VersioningConfiguration > 

E então habilite a expiração da versão:

 PUT? lifecycle < LifecycleConfiguration xmlns = "http://s3. amazonaws. com/doc/2006-03-01/" > < Regra > < ID > Bucket < / ID > < Prefix > * < / Prefix > < Status > Ativado < / Status > < NoncurrentVersionExpiration > < NoncurrentDays > 90 < / NoncurrentDays > < / NoncurrentVersionExpiration > < / Regra > < / LifecycleConfiguration > 

Publicidade

As chaves de API também são muito básicas. Você não terá controle granular sobre intervalos, objetos individuais ou qualquer outra coisa que venha com o AWS IAM. Isso pode ser um problema se você planeja dar as chaves a terceiros.

No geral, a experiência do Digital Ocean está definitivamente longe de quão bom é o S3 da AWS. Mas, se você estiver satisfeito com os limites e não se importar em usar a API para certas tarefas, certamente poderá economizar muito dinheiro em custos de largura de banda.

Auto-anfitrião

Uma vez que S3 é um padrão aberto, também é algo que você mesmo pode hospedar, o que será preferível para muitas pessoas. Existem muitas ferramentas para fazer isso, mas uma das melhores é o MinIO, que é executado no Kubernetes (K8s).

Estar no K8s significa que você pode executá-lo em qualquer nuvem pública, incluindo executá-lo por meio de serviços K8s sem servidor, como AWS EKS. Mas, você ainda estaria sujeito aos custos de largura de banda neste caso.

Onde o MinIO realmente brilha é com servidores dedicados, soluções de nuvem híbrida e execução em datacenters locais. Se você estiver pagando por uma conexão de rede dedicada a um servidor, não será penalizado se saturar essa conexão. Isso pode tornar o armazenamento auto-hospedado muito barato se você estiver planejando fornecer muitos dados aos usuários finais.

Além disso, a execução em seu próprio hardware não está sujeita aos mesmos limites de serviços como o S3. Você pode hospedar MinIO em servidores extremamente rápidos e obter melhor desempenho em cargas de trabalho pesadas de leitura / gravação (e você não será cobrado por solicitações). Obviamente, você deverá pagar os custos de hardware por esse desempenho.

Publicidade

O ponto fraco é na redundância — porque o S3 armazena seus dados em tantos lugares diferentes, basicamente é garantido que sempre funcionará e nunca perderá seus dados, exceto um meteoro gigante. O MinIO, por outro lado, pode ser hospedado em um único servidor ou por meio de uma implantação distribuída. Se você estiver hospedando em um único servidor, ficará ferrado se a sua instância cair. É a opção mais barata, mas recomendamos vários servidores em um cluster ou pelo menos fazer algum tipo de backup para S3.

O MinIO é gratuito para hospedar sob a licença GNU AGPL, mas você não obterá nenhum suporte. As licenças corporativas custam a partir de US $ 1.000 / mês e fornecem suporte 24 horas por dia, 7 dias por semana, bem como um “ Botão de pânico, ” que terá seus engenheiros de recuperação de dados prontos para ajudá-lo a corrigir falhas graves de servidor.