Base de datos en las nubes: a quién y por qué - la opinión de los especialistas de Data Egret

Se cree que el futuro es para DB como Servicio. ¿Vale la pena que todos disparen un DBA e vayan a una nube pública o se esfuercen por crear una nube privada en Docker con Kubernetes? Tres expertos de Data Egret - Alexei Lesovsky, Viktor Yegorov y Andrey Salnikov - en el canal #RuPostgres en vivo compartieron sus puntos de vista sobre qué tipo de proyectos de modelos de nube son adecuados.

El moderador y moderador de la discusión fue Nikolay Samokhvalov, fundador de Postgres.ai y cofundador de la comunidad RuPostgres.org.



Debajo del corte - transcripción de la conversación.

- Hoy hablaremos de Postgres en las nubes. Y comenzaré con una pregunta difícil: ¿es cierto que ya tienes más de la mitad de los clientes en las nubes?

Alexei: Creo que no. Se siente como menos de la mitad. Todos se sientan en sus propios centros de datos o alquilan piezas de hierro.

Pero antes de hablar sobre las nubes, definamos los términos. ¿Qué queremos decir con "nubes": Amazon, Google Cloud, DB as Service?

- Distinguiría Postgres en la nube, preparado en una instancia de Amazon EC2 (o un análogo de Google), donde, en términos generales, puede iniciar sesión a través de ssh y corregir la configuración, y Postgres bajo control (en inglés "administrado"), cuando el acceso directo a nivel de archivo o sin ssh, pero solo existe la posibilidad de conectarse y ejecutar consultas SQL. En principio deberían considerarse por separado. Y mi primera pregunta fue sobre Postgres administrados.

Alexei: Tales clientes son sustancialmente menos de la mitad.

Victor: Bueno, en el primer caso, ¿qué ventajas significativas tenemos de la nube? ¿Cuál es el significado de la nube?

- En el primer caso, utilizando varias herramientas modernas, como patroni y kubernetes (hablaremos de ellas por separado), puede obtener elasticidad, microservicios y todo eso. Esto no es lo mismo que una simple pieza de hierro. Es como "mascotas vs manada": la actitud de planchar como mascota crece en una relación con las máquinas virtuales como con una manada. Ya no sabes qué tipo de glándulas están instaladas allí. No los ordenó, no trabajó con el proveedor, no pensó en la topología. Puedes ahorrar tiempo.

Victor: si. En mi opinión, el primer caso simplemente simplifica el proceso de compra de hierro nuevo. Sabes lo que necesitas: cuántos núcleos y RAM, qué unidades. Y usted elige una máquina virtual de lo que le ofrecen. Es rapido Pero de lo contrario, aún debe configurar y mantener este servidor normalmente.

- ¿Y cómo se siente con respecto a la sobrecarga agregada por las máquinas virtuales (a procesos dentro de una máquina virtual que no están en el metal desnudo, sobrecarga de rendimiento o dificultades de administración)? ¿Alguno de ustedes lo midió?

Alexei: Los gastos generales se pueden medir si tienes control sobre el hipervisor. En los servicios públicos no lo es, lo que dan es lo que usted usa.

La sobrecarga de los sistemas de virtualización habituales que se pueden implementar en casa (KVM, Xen), la medí hace cinco años, y luego fue de aproximadamente el 7-8%. Además, dependía de la configuración de la máquina virtual y la carga de trabajo. Por ejemplo, hubo significativamente más gastos generales en Redis y Postgres que en Unicornio, que sirve a los servidores de Rails.

Quizás ahora los números son diferentes.

- Incluso 5-7% es un gasto general aceptable en comparación con las ventajas de las que habló Victor.

¿Y cómo cambia la composición de los clientes: hay algún movimiento hacia las bases administradas?



Alexey: No. La tendencia es más bien lo contrario. Las personas que trabajan con cosas como RDS carecen de la flexibilidad para administrar y administrar. Como resultado, obtenemos la misma actitud "como a las mascotas", pero en los casos de EC2.

Victor: Esta situación se avecina. Hay clientes cuyas principales bases de producción están muy ocupadas. Naturalmente, se colocan en las piezas de hierro asignadas y bajo supervisión constante. Pero cuando la empresa crece, el desarrollo requiere una gran cantidad de instancias de prueba y desarrollo, y pasan a la virtualización. Es decir, este es un caso híbrido: bajo pruebas y entornos de desarrollo, se puede comprar hardware o alquilar máquinas virtuales. Pero la producción permanece en un hardware serio normal.

