Ir al contenido principal
BlogInformáticaCómo un cliente redujo costes al migrar de EFS a Object Storage

Cómo un cliente redujo costes al migrar de EFS a Object Storage

MigraciónEFStoOBJ_BlogHero_FBLI

En la computación en nube, gestionar la escala es tanto un objetivo como un reto. Esto es especialmente cierto para las empresas que necesitan distribuir actualizaciones de software o firmware de forma inalámbrica (OTA). El reto consiste en gestionar el volumen y garantizar que las cargas y descargas sean seguras, eficientes y puntuales. Una configuración común para algo así es utilizar un sistema de archivos virtual montado en un servidor de nube privado con una CDN para distribuir el software globalmente. Si bien esta es una configuración decente en la que muchas empresas han confiado para ayudar a escalar su distribución, ¿cómo equilibrar esto con la reducción de costes? Esto no es sólo un escenario hipotético, muchas empresas se enfrentan a retos similares, incluyendo un cliente nuestro de electrónica que necesitaba distribuir actualizaciones de firmware OTA a millones de televisores inteligentes en todo el mundo.

La distribución de este tipo de software conlleva grandes riesgos. Estas actualizaciones pueden incluir nuevas funciones, mejoras de la interfaz de usuario, parches de seguridad o mejoras de rendimiento. Una empresa que gestione actualizaciones OTA debe asegurarse de que, si decenas de miles de clientes actualizan sus televisores al mismo tiempo, la solución pueda gestionar la carga de forma eficaz sin costes ni gastos adicionales. No se trata de un reto único. Miles de empresas utilizan OTA para sus productos y software.

En el caso de nuestro cliente, el fabricante utilizó inicialmente varios servicios diferentes para gestionarlo: Content Delivery Network (CDN) de Akamai para la distribución global, Elastic Compute Cloud (EC2) deAWS para la potencia de cálculo, Elastic Load Balancer para el tráfico entrante y Elastic File System (EFS) para almacenar y gestionar los archivos de firmware. Esta configuración se construyó para manejar inmensas escalas de distribución de datos en todo el mundo. Sin embargo, también conllevaba un precio elevado, sobre todo por los costes de salida.

AWSEFS era una parte integral de las operaciones del fabricante que les permitía almacenar y gestionar actualizaciones del sistema operativo y del firmware de forma centralizada, así como distribuirlas de forma eficiente a nivel mundial mediante la integración con EC2 y Elastic Load Balancer. Sin embargo, el coste asociado a EFS, especialmente cuando se trataba de transferencias de datos a gran escala fuera de las redes de AWS, se convirtió en una preocupación creciente.

El aumento de los costes asociados al EFS, sobre todo en concepto de tasas de salida de AWS, llevó a reevaluar el sistema de almacenamiento y distribución de las actualizaciones de sus televisores inteligentes. Esto marcó un momento crucial en la estrategia del fabricante para gestionar los costes y, al mismo tiempo, mantener su sólido sistema de distribución global mediante el cambio de EFS a Linode Object Storage .

Solución

Object Storage Ser más rentable no fue suficiente para convencer a este cliente de migrar desde EFS. También tenía que integrarse perfectamente con su flujo de trabajo existente. Lo consiguieron con la ayuda del equipo de asistencia de Akamai y algunas herramientas de código abierto.

Dentro de su arquitectura, crearon un bucket primario de Object Storage en la región de Asia-Pacífico y Japón y un segundo bucket en Estados Unidos para que sirviera de copia de seguridad. Esta redundancia evita la pérdida de datos y garantiza que la disponibilidad de las actualizaciones de firmware se mantenga constante aunque falle el bucket de almacenamiento primario. Los dos buckets se sincronizan mediante rclone, una utilidad de código abierto conocida por su eficacia en la transferencia y sincronización de archivos. Esta herramienta fue fundamental para garantizar que ambos buckets pudieran servir como servidores de origen fiables para la CDN.

