Hay muchas publicaciones sobre cómo es una típica entrevista de codificación en Google. Pero, aunque no es tan ampliamente descrito y discutido, a menudo también hay una entrevista de diseño del sistema. Para una posición SRE es NALSD: diseño de sistema grande no abstracto. La diferencia clave entre las entrevistas SWE y SRE consiste en estas dos letras: NA.
Entonces, ¿cuál es la diferencia? ¿Cómo estar preparado para esta entrevista? Seamos no abstractos y usemos un ejemplo. Para ser más no abstractos, tomemos algo del mundo material, de modo que no se le pregunte exactamente lo mismo en la entrevista real (al menos, no en la entrevista de Google) :)
Entonces, diseñemos un sistema de biblioteca pública. Para los libros de papel, como has visto en todas partes. El texto completo a continuación fue escrito de una vez en aproximadamente una hora, para mostrarle aproximadamente las áreas que debería poder cubrir / tocar durante la entrevista. Por favor, disculpe algún desorden, así es como pienso (por lo tanto, soy).
Entrevista NALSD: diseño de un sistema de biblioteca pública.
En primer lugar, reunimos características de carga, ya sea a través de preguntas al entrevistador, o haciendo una suposición razonable (sin olvidar decirlo en voz alta). Dado que la entrevista se refiere a sistemas escalables, esperamos una ciudad con una gran población (digamos, 1M +). Tenemos algunas opciones: un gran edificio o bibliotecas locales más almacenamiento. Creo que esto último es más razonable, ya que también nos permite expandir el sistema a múltiples ciudades.
Ahora centrémonos en el sistema para una sola ciudad; deberíamos poder aplicar el mismo diseño (con correcciones menores) nuevamente para expandirlo a nivel de país. Entonces, tenemos una ciudad con más de 1 millón de habitantes. Para facilitar los cálculos, redondeemos a 1 millón de posibles lectores. Todo lector quiere leer algo independientemente del otro lector, en momentos arbitrarios en el tiempo. Entonces podemos modelar el flujo de lectores como un proceso de Poisson. Hacer las matemáticas correctamente es un poco difícil durante el período de la entrevista, así que simplifiquemos una vez más, y solo digamos que aproximadamente el 1% de los posibles lectores vendrían a tomar un libro todos los días. Por lo tanto, presumir 10000 solicitudes de libros por día.
Entonces, nuestra tarea ahora se convirtió en: proporcionar la capacidad de entregar 10000 libros por día (eso también significa que necesitamos poder recuperar estos 10000 libros algún día más tarde) en una ciudad de 1M +. Esta estimación muestra que la solución de construcción única no se mantendrá (para proporcionar los libros para las personas de 1M +, nuestra biblioteca debe ser accesible dentro de un período de tiempo razonable, de lo contrario su voluntad de tomar un libro se agota en el embotellamiento). Entonces, intentemos adivinar cuál es un tamaño razonable para las bibliotecas locales que tenemos que construir. Una estimación absolutamente correcta implicaría la densidad de población, latencias de accesibilidad, etc., pero como esto no afectará el diseño general, nuevamente podemos simplificarlo considerando una distribución uniforme de unidades similares. Todavía no sabemos qué tan grandes deberían ser las unidades; por ejemplo, podríamos distribuir 10000 bibliotecas con 1 libro en toda la ciudad, pero obviamente no funcionará. Yendo un nivel más bajo.
Una sola unidad de biblioteca local. Para que sea útil, la mayoría de los visitantes deberían poder encontrar el libro que desean. Eso significa que necesitamos rastrear el uso y pronosticar la demanda de las solicitudes más populares para estar listos para atenderlas. Además, deberíamos tener una amplia gama de artículos menos populares. Mi suposición aproximada es una biblioteca con menos de 1000 nombres de libros, con docenas de copias para los más populares y piezas sueltas para las colas. El tiempo promedio para leer un libro en nuestra biblioteca varía de 3 días a 2 semanas (por supuesto, el tiempo real depende del libro en sí, lo que en un caso real requeriría un análisis adicional); vamos a estimar como 1 semana por libro. Eso significa que un libro que se entregó volverá en 1 semana, por lo que deberíamos tener el suministro de los mejores libros para 1 semana (después de una semana se reponen de las devoluciones).
Supongamos un factor de expansión promedio de 6, que nos llevaría a una capacidad de almacenamiento de 6000 libros. Menos almacenamiento significaría una escasez en los nombres más populares (bueno, las unidades más pequeñas aún podrían ser útiles, como un pequeño kiosco de centro comercial con "Crepúsculo", pero mantengámoslo fuera de nuestro diseño ahora).
En un estado estable, los retornos y los préstamos todos los días son casi similares (con cierta dispersión), pero también debemos planificar los retornos máximos (que podrían ser eventos de sincronización externos: vacaciones, tendencias, etc.). La forma correcta es hacer y ejecutar un modelo estadístico. Pero por ahora, mantengamos ⅓ como un búfer. Eso significa que deberíamos tener 6000 libros listos para repartir más espacio para el 2000.
En resumen: necesitamos una unidad de biblioteca con 8000 libros de almacenamiento. Se espera que sea costoso reabastecerlo todos los días, por lo que deberíamos esperar que esto sea suficiente durante una o dos semanas. Dos semanas, 6000 libros, con posibles retornos sesgados, son alrededor de 300 libros por día. Para el día de apertura, podemos llenar todo el almacenamiento (8000 libros) para sembrar el volumen inicial de 2000 de libros. 2000 en 3 días = 600 libros al día, con búfer de inclinación = 800 libros al día.
Calculemos el rendimiento y las limitaciones de nuestro almacenamiento. 1 libro tiene alrededor de 2 cm lineales de espacio, 8000 libros = 160 metros. Podemos doblarlo verticalmente 4 veces, por lo que son 40 metros lineales. Si lo dividimos en bastidores de ~ 5 metros, obtendremos 8 bastidores con 4 estantes, cada uno de 5 metros de largo. Un bibliotecario (o robo-bibliotecario) debería poder trabajar con dos bastidores; la extracción de un solo libro tomará: 5 segundos para caminar hacia los estantes, 5 segundos para agarrar / poner el libro en su lugar, 5 segundos para caminar de regreso (15 segundos en total). 4 bibliotecarios nos darán un rendimiento máximo de 15 libros por minuto. Por lo tanto, un manejo de 900 libros por hora como máximo.
Si también tenemos en cuenta el tiempo de manejo de la solicitud (10s), el tiempo de búsqueda (5s), el tiempo de seguimiento en el sistema (2s), obtendremos un pico de 400 libros / hora. Por lo tanto, deberíamos poder manejar nuestra estimación de 800 libros al día en 2 horas.
Calculemos otros aspectos: para poder entregar 400 libros / hora por 4 bibliotecarios, necesitamos tener suficiente espacio para 100 personas esperando en la fila, y las puertas de entrada deben permitir que 400 personas / hora pasen en ambas direcciones. . Eso significa que nuestro principal estrangulamiento sería el espacio de espera y las puertas del edificio.
Eso significa que deberíamos poder encontrar un equilibrio óptimo entre el espacio de almacenamiento y el área de espera durante los cálculos adecuados para el diseño real.
Eso es todo para este nivel, es hora de seguir adelante. Tenemos una estimación de las demandas generales de la red de bibliotecas como 10000 libros / día. Una unidad es de 800 libros / día, por lo que necesitamos 12.5 unidades. Si hacemos una distribución geográfica uniforme, cada lector debe estar dentro del rango de 1-2 unidades (en el límite de la ciudad) y 3-4 (dentro de la ciudad). Eso le daría la capacidad de suavizar un poco los picos y / o cubrir la escasez de los mejores libros.
También sabemos que todas las bibliotecas se pueden cerrar en cualquier momento (incendio, inspección, repintado de manijas de las puertas del refrigerador, etc.), y que cuantas más unidades tengamos, mayor será la probabilidad de coincidencia de estos eventos. Por lo tanto, necesitamos 1 unidad redundante por cada 5-6 unidades. Entonces, en total, necesitamos 15 unidades para cumplir con las demandas de nuestra ciudad, si mantenemos el suministro requerido dentro de cada unidad.
Como ya pensamos anteriormente, necesitamos reponer el almacenamiento cada semana o dos (antes adivinamos dos): alrededor de la mitad del almacenamiento debe reemplazarse, para seguir las tendencias, etc. Entonces 4000 libros de nueva entrega y 4000 libros eliminados de él. En cada reabastecimiento, necesitamos extraer 4000 libros e insertar 4000 nuevas entradas. Con nuestro rendimiento de 400 libros / hora, un reabastecimiento será de 10 horas muy intensas. Bueno, todavía parece estar bien, especialmente porque las operaciones masivas suelen ser más baratas; pero de todos modos, debemos tener en cuenta que la operación de reposición es 5 veces más costosa que solo servir.
Un libro promedio (2cm * 20cm * 30cm) tiene 1.5 litros de volumen, entonces 4000 libros = 6 metros cúbicos. Esto debería caber en un solo vehículo de carga ligera promedio. 1 metro cúbico de papel pesa 600 kg, 6 m ^ 3 = 3.6 toneladas. Un vehículo de carga liviano promedio puede manejar ~ 1.5 toneladas, por lo que necesitamos 3 de ellos. Más uno para redundancia. Tenemos 15 unidades de biblioteca que se actualizan una vez cada 2 semanas, lo que significa que este sería un horario apretado, por lo que necesitamos un automóvil más.
Y todavía no pensamos cómo y de dónde moverían estos autos los libros, por lo que nuestro diseño también necesitará almacenes de proveedores y puntos de recolección de basura para libros que ya no son populares ...
Se acabó el tiempo. Entonces, ¿qué tiene de especial la pregunta NALSD? Se espera escalabilidad de cualquier diseño de sistema grande. Pero en una entrevista NALSD, uno tiene que ser
específico .
Puede ver arriba muchas suposiciones y suposiciones, pero todos los cálculos se basaron en números realizados previamente. También he tratado de explicar cómo llegar al número correcto, pero es fácil cansarse / aburrirse y comenzar a fallar para hacerlo. Además, es fácil quedarse con algún número de su memoria, sin proporcionar una buena explicación de sus razones ... Pero dado que el diseño es muy específico, si comete un error con cualquier número, puede cambiar el número y volver a calcular el resto.
Todavía recuerdo cómo durante mi entrevista NALSD me quedé con IOPS de un solo HDD igual a 600, solo porque había trabajado recientemente en la optimización de una matriz de incursiones, donde toda la matriz tenía 600 IOPS ... El entrevistador se sorprendió un poco: 600 IOPS por conducir? : DDurante la entrevista, el entrevistador podría corregir cualquiera de sus suposiciones y conjeturas. Además, el entrevistador podría agregar algunas restricciones adicionales (que olvidó, no sabía, no preguntó o simplemente ajustó la tarea porque le gustaría o cree que esta es una mejor manera de continuar). Como está operando únicamente con números específicos, eso requeriría pequeñas actualizaciones de números siguiendo las ecuaciones ya dadas.
Si la corrección de una suposición requiere un rediseño completo del sistema, es un error de diseño o una corrección incorrecta, o la nueva suposición nos lleva más allá de la aplicabilidad del diseño (y no es tan raro en la vida real). Es importante no perderse este hecho: debe validar los números que obtiene, para asegurarse de que sean realistas, tanto durante el diseño como después de cualquier corrección.
Como SRE, tenemos que pensar en la escalabilidad de los sistemas reales dentro de las limitaciones de las limitaciones reales del hardware. Podría haber un
algoritmo hermoso que intercambia una complejidad de tiempo gigantesca a una cierta cantidad de RAM ... Pero aún así, 1PiB de RAM por 1 CPU no es algo que podamos construir hoy. Entonces, si tenemos 1 PiB de RAM, también tenemos alrededor de 10k CPU. O 20k. O incluso 30k. Eso significa que debemos centrarnos en el óptimo real (local), accesible hoy en realidad, y no en el óptimo global accesible en condiciones ideales.
No debe recordar números precisos, pero debe poder aplicar reglas generales para obtener órdenes de magnitud. Como, IOPS: HDD es de alrededor de 100s, SSD es de alrededor de 100s miles. Pero estos miles de miles vienen con una diferencia de precio entre HDD y SSD, como 1: 3 o 1: 4. También está ignorando todo: espacio en bastidor, blades para las unidades, puertos de red y otras cosas, que ya no son baratas una vez que trabajas en peta y exa-escalas.
Ahora póngase cómodo en su silla, relájese e intente diseñar un sistema de crecimiento y entrega de huevos de gallina frescos con suscripción.