A/Briendo los testes: La Plataforma de Experimentación de Netflix

13/09/16

Ya se preguntó cómo Netflix brinda una excelente experiencia de streaming de video, con alta calidad y con el mínimo de interrupciones en la reproducción? Gracias al equipo de ingenieros y científicos de datos que aplican pruebas A/B constantemente a sus innovaciones para nuestros algoritmos de entrega de contenido y transmisión personalizada. Y en cuanto a los cambios más obvios, como la reformulación completa de nuestro layout de la interfaz de usuario o de nuestra nueva página inicial personalizada? Sí, todo es resultado de pruebas A/B.

Cada cambio de producto que Netflix considera pasa por un proceso riguroso de pruebas A/B antes de pasar a ser la experiencia padrón del usuario. Grandes alteraciones en el diseño, como los de arriba, mejoran mucho el servicio al permitir que miembros encuentren más rápido el contenido que ellos quieren ver. Sin embargo, es muy arriesgado publicar este tipo de rediseño sin extensas pruebas A/B, que permiten probar que la nueva experiencia tuvo más éxito que la anterior. Y si usted ya se preguntó si la intención es realmente probar todo lo que se pueda, sepa que hasta las imágenes asociadas con muchos títulos pasaron por pruebas A/B, a veces resultando de 20% a 30% más de visualización para ese título!

Resultados como estos demuestran porque somos fanáticos de las pruebas A/B. Al seguir un camino empírico, podemos garantizar que las modificaciones del producto no son guiadas por adivinanzas de los funcionarios de Netflix, y si por datos reales, permitiendo que nuestros propios clientes nos guíen en dirección de las experiencias que ellos aman.

En este post vamos a hablar sobre la Plataforma de Experimentos: el servicio que hace posible para cada equipo de ingeniería de Netflix implementar sus pruebas A/B con el apoyo de un equipo de ingeniería especializada. Vamos a comenzar definiendo un contexto de alto nivel en torno a las pruebas A/B antes de hablar de arquitectura de nuestra plataforma actual y como otros servicios se integran con la plataforma para traer una prueba A/B a la vida.

Visión General

El concepto general detrás de las pruebas A/B es crear un experimento con un grupo control y uno o más grupos experimentales (llamadas «células» dentro de Netflix) que reciben tratamientos alternativos. Cada miembro pertenece exclusivamente a una célula dentro de un experimento dado y una célula siempre que se conoce como «célula estándar». Esta célula es el grupo de control, recibiendo la misma experiencia que todos los miembros de Netflix fuera de la prueba. Una vez que la prueba comienza a correr, seguimos las métricas específicas de más importancia, por lo general (pero no siempre) horas de streaming y retención. Una vez que tenemos suficientes participantes para sacar conclusiones estadísticamente significativas, podemos obtener una lectura sobre la efectividad de cada célula de prueba y encontrar un ganador.

Desde el punto de vista del participante, cada miembro es generalmente parte de varias pruebas A/B en un momento dado, siempre que las pruebas no entren en conflicto entre sí (dos pruebas que modifiquen la misma área de una aplicación de Netflix de diferentes maneras). Para ayudar a los propietarios a rastrear conflictos potenciales, ofrecemos un programa de pruebas schedule view en ABlaze, o front-end de nuestra plataforma. Esta herramienta le permite filtrar las pruebas en diferentes dimensiones para encontrar otras pruebas que pueden afectar a un área similar.

netflix-1

Hay un tema más para resolver antes de profundizar en los detalles: cómo los participantes se asignan a una prueba en particular. Se admiten dos formas principales de asignación: por lotes y en tiempo real.

Las asignaciones del lote dan a los analistas la máxima flexibilidad, lo que les permite completar las pruebas tanto con las consultas personalizadas simples como con las complejas, conforme sea necesario. Estas consultas devuelven un conjunto fijo y conocido de los miembros que se añaden a la prueba. Las principales desventajas de este enfoque es que no tiene la capacidad de asignar nuevos clientes y no puede asignar basándose en el comportamiento del usuario en tiempo real. Y si bien se conoce el número de miembros asignados, no podemos garantizar que todos los miembros asignados pasará la prueba (por ejemplo, si estamos probando una nueva característica en un iPhone, no podemos estar seguros de que cada participante asignado accederá al Netflix en un iPhone mientras la prueba está activa).