La transición supuso un importante reto técnico: sustituir su solución de almacenamiento actual (EFS) por un nuevo protocolo de almacenamiento (Object Storage) sin interrumpir su flujo de trabajo. EFS y Object Storage son fundamentalmente diferentes en su arquitectura y funcionalidad. EFS proporciona una interfaz y una semántica de sistema de archivos, esenciales para muchas aplicaciones que requieren un sistema de archivos tradicional. Por el contrario, Object Storage, se accede a través de una API web, que no soporta de forma nativa las operaciones del sistema de archivos. Como resultado, no se puede simplemente cambiar EFS por Object Storage.

Para superar esto, aprovechamos S3FS, una herramienta de código abierto que simula una interfaz de sistema de archivos sobre la API S3 . S3FS nos permitió "montar" los buckets de Object Storage en las instancias EC2 existentes del fabricante, por lo que se comporta como EFS. Este enfoque permitió a las aplicaciones y procesos existentes interactuar con Object Storage como si se tratara de un sistema de archivos tradicional, minimizando los cambios necesarios en el código de la aplicación y reduciendo el riesgo de errores durante la transición.

Esta arquitectura (arriba) no sólo agiliza el proceso de actualización del software en millones de dispositivos de todo el mundo, sino que también supone un importante ahorro de costes. Al pasar de AWS's Elastic File System (EFS) a Object Storage, la empresa redujo drásticamente los costes de almacenamiento, ya que Object Storage resultó ser más de 15 veces menos caro por GB que EFS. También se redujeron en un 90% los costes de salida, lo que supuso una mejora sustancial con respecto al entorno AWS anterior. Estos ahorros ilustran la eficacia de la nueva solución de almacenamiento a la hora de gestionar tanto la eficiencia operativa como la rentabilidad.

No se trataba sólo de una actualización técnica, sino de una realineación con los objetivos de eficiencia, escalabilidad y gestión de costes del fabricante. Al adoptar Object Storage e integrarlo sin problemas (con la ayuda de herramientas como rclone y S3FS), el fabricante pudo reducir significativamente sus costes operativos sin comprometer la fiabilidad o la velocidad de su distribución global de firmware. Este caso práctico demuestra cómo las decisiones en materia de adopción de tecnología pueden repercutir significativamente en los resultados de una organización.

Análisis crítico de la rentabilidad

Al examinar la transición de AWS a Linode a través de Akamai, la decisión aparece inicialmente como una clara ganancia en ahorro de costes. Sin embargo, una inmersión más profunda en las estructuras de costes y la comparación de productos revela algunos matices. He aquí algunos puntos clave de la decisión a tener en cuenta:

  1. AWS S3 vs. Linode Object Storage : La arquitectura inicial canalizaba un tráfico de salida considerable a través del Elastic Load Balancer hacia la CDN de Akamai. Dada esta estructura, el uso de Object Storage resultó ser más rentable que AWS S3 debido a unos costes de salida significativamente inferiores. Sin embargo, si se combina con AWS Cloudfront, los costes de salida para el almacenamiento de objetos podrían ser nulos.
  2. AWS Cloudfront frente a Akamai CDN: La elección de seguir con Akamai en lugar de AWS Cloudfront estuvo influenciada por la necesidad de minimizar los cambios en la arquitectura. La organización valoró el rendimiento, la fiabilidad y la asistencia probados de Akamai, así como la flexibilidad que proporciona el uso de varios proveedores de nube.

Para cuantificar el impacto financiero, consideremos un escenario hipotético en el que, mensualmente, un cliente gestiona 50 TB de datos almacenados con 100 TB de transferencias salientes. A continuación se muestra un desglose de costes simplificado para AWS EFS, AWS S3 , y Linode Object Storage :

Solución de almacenamientoCálculoCoste 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
Linode Object Storage(0,02 $/GB * 50.000GB) + (0,005 $/GB * 49.000GB)$1,245