- ¿Se utiliza Amazon RDS para esto?

Alexey: Nuestros clientes, por el contrario, rechazan RDS. La razón, como dije, es la falta de flexibilidad en la gestión.

Las instancias se bloquean y, en algunos casos, el problema no se resuelve solo alquilando una pieza de hierro más potente.

No puede resolver muchos problemas por sí mismo, solo con la ayuda del apoyo.

- ¿Es posible dar ejemplos? Parece que recientemente Amazon compró OpenSCG, grandes personas que deberían haber desarrollado la experiencia interna de Postgres. Y sé por experiencia propia que hay un examen. Si abre un ticket con el soporte de Amazon RDS y se topa con una persona que no puede ayudarlo, simplemente cierre el ticket y ábralo nuevamente, para obtener uno más competente.

Alexey: OpenSCG es, por supuesto, un equipo de profesionales. Pero comprar un equipo así no cierra el 100% de las posibles situaciones. Hay problemas que apoyan las caras por primera vez. Esto también pasa con nosotros.

De estos últimos, en una de las réplicas de PostgreSQL 10.6, el promedio de carga del cliente en el host aumentó repentinamente de 30 a 40 unidades, aunque no hay carga. Un golpe subterráneo tan incomprensible. No afecta mucho, pero la imagen misma del rebote promedio de la carga es incomprensible. Y ella molesta a los administradores del cliente. Tenemos un par de hipótesis, lo que lo causó, pero hasta ahora no hemos podido probarlas, porque el sistema es productivo y no todo se puede hacer rápidamente allí.

Y tales "golpes subterráneos" aparecen una vez al año, y comienzas a abordar la tarea de manera creativa. Y Amazon RDS es un mayor número de instancias, un mayor número de instalaciones y tickets, respectivamente, y todo tipo de situaciones son mucho más grandes.



Andrew: Me gustaría agregar sobre la comparación de instancias RDS y EC2.
Teníamos un cliente con producción en RDS. Él buscó consejo. El circuito de desarrollo se encontraba en Microsoft Azure, aparentemente, Azure se consideró inicialmente como el servicio principal en la nube.

Arrastré la base del circuito de desarrollo de Azure a Amazon en EC2 para acercarme a la producción, y los problemas de pronóstico se acercaron a la base de datos del producto.

Aunque el servidor EC2 era dos veces más simple que en instancias RDS, y la carga de prueba era mayor que el producto, en el circuito de desarrollo después de mi configuración, los resultados fueron mucho mejores que en Amazon en la instancia RDS en producción.

Sospecho que, debido a la falta de experiencia en PostgreSQL dentro de la empresa del cliente, RDS se utilizó con la configuración predeterminada. Retorcemos todas las configuraciones.

Como resultado, el cliente quedó muy impresionado. Me dirigí a la administración con una propuesta en lugar de RDS para tomar y configurar instancias simples.

- Por cierto, ¿cómo se midió, cuál es mejor, cuál es peor?

Andrew: El cliente observó las métricas de su aplicación, la rapidez con la que se descargaron y procesaron los datos.

- Ahora estamos regañando a RDS, pero tiene enormes ventajas: elimina muchos dolores de cabeza asociados con la implementación, las copias de seguridad y la replicación. Estas de acuerdo

Andrew: si. Y, muy probablemente, la razón principal por la que el cliente permaneció en RDS fue precisamente por la falta de experiencia en PostgreSQL mencionada. Obtienen todo lo que necesitan con RDS, solo pagan más por las instancias.

- Además de Amazon RDS, hay otros postgres gestionados basados ​​en la nube. ¿Te has encontrado, por ejemplo, con el servicio Yandex?

Andrei: Me encontré con sus máquinas virtuales y realmente no me gustaron, las unidades NVMe no son muy honestas allí. De hecho, hay unidades conectadas a través de una red.

- NVMe honesto (unidades locales) también es un problema. Google y Amazon tienen NVMe, pero las unidades son efímeras. Si reinicia la instancia, pierde todos los datos porque se le proporciona otra máquina virtual.

