👲 👊🏽 🚶🏼 Houston, tenemos un problema. Falla de diseño del sistema 👨🏾‍🚀 🧛🏻 🤳

En 1970, los ingenieros estadounidenses lanzaron la nave espacial Apolo 13 a la luna. A bordo hay tres baterías de celdas de combustible, no hay nada de qué preocuparse, todo se duplica de manera confiable y repetida. Pero nadie podría haber imaginado que la explosión de un cilindro de oxígeno desactivaría dos de las tres baterías. ¡Tragedia! Los astronautas regresaron a casa, se realizó un largometraje sobre el evento con Tom Hanks, y la frase del astronauta Jack Swigert: "¡Houston, tenemos un problema!", Pasó a la historia.

La historia del Apolo 13 es otra prueba del hecho bien conocido de que no puede prepararse para todos los posibles problemas. Esta es una propiedad natural del mundo: el hierro se rompe periódicamente, el código se bloquea y la gente comete errores. Es imposible eliminar completamente esto.

Para sistemas distribuidos grandes, este comportamiento es normal; es consecuencia de economías de escala y estadísticas. Es por eso que Design for Failure (AWS) es el principio de diseño básico para los servicios en la nube de AWS. Los sistemas se construyen inicialmente de tal manera que restablecen la operación a tiempo completo lo más rápido posible y minimizan el daño de fallas conocidas y aún desconocidas. En HighLoad ++, Vasily Pantyukhin, utilizando como ejemplo problemas de la vida real con servicios de combate, mostró patrones de diseño para sistemas distribuidos que usan los desarrolladores de AWS.

Vasily Pantyukhin (Gallina) Es el arquitecto de Amazon Web Services en Europa, Oriente Medio y África. Comenzó como administrador de Unix, trabajó en Sun Microsystem durante 6 años, impartió cursos técnicos y durante 11 años enseñó la centralización de datos del mundo en EMC. En un equipo internacional, diseñó e implementó proyectos desde Ciudad del Cabo hasta Oslo. Ahora ayuda a grandes y pequeñas empresas a trabajar en nubes públicas.

En 1949, se investigó un accidente aéreo en una base de la fuerza aérea de California. Uno de los ingenieros que hizo esto fue Edward Murphy. Describió el trabajo de los técnicos locales de la siguiente manera: "Si hay dos formas de hacer algo y una de ellas conduce al desastre, entonces alguien elegirá este método".

Más tarde, gracias a Arthur Bloch, la declaración pasó a la historia como una de las leyes de Murphy. En ruso: la ley de la maldad. Su esencia es que no será posible evitar averías y errores humanos, y tendrá que vivir con ello de alguna manera. Es por eso que, al diseñar, inmediatamente colocamos fallas y fallas de componentes individuales en nuestros sistemas.

Diseño de falla

En el diseño para fallas, estamos tratando de mejorar tres características:

accesibilidad (esos mismos "nueves");
fiabilidad: la propiedad del sistema para proporcionar el nivel de servicio necesario;
tolerancia a fallas: una propiedad del sistema para evitar la aparición de problemas y recuperarse rápidamente después de ellos.

La fiabilidad tiene la propiedad de " incógnitas conocidas ". Nos protegemos de los problemas conocidos, pero no sabemos cuándo ocurrirán.

“ Un conocidos desconocidos” se añaden a la tolerancia a fallos - estos son problemas sorpresa de que no sabemos nada. Muchos de estos problemas en la nube están relacionados con economías de escala: el sistema crece al tamaño cuando aparecen efectos nuevos, sorprendentes e inesperados.

El fracaso generalmente no es un fenómeno binario. Su propiedad principal es el "radio de explosión" o el nivel de degradación del servicio, radio de destrucción. Nuestra tarea es reducir el "radio de explosión" de los sistemas.

