Escrito por Viraj Jasani y Andrew Purtell
Los datos son el motor de las operaciones de Salesforce, ayudando a nuestros clientes a tomar mejores decisiones a diario. El equipo de almacenamiento de Big Data (BDS), una parte clave de la organización de ingeniería de Salesforce, despliega posiblemente una de las mayores huellas de producción de bases de datos distribuidas. Esta infraestructura se basa en la combinación de HBase y Phoenix de código abierto, diseñadas para permitir el acceso aleatorio de lectura y escritura a petabytes de datos a gran escala, alto rendimiento, baja latencia y en tiempo real. Se trata de una capacidad inalcanzable para las bases de datos relacionales tradicionales
En 2014, BDS describió sus motivaciones en detalle, encapsulando cómo HBase y Phoenix resolvieron muchos problemas técnicos durante el viaje de más de 10 años del equipo. Una parte importante de este viaje implicó el desarrollo de una estrategia para actualizar la infraestructura. A la escala de Salesforce, donde los clientes exigen un funcionamiento ininterrumpido y sin interrupciones las 24 horas del día, los 7 días de la semana, surgieron desafíos significativos.
Siga leyendo para explorar cómo BDS impulsó la actualización de HBase 1 a HBase 2 con un impacto mínimo para los clientes de Salesforce.
¿Por qué actualizar a HBase 2?
Durante muchos años, la ejecución de HBase 1 y Phoenix 4 presentaba problemas mínimos. Sin embargo, una importante actualización a HBase 2 y Phoenix 5 fue perseguido por varias razones, tales como:
- Disponibilidad. HBase, una base de datos distribuida fuertemente consistente (CP de teorema CAP), carecía de alta disponibilidad durante las transiciones de regiones de tablas (véase nuestro post existente sobre los detalles de las transiciones de regiones). HBase 2 rediseñó significativamentelos flujos de trabajo de asignación de regiones eliminando su dependencia de Zookeeper. Esto aumentó la disponibilidad general del almacén de datos e impulsó la estabilidad de la infraestructura al tiempo que mantuvo la confianza de los clientes.
- Necesidad de velocidad. HBase 2 mejoró el rendimiento de las solicitudes de escritura con un diseño que escribe en varias réplicas de los archivos Write-Ahead-Log (WAL) de forma asíncrona, algo clave para las aplicaciones que utilizan una base de datos y que ofrece un alto rendimiento
- Baja latencia. Siendo una base de datos sensible a la latencia, BDS encontró problemas de largas pausas GC a veces. HBase 2 y Phoenix 5 proporcionan soporte de compilación y tiempo de ejecución para Java 11. Utilizar Java junto con Shenandoah GC en producción ayudó a reducir la latencia.
- Menos hilos ociosos. Durante la producción, BDS informó regularmente de un mayor número de hilos ociosos que estaban destinados a iniciar Remote-Procedure Calls (o RPC). HBase 2 soporta un marcoNetty asíncrono, impulsado por eventos, basado en socket no bloqueante para reducir el consumo de recursos y mejorar el rendimiento durante las llamadas RPC.
- Correcciones rápidas de seguridad. Mantenerse cerca de las últimas versiones importantes de código abierto impulsa la resolución rápida y eficaz de las vulnerabilidades de seguridad de terceros. El estado de fin de vida de la línea de lanzamiento de HBase 1 justificó aún más el paso a HBase 2.
- Correcciones rápidas de seguridad
¿A qué retos se enfrentó el BDS?
Independientemente de la actualización, maximizar la disponibilidad para los clientes es un enfoque clave. Mantener una disponibilidad del 99,999% es fundamental, por lo que cualquier error o cambio de comportamiento es una prioridad a resolver. Consecuentemente, cualquier actualización mayor, menor, o parche de HBase/Phoenix significaba que BDS tenía que mantener la disponibilidad tanto durante como después de la finalización de la actualización continua.
Salesforce ha participado en un proyecto de varios años para migrar de sus propios centros de datos privados a la infraestructura de nube pública (más detalles aquí), y la flexibilidad de la infraestructura de nube pública puede mejorar en gran medida la capacidad del equipo de BDS para realizar una migración sin problemas mediante el aprovechamiento de recursos adicionales para construir una réplica exacta del clúster dado, seguido de una conmutación del tráfico de clientes del clúster en ejecución de la versión antigua al nuevo clúster.
Sin embargo, a partir de este momento, un número significativo de clústeres todavía se están ejecutando en centros de datos de primera parte. Por lo tanto, la actualización de HBase 1 a HBase 2, junto con Phoenix 4 a Phoenix 5, viene con un desafío crítico: tenía que llevarse a cabo sin ningún tiempo de inactividad, independientemente de la infraestructura subyacente.
Cambios de clúster
Como ejemplo de escala, los clústeres de producción con aproximadamente 300 nodos tardan más de 5 horas en completar la actualización continua de todos los componentes. La significativa re-arquitectura con HBase 2 hace imposible realizar la actualización sin tiempo de inactividad. BDS ha trabajado con la comunidad de código abierto para encontrar soluciones a este problema, ya que se trata de un reto único para organizaciones a la escala de Salesforce
¿Cómo se preparó BDS?
Cualquier objetivo complejo conlleva importantes compromisos. BDS evaluó metódicamente las funcionalidades básicas de HBase/Phoenix, determinando si las actividades de fondo no críticas podían desactivarse temporalmente durante la actualización. Este proceso duró dos años y se caracterizó por una dedicación inquebrantable a la entrega de un despliegue de producción sin problemas, lo que implicó varios pasos clave
La estabilización de las compilaciones fue una prioridad inicial, que garantizó la estabilidad de HBase y los proyectos posteriores de Phoenix. Para ello, se verificó en profundidad la compilación del código y se probó con éxito toda la compilación de CI
El desafío más difícil surgió cuando BDS necesitó evaluar varias compensaciones y desarrollar una estrategia para ejecutar una actualización continua sin problemas, eliminando el tiempo de inactividad. Esto requirió mucho tiempo, el desarrollo de una secuencia exacta de pasos que lograron los objetivos, manteniendo el servicio, mientras que también trabaja en torno a los problemas de compatibilidad en los estados intermedios.
A medida que el equipo se encontraba con problemas relacionados con las diferencias en los esquemas de las tablas del sistema entre las dos versiones, reconocía la posible imposibilidad de llevar a cabo la tarea. Sin embargo, BDS lo resolvió con éxito mediante la implementación de un procedimiento que podía actualizar los esquemas sin alterar la compatibilidad entre los clientes antiguos y los servidores nuevos.
El equipo de BDS se dio cuenta de que la tarea era imposible
Además, al encontrarse con otros obstáculos, BDS contribuyó con sus correcciones a la base de código de fuente abierta.
Además, como utilizaban HBase y Phoenix, el equipo se aseguró de que los clientes que utilizaban conexiones JDBC para consultar datos pudieran seguir realizando operaciones CRUD con un mínimo de reintentos durante la actualización.
Cuidado con los datos
Por último, para gestionar la actualización sin tiempo de inactividad, fue bastante crucial para BDS hacer hincapié en la construcción de un procedimiento que facilitara la transición de las asignaciones de regiones de tabla «basadas en Zookeeper» a «sin Zookeeper», un requisito previo crítico para su actualización.
Actualización sin tiempo de inactividad
El equipo también realizó rigurosas pruebas de rendimiento durante todo el ciclo de vida del proyecto. Ser uno de los miembros activos de la comunidad de código abierto también les ayudó a conseguir una mejor tracción en las correcciones de errores críticos que contribuyeron.
Un vistazo a HBase 2 pre-requisito + actualización pasos de procedimiento. (detalles aquí)