Andrei: Me comentaron en Yandex Cloud que tienen NVMe honesto en DB como servicio, pero aún no he encontrado este servicio. Aparentemente, hay una arquitectura ligeramente diferente a nivel de provisión de recursos.

Trabajan muy duro en DB como servicio, ya que lo usan para sus servicios. Es solo que hay diferentes puntos de entrada para clientes externos y uso interno.

- Y qué piensas, ¿hay alguna perspectiva para los Postgres rusos en la nube? ¿Despegará o no despegará?

Andrew:

Yandex tiene un excelente equipo, bastante experimentado, con buena experiencia. Creo que despegarán.

En primer lugar, ellos mismos operan muchos Postgres (más de 1000 bases de datos en sus proyectos), y desde explotar, todos los conos y puntos doloridos funcionarán y se arreglarán más rápido. Creo que el cliente recibirá un servicio final de bastante buena calidad.

Y existe una demanda de tales soluciones. Tome una startup que al principio no pueda tener la experiencia necesaria en Postgres por varias razones: caras, no ven el punto, pruebe diferentes tecnologías. Para él, esta es una buena solución, porque en tales servicios hay "giros" limitados que no deberían retorcerse, y si eso, creo, habrá soporte técnico.

Es cierto que Yandex Cloud todavía está en el inicio, y no se presenta tanta funcionalidad en este momento.

- Tenemos preguntas de la sala de chat: ¿qué piensa sobre el hecho de que al emitir máquinas virtuales, alguien físicamente puede sentarse en esta máquina (estrangulamiento, robar tiempo).



Victor: Sí, existe tal experiencia. Solo quería mencionarlo. Hay clientes que tienen sus propios sistemas de virtualización implementados. De vez en cuando solicitan ver algún servidor que no sea de producto, y vemos una situación incomprensible: no observamos las razones por las que debería romperse en este servidor. Luego, redirigimos las preguntas a sus administradores con una solicitud para ver qué está sucediendo en el host.

- Y qué hacer, ¿hay un efecto similar en Amazon? ¿Hay algún método para determinar que estás "exprimido"? pgbench para conducir?

Alexei: No recuerdo eso. Pero la forma habitual es determinar a través del tiempo de robo. En los gráficos de monitoreo, por regla general, no vemos valores grandes.

- Siento que realmente no te gusta el Postgres administrado. ¿Se debe al hecho de que RDS se lleva tu trabajo?

Alexey: No. Esto es más probable debido al hecho de que simplemente no lo tenemos. Managed Postgres es bueno porque puede implementar la infraestructura con solo hacer clic en un botón. Mientras sea una startup y solo agregue o lea datos sin ninguna lógica compleja, todo está bien. Y cuando cruza una línea determinada, por ejemplo, comienza a ejecutar muchas UNIONES, realiza SQL complejo, surge la tarea de optimizar las consultas y RDS deja de ser suficiente. Se necesita más libertad e influencia, pero las herramientas disponibles no lo ayudan a resolver los problemas profundos asociados con la disposición de recursos dentro de Postgres. Solo existe la oportunidad de aumentar el poder de la pieza de hierro: se paga más dinero - se recibe.

Andrew: No hay tanto desagrado por RDS y miedo por el trabajo. El problema es diferente. Supongamos que una startup toma RDS, él les da todo. Pero no aumentó su experiencia en Postgres. A continuación, digamos una toma de inicio. Las cargas están creciendo: la escritura y la lectura han aumentado. En ausencia de su experiencia, una startup tiene que buscar personas al margen. DBA severos vienen y ven que no pueden sacar más provecho de RDS, pero desde una instancia EC2 normal es bastante posible obtener más rendimiento, como en el ejemplo que mencioné anteriormente. Si se nos permitiera usar RDS, tal vez podríamos modificar y mejorar la base de datos, pero no lo hicimos.

- El problema con el acceso se está resolviendo. Hay Postgres gestionados que proporcionan acceso ssh (e incluso completamente root), por ejemplo, una pequeña empresa Aiven de Finlandia. De manera predeterminada, no dan acceso a la raíz, pero el fundador (y hablé con él un par de veces) habló sobre su disposición a otorgar acceso a pedido.

