¿Por qué las organizaciones deben replicar sus datos sobre varios clusters para evitar pérdidas irreparables?

Hacer una copia de seguridad de los datos informáticos es un consejo que todos hemos dado y recibido si se quiere evitar que un problema inesperado nos haga perder información valiosa. Para las empresas y organizaciones ese consejo es doblemente válido.
En el mundo de Apache Kafka, la preservación de los datos de posibles pérdidas críticas es inseparable de un despliegue multicluster y cross-data center.

De hecho, este modo de actuar se está convirtiendo en la norma más que en la excepción. Cada vez más las organizaciones se dan cuenta de que para evitar el tiempo de inactividad o la pérdida de datos en Kafka, además de la gestión nativa de fallos -como los problemas con un disco o la red -es necesario un despliegue en varios clusters o clouds para sobrevivir a la interrupción de uno de estos clusters. Aunque cada vez más organizaciones se dan cuenta de que es una buena idea, cada empresa tiene sus necesidades específicas y por eso tienen que elegir el modo que mejor se adapta a ellas.

Hay que equilibrar la complejidad con la posibilidad de asumir una ligera pérdida de datos

Las transacciones empresariales críticas requieren failover y recuperación en caso de incidencia grave, como podría ser la interrupción de un centro de datos o de una región en el cloud. Este tipo de fallos es mucho más común de lo que parece. Por ello, es importante que el “backup” se empiece a entender como una inversión necesaria para el buen funcionamiento del negocio, y no tanto como un gasto de explotación añadido. A día de hoy, aún el 80% de las compañías no realiza copias de seguridad de sus datos. Si nadie ya pone en duda la relevancia de invertir en ciberseguridad, en este caso, proteger el data de otras incidencias debería de ser igualmente importante.

Las soluciones para la recuperación de datos en caso de incidencia grave es es mucho más sencilla de lo que parece: basta con una réplica en tiempo real entre dos cluster de Kafka independientes en data centers, regiones del cloud o incluso dos proveedores de cloud separados. Normalmente, las aplicaciones cambian a otro cluster solo si se produce un incidente. La continuidad de la actividad está garantizada, pero este sistema tiene la desventaja de que la replicación entre los clusters se produce de forma asíncrona y pueden perderse algunos mensajes. Solo sería válido para organizaciones que se puedan “permitir” perder una cantidad pequeña de datos.

Existe una solución más compleja que evita la pérdida de datos: los stretched cluster de Kafka en varias regiones, que funcionan como una única implementación en diferentes centros de datos o regiones del cloud. Sus ventajas son que no se produce periodo de inactividad o pérdidas de datos, incluso en caso de incidente grave. Eso sí, sólo es recomendable si se cumplen requisitos como una latencia buena y estable entre regiones, ya que el precio que se paga es que nuestra latencia de escritura estará condicionada por la existente entre los centros de datos.

El ejemplo de Siemens: integración híbrida entre el data center y la nube

El gigante Siemens es uno de los usuarios de otra de las soluciones posibles: la híbrida entre nube y centro de datos. Mientras el cluster de Kafka en el data center da servicio a las aplicaciones existentes, como una base de datos, un mainframe o un sistema ERP local, otro cluster de Kafka en el cloud se conecta a sistemas SaaS, microservicios nativos del cloud y plataformas de análisis. Entre ambos clusters, y de manera transparente para el usuario final, los datos se distribuyen y sirven allí dónde sea necesario.

Siemens primero empezó migrando su sistema SAP, lo que incrementó la efectividad de sus operaciones. Posteriormente pasó a un sistema Kafka on-premises a Confluent Cloud con Confluent Replicator. La integración de Salesforce a través de Kafka Connect fue el primer paso de la estrategia en la nube de Siemens. Cada vez son más los proyectos y aplicaciones que se suman al viaje del streaming de datos, ya que es fácil aprovechar el flujo de eventos y conectarlo a otras herramientas, API y productos SaaS una vez creada la canalización de streaming inicial.

Los caminos y ritmos para estas arquitecturas multicluster son variadas y adaptables a cada organización, y el hecho de que muchas organizaciones lo adopten es una muestra de que es el buen camino. Además hay muchas herramientas en el mercado para la replicación entre cluster de Kafka: desde MirrorMaker 2, de código abierto y que forma parte de Apache Kafka, a otras comerciales más avanzadas aportan ventajas en términos de facilidad de uso y reducción coste como Confluent Cluster Linking. Es decir, que están al alcance de cualquier organización que quiera.

Eso sí, como siempre, hay que tener en cuenta que ni siquiera las mejores tecnologías por sí solas consiguen que un proyecto Kafka multicluster crítico tenga éxito, por lo que lo mejor es recurrir a la ayuda de expertos de confianza que realizan proyectos similares a diario para comprender todas las mejores prácticas y el equilibrio entre latencia y seguridad de los datos.