Asignaciones en tiempo real, proporcionan a los analistas la capacidad de configurar las reglas que se evalúan conforme el usuario interactúa con Netflix. Usuarios aceptados se incluyen en la prueba en tiempo real, siempre que cumplan los criterios especificados en las reglas y no se encuentren actualmente en una prueba en conflicto. Como resultado, este enfoque supera las debilidades inherentes en el enfoque por lotes. La principal desventaja para la asignación en tiempo real, sin embargo, es que la aplicación incurre en latencia adicional esperando los resultados de asignación. Afortunadamente, a menudo se puede realizar esta llamada en paralelo mientras la aplicación está esperando otra información. Una cuestión secundaria con la asignación en tiempo real es que es difícil estimar cuánto tiempo tomará para que el número necesario de miembros sea asignado a una prueba con el fin de determinar el momento en que puedan evaluar los resultados.

El típico flujo de trabajo de una prueba A/B

Con este background ya podemos hacer un análisis más profundo. El flujo de trabajo típico que participa la Plataforma de Experimentación (referida como A/B en los diagramas) se explica mejor con el siguiente flujo de trabajo a una prueba de selección de imágenes. Tenga en cuenta que hay matices en el siguiente diagrama, que no se tratará en profundidad, sobre todo la arquitectura de la capa API de Netflix, que actúa como puerta de enlace entre las aplicaciones externas de Netflix y servicios internos.

En este ejemplo, estamos ejecutando una prueba A/B hipotética con el fin de encontrar la imagen que se traduce en un mayor número de miembros que asisten un título específico. Cada celda representa una imagen. En el diagrama también estamos dando un flujo de llamadas a partir de un Netflix App siendo ejecutado en un PS4, aún que el mismo flujo es válido para la mayoría de nuestros Device Apps.

netflix-2

  1. 1. La aplicación de Netflix PS4 llama a la API de Netflix. Como parte de esta convocatoria, que proporciona una carga JSON que contiene información sobre el nivel de sesión relacionada con el usuario y el dispositivo.
  1. La llamada se procesa en un script escrito por el equipo de PS4 App. Este script se ejecuta en el Client Adaptor Layer de la API de Netflix, donde cada equipo de Client App agrega secuencias de comandos relevantes para su aplicación. Cada uno de estos scripts viene completo con sus propios terminales REST distintos. Esto permite que la API de Netflix tenga funcionalidad común a la mayoría de aplicaciones, dando a cada control sobre su aplicación lógica específica. La aplicación de secuencias de comandos PS4 ahora llama al Cliente A/B, una biblioteca de nuestro equipo se mantiene dentro de la API de Netflix. Esta biblioteca permite la comunicación con nuestros servidores de back-end, así como otros servicios internos de Netflix.
  1. El A/B Client llama a una serie de otros servicios para reunir un contexto adicional sobre el miembro y el dispositivo.
  1. El A/B Client llama al A/B Server para evaluación, pasando por todo el contexto del mismo.
  1. En la fase de evaluación:
  2.       El A/B Server recupera todas las combinaciones de prueba/célula a la que ya ha sido asignado a este miembro.
  3.       Para las pruebas utilizando el enfoque de asignación de lotes, las asignaciones son ya conocidas en esta etapa.
  4.       Para los ensayos que utilizan la asignación en tiempo real, el A/B Server evalúa el contexto para ver si el miembro ha de ser beneficiario de cualquier prueba adicional.
  5.       Una vez que todas las evaluaciones y tareas se han completado, el A/B Server pasa el conjunto completo de células de ensayo y para el A/B Client, que a su vez pasa a la secuencia de comandos de la PS4 App. Tenga en cuenta que la PS4 App tiene ni idea de si el usuario está en una prueba en particular durante semanas o sólo en los últimos microsegundos. Él no necesita saber o preocuparse por eso.
  1. Dada las combinaciones de prueba/célula devueltas a él, el PS4 App Script ahora funciona en todas las pruebas aplicables a la solicitud del cliente actual. En nuestro ejemplo, se utilizará esta información para seleccionar la pieza apropiada de arte asociado con el título tiene que mostrar, que es devuelto por el servicio que lleva a cabo tales metadatos título. Tenga en cuenta que la Plataforma de Experimentación en realidad no controla este comportamiento: esta es la misión de servicio que se ajusta en realidad cada experiencia dentro de una prueba en particular.
  1. El PS4 App Script (a través de la API Netflix) «dice» a la PS4 App cuál imagen se mostrará, junto con todas las demás operaciones que la App PS4 debe llevar a cabo con el fin de procesar correctamente la interfaz de usuario.

