Hoy en día, el servicio Bitrix24 no tiene cientos de gigabits de tráfico, ni tampoco una enorme flota de servidores (aunque, por supuesto, existen bastantes). Pero para muchos clientes es la herramienta principal para trabajar en la empresa, es una aplicación realmente crítica para el negocio. Por tanto, no hay forma de caer. ¿Qué pasa si el bloqueo ocurrió, pero el servicio se “recuperó” tan rápido que nadie notó nada? ¿Y cómo es posible implementar el failover sin perder la calidad del trabajo y la cantidad de clientes? Alexander Demidov, director de servicios en la nube de Bitrix24, habló para nuestro blog sobre cómo ha evolucionado el sistema de reservas durante los 7 años de existencia del producto.
“Lanzamos Bitrix24 como SaaS hace 7 años. La principal dificultad probablemente fue la siguiente: antes de su lanzamiento público como SaaS, este producto simplemente existía en formato de solución en caja. Los clientes nos lo compraron, lo alojaron en sus servidores, configuraron un portal corporativo: una solución general para la comunicación de los empleados, almacenamiento de archivos, gestión de tareas, CRM, eso es todo. Y en 2012, decidimos que queríamos lanzarlo como SaaS, administrándolo nosotros mismos, garantizando confiabilidad y tolerancia a fallas. En el camino adquirimos experiencia, porque hasta entonces simplemente no la teníamos: sólo éramos fabricantes de software, no proveedores de servicios.
Al lanzar el servicio, entendimos que lo más importante es garantizar la tolerancia a fallas, la confiabilidad y la disponibilidad constante del servicio, porque si tienes un sitio web simple y corriente, una tienda, por ejemplo, y se te cae encima y se queda allí durante una hora, solo tú sufres, pierdes pedidos, pierdes clientes, pero para tu propio cliente esto no es muy crítico para él. Estaba molesto, por supuesto, pero fue y lo compró en otro sitio. Y si se trata de una aplicación a la que está ligado todo el trabajo dentro de la empresa, las comunicaciones, las decisiones, entonces lo más importante es ganarse la confianza de los usuarios, es decir, no defraudarlos ni caer. Porque todo trabajo puede detenerse si algo dentro no funciona.
Bitrix.24 como SaaS
Montamos el primer prototipo un año antes del lanzamiento público, en 2011. Lo montamos en aproximadamente una semana, lo miramos, lo giramos e incluso estaba funcionando. Es decir, podrías ingresar al formulario, ingresar allí el nombre del portal, se abriría un nuevo portal y se crearía una base de usuarios. Lo analizamos, evaluamos el producto en principio, lo desechamos y continuamos perfeccionándolo durante todo un año. Porque teníamos una gran tarea: no queríamos crear dos bases de código diferentes, no queríamos admitir un producto empaquetado separado, soluciones en la nube separadas; queríamos hacerlo todo dentro de un solo código.
Una aplicación web típica en ese momento era un servidor en el que se ejecutaba algún código PHP, una base de datos MySQL, se cargaban archivos, se colocaban documentos e imágenes en la carpeta de carga; bueno, todo funciona. Lamentablemente, es imposible iniciar un servicio web críticamente estable usando esto. Allí, no se admite la caché distribuida ni la replicación de bases de datos.
Formulamos los requisitos: esta es la capacidad de estar ubicado en diferentes ubicaciones, admitir replicación e idealmente estar ubicado en diferentes centros de datos distribuidos geográficamente. Separe la lógica del producto y, de hecho, el almacenamiento de datos. Ser capaz de escalar dinámicamente según la carga y tolerar la estática por completo. De estas consideraciones surgieron los requisitos del producto, que fuimos perfeccionando a lo largo del año. Durante este tiempo, en la plataforma, que resultó estar unificada (para soluciones en caja, para nuestro propio servicio), brindamos soporte para aquellas cosas que necesitábamos. Soporte para replicación de mysql a nivel del propio producto: es decir, el desarrollador que escribe el código no piensa en cómo se distribuirán sus solicitudes, usa nuestra api y sabemos cómo distribuir correctamente las solicitudes de escritura y lectura entre maestros. y esclavos.
Hemos brindado soporte a nivel de producto para varios almacenamientos de objetos en la nube: Google Storage, Amazon S3 y soporte para Open Stack Swift. Por lo tanto, esto fue conveniente tanto para nosotros como servicio como para los desarrolladores que trabajan con una solución empaquetada: si solo usan nuestra API para trabajar, no piensan en dónde se guardará finalmente el archivo, localmente en el sistema de archivos o en el almacenamiento de archivos de objetos.
Como resultado, decidimos de inmediato que reservaríamos a nivel de todo el centro de datos. En 2012, lanzamos íntegramente en Amazon AWS porque ya teníamos experiencia con esta plataforma: nuestro propio sitio web estaba alojado allí. Nos atrajo el hecho de que en cada región Amazon tiene varias zonas de disponibilidad; de hecho, (en su terminología) varios centros de datos que son más o menos independientes entre sí y nos permiten reservar a nivel de un centro de datos completo: si falla repentinamente, las bases de datos se replican maestro-maestro, se realiza una copia de seguridad de los servidores de aplicaciones web y los datos estáticos se mueven al almacenamiento de objetos s3. La carga está equilibrada: en ese momento Amazon elb, pero un poco más tarde llegamos a nuestros propios balanceadores de carga, porque necesitábamos una lógica más compleja.
Lo que querían es lo que obtuvieron...
Todas las cosas básicas que queríamos garantizar (tolerancia a fallos de los propios servidores, aplicaciones web, bases de datos) todo funcionó bien. El escenario más simple: si una de nuestras aplicaciones web falla, entonces todo es simple: se desconecta del equilibrio.
El equilibrador (en ese momento era el elb de Amazon) marcó las máquinas que estaban fuera de servicio como en mal estado y desactivó la distribución de carga en ellas. El escalado automático de Amazon funcionó: cuando la carga creció, se agregaron nuevas máquinas al grupo de escalado automático, la carga se distribuyó a nuevas máquinas, todo estuvo bien. Con nuestros equilibradores, la lógica es aproximadamente la misma: si algo le sucede al servidor de aplicaciones, eliminamos solicitudes, desechamos estas máquinas, iniciamos otras nuevas y continuamos trabajando. El esquema ha cambiado un poco a lo largo de los años, pero continúa funcionando: es simple, comprensible y no presenta dificultades.
Trabajamos en todo el mundo, los picos de carga de los clientes son completamente diferentes y, de forma amigable, deberíamos poder realizar determinados trabajos de servicio en cualquier componente de nuestro sistema en cualquier momento, sin que los clientes se den cuenta. Por lo tanto, tenemos la oportunidad de desactivar la base de datos, redistribuyendo la carga a un segundo centro de datos.
¿Cómo funciona todo? — Cambiamos el tráfico a un centro de datos en funcionamiento: si hay un accidente en el centro de datos, entonces por completo, si este es nuestro trabajo planificado con una base de datos, luego transferimos parte del tráfico que atiende a estos clientes a un segundo centro de datos, suspendiendo es replicación. Si se necesitan nuevas máquinas para aplicaciones web porque la carga en el segundo centro de datos ha aumentado, se iniciarán automáticamente. Terminamos el trabajo, se restaura la replicación y devolvemos toda la carga. Si necesitamos reflejar algún trabajo en el segundo DC, por ejemplo, instalar actualizaciones del sistema o cambiar la configuración en la segunda base de datos, entonces, en general, repetimos lo mismo, solo que en la otra dirección. Y si esto es un accidente, entonces hacemos todo de manera trivial: utilizamos el mecanismo de manejo de eventos en el sistema de monitoreo. Si se activan varias comprobaciones y el estado pasa a crítico, ejecutamos este controlador, un controlador que puede ejecutar tal o cual lógica. Para cada base de datos, especificamos qué servidor es la conmutación por error y dónde se debe cambiar el tráfico si no está disponible. Históricamente, utilizamos nagios o algunas de sus bifurcaciones de una forma u otra. En principio, existen mecanismos similares en casi cualquier sistema de seguimiento; no utilizamos nada más complejo todavía, pero quizás algún día lo hagamos. Ahora el monitoreo se activa cuando no hay disponibilidad y tiene la capacidad de cambiar algo.
¿Hemos reservado todo?
Tenemos muchos clientes de EE. UU., muchos clientes de Europa, muchos clientes más cercanos al Este: Japón, Singapur, etc. Por supuesto, una gran parte de los clientes se encuentran en Rusia. Es decir, el trabajo no está en una sola región. Los usuarios quieren una respuesta rápida, existen requisitos para cumplir con varias leyes locales y dentro de cada región reservamos dos centros de datos, además hay algunos servicios adicionales que, nuevamente, es conveniente colocar dentro de una región, para los clientes que están en esta región están funcionando. Controladores REST, servidores de autorización, son menos críticos para el funcionamiento del cliente en su conjunto, puede cambiarlos con un pequeño retraso aceptable, pero no desea reinventar la rueda sobre cómo monitorearlos y qué hacer. con ellos. Por lo tanto, estamos tratando de aprovechar al máximo las soluciones existentes, en lugar de desarrollar algún tipo de competencia en productos adicionales. Y en algún lugar usamos trivialmente la conmutación a nivel de DNS y determinamos la vivacidad del servicio mediante el mismo DNS. Amazon tiene un servicio Route 53, pero no es sólo un DNS en el que puedes realizar entradas y eso es todo: es mucho más flexible y conveniente. A través de él, puede crear servicios geodistribuidos con geolocalizaciones, cuando lo usa para determinar de dónde vino el cliente y darle ciertos registros; con su ayuda puede construir arquitecturas de conmutación por error. Las mismas comprobaciones de estado se configuran en la propia Ruta 53, usted configura los puntos finales que se monitorean, establece métricas, establece qué protocolos para determinar la "vivacidad" del servicio: tcp, http, https; establecer la frecuencia de las comprobaciones que determinan si el servicio está activo o no. Y en el propio DNS usted especifica qué será primario, qué será secundario, dónde cambiar si la verificación de estado se activa dentro de la ruta 53. Todo esto se puede hacer con algunas otras herramientas, pero ¿por qué es conveniente? Nosotros lo configuramos. una vez y luego no pensar en ello en absoluto cómo hacemos las comprobaciones, cómo cambiamos: todo funciona por sí solo.
El primer "pero": ¿Cómo y con qué reservar la propia ruta 53? Quién sabe, ¿y si le pasa algo? Afortunadamente, nunca pisamos este rastrillo, pero nuevamente, tendré una historia por delante de por qué pensamos que aún necesitábamos hacer una reserva. Aquí nos pusimos pajitas de antemano. Varias veces al día hacemos una descarga completa de todas las zonas que tenemos en la ruta 53. La API de Amazon te permite enviarlos fácilmente en JSON, y tenemos varios servidores de respaldo donde lo convertimos, lo subimos en forma de configuraciones y tenemos, en términos generales, una configuración de respaldo. Si sucede algo, podemos implementarlo rápidamente de forma manual sin perder los datos de configuración de DNS.
Segundo "pero": ¿Qué hay en esta imagen que aún no ha sido reservado? ¡El propio equilibrador! Nuestra distribución de clientes por región se hace muy sencilla. Tenemos los dominios bitrix24.ru, bitrix24.com, .de; ahora hay 13 dominios diferentes que operan en varias zonas. Llegamos a lo siguiente: cada región tiene sus propios equilibradores. Esto hace que sea más conveniente distribuir entre regiones, dependiendo de dónde se encuentre la carga máxima en la red. Si se trata de una falla a nivel de un solo equilibrador, simplemente se pone fuera de servicio y se elimina del DNS. Si hay algún problema con un grupo de balanceadores, entonces se respaldan en otros sitios y el cambio entre ellos se realiza usando la misma ruta53, porque debido al TTL corto, el cambio se produce en un máximo de 2, 3, 5 minutos. .
Tercer "pero": ¿Qué aún no está reservado? T3, correcto. Cuando colocamos los archivos que almacenamos para los usuarios en s3, creíamos sinceramente que era perforante y que no había necesidad de reservar nada allí. Pero la historia muestra que las cosas suceden de manera diferente. En general, Amazon describe S3 como un servicio fundamental, porque el propio Amazon usa S3 para almacenar imágenes de máquina, configuraciones, imágenes AMI, instantáneas... Y si s3 falla, como sucedió una vez durante estos 7 años, mientras llevamos usando bitrix24, lo sigue como un fan. Surgen un montón de cosas: incapacidad para iniciar máquinas virtuales, falla de API, etc.
Y S3 puede caer; sucedió una vez. Por lo tanto, llegamos al siguiente esquema: hace unos años no había instalaciones públicas serias de almacenamiento de objetos en Rusia, y consideramos la opción de hacer algo por nuestra cuenta... Afortunadamente, no empezamos a hacer esto, porque Hemos profundizado en la experiencia que no tenemos y probablemente lo estropearíamos. Ahora Mail.ru tiene almacenamiento compatible con s3, Yandex lo tiene y varios otros proveedores lo tienen. Finalmente se nos ocurrió la idea de que queríamos tener, en primer lugar, una copia de seguridad y, en segundo lugar, la capacidad de trabajar con copias locales. Específicamente para la región rusa, utilizamos el servicio Mail.ru Hotbox, que es compatible con API con s3. No necesitábamos modificaciones importantes en el código dentro de la aplicación e hicimos el siguiente mecanismo: en s3 hay activadores que activan la creación/eliminación de objetos, Amazon tiene un servicio llamado Lambda: este es un lanzamiento de código sin servidor. que se ejecutará justo cuando se activen ciertos desencadenantes.
Lo hicimos de manera muy simple: si nuestro disparador se activa, ejecutamos un código que copiará el objeto al almacenamiento de Mail.ru. Para iniciar completamente el trabajo con copias locales de datos, también necesitamos sincronización inversa para que los clientes que están en el segmento ruso puedan trabajar con un almacenamiento más cercano a ellos. El correo está a punto de completar los activadores en su almacenamiento; será posible realizar una sincronización inversa a nivel de infraestructura, pero por ahora lo estamos haciendo a nivel de nuestro propio código. Si vemos que un cliente ha publicado un archivo, entonces a nivel de código colocamos el evento en una cola, lo procesamos y realizamos una replicación inversa. Por qué es malo: si hacemos algún tipo de trabajo con nuestros objetos fuera de nuestro producto, es decir, por algún medio externo, no lo tendremos en cuenta. Por lo tanto, esperamos hasta el final, cuando aparecen disparadores en el nivel de almacenamiento, para que no importa desde dónde ejecutemos el código, el objeto que nos llegó se copie en la otra dirección.
A nivel de código, registramos ambos almacenamientos para cada cliente: uno se considera principal y el otro de respaldo. Si todo está bien, trabajamos con el almacenamiento que está más cerca de nosotros: es decir, nuestros clientes que están en Amazon trabajan con S3, y los que trabajan en Rusia, trabajan con Hotbox. Si se activa la bandera, entonces se debe conectar la conmutación por error y cambiamos los clientes a otro almacenamiento. Podemos marcar esta casilla de forma independiente por región y cambiarlas de un lado a otro. Aún no lo hemos usado en la práctica, pero hemos previsto este mecanismo y creemos que algún día necesitaremos este interruptor y nos resultará útil. Esto ya sucedió una vez.
Ah, y Amazon se escapó...
Este abril se cumple el aniversario del inicio del bloqueo de Telegram en Rusia. El proveedor más afectado es Amazon. Y, lamentablemente, las empresas rusas que trabajaban para todo el mundo sufrieron más.
Si la empresa es global y Rusia es un segmento muy pequeño para ella, del 3 al 5%, bueno, de una forma u otra, puedes sacrificarlos.
Si se trata de una empresa puramente rusa (estoy seguro de que debe estar ubicada localmente), bueno, simplemente será conveniente para los propios usuarios, cómoda y habrá menos riesgos.
¿Qué pasa si se trata de una empresa que opera a nivel mundial y tiene aproximadamente el mismo número de clientes de Rusia y de algún otro lugar del mundo? La conectividad de los segmentos es importante y deben trabajar entre sí de una forma u otra.
A finales de marzo de 2018, Roskomnadzor envió una carta a los mayores operadores indicando que planeaban bloquear varios millones de IP de Amazon para poder bloquear... el mensajero Zello. Gracias a estos mismos proveedores, lograron filtrar la carta a todos y se entendió que la conexión con Amazon podría romperse. Era viernes y, presa del pánico, corrimos hacia nuestros colegas de servers.ru y les dijimos: "Amigos, necesitamos varios servidores que no estarán ubicados en Rusia ni en Amazon, sino, por ejemplo, en algún lugar de Ámsterdam". para poder al menos instalar de alguna manera nuestra propia VPN y proxy allí para algunos puntos finales en los que no podemos influir de ninguna manera, por ejemplo, puntos finales del mismo s3; no podemos intentar crear un nuevo servicio y obtener una IP diferente, Todavía necesitas llegar allí. En apenas unos días configuramos estos servidores, los pusimos en funcionamiento y, en general, nos preparamos para el momento en que comenzara el bloqueo. Es curioso que RKN, ante el alboroto y el pánico, dijera: "No, no bloquearemos nada ahora". (Pero esto es exactamente hasta el momento en que Telegram comenzó a bloquearse). Habiendo configurado las capacidades de derivación y dándonos cuenta de que el bloqueo no se había introducido, nosotros, sin embargo, no comenzamos a resolver todo el asunto. Sí, por si acaso.
Y en 2019 todavía vivimos en condiciones de bloqueo. Lo miré anoche: alrededor de un millón de IP siguen bloqueadas. Es cierto que Amazon se desbloqueó casi por completo, en su punto máximo alcanzó los 20 millones de direcciones... En general, la realidad es que puede que no haya coherencia, buena coherencia. De repente. Puede que no exista por razones técnicas: incendios, excavadoras, todo eso. O, como hemos visto, no del todo técnico. Por lo tanto, alguien grande y grande, con sus propios AS, probablemente pueda manejar esto de otras maneras: la conexión directa y otras cosas ya están en el nivel l2. Pero en una versión simple, como la nuestra o incluso más pequeña, puede, por si acaso, tener redundancia a nivel de servidores levantados en otro lugar, configurados de antemano como vpn, proxy, con la capacidad de cambiar rápidamente la configuración a ellos en esos segmentos. que son críticos para su conectividad. Esto nos resultó útil más de una vez, cuando comenzó el bloqueo de Amazon; en el peor de los casos, solo permitíamos el tráfico S3 a través de ellos, pero poco a poco todo esto se fue resolviendo.
¿Cómo reservar... un proveedor completo?
En este momento no tenemos un escenario en caso de que todo el Amazonas caiga. Tenemos un escenario similar para Rusia. En Rusia, estábamos alojados en un proveedor, del cual elegimos tener varios sitios. Y hace un año nos enfrentamos a un problema: aunque se trata de dos centros de datos, es posible que ya haya problemas a nivel de configuración de red del proveedor que seguirán afectando a ambos centros de datos. Y es posible que terminemos no disponibles en ambos sitios. Por supuesto que eso es lo que pasó. Terminamos reconsiderando la arquitectura interior. No ha cambiado mucho, pero para Rusia ahora tenemos dos sitios, que no son del mismo proveedor, sino de dos diferentes. Si uno falla, podemos cambiar al otro.
Hipotéticamente, para Amazon estamos considerando la posibilidad de reservar a nivel de otro proveedor; tal vez Google, tal vez alguien más... Pero hasta ahora hemos observado en la práctica que, si bien Amazon tiene accidentes a nivel de una zona de disponibilidad, los accidentes a nivel de toda una región son bastante raros. Por lo tanto, teóricamente tenemos la idea de que podríamos hacer una reserva de “Amazon no es Amazon”, pero en la práctica todavía no es así.
Algunas palabras sobre la automatización
¿Es siempre necesaria la automatización? Conviene recordar aquí el efecto Dunning-Kruger. En el eje “x” está el conocimiento y la experiencia que adquirimos, y en el eje “y” está la confianza en nuestras acciones. Al principio no sabemos nada y no estamos del todo seguros. Entonces sabemos un poco y nos volvemos muy seguros: este es el llamado "pico de la estupidez", bien ilustrado por la imagen "demencia y coraje". Entonces hemos aprendido un poco y estamos listos para ir a la batalla. Luego cometemos algunos errores megagraves y nos encontramos en un valle de desesperación, cuando parece que sabemos algo, pero en realidad no sabemos mucho. Luego, a medida que ganamos experiencia, nos volvemos más seguros.
Nuestra lógica sobre varios interruptores automáticos ante determinados accidentes está muy bien descrita en este gráfico. Empezamos, no sabíamos hacer nada, casi todo el trabajo lo hacíamos a mano. Luego nos dimos cuenta de que podíamos automatizar todo y dormir tranquilos. Y de repente pisamos un mega rastrillo: se activa un falso positivo y cambiamos el tráfico de un lado a otro cuando, en el buen sentido, no deberíamos haberlo hecho. En consecuencia, la replicación falla o algo más: éste es el verdadero valle de la desesperación. Y luego llegamos a comprender que debemos abordar todo con prudencia. Es decir, tiene sentido confiar en la automatización, previendo la posibilidad de falsas alarmas. ¡Pero! si las consecuencias pueden ser devastadoras, entonces es mejor dejarlo en manos del turno de guardia, de los ingenieros de turno, quienes se asegurarán y controlarán que realmente haya un accidente, y realizarán las acciones necesarias manualmente...
Conclusión
A lo largo de 7 años, pasamos del hecho de que cuando algo caía, había pánico-pánico, a comprender que los problemas no existen, solo hay tareas, que deben y pueden resolverse. Cuando esté creando un servicio, mírelo desde arriba y evalúe todos los riesgos que pueden ocurrir. Si los ve de inmediato, prevea la redundancia con anticipación y la posibilidad de construir una infraestructura tolerante a fallas, porque cualquier punto que pueda fallar y provocar la inoperancia del servicio definitivamente lo hará. E incluso si le parece que algunos elementos de la infraestructura definitivamente no fallarán, como el mismo s3, tenga en cuenta que pueden hacerlo. Y al menos en teoría, ten una idea de lo que harás con ellos si sucede algo. Contar con un plan de gestión de riesgos. Cuando piense en hacer todo de forma automática o manual, evalúe los riesgos: ¿qué pasará si la automatización comienza a cambiar todo? ¿No conducirá esto a una situación aún peor en comparación con un accidente? Quizás en algún lugar sea necesario llegar a un compromiso razonable entre el uso de la automatización y la reacción del ingeniero de turno, quien evaluará la imagen real y comprenderá si es necesario cambiar algo en el acto o "sí, pero no ahora".
Un compromiso razonable entre el perfeccionismo y el esfuerzo real, el tiempo y el dinero que puedes gastar en el esquema que eventualmente tendrás.
Este texto es una versión actualizada y ampliada del informe de Alexander Demidov en la conferencia. .
Fuente: habr.com