Andrew: El problema no es solo el acceso. ¿Por qué estamos mejor con glándulas puras? Porque tenemos muchos clientes diferentes y cada uno tiene su propia infraestructura. Y las infraestructuras están tan separadas que la metodología general que funciona igual en todas partes, simplemente no podemos. Porque hay quienes tienen su propio hardware, y simplemente no pueden alojar en algún lugar (de acuerdo con algunas de sus propias reglas y restricciones), y hay quienes están en las nubes.

- ¿Quiere decir que la definición de índices no utilizados depende de la pieza de hierro? ¿O algunas otras cosas comunes?

Andrew: Desde el punto de vista de la administración, es el esquema de la base de datos y la definición de los índices no utilizados que las nubes no son diferentes de su hardware. Todo está unificado.

La diferencia entre una nube y una pieza real de hardware, en la capa entre la base y específicamente el hardware que se encuentra debajo, es el sistema operativo y las virtualizaciones utilizadas. Cuando tiene bases de datos grandes, es importante para usted la rapidez con que las unidades envían y reciben datos, qué tan eficientemente se utilizan la memoria y el procesador, por lo que es extremadamente importante reducir la influencia de esta capa para que la base de datos funcione de manera más eficiente.

- Otra pregunta de la audiencia: ¿qué pasa con la configuración del kernel?

Victor: En EC2, esas cosas son personalizables.

- Existen nuevas soluciones para la clase "Postgres gestionados" de proveedores conocidos, además de los habituales Amazon y Google. Por ejemplo, Nutanix y SAP anunciaron en 2018 la creación de soluciones basadas en Postgres. ¿No crees que todos estos tipos nos llevan a la aparición de algunas decisiones que harán lo mismo, pero solo en tu pieza de hierro? Para que pueda hacer clic en el botón e implementar el nuevo Postgres, donde las copias de seguridad y la replicación ya están configuradas.

Alexei: Me parece que SAP y otros no son totalmente rentables. Estos son grandes vendedores de hierro y software. Hacen un producto con el objetivo de ganar dinero. Venta de soporte al menos. Por lo tanto, debemos ver cómo se beneficiarán de esto. Si tal modelo de entrega del producto es beneficioso para ellos, entonces ¿por qué no?

- Quise decir un poco diferente. Específicamente, estos chicos no publicarán nada en código abierto y regalarán gratis. ¿Pero no crees que alguien del más pequeño, pero juguetón, hará algo así? Tal vez esto se centre en Kubernetes, Operator Framework. Ya hay un par de desarrollos que los operadores están haciendo: Zalando, por ejemplo. ¿Y no crees que RDS basado en la nube ayuda a una transición gradual hacia tales soluciones? Vemos cómo puedes vivir sin subir a las configuraciones con tus manos.

Alexey: Resulta que no está del todo bien manejado.

De todos modos, necesitará contar con especialistas que supervisen todo esto y se suban debajo del capó si algo sale mal.

Incluso el mismísimo Kubernetes es una máquina muy compleja, con muchos componentes debajo del capó. Formalmente, esto es solo cinco binarios. Pero su interacción entre ellos se describe por volúmenes de documentación y mucha información en salas de chat, boletines y grupos de Google. Es decir Todavía necesita un especialista que siga esta cocina.

Además, todo esto se está desarrollando de manera muy dinámica. La compatibilidad con versiones anteriores se rompe de una versión a otra. Es decir todo es muy inestable e inestable. Cuando todo se estabilice, tal vez obtengamos un producto adecuado, estable y confiable. Pero hasta ahora, no todo es muy bueno.

Victor: Estamos comenzando a hablar sobre el hecho de que tenemos una capa adicional de infraestructura que necesita ser administrada, para organizar este Kubernetes.

No estoy de acuerdo en que siempre trabaje mágicamente con solo hacer clic en un botón de la manera que queramos. Es necesario mantener especialistas relevantes.

Y la segunda: nuestros clientes se adaptan constantemente a los cambios comerciales. En consecuencia, la carga en la base de datos cambia constantemente. Y si lamimos todo hace tres meses, como resultado de lo cual todas las solicitudes funcionaron como deberían, y todo estuvo bien, entonces una nueva solicitud puede llegar hoy o mañana, o debido a cambios en los datos, la solicitud existente dejará de funcionar como debería. Y necesitamos analizar la situación y entrar en la configuración del sistema. Y esta es esa automatización, que me parece que hace que tales instancias administradas sean muy difíciles. Cuando las nubes alcanzan un estado tal que también se adaptarán a tales situaciones, no lo sé. Pero si bien esta es una parte importante del trabajo que debe realizarse, es necesario adaptar la configuración de la base de datos a los cambios en el patrón de las solicitudes entrantes.