Ahora que entendemos el flujo de llamadas, vamos a echar un vistazo a lo que conocemos por «A/B Server».

La Plataforma de Experimentación

netflix-3

Las solicitudes de asignación y recuperación descritos en la sección anterior pasan por los terminales de API REST para nuestro servidor. Metadatos de ensayo para cada prueba, incluyendo las reglas de asignación, se almacenan en un almacén de datos Cassandra.Son estas reglas de asignación que se comparan con el pasado contexto del A/B Client con el fin de determinar la elegibilidad de un miembro de participar en un test (por ejemplo, un usuario en Australia con una PS4 que nunca había utilizado esta versión de la aplicación para PS4).

Asignaciones de los miembros también son persistentes en Cassandra, dirigidas por una capa de almacenamiento en caché en forma de un cluster EVCache, que sirve para reducir el número de llamadas directas a Cassandra. Cuando una aplicación realiza una solicitud para asignaciones actuales, el A/B Client busca primero en el EVCache por los registros de asignación de este usuario. Si esta información ha sido solicitada previamente en las últimas 3 horas (TTL para nuestro caché), una copia de las asignaciones se volvió de EVCache. Si no es así, el A/B del servidor hace una llamada directa a Cassandra, pasando asignaciones de nuevo a la A/B de cliente y, simultáneamente, llenándolas en EVCache.

Cuando hay asignaciones para la prueba A/B, tenemos que decidir en qué célula colocar cada miembro. Este paso debe ser trabajado con cuidado, ya que la población en cada célula debe ser lo más homogénea posible con el fin de sacar conclusiones estadísticamente significativas del teste. La homogeneidad se mide en relación a un conjunto de cuestiones fundamentales, tales como país y tipo de dispositivo (es decir, Smart TV, consola de juegos, etc.) son los más destacados. En consecuencia, nuestro objetivo es asegurar que cada célula contiene una proporción similar de miembros de cada país, utilizando proporciones similares de cada tipo de dispositivo, etc. Un muestreo puramente aleatorio puede deteriorar los resultados de la prueba si, por ejemplo, asignar más usuarios de la consola de Australia en una célula con respecto a otra. Para mitigar este problema se emplea un método de muestreo llamado muestreo estratificado, que tiene como objetivo mantener la homogeneidad entre las principales dimensiones antes mencionadas. Hay una buena cantidad de complejidad a nuestra aplicación muestra estratificada, que tenemos la intención de compartir en un futuro post.

En el último paso del proceso de asignación, persistimos detalles de asignación de Cassandra y invalidamos los cachés A/B asociada a este miembro. Como resultado, la próxima vez que reciba una solicitud de asignación en relación con esta persona, vamos a experimentar una pérdida de memoria caché y ejecutar las etapas relacionadas con la memoria caché que describimos anteriormente.

También publicamos simultáneamente eventos de asignación a una pipeline de datos Kafka, que se alimenta de múltiples almacenes de datos. El feed publicado en las tablas Hive proporciona una fuente de datos para el análisis ad-hoc y Ignite, la herramienta interna de Netflix para la visualización y análisis de tests A/B. Es dentro de Ignite que los propietarios de prueba analizan las métricas y evalúan los resultados de una prueba. Este tema dará otro post centrado en Ignite en un futuro próximo.