Si reconocemos que los problemas no pueden evitarse, entonces debemos prepararnos proactivamente para ellos. Esto significa que diseñamos servicios de tal manera que, en caso de problemas (seguramente lo serán), controlamos los problemas, y no al revés.

Cuando respondemos a un problema, nos controla.

Plano de datos y plano de control

Seguramente, tiene dispositivos electrónicos en el hogar controlados por un control remoto, como un televisor. La pantalla del televisor es parte del plano de datos, que realiza directamente la función. El control remoto es la interfaz de usuario - Plano de control. Se utiliza para administrar y configurar el servicio. En la nube, intentamos separar el plano de datos y el plano de control para pruebas y desarrollo.

Los usuarios, con mayor frecuencia, no ven la complejidad del plano de Control. Pero los errores en su diseño e implementación son las causas más comunes de fallas masivas. Es por eso que mi consejo se centra en el plano de Control, a veces explícitamente, a veces no.

La historia de un problema

En julio de 2012, una tormenta severa pasó en el norte de Virginia. El centro de datos tiene protección, generadores diésel y más, pero sucedió que en uno de los centros de datos de una de las zonas de disponibilidad (Zona de disponibilidad, AZ) de la región de Virginia del Norte, se perdió la energía. La electricidad se restableció rápidamente, pero la restauración de los servicios se prolongó durante horas.

Te contaré las razones en el ejemplo de uno de los servicios básicos: CLB (Classic Load Balancer). Funciona de manera simple: cuando inicia un nuevo equilibrador en cada zona de disponibilidad, se crean instancias separadas, cuya IP resolverá el DNS.

Cuando falla una de las instancias, se envía un mensaje sobre esto a una base de datos especial.

En respuesta, comienzan los procedimientos: eliminar registros del DNS, comenzar una nueva instancia y agregar una nueva IP al DNS.

Nota: Así es como funcionaba el sistema en el pasado, ahora todo es fundamentalmente diferente.

Todo es simple: no hay nada que romper. Pero durante una falla masiva, cuando miles de instancias colapsan al mismo tiempo, aparece un enorme Backlog en la base de datos de mensajes para su procesamiento.

Pero se puso peor. El plano de control es un sistema distribuido. Debido a un error, recibimos duplicados y miles de registros en la base de datos aumentaron a cientos de miles. Se hizo muy difícil trabajar con esto.

Cuando ocurre una falla en una de las instancias, todo el tráfico se cambia casi instantáneamente a las máquinas sobrevivientes y la carga se duplica (en el ejemplo, por simplicidad, solo hay dos zonas de acceso).

No hay suficientes recursos, una instancia en vivo comienza a escalar automáticamente. El proceso lleva un tiempo relativamente largo. Todo sucede al máximo y al mismo tiempo con una gran cantidad de instancias: los recursos gratuitos de la zona de disponibilidad se están agotando. Comienza la "lucha" por los recursos.

En el norte de Virginia, la automatización no pudo hacer frente a la falla masiva, y los ingenieros manualmente (usando scripts) restauraron los servicios para que funcionen. Tales problemas son raros. Durante la sesión informativa, surgieron preguntas sobre las causas de la falla, decidieron que la situación ya no debería repetirse y que todo el servicio debería cambiarse.

Los ocho patrones que cubriré son respuestas a algunas de las preguntas.

Nota. Esta es nuestra experiencia en el diseño de servicios, no la sabiduría universal para un uso generalizado. Los patrones se usan en situaciones específicas.

— . AWS . — , . . — . !

Para minimizar el impacto de las fallas, muchos enfoques. Una de ellas es responder la pregunta: "¿Cómo puedo asegurarme de que los usuarios que no conocen un problema no lo sepan durante una falla y durante la recuperación?"

Nuestro enorme Backlog no solo recibe mensajes fallidos, sino también otros, por ejemplo, sobre el escalado o que alguien está lanzando un nuevo equilibrador. Dichos mensajes deben aislarse entre sí, agrupando funcionalmente: un grupo separado de mensajes de recuperación después de una falla, iniciando por separado un nuevo equilibrador.