Y dado que la nube misma es una carga administrativa adicional, es más fácil para nosotros cuando esta capa simplemente no está allí, porque podemos concentrarnos en los problemas de la base de datos.

Si el cliente quiere vivir en la nube y tiene la experiencia, no tenemos nada en contra. Lo principal es que tenemos la oportunidad, cuando la base de datos no sea muy buena, escale (preferiblemente por ssh), verifique todo y obtenga acceso a todas las estadísticas.

Alexey: No necesariamente por ssh. Pero en cualquier caso, se necesitan herramientas de diagnóstico. Porque el diagnóstico por correo electrónico es muy largo y tedioso. Es molesto cuando envía un enlace de chat a la solicitud que se ejecutará, el cliente, por otro lado, hace clic en este enlace, copia la solicitud, luego le copia el resultado o le envía una captura de pantalla. Esto es todo el tiempo

Es mucho más fácil conectarse y ver directamente, probar algunas de sus hipótesis y actuar más lejos de ellas.

- ¿Tienes algún ejemplo activo de dónde Kubernetes ya se usa y Postgres vive en él?

Alexei: Desafortunadamente no. Pero realmente me gustaría. Realmente me gusta Kubernetes, estoy cerca de su concepto y filosofía.

En mi opinión, Kubernetes es algo que alienta a las personas a programar más, crear un producto más, sin pensar en aspectos secundarios como la estructura interna de la infraestructura.

Un papel similar solía ser jugado por OOP. Apareció, y muchas personas se interesaron en esta área, porque la programación se ha vuelto algo más fácil. Kubernetes también cierra muchas cosas en sí mismo, las oculta bajo el capó y permite que una persona se concentre en el aspecto creativo y programe más.

Kubernetes implementa soporte para instancias, hogares y la aplicación funciona. Si de repente se bloquea, entonces Kubernetes lo lanzará nuevamente. Es decir El desarrollador y el administrador están libres de dolores de cabeza y de seguimiento constante. Me gusta esta respuesta a la situación. Cuando algo cae, se reinicia automáticamente.

, , . — , , . .

– , ?

: , . , . - , . , , Kubernetes. Kubernetes . CNCF . , .

– - kubernetes_ru. github, Kubernetes: . Postgres, .

, , , . , Kubernetes – , . - IT.

– , Amazon Aurora PostgreSQL Serverless ? , , . , . Es decir .

:

. .

, . , , . : , . , - . .

– . . , , .

: . , . , , – . , , , , .

Es decir . – , , 70% . . .

, , « », .

– . , , DBA : - , - — , ?

: , , , – DBA, SQL-developer. Oracle SQL-developer, , , , . , Oracle. . DBA , - .

DBA — - «» , .

Kubernetes. , . . , Kubernetes . , volume . Es decir , . , .

– ?

: .

, . , , . , Postgres ( ). Postgres - . Es decir (, ), .

, .

, , . . . .

– ?

: - . , , .

, Cassandra. . Es decir — , Kubernetes.

, , . , , .

Es decir . DBA, , – . , , - – .

– ?

: . , . , , , Kubernetes . , , , , - - Kubernetes ( ).

: Kubernetes. – patroni. Zalando Kubernetes. , , ( – , Amazon , ). , – . , – . – - Kubernetes.

– RDS. EC2 Postgres . patroni ( https://github.com/zalando/patroni ), .

: , , - high availability.

– . — , ?

: , - .
Zalando DBA, patroni. Es decir , Kubernetes , DBA .

– . DBA, DBA «» «».

: , . . , , .

– - Kubernetes? ?

: - , . Kubernetes – , . Kubernetes - . . DBA. Kubernetes (, Kubernetes , , ).

- , , - - -.

: ( Kubernetes ), - . , — — . - , , , , , , .

:

. Kubernetes , . , . .

, — . , Postgres- , , . .

: …

– .. : - — dev environment, production – Kubernetes. ...

: latency , , . .

– , . .
, HighLoad++ .

PS .