Los últimos cambios en nuestra tecnología han añadido Spark Streaming, que ingiere y transforma los flujos de datos Kafka antes de ellos persisten en ElasticSearch, que nos permite mostrar actualizaciones casi en tiempo real en ABlaze. Nuestros casos de uso actuales implican métricas simples, lo que permite a los usuarios ver las asignaciones de prueba en tiempo real a través de las dimensiones de interés. Sin embargo, estas adiciones han sentado las bases para un análisis en tiempo real mucho más sofisticado en un futuro próximo.

Proyectos futuros

La arquitectura descrita aquí ha funcionado bien para nosotros hasta ahora. Seguimos apoyando un número creciente de áreas: la interfaz de usuario, recomendaciones, reproducción, búsqueda, e-mail, subscription y muchos más. A través del auto-scaling, lidiamos sin problemas con el tráfico normal de nuestra plataforma, que va desde 150K a 450K solicitudes por segundo. Del punto de vista responsivo, latencias que buscan asignaciones existentes varían de un promedio de 8 ms cuando nuestro caché es frío a <1 ms, cuando la caché está caliente. Las calificaciones en tiempo real tardan un poco más, con una latencia media de alrededor de 50 ms.

Sin embargo, como nuestra base de miembros continúa ampliando de manera global, la velocidad y el alcance de las pruebas A/B está creciendo rápidamente. Sólo para contextualizar, la arquitectura general que acabamos de describir ya fue utilizada desde 2010 (con algunas excepciones obvias, como Kafka). Desde entonces:

     – Netflix creció de streaming en dos países a más de 190

     – Hemos pasado de 10 millones de miembros a más de 80 millones

     – Pasamos de docenas de dispositivos de miles de personas, muchas de ellas con su propia aplicación de Netflix

La expansión internacional es parte de la razón por la que estamos viendo un aumento en los tipos de dispositivos. En particular, hay un aumento en el número de dispositivos móviles utilizados para transmitir Netflix. En este escenario, tenemos gran cantidad de asignaciones, como nuestro enfoque actual de asignación en tiempo real simplemente no funciona: el ancho de banda en los dispositivos móviles no es lo suficientemente confiable para una aplicación que nos espere antes de decidir lo que la experiencia sirva todo esto … mientras el usuario está impaciente mirando a una pantalla de carga.

Por otra parte, algunas nuevas áreas de innovación resultado de pruebas A/B en un tiempo mucho más corto que antes. Pruebas centradas en los cambios en la interfaz de usuario, algoritmos de recomendación y otros a menudo corren por semanas antes de que  se pueda medir con claridad sus efectos sobre el comportamiento de los usuarios. Sin embargo, las pruebas de adaptación de streaming mencionados anteriormente en esta entrada se llevan a cabo en cuestión de horas.

Como resultado, hay varios aspectos de nuestra arquitectura que estamos planeando para renovar de manera significativa. Por ejemplo, mientras que el mecanismo de asignación en tiempo real permite un control granular, las evaluaciones tienen que ser más rápidas y deben interactuar de manera más eficiente con los dispositivos móviles.

 

También tenemos la intención de aprovechar los datos que fluyen a través del Spark Streaming para comenzar a predecir tasas de asignación de testes, teniendo en cuenta las reglas de asignación. El objetivo es resolver la segunda principal desventaja del enfoque de atribución en tiempo real, que es la incapacidad de predecir la cantidad de tiempo necesario para obtener suficientes miembros asignados en el teste. Dar a los analistas la capacidad de predecir las tasas de asignación permitirá la planificación y coordinación de testes con más precisión.

Estos son sólo algunos de nuestros próximos desafíos. Si usted está simplemente curioso por saber más acerca de cómo trataremos con ellos, permanezca atento a las próximas entradas. Sin embargo, si la idea de resolver estos retos y ayudar a construir la siguiente generación de plataforma de ensayos Netflix te excita, no dude en ponerse en contacto con nosotros!

Texto original por Steve Urbano, Rangarajan Sreenivasan y Vineet Kannan.

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.