Supongamos que diez usuarios notaron un problema: uno de los nodos de sus equilibradores se cayó. Los servicios de alguna manera funcionan con los recursos restantes, pero el problema se siente.

Tenemos diez usuarios frustrados. El undécimo aparece: no sabe nada sobre el problema, pero simplemente quiere un nuevo equilibrador. Si su solicitud de dejar la cola para el procesamiento, lo más probable es que no espere. Mientras se completan otros procedimientos de procesamiento, el tiempo de solicitud finalizará. En lugar de diez usuarios frustrados, tendremos once.

Para evitar que esto suceda, priorizamos algunas solicitudes : colocamos las colas en la parte superior, por ejemplo, solicitudes de nuevos recursos. Con una falla masiva, un número relativamente pequeño de tales solicitudes no afectará el tiempo de recuperación de los recursos de otros clientes. Pero en el proceso de recuperación, restringiremos la cantidad de usuarios involucrados en el problema.

Trabajo de tiempo completo

La respuesta a los informes de problemas es el lanzamiento de procedimientos de recuperación, en particular, el trabajo con DNS. Las fallas masivas son enormes cargas máximas en el plano de control. El segundo patrón ayuda al plano de Control a ser más estable y predecible en tal situación.

Utilizamos un enfoque llamado trabajo constante: trabajo permanente .

Por ejemplo, el DNS se puede hacer un poco más inteligente: comprobará constantemente las instancias del equilibrador, estén activas o no. El resultado será un mapa de bits cada vez: la instancia responde - 1, muerta - 0. El

DNS verifica las instancias cada pocos segundos, independientemente de si el sistema se restaura después de una falla masiva o está funcionando normalmente. Él hace el mismo trabajo: sin picos, todo es predecible y estable.

Otro ejemplo simplificado: queremos cambiar la configuración en una flota grande. En nuestra terminología, una flota es un grupo de máquinas virtuales que juntas hacen algo de trabajo.

Colocamos los cambios de configuración en el bucket S3, y cada 10 segundos (por ejemplo) enviamos toda esta configuración a nuestra flota de máquinas virtuales. Dos puntos importantes.

Hacemos esto regularmente y nunca rompemos la regla. Si elige un segmento de 10 segundos, presione solo de esta manera, independientemente de la situación.
Siempre damos la configuración completa , independientemente de si ha cambiado o no. El plano de datos (máquinas virtuales) ellos mismos deciden qué hacer con él. No empujamos el delta. Puede hacerse muy grande con interrupciones o cambios masivos. Potencialmente, esto puede contribuir a la inestabilidad e imprevisibilidad.

Cuando realizamos algún tipo de trabajo permanente, pagamos más por ello. Por ejemplo, 100 máquinas virtuales solicitan una configuración cada segundo. Cuesta alrededor de $ 1200 por año. Esta cantidad es esencialmente menor que el salario de un programador, a quien podemos confiar el desarrollo de un plano de Control con un enfoque clásico: una reacción a una falla y la distribución de solo cambios de configuración.

Si cambia la configuración cada pocos segundos, como en el ejemplo, entonces esto es lento. Pero en muchos casos, un cambio de configuración o el lanzamiento de servicios lleva minutos; unos segundos no resuelven nada.

Los segundos son importantes para los servicios en los que la configuración debe cambiar instantáneamente, por ejemplo, al cambiar la configuración de VPC. Aquí el "trabajo permanente" no es aplicable. Esto es solo un patrón, no una regla. Si esto no funciona en su caso, no lo use.

Escalamiento preliminar

En nuestro ejemplo, cuando la instancia del equilibrador se bloquea, la segunda instancia superviviente recibe la carga duplicada casi de inmediato y comienza a escalar. En una falla masiva, consume una gran cantidad de recursos. El tercer patrón ayuda a controlar este proceso: escalar por adelantado .

