PIXEL FACEBOOK
logo-blanco

Confiabilidad de la plataforma a escala

Lo que vas a encontrar...

Ejecutar cualquier plataforma distribuida escalable requiere un compromiso con la confiabilidad para garantizar que los clientes tengan lo que necesitan cuando lo necesitan. Las dependencias pueden ser bastante complejas, especialmente con una plataforma tan grande como Roblox. Crear servicios confiables significa que, independientemente de la complejidad y el estado de las dependencias, ningún servicio se romperá (es decir, será altamente accesible), funcionará sin errores (es decir, alto calidad) y sin errores (es decir, Tolerancia a fallos🇧🇷

Por qué la confiabilidad es importante

Nuestro equipo de identidad de cuentas está comprometido a lograr una mayor confiabilidad, ya que los servicios de cumplimiento que construimos son componentes críticos de la plataforma. La violación del cumplimiento puede tener consecuencias graves. El costo de bloquear la operación natural de Roblox es muy alto, se necesitan recursos adicionales para recuperarse después de un bloqueo y una experiencia de usuario debilitada.

El enfoque típico de la confiabilidad se enfoca principalmente en la disponibilidad, pero en algunos casos los términos se confunden y se usan incorrectamente. La mayoría de las medidas de disponibilidad solo miden si los servicios están en funcionamiento, mientras que aspectos como la tolerancia y la consistencia de la partición a veces se pasan por alto o se malinterpretan.

De acuerdo con el teorema CAP, cualquier sistema distribuido puede garantizar solo dos de estos tres aspectos, por lo que nuestros servicios de cumplimiento sacrifican algo de consistencia para ser altamente disponibles y tolerantes a la partición. Sin embargo, nuestros servicios sacrificaron poco y encontraron mecanismos para lograr una buena coherencia con los cambios arquitectónicos razonables que se explican a continuación.

El proceso para lograr una mayor confiabilidad es iterativo, con una medición rigurosa combinada con un trabajo continuo para prevenir, localizar, detectar y corregir defectos antes de que ocurran incidentes. Nuestro equipo identificó un gran valor en las siguientes prácticas:

Medición correcta: construya una observabilidad completa sobre cómo se entrega la calidad a los clientes y cómo las instalaciones nos entregan calidad. Anticipación proactiva: realice actividades como revisiones de arquitectura y evaluaciones de riesgo de dependencia. Priorizar la remediación: preste mayor atención a la resolución de informes de incidentes para el servicio y las dependencias que están vinculadas a nuestro servicio.

Construir una mayor confiabilidad requiere una cultura de calidad. Nuestro equipo ya ha estado invirtiendo en desarrollo orientado al rendimiento y sabe que el éxito de un proceso depende de su adopción. El equipo adoptó completamente este proceso y aplicó las prácticas como un estándar. El siguiente diagrama destaca los componentes del proceso:

jagonzalez.org | | Confiabilidad de plataforma a escala

El poder de la medición correcta

Antes de profundizar en las métricas, hay una aclaración rápida que hacer sobre las mediciones del nivel de servicio.

SLO (Objetivo de nivel de servicio) es el objetivo de confiabilidad que busca nuestro equipo (es decir, 99,999%). SLI (Indicador de nivel de servicio) es la confiabilidad alcanzada durante un período de tiempo (es decir, 99,975% en febrero pasado). SLA (Acuerdo de Nivel de Servicio) es la confiabilidad acordada para entregar y que nuestros clientes esperan en un cierto período de tiempo (es decir, 99.99% por semana).

El SLI debe reflejar la disponibilidad (sin respuestas no controladas o faltantes), tolerancia a fallas (sin errores de servicio) y calidad lograda (sin errores inesperados). Por lo tanto, definimos nuestro SLI como el “índice de éxito” de respuestas exitosas al total de solicitudes enviadas a un servicio. Las respuestas exitosas son aquellas solicitudes que fueron despachadas en tiempo y forma, es decir que no hubo conectividad, servicio o errores inesperados.

Este SLI o tasa de éxito se recoge desde el punto de vista de los consumidores (es decir, los clientes). La intención es medir la experiencia real de extremo a extremo brindada a nuestros clientes para que podamos estar seguros de que se cumplirán los SLA. No hacerlo crearía una falsa sensación de confiabilidad que ignora todas las preocupaciones de infraestructura para conectarse con nuestros clientes. Al igual que el SLI del consumidor, recopilamos el SLI de dependencia para rastrear cualquier riesgo potencial. En la práctica, todos los SLA de dependencia deben estar en línea con el SLA de servicio y existe una dependencia directa de ellos. El fracaso de uno implica el fracaso de todos. También rastreamos e informamos las métricas del propio servicio (es decir, el servidor), pero esta no es la fuente práctica de alta confiabilidad.

Además de los SLI, cada compilación recopila métricas de calidad que informa nuestro flujo de trabajo de CI. Esta práctica ayuda a reforzar las puertas de calidad (es decir, la cobertura del código) y a informar otras métricas significativas, como el cumplimiento de los estándares de codificación y el análisis de código estático. Este tema fue tratado anteriormente en otro artículo, Creación de microservicios basados ​​en el rendimiento🇧🇷 La adherencia diligente a la calidad se suma cuando se habla de confiabilidad, ya que cuanto más invertimos para lograr puntajes excelentes, más seguros estamos de que el sistema no fallará en condiciones adversas.

Nuestro equipo tiene dos paneles. One le brinda toda la visibilidad de SLI de consumidor y SLI de dependencia. El segundo muestra todas las métricas de calidad. Estamos trabajando para fusionar todo en un solo tablero, de modo que todos los aspectos que nos interesan estén consolidados y listos para ser informados en cualquier momento.

Anticiparse al fracaso

Haciendo reseñas de arquitectura es una parte clave de ser digno de confianza. Primero, determinamos si existe redundancia y si el servicio tiene los medios para sobrevivir cuando las dependencias disminuyen. Además de las ideas típicas de replicación, la mayoría de nuestros servicios han aplicado técnicas mejoradas de hidratación de caché dual, estrategias de recuperación dual (como las colas locales de conmutación por error) o estrategias de pérdida de datos (como el soporte transaccional). Estos temas son lo suficientemente extensos como para justificar otra entrada de blog, pero, en última instancia, la mejor recomendación es implementar ideas que consideren escenarios de desastre y minimicen las penalizaciones de rendimiento.

Otra cosa importante a tener en cuenta es cualquier cosa que pueda mejorar la conectividad. Esto significa ser agresivo con respecto a la baja latencia para los clientes y prepararlos para un tráfico muy alto utilizando técnicas de control de caché, sidecars y políticas de alto rendimiento para tiempos de espera, disyuntores y reintentos. Estas prácticas se aplican a cualquier cliente, incluidos cachés, almacenes, colas y clientes interdependientes a través de HTTP y gRPC. También significa mejorar las señales de salud de los servicios y comprender que los controles de salud juegan un papel importante en toda la orquestación de contenedores. La mayoría de nuestros servicios emiten mejores señales de degradación como parte de los comentarios de verificación de estado y verifican que todos los componentes críticos funcionen antes de enviar señales de estado.

Dividir los servicios en partes críticas y no críticas ha demostrado ser útil para centrarse en la funcionalidad más importante. Solíamos tener puntos finales solo para administradores en el mismo servicio y, aunque no se usaban con frecuencia, afectaban las métricas de latencia generales. Cambiarlos a su propio servicio impactó todas las métricas en una dirección positiva.

Evaluación del riesgo de adicción es una herramienta importante para identificar posibles problemas con las dependencias. Esto significa que identificamos dependencias con bajo SLI y solicitamos la alineación de SLA. Estas dependencias necesitan atención especial durante los pasos de integración, por lo que nos tomamos más tiempo para comparar y probar si las nuevas dependencias son lo suficientemente maduras para nuestros planes. Un buen ejemplo es la adopción temprana que tuvimos para Roblox Storage-as-a-Service. La integración con este servicio requería el registro de tickets de errores y reuniones periódicas de sincronización para comunicar hallazgos y comentarios. Todo este trabajo utiliza la etiqueta de “confiabilidad” para que podamos identificar rápidamente su origen y prioridades. La caracterización se realizó con frecuencia hasta que estuvimos seguros de que la nueva dependencia estaba lista para nosotros. Este trabajo adicional ayudó a llevar la dependencia al nivel requerido de confiabilidad que esperamos brindar al actuar juntos hacia un objetivo común.

Llevar estructura al caos

Nunca es deseable tener incidentes. Pero cuando suceden, hay información importante para recopilar y aprender a ser más confiable. Nuestro equipo tiene un informe de incidentes del equipo que se construye más allá del típico informe de toda la empresa, por lo que nos enfocamos en todos los incidentes, independientemente de la escala de su impacto. Identificamos la causa raíz y priorizamos todo el trabajo para mitigarla en el futuro. Como parte de este informe, reunimos a otros equipos para remediar incidentes de adicción de alta prioridad, realizar un seguimiento de la resolución adecuada, mirar hacia atrás y buscar patrones que puedan aplicarse a nosotros.

El equipo produce un Reporte Mensual de Confiabilidad por Servicio esto incluye todos los SLI explicados aquí, todos los tickets que abrimos por razones de confiabilidad y cualquier incidente potencial asociado con el servicio. Estamos tan acostumbrados a generar estos informes que el siguiente paso natural es automatizar su extracción. Hacer esta actividad periódicamente es importante y es un recordatorio de que la confiabilidad es constantemente rastreada y considerada en nuestro desarrollo.

jagonzalez.org | | 1657420900 368 Confiabilidad de plataforma a escala

Nuestra instrumentación incluye métricas personalizadas y alertas mejoradas para que se nos notifique lo más rápido posible cuando ocurran problemas conocidos y esperados. Todas las alertas, incluidos los falsos positivos, se revisan cada semana. En este punto, es importante pulir toda la documentación para que nuestros clientes sepan qué esperar cuando se activen las alertas y cuando ocurran errores, y luego todos sepan qué hacer (por ejemplo, los libros de estrategias y las pautas de incorporación se alinean y actualizan con frecuencia).

En última instancia, adoptar la calidad en nuestra cultura es el factor más crítico y decisivo para lograr una mayor confiabilidad. Podemos observar cómo estas prácticas aplicadas a nuestra vida diaria ya están dando sus frutos. Nuestro equipo está obsesionado con la confiabilidad y este es nuestro logro más importante. Hemos aumentado nuestra conciencia sobre el impacto que pueden tener los posibles defectos y cuándo se pueden introducir. Los servicios que han implementado estas prácticas han cumplido consistentemente con sus SLO y SLA. Los informes de confiabilidad que nos ayudan a realizar un seguimiento de todo el trabajo que hacemos son prueba del trabajo que ha realizado nuestro equipo y representan lecciones invaluables para informar e influir en otros equipos. Es así como la cultura de la confiabilidad afecta a todos los componentes de nuestra plataforma.

El camino hacia una mayor confianza no es fácil, pero es necesario si desea crear una plataforma confiable que reinvente la forma en que las personas se conectan.

Alberto es el ingeniero de software principal del equipo de identidad de la cuenta de Roblox. Ha estado en la industria del juego durante mucho tiempo, con créditos en muchos títulos de juegos AAA y plataformas de redes sociales con un fuerte enfoque en arquitecturas altamente escalables. Ahora está ayudando a Roblox a lograr el crecimiento y la madurez aplicando las mejores prácticas de desarrollo.

Facebook
Twitter
LinkedIn
WhatsApp

Deja una respuesta

Artículos Relacionados

Síguenos