(Nota: las comparaciones holísticas de precios son difíciles. Esto sólo tiene en cuenta los costes de almacenamiento y ancho de banda para el almacenamiento de archivos, pero no tiene en cuenta la CDN. También cabe mencionar que algunos proveedores ofrecen tarifas más reducidas a clientes con un volumen excepcionalmente alto).

Veamos ahora los costes comparativos asociados al almacenamiento y la salida de estos servicios en la nube (Nota: los precios se basan en el coste en el momento de escribir esto).

Tipo de servicioDescripción de costesPrecioNotas
Almacenamiento EFSPor GB al mes0,30 $/GBAPI intuitiva y fácil de usar, pero coste elevado. Considere alternativas para grandes volúmenes
S3 AlmacenamientoPor GB al mes para los primeros 50 TB0,023 $/GBEconómico para el almacenamiento de grandes volúmenes de datos
S3 SalidaPor GB para los primeros 10 TB0,09 $/GBMás costoso para una alta transferencia de datos, a menos que se combine con Cloudfront. 
Por GB para los próximos 40 TB0,085 $/GBCostes variables en función del volumen
Por GB para los próximos 100 TB0,07 $/GBMejores tarifas para transferencias de mayor volumen
Linode AlmacenamientoPor GB al mes0,02 $/GBMás rentable para el almacenamiento
Linode SalidaPrimero 1 TB gratis, luego por GB0,005 $/GBAhorro significativo en la salida de datos, maximiza la eficiencia presupuestaria

En este análisis, el uso de Object Storage supone aproximadamente 1/15 del coste de la solución original con AWS EFS, y alrededor de 1/7 del coste del uso de AWS S3 (suponiendo que no se utilice AWS Cloudfront para compensar las tasas de salida).

Conclusión

Esta comparación de costes ilustra el importante ahorro conseguido al cambiar a Linode Object Storage . También pone de relieve la importancia de adaptar las soluciones en la nube a las características específicas de los patrones de tráfico y los requisitos de la red de distribución de contenidos (CDN) de una empresa. Cuando las empresas analizan sus estrategias de uso y distribución de datos, pueden descubrir importantes oportunidades de ahorro de costes que, de otro modo, podrían pasarse por alto.

La decisión de cambiar de solución de almacenamiento no se tomó a la ligera, sino que estuvo respaldada por una evaluación detallada de los requisitos operativos y los objetivos financieros de la empresa. Al conocer el volumen de datos gestionados, la frecuencia de acceso a los datos y la distribución geográfica de los usuarios, la empresa pudo identificar Linode como la solución más rentable que, además, satisfacía sus necesidades. Este tipo de toma de decisiones informada es fundamental en las arquitecturas de nube, donde los costes pueden variar drásticamente en función del tipo de almacenamiento, los volúmenes de transferencia de datos y las frecuencias de acceso.

Aunque los programadores y arquitectos deben centrarse en el rendimiento y la escalabilidad de una solución, también deben tener en cuenta el impacto financiero en las empresas para las que trabajan. Las soluciones no sólo deben cumplir los requisitos técnicos, sino también alinearse con las estrategias financieras más amplias de una organización. De este modo se pueden evitar excesos presupuestarios y garantizar que las inversiones en TI ofrezcan el máximo rendimiento posible.

Ayudamos a las empresas a diseñar soluciones de este tipo. Si desea obtener más información sobre cómo implementar esto usted mismo, suscríbase a nuestro boletín, conéctese con nosotros en Twitter o LinkedIn, o suscríbase a nuestro canal de YouTube. Además de estas guías técnicas, si usted o su organización están pensando en optimizar sus soluciones de almacenamiento en la nube y CDN, puede probar las soluciones de Linoderegistrándose para obtener 100 dólares en créditos gratuitos.


Comentarios

Dejar una respuesta

Su dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *.