De alguna manera, históricamente, la industria de TI se divide en dos bandos condicionales por cualquier motivo: los que están "a favor" y los que están "en contra". Además, el tema de las disputas puede ser completamente arbitrario. ¿Qué sistema operativo es mejor: Win o Linux? ¿En un teléfono inteligente Android o iOS? ¿Debería guardar todo en las nubes o colocarlo en un almacenamiento RAID en frío y guardar los tornillos en una caja fuerte? ¿La gente de PHP tiene derecho a ser llamados programadores? Estas disputas son, en ocasiones, de carácter exclusivamente existencial y no tienen más fundamento que el interés deportivo.
Dio la casualidad de que con la llegada de los contenedores y toda esta querida cocina con Docker y K8 condicionales, comenzaron los debates "a favor" y "en contra" del uso de nuevas capacidades en varias áreas del backend. (Hagamos una reserva de antemano de que, aunque Kubernetes se indicará con mayor frecuencia como orquestador en esta discusión, la elección de esta herramienta en particular no es de fundamental importancia. En su lugar, puede sustituirla por cualquier otra que le parezca más conveniente y familiar). .)
Y, al parecer, esto sería una simple disputa entre dos caras de la misma moneda. Tan insensato y despiadado como el eterno enfrentamiento entre Win y Linux, en el que las personas adecuadas existen en algún punto intermedio. Pero en el caso de la contenerización, no todo es tan sencillo. Por lo general, en tales disputas no hay un lado correcto, pero en el caso de "usar" o "no usar" contenedores para almacenar bases de datos, todo se pone patas arriba. Porque en cierto sentido tanto los partidarios como los detractores de este enfoque tienen razón.
Lado positivo
El argumento del Lado Luminoso se puede describir brevemente en una frase: "¡Hola, 2k19 está afuera de la ventana!" Suena a populismo, claro, pero si se profundiza en la situación en detalle, tiene sus ventajas. Vamos a solucionarlos ahora.
Digamos que tienes un gran proyecto web. Podría haberse construido inicialmente sobre la base de un enfoque de microservicio, o en algún momento llegar a él a través de un camino evolutivo; de hecho, esto no es muy importante. Dividió nuestro proyecto en microservicios separados, configuró la orquestación, el equilibrio de carga y el escalado. Y ahora, con la conciencia tranquila, bebes un mojito en una hamaca durante los efectos de habra en lugar de levantar a los servidores caídos. Pero en todas las acciones debes ser coherente. Muy a menudo, sólo la aplicación misma (el código) está en contenedores. ¿Qué más tenemos además del código?
Así es, datos. El corazón de cualquier proyecto son sus datos: pueden ser un DBMS típico (MySQL, Postgre, MongoDB) o un almacenamiento utilizado para la búsqueda (ElasticSearch), un almacenamiento clave-valor para el almacenamiento en caché (por ejemplo, redis, etc.). Hablaremos sobre las opciones de implementación de backend corruptas cuando la base de datos falla debido a consultas mal escritas y, en su lugar, hablaremos sobre cómo garantizar la tolerancia a fallas de esta misma base de datos bajo la carga del cliente. Después de todo, cuando colocamos nuestra aplicación en contenedores y le permitimos escalar libremente para procesar cualquier cantidad de solicitudes entrantes, esto naturalmente aumenta la carga en la base de datos.
De hecho, el canal para acceder a la base de datos y el servidor en el que se ejecuta se convierten en el ojo de la aguja de nuestro hermoso backend en contenedores. Al mismo tiempo, el motivo principal de la virtualización de contenedores es la movilidad y flexibilidad de la estructura, lo que nos permite organizar la distribución de las cargas punta en toda la infraestructura disponible de la manera más eficiente posible. Es decir, si no colocamos en contenedores y no implementamos todos los elementos existentes del sistema en todo el clúster, estamos cometiendo un error muy grave.
Es mucho más lógico agrupar no sólo la aplicación en sí, sino también los servicios responsables de almacenar datos. Al agrupar e implementar servidores web que funcionan de forma independiente y distribuyen la carga entre ellos en k8, ya estamos resolviendo el problema de la sincronización de datos: los mismos comentarios en las publicaciones, si tomamos como ejemplo algún medio o plataforma de blogs. En cualquier caso, tenemos una representación intra-clúster, incluso virtual, de la base de datos como un Servicio Externo. La cuestión es que la base de datos en sí aún no está agrupada: los servidores web desplegados en el cubo toman información sobre los cambios de nuestra base de datos de combate estática, que rota por separado.
¿Sientes una trampa? Usamos k8s o Swarm para distribuir la carga y evitar fallas en el servidor web principal, pero no hacemos esto con la base de datos. Pero si la base de datos falla, entonces toda nuestra infraestructura agrupada no tiene sentido: ¿de qué sirven las páginas web vacías que devuelven un error de acceso a la base de datos?
Por eso es necesario agrupar no sólo los servidores web, como se suele hacer, sino también la infraestructura de la base de datos. Sólo así podremos garantizar una estructura que funcione plenamente en un solo equipo, pero al mismo tiempo independiente entre sí. Además, incluso si la mitad de nuestro backend "colapsa" bajo carga, el resto sobrevivirá, y el sistema de sincronización de las bases de datos entre sí dentro del clúster y la capacidad de escalar e implementar nuevos clústeres sin cesar ayudarán a alcanzar rápidamente la capacidad requerida. si tan solo hubiera racks en el centro de datos.
Además, el modelo de base de datos distribuida en clusters permite llevar esta misma base de datos a donde sea necesaria; Si hablamos de un servicio global, entonces es bastante ilógico crear un clúster web en algún lugar del área de San Francisco y al mismo tiempo enviar paquetes al acceder a una base de datos en la región de Moscú y viceversa.
Además, la contenedorización de la base de datos le permite construir todos los elementos del sistema en el mismo nivel de abstracción. Lo que, a su vez, permite que los desarrolladores administren este mismo sistema directamente desde el código, sin la participación activa de los administradores. Los desarrolladores pensaron que se necesitaba un DBMS independiente para el nuevo subproyecto. ¡Fácil! escribió un archivo yaml, lo cargó en el clúster y listo.
Y por supuesto, el funcionamiento interno se simplifica enormemente. Dime, ¿cuántas veces has cerrado los ojos cuando un nuevo miembro del equipo metió las manos en la base de datos de combate para trabajar? ¿Cuál, de hecho, es el único que tienes y está girando ahora mismo? Por supuesto, aquí todos somos adultos, y en algún lugar tenemos una copia de seguridad nueva, y aún más lejos, detrás del estante con los pepinos de la abuela y los esquís viejos, otra copia de seguridad, tal vez incluso en una cámara frigorífica, porque su oficina ya estuvo en llamas una vez. Pero de todos modos, cada presentación de un nuevo miembro del equipo con acceso a la infraestructura de combate y, por supuesto, a la base de datos de combate es una gran cantidad de validol para todos los que nos rodean. Bueno, ¿quién lo conoce, un novato, tal vez sea cruzado? Da miedo, estarás de acuerdo.
La contenerización y, de hecho, la topología física distribuida de la base de datos de su proyecto ayuda a evitar esos momentos de validación. ¿No confías en un novato? ¡DE ACUERDO! Démosle su propio clúster para trabajar y desconectemos la base de datos de los otros clústeres: sincronización solo mediante pulsación manual y rotación sincrónica de dos claves (una para el líder del equipo y la otra para el administrador). Y todos están felices.
Y ahora es el momento de oponernos a la agrupación de bases de datos.
Lado oscuro
Al argumentar por qué no vale la pena contener la base de datos y continuar ejecutándola en un servidor central, no nos rebajaremos a la retórica de ortodoxias y declaraciones como "los abuelos manejaban bases de datos en hardware, ¡y nosotros también!". En lugar de ello, intentemos encontrar una situación en la que la contenedorización realmente produzca dividendos tangibles.
De acuerdo, los proyectos que realmente necesitan una base en un contenedor se pueden contar con los dedos de una mano y no es el mejor operador de fresadora. En su mayor parte, incluso el uso de k8s o Docker Swarm es redundante; muy a menudo se recurre a estas herramientas debido a la exageración general de las tecnologías y las actitudes del "todopoderoso" en la persona de los géneros para empujar todo hacia el Nubes y contenedores. Pues porque ahora está de moda y todo el mundo lo hace.
En al menos la mitad de los casos, usar Kubernetis o simplemente Docker en un proyecto es redundante. El problema es que no todos los equipos o empresas de outsourcing contratados para mantener la infraestructura del cliente son conscientes de ello. Es peor cuando se imponen contenedores, porque al cliente le cuesta una cierta cantidad de monedas.
En general, existe la opinión de que la mafia Docker/Cube está aplastando estúpidamente a los clientes que subcontratan estos problemas de infraestructura. Después de todo, para trabajar con clústeres, necesitamos ingenieros que sean capaces de hacerlo y que comprendan en general la arquitectura de la solución implementada. Una vez ya describimos nuestro caso en la publicación Republic: allí capacitamos al equipo del cliente para trabajar en las realidades de Kubernetis y todos quedaron satisfechos. Y fue decente. A menudo, los "implementadores" de k8s toman como rehén la infraestructura del cliente, porque ahora sólo ellos entienden cómo funciona todo allí; no hay especialistas del lado del cliente.
Ahora imagina que de esta forma subcontratamos no sólo la parte del servidor web, sino también el mantenimiento de la base de datos. Dijimos que BD es el corazón y la pérdida del corazón es fatal para cualquier organismo vivo. En definitiva, las perspectivas no son las mejores. Entonces, en lugar de exagerar Kubernetis, muchos proyectos simplemente no deberían preocuparse por la tarifa normal de AWS, que resolverá todos los problemas con la carga en su sitio/proyecto. Pero AWS ya no está de moda y los alardes valen más que el dinero; lamentablemente, también en el entorno de TI.
DE ACUERDO. Quizás el proyecto realmente necesite agrupación, pero si todo está claro con las aplicaciones sin estado, ¿cómo podemos organizar una conectividad de red decente para una base de datos agrupada?
Si hablamos de una solución de ingeniería perfecta, que es la transición a k8s, entonces nuestro principal dolor de cabeza es la replicación de datos en una base de datos agrupada. Algunos DBMS son inicialmente bastante leales a la distribución de datos entre sus instancias individuales. Muchos otros no son tan acogedores. Y muy a menudo el argumento principal a la hora de elegir un DBMS para nuestro proyecto no es la capacidad de replicarlo con costes mínimos de recursos e ingeniería. Especialmente si el proyecto no se planeó inicialmente como un microservicio, sino que simplemente evolucionó en esta dirección.
Creemos que no es necesario hablar de la velocidad de las unidades de red: son lentas. Aquellos. Todavía no tenemos una oportunidad real, si sucede algo, de reiniciar una instancia de DBMS en algún lugar donde haya más, por ejemplo, potencia de procesador o RAM libre. Muy rápidamente nos toparemos con el rendimiento del subsistema de disco virtualizado. En consecuencia, el DBMS debe estar fijado a su propio conjunto personal de máquinas ubicadas muy cerca. O es necesario enfriar de alguna manera por separado una sincronización de datos suficientemente rápida para las supuestas reservas.
Continuando con el tema de los sistemas de archivos virtuales: los Docker Volumes, lamentablemente, no están exentos de problemas. En general, en una cuestión como el almacenamiento de datos fiable a largo plazo, me gustaría conformarme con los esquemas técnicamente más sencillos. Y agregar una nueva capa de abstracción desde el FS del contenedor al FS del host principal es un riesgo en sí mismo. Pero cuando el funcionamiento del sistema de soporte de contenedores también encuentra dificultades con la transmisión de datos entre estas capas, entonces es realmente un desastre. Por el momento, la mayoría de los problemas conocidos por la humanidad progresista parecen haber sido erradicados. Pero ya sabes, cuanto más complejo es el mecanismo, más fácil se rompe.
A la luz de todas estas "aventuras", es mucho más rentable y más fácil mantener la base de datos en un solo lugar, e incluso si necesita contener la aplicación, déjela ejecutarse por sí sola y, a través del portal de distribución, reciba comunicación simultánea con el base de datos, que será leída y escrita sólo una vez y en un solo lugar. Este enfoque reduce al mínimo la probabilidad de errores y desincronización.
¿A qué nos dirigimos? Además, la contenedorización de bases de datos es apropiada cuando existe una necesidad real. No puedes llenar una base de datos de aplicaciones completa y hacerla girar como si tuvieras dos docenas de microservicios; no funciona de esa manera. Y esto debe entenderse claramente.
En lugar de salida
Si está esperando una conclusión clara sobre "virtualizar la base de datos o no", entonces lo decepcionaremos: no estará aquí. Porque a la hora de crear cualquier solución de infraestructura hay que guiarse no por la moda y el progreso, sino, ante todo, por el sentido común.
Hay proyectos para los que los principios y herramientas que vienen con Kubernetis encajan perfectamente, y en esos proyectos hay paz al menos en el área backend. Y hay proyectos que no necesitan contenedores, sino una infraestructura de servidor normal, porque fundamentalmente no pueden reescalarse al modelo de clúster de microservicios, porque caerán.
Fuente: habr.com