De alguna manera, sucedió históricamente que la industria de TI, por cualquier motivo, se divide en dos campos condicionales: a favor y en contra. Además, el tema de controversia puede ser absolutamente arbitrario. ¿Qué sistema operativo es mejor: Win o Linux? ¿En un teléfono inteligente Android o iOS? ¿Mantener todo en las nubes o cargarlo en un almacenamiento RAID frío y poner tornillos en una caja fuerte? ¿Los schnicks de PHP tienen derecho a ser llamados programadores? Estas disputas son, a veces, exclusivamente de naturaleza existencial y no tienen otra base además del interés deportivo.
Dio la casualidad de que con el advenimiento de los contenedores y toda esta amada cocina con estibador y k8 condicional, las disputas a favor y en contra comenzaron a usar nuevas oportunidades en varias áreas del backend. (Haremos una reserva por adelantado que, aunque la mayoría de las veces Kubernetes será indicado como un orquestador en esta discusión, la elección de este instrumento no importa. En cambio, puede sustituirlo por otro que le parezca más conveniente y familiar).
Y, al parecer, sería un simple argumento sobre las dos caras de la misma moneda. Tan insensato y despiadado como la eterna confrontación Win vs Linux, en la que las personas adecuadas existen para sí mismas en algún punto intermedio. Eso es solo en el caso de la contenedorización no es tan simple. Por lo general, en tales disputas no hay un lado correcto, pero en el caso de los contenedores "aplicar" o "no aplicar" para almacenar la base de datos, todo se pone patas arriba. Porque, en cierto sentido, tanto los partidarios como los oponentes de este enfoque tienen razón.
Lado bueno
Puede describir brevemente los argumentos del lado bueno con una frase: "¡Hola, 2k19 fuera de la ventana!" Suena a populismo, por supuesto, pero si profundizas en la situación en detalle, tiene sus ventajas. Los analizaremos ahora.
Supongamos que tiene un gran proyecto web. Inicialmente podría construirse sobre la base de un enfoque de microservicio, o en algún momento llegó a él de una manera evolutiva; de hecho, esto no es muy importante. Dispersó nuestro proyecto en microservicios separados, configuró la orquestación, el equilibrio de carga, el escalado. Y ahora, con la conciencia tranquila, beba mojito en una hamaca durante un efecto habr, en lugar de levantar los servidores caídos. Pero todas las acciones deben ser consistentes. Muy a menudo solo la aplicación en sí está en contenedores: el código. ¿Qué más tenemos además del código?
Correcto, datos. El corazón de cualquier proyecto son sus datos: puede ser un DBMS típico: MySQL, Postgre, MongoDB o almacenamiento utilizado para la búsqueda (ElasticSearch), almacenamiento de valor clave para el almacenamiento en caché, por ejemplo, redis, etc. Ahora no lo hacemos. hablaremos sobre las opciones de implementación de backend torcidas cuando la base de datos se bloquee debido a consultas mal escritas, y en su lugar hablaremos sobre proporcionar tolerancia a fallas para esta misma base de datos bajo la carga del cliente. De hecho, cuando incluimos nuestra aplicación en contenedores y le permitimos escalar libremente para manejar 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 al servidor en el que gira se convierte en el ojo de la aguja en nuestro hermoso backend contenedorizado. Al mismo tiempo, el motivo principal para la virtualización de contenedores es la movilidad y la plasticidad de la estructura, lo que permite organizar la distribución de la carga máxima en toda la infraestructura disponible de la manera más eficiente posible. Es decir, si no colocamos en contenedores y enrollamos todos los elementos disponibles del sistema en un clúster, cometemos un error muy grave.
Es mucho más lógico agrupar no solo la aplicación en sí, sino también los servicios responsables del almacenamiento de datos. Al agrupar e implementar de forma independiente trabajando y distribuyendo la carga de servidores web en k8s, ya resolvemos el problema de la sincronización de datos: los mismos comentarios para las publicaciones, si tomas algún tipo de plataforma de medios o blog como ejemplo. En cualquier caso, comenzamos una representación intracluster, incluso virtual, de la base de datos como un ExternalService. La pregunta es que la base de datos en sí aún no se ha agrupado: los servidores web implementados en el cubo toman información sobre los cambios de nuestra base de combate estática, que gira por separado.
Siente la trampa? Utilizamos k8s o Swarm para distribuir la carga y evitar la caída del servidor web principal, pero no hacemos esto para la base de datos. Pero, después de todo, si la base de datos se bloquea, entonces, en 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?
Es por eso que no solo los servidores web deben agruparse, como se hace generalmente, sino también la infraestructura de la base de datos. Solo de esta manera podemos asegurarnos de que los elementos de la misma estructura que son completamente operativos en un equipo, pero al mismo tiempo, sean independientes entre sí. Al mismo tiempo, incluso si la mitad de nuestro backend bajo carga "colapsa", el resto sobrevivirá, y el sistema de sincronización de la base de datos entre sí dentro del clúster y la posibilidad de escalado infinito y la implementación de nuevos clústeres ayudarán a alcanzar rápidamente las capacidades requeridas: habría bastidores en el centro de datos .
Además, el modelo de base de datos distribuido en grupos le permite llevar esta misma base de datos a donde se necesita; si estamos hablando de un servicio global, es bastante ilógico torcer un clúster web en algún lugar del área de San Francisco y al mismo tiempo conducir paquetes al acceder a la 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 al mismo nivel de abstracción. Lo que, a su vez, permite administrar este sistema directamente desde el código, por parte de los desarrolladores, sin la participación activa de los administradores. Los desarrolladores pensaron que necesitaban un DBMS separado para un nuevo subproyecto, ¡fácil! escribió un archivo yaml, lo cargó en el clúster y ya está.
Bueno, por supuesto, la operación interna se simplifica enormemente. Dime, ¿cuántas veces has entrecerrado los ojos en los momentos en que un nuevo miembro del equipo metió las manos en la base de datos de combate para trabajar? ¿Cuál, de hecho, está girando en este momento? Por supuesto, todos somos adultos aquí, y en algún lugar tenemos una copia de seguridad nueva, y aún más, detrás de un estante con pepinos de la abuela y esquís viejos, otra copia de seguridad, posiblemente incluso en una cámara frigorífica, porque una vez que su oficina se incendió. Pero aún así, 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 un balde de validol para todos los que lo rodean. Bueno, ¿quién, un novato, sabe, tal vez está entrecerrando los ojos? Miedo, de acuerdo.
La contenedorización y, de hecho, la topología de base de datos física distribuida de su proyecto ayuda a evitar esos momentos válidos. ¿No confías en el novato? Esta bien Levantaremos nuestro propio clúster para él y lo desconectaremos del resto de los clústeres de la base de datos: sincronización solo mediante inserción manual y rotación simultánea de dos teclas (un líder del equipo, el segundo administrador). Y todos están felices.
Y ahora es el momento de cambiar de zapatos en los oponentes de la contenedorización de bases de datos.
Lado oscuro
Argumentando por qué no es necesario contener la base de datos y continuar rotándola en un servidor central, no nos rebajaremos a la retórica de la ortodoxia y las declaraciones como "abuelos convirtieron la base de datos en hardware, ¡y lo haremos!" En cambio, tratemos de llegar a una situación en la que la contenedorización realmente traiga dividendos tangibles.
Debe admitir que los proyectos que realmente necesitan una base en el contenedor se pueden contar con los dedos de una mano como el mejor operador de fresadora. En su mayor parte, incluso el uso mismo de k8s o Docker Swarm es redundante; a menudo recurren a estas herramientas debido a la naturaleza general de la tecnología y las "más poderosas", en la persona de los géneros, para conducir todo a nubes y contenedores. Bueno, porque ahora está de moda y todos lo hacen.
Al menos en la mitad de los casos, usar kubernetis o simplemente un acoplador en un proyecto es redundante. La pregunta es que no todos los equipos o empresas de outsourcing contratados para dar servicio a la infraestructura del cliente son conscientes de esto. Peor: cuando se imponen contenedores, ya que aumenta en una cierta cantidad de monedas para el cliente.
En general, existe la opinión de que el cubo acoplable / mafioso aplasta estúpidamente a los clientes que subcontratan estos problemas de infraestructura. De hecho, para trabajar con clústeres, necesita ingenieros que sean capaces de esto y entiendan la arquitectura de la solución implementada en general. De alguna manera, ya describimos nuestro caso con la edició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 k8 toman como rehenes a la infraestructura del cliente: ahora solo entienden cómo funciona todo allí, no hay especialistas del lado del cliente.
Ahora imagine que de esta manera le damos no solo la parte del servidor web a la subcontratación, sino también el mantenimiento de la base de datos. Dijimos que un DB es un corazón, y la pérdida del corazón es fatal para cualquier organismo vivo. En resumen, las perspectivas no son las mejores. Entonces, en lugar de hype kubernetis, muchos proyectos simplemente no deberían volverse locos con la tarifa normal de AWS, que resolverá todos los problemas con la carga en su sitio web / proyecto. Pero AWS ya no está de moda, y las exhibiciones son más caras que el dinero, desafortunadamente, también en el entorno de TI.
Esta bien Quizás el proyecto realmente necesite agrupamiento, pero si todo está claro con aplicaciones sin estado, ¿cómo podemos organizar una provisión decente de conectividad de red para la base de datos agrupada?
Si estamos hablando de una solución de ingeniería perfecta, que parece ser 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 a menudo, el argumento principal al elegir un DBMS para nuestro proyecto no es la capacidad de replicarse con un mínimo de recursos y costos de ingeniería. Especialmente si el proyecto no se planeó originalmente como un microservicio, sino que simplemente evolucionó en esta dirección.
No necesitamos hablar sobre la velocidad de las unidades de red: son lentas. Es decir todavía no tenemos una posibilidad real, en cuyo caso, actualizar una instancia de DBMS en algún lugar, donde haya más, por ejemplo, capacidades de procesador o RAM libre. Nos encontramos rápidamente con el rendimiento de un subsistema de disco virtualizado. En consecuencia, el DBMS debe clavarse en su propio conjunto personal de máquinas en las proximidades. O bien, es necesario separar de alguna manera la sincronización suficientemente rápida de la sincronización de datos con las reservas estimadas.
Continuando con el tema de FS virtual: Docker Volumes, desafortunadamente, no es fácil. En general, en un caso de almacenamiento de datos confiable a largo plazo, me gustaría administrar con los esquemas técnicos más simples. Y agregar una nueva capa de abstracción del contenedor FS al FS del host principal es un riesgo en sí mismo. Pero cuando también hay dificultades para transmitir datos entre estas capas en el funcionamiento del sistema de soporte de contenedorización, entonces es realmente un desastre. Por el momento, la mayoría de los problemas conocidos por la humanidad progresiva parecen erradicarse. Pero usted mismo comprende, 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 la contenedorización de la aplicación, déjela girar sola y, a través de la puerta de enlace de distribución, reciba comunicación simultánea con la base de datos, que se leerá y escribirá solo una vez y en un solo lugar Este enfoque reduce la probabilidad de errores y errores de sincronización a valores mínimos.
¿A qué nos estamos dirigiendo? Además, la contenedorización de la base de datos es apropiada cuando existe una necesidad real de ella. No puede llenar la base de la aplicación completa y girarla como si tuviera dos docenas de microservicios; esto no funciona. Y esto debe entenderse claramente.
En lugar de salida
Si está esperando la conclusión inteligible "virtualice o no la base de datos", entonces estamos decepcionados: no estará aquí. Porque al crear cualquier solución de infraestructura, uno no debe guiarse por la moda y el progreso, sino, en primer lugar, por el sentido común.
Hay proyectos en los que los principios y herramientas que vienen con kubernetis encajan perfectamente, y en tales proyectos, la paz llega al menos en el área de back-end. Y hay proyectos que no necesitan contenedorización, sino una infraestructura de servidor normal, porque básicamente no se pueden redimensionar a un modelo de clúster de microservicios, porque se caerán.