PROPÓSITO DEL SISTEMA DE SERVICIO PARA COMPARTIR VÍDEOS
Youtube es el servicio para compartir vídeos basado en anuncios que permite a los usuarios cargar contenido multimedia basado en vídeos. Los usuarios pueden cargar, ver, buscar, dar me gusta, no me gusta videos, agregar comentarios a los videos. Los usuarios cargan/eliminan videos solo como usuarios que cierran sesión, pero pueden buscar/ver videos como usuarios que cierran sesión. Este servicio es un servicio basado en anuncios y es gratuito, por lo que los usuarios verán anuncios mientras miran el video. Además, los usuarios pueden seguir a otros usuarios o canales por sus cuentas. Además, los usuarios pueden agregar comentarios a los videos solo cuando inician sesión en el sistema.
Antes de comenzar a diseñar cualquier sistema como un sistema de servicio de redes sociales para compartir fotos y videos, se recomienda pensar en los límites y requisitos del sistema en detalle y tratar de comprender cuáles serán las capacidades del sistema en el futuro (como 5 o 10 años) Esto es muy crítico ya que en algún momento si el conteo de usuarios del sistema aumenta exponencialmente, la capacidad del sistema no será suficiente para dar una respuesta rápida. Detrás del diseño arquitectónico, debe pensar en cinco pilares (disponibilidad, confiabilidad, resiliencia, durabilidad, rendimiento de costos). Estos son los pilares que debemos considerar juntos ya que están acoplados entre sí. En resumen, disponibilidad significa que el sistema debe estar siempre disponible. Confiabilidad significa que el sistema debe funcionar como se espera. Resiliencia significa cómo y cuándo el sistema se recuperará si hay algún problema. La durabilidad es el único pilar en el que cada parte del sistema debe existir hasta que lo eliminemos. El desempeño de costos también es un tema importante que básicamente se relacionará con el uso de servicios bajo la eficiencia de costos. Se puede ilustrar como si el sistema se construyera en AWS y fuera suficiente usar instancias t2 micro EC2, no habrá ninguna razón para usar instancias EC2 más grandes y pagar dinero extra.
REQUISITOS Y OBJETIVOS DEL SISTEMA
Youtube es uno de los mayores servicios para compartir videos y tiene muchos componentes ahora, sin embargo, no es así como se creó en el pasado. Cada sistema está cada vez más enfocado en el crecimiento y los sistemas tendrán más componentes que sus primeras versiones. Ahora vamos a diseñar las principales características de Youtube. No entraremos en detalles sobre el sistema de recomendación, los antecedentes de los canales, el sistema de búsqueda, ya que todos son temas de discusión separados.
Entonces, si desea diseñar un sistema, primero debe definir los requisitos y los límites del sistema. Probablemente tendrá documentos de diseño de servicios y definirá requisitos, límites, decisiones arquitectónicas y otros en estos documentos de diseño de servicios. Youtube es un servicio para compartir videos que el usuario puede cargar/ver videos. Por lo tanto, su sistema admitirá estas funciones;
– Los usuarios deben poder crear una cuenta.
– Cada usuario registrado debe tener su propia página de cuenta personal.
– Los usuarios deben poder iniciar sesión en el sistema y cerrar sesión en el sistema.
– Los usuarios deben poder cargar/eliminar videos en el sistema cuando inician sesión.
– Los usuarios deben poder agregar comentarios a los videos en el sistema cuando inician sesión.
– Los usuarios deben poder ver videos en el sistema cuando inician sesión o cierran sesión.
– Los usuarios deben poder buscar videos/usuarios/grupos cuando inician sesión o cierran sesión.
– Los usuarios deben poder seguir los canales.
– Los usuarios deben poder gustar/no gustar videos.
– A los usuarios les pueden gustar o no los videos, bajo esta condición, el sistema debe mantener números de Me gusta, No me gusta, comentarios, vistas para presentar estos números a los usuarios.
– El sistema debe ser capaz de monitorear.
– El sistema debe ser capaz de admitir cuentas públicas y privadas.
– El sistema debe ser compatible con videos públicos y privados.
Cuando se definen los límites del sistema y los requisitos funcionales, es necesario pensar en opciones en la nube o bajo promesa. Su sistema puede ser;
– %100 on-promise (su propio centro de datos/servidor)
– %100 cloud (AWS, Google Cloud, Azure)
– Mezcla de on-promise y nube (puede tener ambos durante el proceso de migración)
Hoy en día, los servicios en la nube tienen una gran popularidad gracias a las ventajas del mecanismo de la nube. Estas ventajas;
– Rentabilidad
– Alta velocidad
– Seguridad
– Soluciones de respaldo
– Capacidad de almacenamiento ilimitada
– Muchas opciones de servicio diferentes. No necesita crear un mundo desde cero
– Confiabilidad
– Durabilidad
– Resiliencia
– Monitoreo para casi todos los servicios
– Fácil integración de software con otros servicios
Si hablamos de Youtube, Netflix u otros grandes sistemas escalables, esto significa que estos sistemas van a estar expuestos a un gran tráfico. Puede haber una gran cantidad de requests al mismo tiempo en el sistema y el sistema debería tender a responder a todas las requests en una experiencia en tiempo real. La replicación, la fragmentación y el balanceador de carga ayudan a que el sistema tenga una alta disponibilidad. Hablaremos de las tres características más adelante.
Además, el sistema debe responder con una latencia mínima. Te imaginas que serías un usuario y quieres hacer cualquier cosa en Youtube, ¿de verdad quieres esperar mucho tiempo para obtener la respuesta? Creo que no desea esperar demasiado tiempo y desea experimentar el sistema en tiempo real. Para ilustrar esto, cuando busca un video en el sistema, este debería sugerir videos relacionados lo antes posible.
Pensemos en los límites del diseño;
El servicio será de lectura intensiva ya que muchos usuarios verán videos en el sistema, por lo que el sistema se mantendrá consistente y confiable, lo que significa que no debería haber ninguna pérdida de datos. Además, el servicio será duradero, lo que significa que todas las partes del sistema deben existir hasta que se eliminen manualmente. Antes de considerar la capacidad, debe definir cuál es el propósito del servicio. Incluso si es más esencial para los servicios bajo promesa, es esencial tanto para los servicios bajo promesa como en la nube, ya que puede seleccionar los servicios correctos según el propósito, ubicarlos según las regiones disponibles y definir las capacidades. Tales ejemplos son;
– Crear más servicios de lectura que de escritura.
– Seleccionar el tipo de servidor según el tipo de operación.
– Defina estrategias de almacenamiento en caché en función de su estimación de capacidad.
– Seleccione el tipo de base de datos (SQL, NoSQL) según sus requisitos.
– Defina soluciones de respaldo basadas en sus estimaciones de capacidad.
– Defina estrategias de fragmentación de datos según sus requisitos, etc.
Supongamos que tiene 100 millones de usuarios en total y supondremos que el tráfico de lectura es más pesado que el tráfico de escritura y supongamos que la proporción de descarga y carga de datos es 25:1.
Asumiremos que el tamaño promedio de video es de 250 MB, por lo que el sistema tendrá;
Capacidad de videos en 5 años;
– 5 * 100M * 1 * 250 MB = 120 PB. (Suponiendo que cada usuario suba 1 videos cada año).
– 360 PB con replicación y respaldo.
Este cálculo es solo un breve ejemplo de cómo definir la capacidad del sistema y no calcularemos la capacidad de carga/descarga diaria ni las capacidades de metadatos, pero debe considerar este cálculo (y la estimación de la capacidad de lectura/escritura diaria) para escalar servicios/bases de datos.
Además, el caché es un sistema esencial para devolver datos. Si está construyendo un gran sistema escalable, debe pensar en diferentes estrategias de almacenamiento en caché. Puede usar CDN como caché de contenido de video y Redis/Memcache como caché de metadatos. El mayor problema del caché será el escalado (mecanismo de almacenamiento en caché global) y las políticas de desalojo de caché. Si está creando su servicio en AWS, puede usar Cloudfront como CDN (caché de contenido) y puede usar el servicio elasticache en AWS para el caché de metadatos. Tenga en cuenta que Cloudfrount es un servicio de AWS altamente escalable que no necesita para trabajar con mantenimiento/escalabilidad. AWS mantendrá y escalará el servicio Cloudfront en sí mismo.
DISEÑO DE API
En el mundo actual, muchos sistemas son compatibles con la plataforma móvil, por lo que las API son las mejores opciones para poder proporcionar la distinción entre los desarrolladores y la compatibilidad con dispositivos móviles también. Podemos usar REST o SOAP. Muchas grandes empresas prefieren REST o SOAP según sus sistemas. Hay tres API principales que mencionaremos a continuación:
1- Subir video (apiKey, título, descripción, ID de categoría, idioma)
Subir video es la primera API que debemos mencionar. Hay básicamente cinco propiedades principales de esta API. Puede agregar más propiedades a la API UploadVideo. Tenga en cuenta que apiKey es la clave de desarrollador de la cuenta de servicio registrada. Gracias a apiKey podemos eliminar los ataques de los hackers. UploadVideo devuelve la respuesta HTTP que demuestra que el video se cargó correctamente o no.
2- Eliminar video (apiKey, ID de video)
Compruebe si el usuario tiene permiso para eliminar el video. Devolverá la respuesta HTTP 200 (OK), 202 (Aceptado) si la acción se ha puesto en cola o 204 (Sin contenido) según su respuesta.
3- GetVideo (apiKey, query, videoCountToReturn, pageNumber)
Devuelve JSON que contiene información sobre la lista de videos y canales. Cada recurso de video tendrá un título, fecha de creación, como recuento, recuento total de vistas, propietario y otra metainformación.
**Existen más API para diseñar un servicio para compartir videos, sin embargo, estas tres API son más importantes que las demás. Otras API serán como video, agregar comentario, búsqueda, recomendación, etc.
DISEÑO DE BASE DE DATOS
Hay dos opciones para definir el esquema de la base de datos. Estos son SQL y NoSQL. Podemos utilizar un sistema de gestión de base de datos tradicional como MsSQL o MySQL para conservar los datos. Como sabe, debemos mantener la información sobre videos y usuarios en RDBMS. También se debe conservar otra información sobre los videos, llamada metadatos. Ahora tenemos las tres tablas principales para guardar datos. (Tenga en cuenta que solo pensamos en las propiedades básicas de Youtube. Podemos olvidarnos del sistema de recomendación).
Usuario
– ID de usuario (clave principal)
– Nombre (nvarchar)
– Edad (entero)
– Correo electrónico (nvarchar)
– Dirección (nvarchar)
– Fecha de registro (DateTime)
– Último inicio de sesión (DateTime)
Video
– VideoID (clave principal – generada por KGS – Servicio de generación de claves)
– VideoTitle (nvarchar)
– Tamaño (float)
– UserID (clave externa con tabla de usuario)
– Descripción (nvarchar)
– CategoryID (int): tenga en cuenta que podemos crear una tabla de categorías para definir categorías
– Número de Me gusta (int)
– Número de No me gusta (int)
– Número de visualizados (int) – Podemos usar big int para mantener el número mostrado
– Fecha de carga (DateT?me)
VideoComment
– CommentID (clave principal)
– UserID (clave externa con tabla de usuarios)
– VideoID (clave externa) con tabla de video)
– Comentario (nvarchar)
– CommentDate (DateTime)
CONSIDERACIÓN DE DISEÑO DEL SISTEMA
Hay características básicas que se encuentran en los sistemas basados en web. Los principales son los sistemas de cliente, servidor web, servidor de aplicaciones, base de datos y caché. Según la intensidad del tráfico del sistema, la cantidad de servidores o servicios aumenta y el equilibrador de carga distribuye las requests entrantes entre estos servidores o servicios. Además, las colas se pueden usar según la densidad de los solicitantes entrantes. La operación de cola ayuda a los usuarios a evitar esperar más tiempo para obtener una respuesta. En nuestro servicio de Youtube;
– Cliente
– Servidor web
– Servidor de aplicaciones
– Base de datos
– Almacenamiento de video
– Servicio de codificación
– Cola
– Replicación
– Redundancia
– Equilibrio de carga
– Fragmentación
Podemos distribuir los servicios en tres partes para disminuir el tiempo de respuesta porque la carga de videos lleva más tiempo que la descarga de videos. El video se puede descargar desde el caché y obtener datos del caché es una forma rápida. El cliente básicamente los usuarios que utilizan el sistema. Web Server es la primera entidad que atiende la solicitud. La solicitud entrante puede tener lugar en el servicio de carga, el servicio de búsqueda o el servicio de descarga. Si damos una oportunidad a los usuarios que descargan videos de forma asíncrona, el tráfico del sistema se relajará. Un codificador es para codificar el video subido en múltiples formatos. Hay tres tipos de bases de datos que son la base de datos de contenido de video, la base de datos de usuario y el almacenamiento de metadatos de video. El proceso de cola se lleva a cabo entre un servidor de aplicaciones y la codificación.
Nuestro servicio de Youtube tendría muchas lecturas y deberíamos tener cuidado al construir un sistema. Nuestro principal objetivo debe ser devolver videos rápidamente. Podemos guardar copias de videos en diferentes servidores para manejar los problemas de tráfico. Además, esto garantiza la seguridad de este sistema. Podemos distribuir nuestro tráfico a diferentes servidores usando un balanceador de carga. El sistema puede mantener dos réplicas más de la base de datos de metadatos, la base de datos de usuarios y la base de datos de contenido de video. Podemos usar CDN para almacenar en caché datos populares.
Diagrama de flujo del sistema;
1- Un cliente envía una solicitud.
2- Solicitud de reuniones desde el servidor web.
3- El servidor web controla el caché. Puede haber dos bases de datos de caché más en el sistema.
4- Si la solicitud se realiza en un caché, se redirige una respuesta al cliente.
5- De lo contrario, el servidor web redirige la solicitud al servidor de aplicaciones.
6- Puede haber equilibrador de carga entre servidores web y servidores de aplicaciones.
** Si esta solicitud es un servicio de búsqueda o visualización, intenta encontrar la solicitud consultando la base de datos de metadatos y la base de datos de contenido de video. Se puede colocar un balanceador de carga en cada capa del sistema, como entre el servidor de aplicaciones y el almacenamiento de contenido de video, entre el servidor de aplicaciones y la base de datos de metadatos, etc.
Cuando un servidor responde la solicitud del cliente, los datos relacionados se almacenan en caché de acuerdo con el proceso de caché. .
Como sabemos, Youtube es un gran sistema para compartir videos. Los usuarios pueden subir videos y la cantidad de videos subidos crece exponencialmente día a día. De acuerdo con la carga de videos, puede haber un mismo video más en el sistema. Para eliminar la duplicación de videos podemos implementar un algoritmo inteligente. Por ejemplo, cuando un video llega a un sistema, el algoritmo verifica automáticamente si este video ya está guardado en el sistema o no. Si el sistema ya tiene este video, entonces no necesitamos mantener datos duplicados. Nos salva del uso innecesario del espacio. Además, si el video entrante incluye un video guardado en el sistema, entonces podemos dividir los videos en pequeños fragmentos y solo damos la única referencia a los mismos fragmentos de video para manejar el problema de duplicación.
La replicación y el respaldo son dos conceptos importantes para proporcionar los pilares que mencionamos anteriormente. La replicación es un concepto muy importante para manejar una falla de servicios o servidores. La replicación se puede aplicar a servidores de bases de datos, servidores web, servidores de aplicaciones, almacenamiento de medios, etc. En realidad, podemos replicar todas las partes del sistema. (Algunos de los servicios de AWS, como Route53, son altamente disponibles en sí mismos, por lo que no es necesario que se ocupe de la replicación de Route53, el balanceador de carga, etc.) Tenga en cuenta que la replicación también ayuda al sistema a reducir el tiempo de respuesta. Imagínese, si dividimos las requests entrantes en más recursos en lugar de un recurso, el sistema puede satisfacer fácilmente todas las requests entrantes. Además, el número óptimo de una réplica para cada recurso es 3 o más.
Para las estrategias de almacenamiento en caché, podemos usar un mecanismo de almacenamiento en caché global mediante el uso de servidores de caché. Podemos usar Redis o Memcache, pero la parte más importante de la estrategia de almacenamiento en caché es cómo proporcionar el desalojo de caché. Si usamos servidores de caché global, garantizaremos que cada usuario verá los mismos datos en el caché, pero habrá tiempo de latencia si usamos servidores de caché global. Como estrategias de almacenamiento en caché, podemos usar el algoritmo LRU (Usado menos recientemente).
Para el almacenamiento en caché de archivos multimedia, como mencionamos antes, usaremos CDN. CDN está ubicado en diferentes ubicaciones de borde, por lo que el tiempo de respuesta será menor que obtener contenido multimedia directamente desde AWS S3.
El balanceador de carga permite redirigir las requests entrantes a los recursos de acuerdo con ciertos criterios. Podemos usar el balanceador de carga en cada capa del sistema. Si queremos utilizar el servicio de equilibrador de carga de AWS, AWS admitirá tres tipos diferentes de equilibrador de carga que son;
– Equilibrador de carga de red
– Equilibrador de carga clásico (obsoleto)
– Equilibrador de carga de aplicaciones
Para este servicio, el equilibrador de carga de aplicaciones se adaptará a nuestro servicio y también manejará la distribución AZ en sí mismo. De lo contrario, puede usar NGinx, pero debe implementar el algoritmo y debe proporcionar mantenimiento si queremos usar NGinx.
Podemos usar el balanceador de carga;
– Entre requests y servidores web.
– Entre servidores web y servidores de aplicaciones.
– Entre servidores de aplicaciones y bases de datos
– Entre servidores de aplicaciones y almacenamientos de imágenes.
– Entre servidores de aplicaciones y bases de datos de caché.
– Podemos usar el método Round Robin para el balanceador de carga. El método Round Robin evita que las requests vayan a servidores inactivos, pero el método Round Robin no se ocupa de la situación en la que cualquier servidor tiene mucho tráfico. Podemos modificar el método Round Robin para que sea un método más inteligente para manejar este problema.
La carga de videos es un gran proceso. Debería funcionar con el mecanismo de fragmentación y, cuando falla, el sistema debe asegurarse de continuar cargando el video desde el punto de falla.
El proceso de codificación de video debe incluir operaciones de cola. Cuando llega un video cargado, esta nueva tarea se agrega a una cola y todas las tareas en la cola se toman una por una de una cola.
CODIFICACIÓN BÁSICA DEL SISTEMA
Java
// Java program for design
public enum AccountStatus{
PUBLIC,
PRIVATE,
CLOSED
}
public enum VideoContentStatus {
PENDING,
PROCESSED,
FAIL,
REJECTED
}
public enum VideoStatus {
PUBLIC,
PRIVATE,
DELETED
}
public enum VideoQuality {
LOW,
MIDDLE,
HIGH
}
public class AddressDetails {
private String street;
private String city;
private String country;
...
}
public class AccountDetails {
private Date createdTime;
private AccountStatus status;
private boolean updateAccountStatus(AccountStatus accountStatus);
...
}
public class Comment {
private Integer id;
private User addedBy;
private Date addedDate;
private String comment;
public boolean updateComment(String comment);
...
}
public class Video {
private Integer id;
private User createdBy;
private String path;
private VideoStatus videoStatus;
private VideoContentStatus videoContentStatus;
private int viewsCount;
private HashSet<Integer> userLikes;
private HashSet<Integer> userDisLikes;
private HashSet<Integer> userComments;
...
}
public class User {
private int id;
private String password;
private String nickname;
private String email;
private AddressDetails addressDetails;
private AccountDetails accountDetails;
private UserRelations userRelations;
private HashSet<ConnectionInvitation> invitationsByMe;
private HashSet<ConnectionInvitation> invitationsToMe;
private boolean updatePassword();
public boolean uploadVideo(Video video);
public List<Videos> getVideos();
...
}
Referencia: http://highscalability.com/youtube-architecture
Escriba comentarios si encuentra algo incorrecto o si desea compartir más información sobre el tema tratado anteriormente.