En el caso de dos zonas de disponibilidad, escalamos al eliminar menos del 50%.

Si todo se hace por adelantado, en caso de falla, las instancias sobrevivientes del equilibrador están listas para aceptar el tráfico duplicado.

Anteriormente, escalamos solo con alta utilización, por ejemplo, 80%, y ahora en 45%. El sistema está inactivo la mayor parte del tiempo y se vuelve más costoso. Pero estamos listos para soportar esto y usar activamente el patrón, porque esto es seguro. Debe pagar el seguro, pero en caso de problemas serios, la ganancia cubre todos los gastos. Si decide utilizar el patrón, calcule todos los riesgos y el precio por adelantado.

Arquitectura celular

Hay dos formas de construir y servicios escalados: el monolito y la estructura de panal (basada en células).

El monolito se desarrolla y crece como un solo contenedor grande. Agregamos recursos, el sistema se hincha, nos encontramos con diferentes límites, las características lineales se vuelven no lineales y se saturan, y el "radio de explosión" del sistema: todo el sistema.

Si el monolito se prueba mal, aumenta la probabilidad de sorpresas: "incógnitas desconocidas". Pero un gran monolito no se puede probar completamente. A veces, para esto, tendrá que construir una zona de acceso separada, por ejemplo, para un servicio popular que se construye como un monolito dentro de la zona de acceso (se trata de muchos centros de datos). Además de crear de alguna manera una gran carga de prueba que es similar al presente, esto es imposible desde un punto de vista financiero.

Por lo tanto, en la mayoría de los casos, utilizamos una arquitectura celular , una configuración en la cual un sistema se construye a partir de celdas de un tamaño fijo. Al agregar celdas, lo escalamos.

La arquitectura celular es popular en la nube de AWS. Ayuda a aislar fallas y reducir el radio de explosión.a una o más celdas. Podemos probar completamente las células de tamaño mediano, esto reduce seriamente los riesgos.

Se utiliza un enfoque similar en la construcción naval: el casco de un barco o embarcación se divide por particiones en compartimentos. En el caso de un agujero, uno o más compartimientos se inundan, pero el barco no se hunde. Sí, no ayudó al Titanic, pero rara vez encontramos problemas de iceberg.

Ilustraré la aplicación del enfoque de malla utilizando el Servicio de formas simples como ejemplo. Este no es un servicio de AWS, se me ocurrió. Este es un conjunto de API simples para trabajar con formas geométricas simples. Puede crear una instancia de una forma geométrica, solicitar el tipo de una forma por su id o contar todas las instancias de un tipo dado. Por ejemplo, put(triangle)un objeto "triángulo" con alguna identificación se crea en una solicitud .getShape(id)devuelve el tipo "triángulo", "círculo" o "rombo".

Para hacer un servicio nublado, debe ser utilizado por diferentes usuarios al mismo tiempo. Hagámoslo multiinquilino.

A continuación, debe encontrar una forma de partición: separar las figuras en celdas. Hay varias opciones para elegir la clave de partición. El más simple está en la forma geométrica : todos los rombos en la primera celda, círculos en la segunda, triángulos en la tercera.

Este método tiene pros y contras.

Si hay notablemente menos círculos que otras figuras, entonces la celda correspondiente permanecerá subutilizada (distribución desigual).
Algunas solicitudes de API son fáciles de implementar. Por ejemplo, contando todos los objetos en la segunda celda, encontramos el número de círculos en el sistema.
Otras consultas son más complicadas. Por ejemplo, para encontrar una forma geométrica por id, debe pasar por todas las celdas.

La segunda forma es usar la identificación de los objetos por rangos : los primeros mil objetos en la primera celda, el segundo en la segunda. Entonces la distribución es más uniforme, pero hay otras dificultades. Por ejemplo, para contar todos los triángulos, debe usar el método scatter/gather: distribuimos las solicitudes en cada celda, cuenta los triángulos dentro de sí mismo, luego recopila las respuestas, resume y produce el resultado.

