Na computação em nuvem, lidar com a escala é tanto um objetivo como um desafio. Isto é especialmente verdade para as empresas que necessitam de distribuir actualizações de software ou firmware over the air (OTA). O desafio aqui é gerenciar o volume - garantindo que os uploads e downloads sejam seguros, eficientes e oportunos. Uma configuração comum para algo assim é usar um sistema de arquivos virtual montado em um servidor de nuvem privada com uma CDN para distribuir o software globalmente. Embora essa seja uma configuração decente na qual muitas empresas confiaram para ajudar a escalar sua distribuição, como equilibrar isso com a redução de custos? Este não é apenas um cenário hipotético, muitas empresas enfrentam desafios semelhantes, incluindo um cliente eletrónico nosso que precisava de distribuir actualizações de firmware OTA a milhões de smart TVs em todo o mundo.
A distribuição deste tipo de software implica grandes riscos. Estas actualizações podem ser para novas funcionalidades, aperfeiçoamento da IU, correcções de segurança ou melhorias de desempenho. Uma empresa que lide com actualizações OTA tem de se certificar de que, se dezenas de milhares de clientes actualizarem os seus televisores ao mesmo tempo, a solução consegue lidar com a carga de forma eficiente sem custos adicionais ou despesas gerais. Este não é um desafio único. Milhares de empresas utilizam OTA para os seus produtos e software.
No caso do nosso cliente, o fabricante usou inicialmente vários serviços diferentes para gerenciar isso: A Content Delivery Network (CDN) da Akamai para distribuição global, o Elastic Compute Cloud (EC2) daAWS para poder de computação, o Elastic Load Balancer para tráfego de entrada e o Elastic File System (EFS) para armazenar e gerir os ficheiros de firmware. Esta configuração foi criada para lidar com escalas imensas de distribuição de dados em todo o mundo. No entanto, também tinha um preço elevado, especialmente para os custos de saída.
AWSO EFS da era uma parte integrante das operações do fabricante que lhes permitia armazenar e gerir centralmente as actualizações do SO e do firmware, bem como distribuí-las globalmente de forma eficiente através da integração com o EC2 e o Elastic Load Balancer. No entanto, o custo associado ao EFS, especialmente quando se trata de transferências de dados em grande escala fora das redes do AWS, tornou-se uma preocupação crescente.
Os custos crescentes associados ao EFS - particularmente nas taxas de saída para transferência para fora de AWS- levaram a uma reavaliação do sistema de armazenamento e distribuição para as actualizações das suas smart TVs. Isso marcou um momento crucial na estratégia do fabricante para gerenciar os custos e, ao mesmo tempo, manter seu robusto sistema de distribuição global, passando do EFS para o Linode Object Storage.
Solução
Object Storage O facto de ser mais rentável não foi suficiente para convencer este cliente a migrar do EFS. Ele também precisava se integrar perfeitamente ao fluxo de trabalho existente. Eles conseguiram fazer isso com a ajuda da equipe de suporte da Akamai e de algumas ferramentas de código aberto.
Na sua arquitetura, configuraram um bucket Object Storage primário na região Ásia-Pacífico e Japão e um segundo bucket nos Estados Unidos para servir de cópia de segurança. Esta redundância evita a perda de dados e assegura que a disponibilidade das actualizações de firmware se mantém constante, mesmo que o bucket de armazenamento primário falhe. Os dois buckets são sincronizados utilizando o rclone, um utilitário de código aberto conhecido pela sua eficiência na transferência e sincronização de ficheiros. Essa ferramenta foi fundamental para garantir que ambos os buckets pudessem servir como servidores de origem confiáveis para a CDN.
A transição envolveu um desafio técnico significativo: substituir a sua solução de armazenamento existente (EFS) por um novo protocolo de armazenamento (Object Storage) sem perturbar o seu fluxo de trabalho. O EFS e o Object Storage são fundamentalmente diferentes na sua arquitetura e funcionalidade. O EFS fornece uma interface e uma semântica de sistema de ficheiros, que são essenciais para muitas aplicações que requerem um sistema de ficheiros tradicional. Em contrapartida, o Object Storage, é acedido através de uma API Web, que não suporta nativamente operações de sistema de ficheiros. Como resultado, não pode simplesmente trocar o EFS por Object Storage.
Para ultrapassar este problema, utilizámos o S3FS, uma ferramenta de código aberto que simula uma interface de sistema de ficheiros sobre a API S3 . O S3FS nos permitiu "montar" os buckets do Object Storage nas instâncias EC2 existentes do fabricante, para que ele se comporte como o EFS. Esta abordagem permitiu que as aplicações e os processos existentes interagissem com o Object Storage como se fosse um sistema de ficheiros tradicional, minimizando as alterações necessárias no código da aplicação e reduzindo o risco de erros durante a transição.
Esta arquitetura (acima) não só simplifica o processo de atualização de software em milhões de dispositivos em todo o mundo, como também permite poupanças de custos significativas. Ao fazer a transição do Elastic File System (EFS) da AWSpara a Object Storage, a empresa reduziu drasticamente os custos de armazenamento, tendo a Object Storage provado ser mais de 15 vezes menos dispendiosa por GB do que a EFS. Também se registou uma redução de 90% nos custos de saída, o que representa uma melhoria substancial em relação ao anterior ambiente AWS . Estas poupanças ilustram a eficácia da nova solução de armazenamento na gestão da eficiência operacional e da relação custo-eficácia.
Não se tratava apenas de uma atualização técnica, mas de um realinhamento com os objectivos de eficiência, escalabilidade e gestão de custos do fabricante. Ao adotar o Object Storage e integrá-lo sem problemas (com a ajuda de ferramentas como o rclone e o S3FS), o fabricante pôde reduzir significativamente os seus custos operacionais sem comprometer a fiabilidade ou a velocidade da sua distribuição global de firmware. Este estudo de caso demonstra como as decisões na adoção de tecnologia podem ter um impacto significativo nos resultados de uma organização.
Análise crítica da relação custo-eficácia
Ao examinar a transição de AWS para Linode via Akamai, a decisão inicialmente parece uma clara vitória na economia de custos. No entanto, um mergulho mais profundo nas estruturas de custo e na comparação de produtos revela algumas nuances. Aqui estão alguns pontos de decisão importantes para se ter em mente:
- AWS S3 vs. Linode Object Storage: A arquitetura inicial canalizava um tráfego de saída considerável através do Elastic Load Balancer para o CDN da Akamai. Dada essa estrutura, o uso do Object Storage surgiu como mais econômico do que o AWS S3 devido aos custos de saída significativamente mais baixos. No entanto, se emparelhado com AWS Cloudfront, os custos de saída para o armazenamento de objetos poderiam ser zero.
- AWS Cloudfront vs. CDN da Akamai: a escolha de manter a Akamai em vez do AWS Cloudfront foi influenciada pela necessidade de minimizar as alterações na arquitetura. A organização valorizou o desempenho, a confiabilidade e o suporte comprovados da Akamai, bem como a flexibilidade proporcionada pelo uso de vários provedores de nuvem.
Para quantificar o impacto financeiro, consideremos um cenário hipotético em que, numa base mensal, um cliente gere 50 TB de dados armazenados com 100 TB de transferências de saída. Segue-se uma repartição de custos simplificada para AWS EFS, AWS S3 , e Linode Object Storage:
Solução de armazenamento | Cálculo | Custo total |
AWS EFS | ($0,3/GB * 50.000GB) + ($0,03/GB * 100.000GB) | $18,000 |
AWS S3 | ($0,023/GB * 50.000GB) + ($0,09/GB * 10.000GB) + ($0,085 * 40.000GB) + ($0,07/GB * 50.000GB) | $8,950 |
Armazenamento de objetos Linode | ($0,02/GB * 50.000GB) + ($0,005/GB * 49.000GB) | $1,245 |
(Nota: as comparações holísticas de preços são difíceis. Isto apenas tem em conta os custos de armazenamento e largura de banda para o armazenamento de ficheiros, mas não tem em conta a CDN. Também vale a pena mencionar que alguns fornecedores oferecem taxas mais reduzidas para clientes com um volume excecionalmente elevado).
Vejamos agora os custos comparativos associados ao armazenamento e à saída para estes serviços em nuvem (Nota: os preços baseiam-se no custo no momento da redação do presente documento).
Tipo de serviço | Descrição dos custos | Preço | Notas |
Armazenamento EFS | Por GB por mês | $0.30/GB | API intuitiva e fácil de utilizar, mas de custo elevado. Considere alternativas para grandes volumes |
S3 Armazenamento | Por GB por mês para os primeiros 50 TB | $0.023/GB | Económico para armazenamento de grandes quantidades de dados |
S3 Egresso | Por GB para os primeiros 10 TB | $0.09/GB | Mais dispendioso para transferências de dados elevadas, a menos que seja combinado com o Cloudfront. |
Por GB para os próximos 40 TB | $0.085/GB | Dimensionamento dos custos em função do volume | |
Por GB para os próximos 100 TB | $0.07/GB | Melhores tarifas para transferências de maior volume | |
Armazenamento Linode | Por GB por mês | $0.02/GB | Mais rentável para armazenamento |
Linode Egress | Primeiro 1TB gratuito, depois por GB | $0.005/GB | Poupanças significativas na saída de dados, maximizando a eficiência orçamental |
Nesta análise, o uso de Object Storage é aproximadamente 1/15 do custo da solução original com AWS EFS, e cerca de 1/7 do custo do uso de AWS S3 (assumindo que AWS Cloudfront não é utilizado para compensar as taxas de saída).
Conclusão
Essa comparação de custos ilustra a economia significativa obtida com a mudança para o Linode Object Storage. Ela também destaca a importância de adaptar as soluções de nuvem às especificidades dos padrões de tráfego de uma empresa e aos requisitos da rede de distribuição de conteúdo (CDN). Quando as empresas analisam suas estratégias de uso e distribuição de dados, elas podem descobrir oportunidades significativas de economia de custos que, de outra forma, poderiam ser ignoradas.
A decisão de mudar as soluções de armazenamento não foi tomada de ânimo leve; foi apoiada por uma avaliação detalhada dos requisitos operacionais e dos objectivos financeiros da empresa. Ao compreender o volume de dados que estava a ser gerido, a frequência de acesso aos dados e a distribuição geográfica dos utilizadores, a empresa conseguiu identificar a Linode como a solução mais rentável que também satisfazia as suas necessidades. Esse tipo de tomada de decisão informada é fundamental nas arquiteturas de nuvem, em que os custos podem variar drasticamente com base no tipo de armazenamento, nos volumes de transferência de dados e nas frequências de acesso.
Embora os programadores e arquitectos se devam concentrar no desempenho e na escalabilidade de uma solução, podem também ter de ter em conta o impacto financeiro nas empresas para as quais trabalham. As soluções devem não só cumprir os requisitos técnicos, mas também alinhar-se com as estratégias financeiras mais alargadas de uma organização. Desta forma, é possível evitar derrapagens orçamentais e garantir que os investimentos em TI proporcionam o máximo retorno possível.
Ajudamos as empresas a arquitetar soluções como esta a toda a hora. Se quiser saber mais sobre como implementar isso você mesmo, inscreva-se em nosso boletim informativo, conecte-se conosco no Twitter ou no LinkedIn ou inscreva-se em nosso canal do YouTube. Além desses guias técnicos, se você ou sua organização estiver pensando em otimizar suas soluções de armazenamento em nuvem e CDN, poderá experimentar as soluções da Linode inscrevendo-se para obter US$ 100 em créditos gratuitos.
Comentários