La tercera vía: división de inquilinos(a los usuarios). Aquí nos enfrentamos a un problema clásico. Por lo general, hay muchos usuarios "pequeños" en la nube que prueban algo y prácticamente no cargan el servicio. Hay usuarios de mastodontes. Son pocos, pero consumen una gran cantidad de recursos. Dichos usuarios nunca encajarán en ninguna celda. Debe encontrar formas complicadas de distribuirlas entre muchas celdas.

No existe una forma ideal, cada servicio es individual. La buena noticia es que la sabiduría mundana funciona aquí: cortar leña es más conveniente a lo largo de las fibras, en lugar de cortarlas. En muchos servicios, estas "fibras" son más o menos obvias. Luego puede experimentar y encontrar la clave de partición óptima.

Las células están interconectadas (aunque débilmente). Por lo tanto, debe haber un nivel de conexión. A menudo se denomina enrutamiento o capa de mapeo. Es necesario comprender a qué celdas enviar solicitudes específicas. Este nivel debe ser lo más simple posible. Trate de no poner lógica empresarial en ello.

Se plantea la cuestión del tamaño de las celdas: pequeño - malo, grande - también malo. No existe un consejo universal: decida según la situación.

En la nube de AWS, utilizamos celdas lógicas y físicas de diferentes tamaños. Hay servicios regionales con un gran tamaño de celda, hay servicios de zona, donde las celdas son más pequeñas.

Nota. Hablé sobre microcélulas en Saint Highload ++ Online a principios de abril de este año. Allí discutí en detalle un ejemplo del uso específico de este patrón en nuestro servicio central de Amazon EBS.

Multiinquilino

Cuando un usuario inicia un nuevo equilibrador, recibe instancias en cada zona de disponibilidad. Independientemente de si los recursos se utilizan o no, se asignan y pertenecen exclusivamente a este inquilino de la nube.

Para AWS, este enfoque es ineficiente porque la utilización de los recursos del servicio es, en promedio, muy baja. Esto afecta el costo. Para los usuarios de la nube, esta no es una solución flexible. No puede adaptarse a condiciones que cambian rápidamente, por ejemplo, para proporcionar recursos con una carga inesperadamente aumentada en el menor tiempo.

CLB fue el primer equilibrador en la nube de Amazon. Los servicios actuales utilizan un enfoque de múltiples inquilinos, como NLB (Network Load Balancer). La base, el "motor" de dichos servicios de red es HyperPlane. Esta es una gran flota de máquinas virtuales (nodos) internas, invisibles para los usuarios finales.

Ventajas del enfoque multiinquilino o el quinto patrón.

La tolerancia a fallas es fundamentalmente mayor . En HyperPlane, una gran cantidad de nodos ya se están ejecutando y están esperando la carga. Los nodos conocen el estado de cada uno: cuando algunos recursos fallan, la carga se distribuye instantáneamente entre los restantes. Los usuarios ni siquiera notan los choques masivos.
Protección de carga máxima . Los inquilinos viven sus propias vidas y sus cargas generalmente no se correlacionan entre sí. La carga promedio total en HyperPlane es bastante suave.
La utilización de tales servicios es fundamentalmente mejor . Por lo tanto, proporcionando un mejor rendimiento, son más baratos.

Eso suena genial! Pero el enfoque de múltiples inquilinos tiene inconvenientes. En la figura, la flota HyperPlane con tres inquilinos (rombos, círculos y triángulos), que se distribuyen en todos los nodos .

Esto plantea el clásico problema del vecino ruidoso: la acción destructiva del inquilino, que genera tráfico ultra alto o malo, afectará potencialmente a todos los usuarios.

El "radio de explosión" en dicho sistema es todos los inquilinos. La probabilidad de un "vecino ruidoso" destructivo en la zona de disponibilidad real de AWS no es alta. Pero siempre debemos estar preparados para lo peor. Nos defendemos usando un enfoque de malla: seleccionamos grupos de nodos como celdas. En este contexto, los llamamos fragmentos. Células, fragmentos, particiones: aquí es lo mismo.

En este ejemplo, un rombo, como "vecino ruidoso", afectará solo a un inquilino: un triángulo. Pero el triángulo será muy doloroso. Para suavizar el efecto, aplique el sexto patrón: mezcla de fragmentación.

Barajar fragmentos

Distribuimos al azar los inquilinos a los nodos. Por ejemplo, un rombo aterriza en 1, 3 y 6 nodos, y un triángulo en 2, 6 y 8. Tenemos 8 nodos y un fragmento de tamaño 3.

Aquí funciona la combinatoria simple. Con una probabilidad del 54%, solo habrá una intersección entre los inquilinos.

"Vecino ruidoso" afectará solo a un inquilino, y no a toda la carga, sino solo al 30 por ciento.

Considere una configuración cercana a la real: 100 nodos, tamaño de fragmento 5. Con una probabilidad del 77%, no habrá intersecciones en absoluto.

La fragmentación aleatoria puede reducir significativamente el "radio de explosión". Este enfoque se utiliza en muchos servicios de AWS.

"Una flota pequeña causa una flota grande, y no al revés"

Cuando nos recuperamos de una falla masiva, actualizamos la configuración de muchos componentes. ¿Una pregunta típica en este caso es empujar o viñetar una configuración cambiada? ¿Quién es el iniciador de los cambios: la fuente que contiene los cambios de configuración o sus consumidores? Pero estas preguntas están mal. La pregunta correcta es ¿qué flota es más grande?

Considere una situación simple: una gran flota de máquinas virtuales front-end y una cierta cantidad de backends.

Utilizamos un enfoque de malla: los grupos de instancias de front-end funcionarán con ciertos backends. Para hacer esto, determine la ruta: mapeo de backends y frontends que trabajan con ellos.

El enrutamiento estático no es adecuado. Los algoritmos de hash no funcionan bien en fallas masivas, cuando necesita cambiar rápidamente la mayoría de las rutas. Por lo tanto, es mejor usarEnrutamiento dinámico . Junto a las grandes flotas de instancias de front-end y back-end, ponemos un pequeño servicio que solo se ocupará del enrutamiento. Él sabrá y asignará un mapeo de backend y frontend en cualquier momento dado.

Supongamos que tuvimos un gran accidente, muchas instancias de front-end cayeron. Comienzan a recuperarse masivamente y casi simultáneamente solicitan la configuración de mapeo del servicio de enrutamiento.

Un pequeño servicio de enrutamiento es bombardeado con una gran cantidad de solicitudes. No hará frente a la carga, en el mejor de los casos, se degradará y, en el peor de los casos, morirá.

Por lo tanto, es correcto no solicitar cambios de configuración de un servicio pequeño, sino más bien construir su sistema para que el "bebé" mismocambios de configuración iniciados hacia una gran flota de instancias .

Usamos el patrón del trabajo constante. Un pequeño servicio de enrutamiento enviará la configuración a todas las instancias de la flota front-end una vez cada pocos segundos. Nunca podrá sobrecargar un gran servicio. El séptimo patrón ayuda a mejorar la estabilidad y la resistencia .

Los primeros siete patrones mejoran el sistema. El último patrón funciona de manera diferente.

Caída de carga

A continuación se muestra un gráfico clásico del retraso versus la carga. En el lado derecho del gráfico está la "rodilla", cuando a cargas extremadamente altas, incluso un pequeño aumento conduce a un aumento significativo en la latencia.

En modo normal, nunca llevamos nuestros servicios al lado derecho del horario. Una manera fácil de controlar esto es agregar recursos a tiempo. Pero nos estamos preparando para cualquier problema. Por ejemplo, podemos movernos hacia el lado derecho del gráfico recuperándonos de una falla masiva.

Ponemos el tiempo de espera del cliente en el gráfico. Cualquiera puede ser un cliente, por ejemplo, otro componente dentro de nuestro servicio. Por simplicidad, dibujamos un gráfico de retraso del percentil 50.

Aquí nos enfrentamos a una situación llamada apagón . Es posible que esté familiarizado con el término apagón cuando se corta la electricidad en la ciudad. Brownout es cuando algo funciona, pero es tan malo y lento que, cuenta, no funciona en absoluto.

Veamos el apagón de la zona marrón. El servicio recibió una solicitud del cliente, la procesó y devolvió el resultado. Sin embargo, en la mitad de los casos, los clientes ya han agotado el tiempo de espera y nadie está esperando el resultado. En la otra mitad, el resultado regresa más rápido que el tiempo de espera, pero en un sistema lento lleva demasiado tiempo.

Nos enfrentamos a un doble problema: ya estamos sobrecargados y estamos en el lado derecho del cronograma, pero al mismo tiempo todavía estamos "calentando el aire", haciendo mucho trabajo inútil. ¿Cómo evitar esto?

Encuentra la "rodilla" , el punto de inflexión en la tabla . Medimos o estimamos teóricamente.

Soltar el tráfico que nos obliga a ir a la derecha del punto de inflexión .

Simplemente debemos ignorar parte de las solicitudes. Ni siquiera intentamos procesarlos, pero inmediatamente devolvemos un error al cliente. Incluso con sobrecarga, podemos permitirnos esta operación: es "barata". Las solicitudes no se cumplen, se reduce la disponibilidad general del servicio. Aunque las solicitudes rechazadas se procesarán tarde o temprano después de uno o varios reintentos de los clientes.

Al mismo tiempo, otra parte de las solicitudes se procesa con una baja latencia garantizada. Como resultado, no hacemos un trabajo inútil, y lo que hacemos, lo hacemos bien.

Breve resumen de los patrones de diseño de sistemas para fallas

Aislamiento y regulación . A veces tiene sentido priorizar ciertos tipos de consultas. Por ejemplo, con un volumen relativamente pequeño de solicitudes para crear nuevos recursos, se pueden colocar en la parte superior de la cola. Es importante que esto no infrinja a otros usuarios. En una interrupción masiva, los usuarios que esperan que se recuperen sus recursos no sentirán una diferencia significativa.

Trabajo a tiempo completo . Reduzca o elimine completamente el cambio de modos de servicio. Un modo, que funciona de manera estable y constante, independientemente de las situaciones de emergencia o de trabajo, mejora fundamentalmente la estabilidad y la previsibilidad del plano de Control.

Escalamiento preliminar. Escale de antemano con valores de eliminación más bajos. Tendrá que pagar un poco más por esto, pero este es un seguro que vale la pena durante fallas graves del sistema.

Arquitectura celular . Se prefieren muchas células débilmente acopladas sobre un monolito. El enfoque de malla reduce el "radio de explosión" y la probabilidad de errores sorpresa.

El enfoque de múltiples inquilinos mejora significativamente la utilización del servicio, reduce su costo y reduce el "radio de explosión".

Barajar fragmentos . Este es un enfoque que se aplica a los servicios de múltiples inquilinos. Además, le permite controlar el "radio de explosión".

"Una flota pequeña causa una flota grande, y no al revés". Intentamos crear servicios para que los servicios pequeños inicien cambios en configuraciones grandes. A menudo lo usamos junto con un patrón de carga constante.

Dejar caer la carga . En situaciones de emergencia, tratamos de hacer solo un trabajo útil y hacerlo bien. Para hacer esto, descartamos parte de la carga, que todavía no podemos manejar.

— , Saint HighLoad++ Online. -- , Q&A-, , . - . , - .

telegram- @HighLoadChannel — , .

Houston, tenemos un problema. Falla de diseño del sistema