En respuesta a la última tarea del taller de optimización de aplicaciones web de MLW, calificamos el SEO que decidiste darle a tu aplicación web. Hablamos de las mejores palabras clave, de los términos de búsqueda por los que vale la pena pelear y aquellos donde el esfuerzo es más grande que los resultados.
Misión: Cómo escalarías un proyecto web
Danos tu idea de cómo afrontarías esta situación:
Tienes un proyecto a lo twitter que genera consultas específicas por usuario. Más de 10mil consultas a la base de datos por segundo. No puedes cachearlas porque todas son diferentes. Utilizas LAMP con Cpanel y estás en un servidor de varios núcleos que podía aguantarlas todas hasta que esto empezó a funcionar en serio.
Piensa que tienes algo programado en PHP, algo más en Python y otras cosas en Java. Y varias consultas vía APIs internos mueven tu plataforma. ¿Cómo escalas? y cómo haces una estrategia más a largo plazo para seguir creciendo.
Colócalo en un párrafo, como comentario de este post. Calificaremos las ideas por efectividad o creatividad. Recuerda que puedes sacar 0, 1 o 2 dependiendo de lo que escribas. Esta es la última misión del curso.
Una buena forma de prevenir todo estos problemas. Es crear tus aplicaciones basandose en la idea de SOA.
Separar las funcionalidades prinicpales de un sitio en aplicaciones separadas. Usando twitter de ejemplo, podriamos crear una api para procesar los nuevos tweets. Otro para consultas, otro para busqueda (sphinx u otros). Otra para administracion de usuarios. Y Obviamente separar todas las tareas de background que podriamos tener.
Un frontend que una toda esas aplicaciones para presentar un servicio unificado. El dia de maniana cuando necesitemos aumentar al cantidad de servidores solo necesitamos mover estas mini aplicaciones a otro servidor o a otro grupo de servidores.
De esto se muy poco, y mi idea seria esta:
Crear el sitio en una estructura descentralizada; tener varios servidores y en cada uno bases de datos y aplicaciones concretas. De esta forma puedes colocar una aplicación en cada servidor, y dividir las DB para agilizar la petición de datos al servidor.
En caso de usar imágenes se puede utilizar el S3 de Amazon, es un servicio bastante económico y muy efectivo.
Un solo servidor no se bancaria proceso, lectura y escritura de datos, por lo que: usaría al menos dos servidores (bd y Aplicación + contenido estático –css, js, img, etc–). y si me da el bolsillo tres (app, bd y contenido estático). Pero también, optimizaría la aplicación para tratar de hacer la menor cantidad de procesos y consultas a la base de datos (por hits, obviamente obteniendo los mismos resultados. por otro lado tener mas ancho de banda. A esta cantidad de hits la aplicación tendría alguna forma de generar dinero por lo que eso no seria problema.
Una arquitectura de cluster para hacer computo de alto
rendimiento sin necesidad de hacer codigo paralelo y flexible en la configuracion del hardware.
Y queremos hacer un cluster que cumpla con los
siguientes objetivos.
1. Respuesta rápida a las peticiones de los usuarios.
2. Alta disponibilidad.
3. Facilidad para incrementar mas nodos.
La idea es hacer un cluster se servidores web ?
Ahora sí que está difícil dado que nunca llegue a esto jajaja:
Bueno, podría afirmar que cualquier proyecto que posea ese nivel de tráfico y consultas va a tener mucho éxito y por lo tanto me sería difícil pensar que sea lo óptimo dejar su control bajo una sola persona.
• Buscaría una relación especial con el propietario del housing para que me asesore de la mejor forma sobre el funcionamiento y tratamiento de su servicio.
• Me aliaría con una persona creativa y de confianza dado que no se puede ser egoísta cuando un proyecto tiene verdadero futuro.
• Dividiría la actividad de la aplicación en servidores que corran en paralelo alivianando cargas importantes de cada sector de la aplicación.
• Separaría bases de datos antiguas de las bases de datos nuevas. Siendo una red al estilo twitter, es seguro que el 40% de la actividad quede atrás, por ejemplo los twitts de hace 3 meses. Estos registros antiguos serían devueltos en el caso de que se los solicite pero aligerarían la carga de la base de datos principal.
• Viendo la situación es seguro que no soy un experto por lo que puedo afirmar que las consultas van a poder ser liberadas en gran medida logrando que consuman menos recursos.
• Integraría un sistema de privacidad que limite el alcanze de la información de cada usuario al resto, un sistema que permita al usuario restringir quien ve su información.
Creo que algo más se puede hacer pero realmente en papel no puedo establecer nada dado que lo lindo y atrapante de esto es hacerlo en el momento que ocurre ^^.
PD: Lindo y atrapante no significa relajante!
PD2: Veo si en estos días puedo avanzar con esta misión!!
Saludos a todos desde argentina
Que tal chicos, les dejo mi comentario, se que pidieron un parrafo pero me fue imposible jeje.
Imprentaría una arquitectura Share Nothing combinada con la arquitectura orientada a servicios (SOA).
Que busco con esto?
En apego al SOA empezar a crear servicios que se comuniquen entre aplicaciones internas que trabajen independientes y puedan compartir información a otros servicios. Todo esto en la capa de negocio (APIs).
La parte de resguardo de datos es muy importante, ya que sería la clave de mi solución. Esta es independiente de todo servicio y seria un arreglo de discos la cual aseguraría 99.9% de la portabilidad y a su vez la escalabilidad del sistema, de esta forma no importara el lenguaje de programación que estén las aplicaciones ni en que plataforma.
Algo muy importante, es identificar los servicios que tienen mucha carga o los que se están actualizando de forma continua y son clave del sistema, tenerlos en un nivel intermedio por tiempo escaso. De igual manera, los datos cuyos movimientos ya no sean frecuentes, moverlos a un histórico para poder reutilizarlos en caso sean solicitados ya como un servicio aparte o complementario.
Con esto cubro la parte de escalabilidad y garantizar el servicio por x usuarios. Ahora… ya que esto funciona!!! y enserio… me apego a la arquitectura Share Noting buscando que la escalabilidad horizontal, solamente con agregar x equipos de la misma capacidad y haciendo una réplica de los otros servidores, podre aceptar mas usuarios. Claro… esto usando un balanceador de carga de servicios para enrutar (no recuerdo la palabra) la carga de trabajo a un servidor que tenga menos procesos y que este seguro de que puede procesar y responder a la solicitud del servicio.
PDT. NO SE MI CALIFICACION de la mision#3. En el video(Calificando la Misión #3 con estrategías SEO) no se guardo cuando hicieron el cambio transmision de @cvander a @marianosaenz
_NoWr = Ebhling para que me sumen los puntos de esta tarea, claro.. si los obtengo. Saludos
Hola a todos.
Teniendo en cuenta que el proyecto o la aplicación, esta en sus inicios, usaría un solo servidor que se encargue de almacenar la aplicación como las bases de datos de la misma.
Cuando se vea que la aplicación empiece a crecer y deje de ser algo de pasa tiempo y sea enserio procedería a buscar dos servidores, uno para el almacenamiento de la aplicación y otro para el de las bases de datos que usaría, además comenzaría a tener contacto con personal especializado de la empresa que me preste el servicio de hosting (teniendo en cuenta que no se nada del tema de servidores), con el fin de que me den accesoria de como poder mejorar el trafico de mi aplicación y distribución de la misma en los servidores, especialmente el la parte de las bases de datos y el acceso a estas.
La planeación y arquitectura no deben ser minorizadas en un inicio, el exitoso escalamiento depende en gran medida de la rapidez con lo que lo puedas lograr.
Mi experiencia? :
[] Recursos:
Descentralizar los recursos estáticos y dinámicos, con esto sugiere mover cada contenido a diferente locación.
Centralizar los procesos de backend de modo que una API general interna se responsabilice de entregar los datos solicitados. Con esto me lleva a la duda si PHP/Py & java son usados solo en backend o en frontent también? si se usan los 3 para el front o incluso los 3 para el back, estamos ante una estructura débil y carente de arquitectura, el trabajo que realiza uno lo puede realizar cualquiera de los otros dos.
El uso de cache para elementos estáticos js/css/jpg.
[] Tunning:
Tunning a Apache y mysql (incluyendo querycache puesto que el cache de Mysql funciona eficazmente). Para incrementar el número de conexiones.
El uso de memcache y almacenamiento de datos constantes puede funcionar increíblemente.
Una vistazo a la estructura de la DB nos dirá que estamos haciendo mal, pruebas de estrés en un ambiente controlado nos proporcionara información sobre las relaciones de nuestras tablas, aquí se podrá analizar la necesidad de cada una de ellas y si es que su papel esta siendo desempeñado como corresponde.
El schema de la tabla también es importante, evitar usar INNODB a menos que se requiera rollback, consume mas espacio.
[] Procesos:
Si existen procesos cron dentro de mantenimiento estos deben ser movidos a horarios con poco o nulo tráfico, no es lindo navegar por ahí y ver un letrero de en mantenimiento.
Lo que me lleva a hablar de procesos, la manera en que muchos programadores piensan es modular, nos obliga a creer que todo tiene que reacciones por una acción y esto no es así; una acción puede desencadenar n procesos así como un proceso no depende de una acción. Me refiero al front y más específicamente a las consultas del usuario.
[] Front
- Si se navega por un rowset de resultados es probable que se desee navegar por la pagina 2, 3 o 4 entonces porque cargar solo una página? carguemos 2 páginas y mostremos solo una a medida que se avanza por los resultados la negación se sentirá más rápida, la carga del motor de base de datos es dividida n veces donde n son los resultados precargados.
-Si se puede hacer en el front entonces porque se lo delegas al Back ¿? : Tarea sencillas como ordenar una tabla de resultados es fácilmente solucionada con Js , es rápido y es barato.
Por último los entornos de desarrollo deben quedar claros, Dev,QA y Prod, no se prueban funcionalidades en QA!!!!
Yo mandaría la aplicación y las bases de datos a diferentes servidores, también utilizaría RIA’s para reducir el trafico hacia los servidores, usaría cache y almacenaría datos temporales del lado del cliente. Los datos estáticos como información y multimedia los pondría en varios servidores para que no se estén conectando todos al mismo servidor y distribuiría el acceso a los servidores. También los videos e imagenes los podría distribuir a otras paginas usando las API’s de varias aplicaciones web.
Algo que usan para esto es SOA y no se si la Cloud Computing vaya en realidad cambiar esta arquitectura ya que aun se me hace un poco pesada esta nueva alternativa para algunos paises por las velocidades que se manejan.
Buenas!
Huy esto la verdad, tampoco sé mucho, y nunca me lo puse a pensar seriamente antes.
En primer lugar, trataria de optimizar las consultas a la base de datos, por ejemplo, ver si no estan enviando cosas innecesarias para ahorrar recursos. Tendria usar un hosting que tenga load balance para que no
colapsen los servidores si hay picos de trafico. Podria utilizar Elastic Compute Cloud de Amazon que permite
ser escalable y según entiendo sólo se paga por los recursos que se consumen. También optimizaria el diseño del sitio, para que sea
lo más liviano y rápido posible.
Resumiendo, mi estrategia es reducir el tamaño de la información para ser efectivo con los servidores, pero a la vez tener unos servidores potentes para asegurarse de que no haya fails o downs del sitio.
No se me ocurren muchas ideas para esta tarea y pues lo primero que se viene después de 5 minutos de análisis.
Tener más de un servidor, ya que con uno solo no nos daríamos abasto de todas las operaciones y tendríamos fugas o mal funcionamiento de nuestro sitio, ya que son 10 mil hits. Con eso estaríamos aumentando la eficiencia en tiempo de respuesta a nuestra sitie. Otra cosa seria aplicar una buena normalización en la base de datos para que no tenga datos redundantes y no extienda mucho, porque eso de dividirla no lo veo muy optimo. Creo que con esto el usuario estará mas conforme con el proyecto, porque los usuarios comúnmente buscan mas velocidad de respuesta y procesos mas eficientes.
Bueno eso es lo que se me ocurre, disculpen pero casi no tuve tiempo la semana pasada por eso hasta hoy postee. Saludos a todos.
Para un proyecto que tienen tantas visitas haría lo siguiente
1.Buscaría tener ingresos por parte de mi aplicación para tener un modo de financiamiento
2.Contrataría una persona adicional para que me ayudara en optimización del api
3.Migraría mi sistema completo a un servidor de 64 bits preferiblemente con linux no virtual dando así mas estabilidad a mi aplicación
4.Separaría la base de datos a un servidor independiente
5.Normalizaría la base de datos para mayor rendimiento en las consultas
6.Depuración de la Api
7.Me asesoraría de mi proveedor de servicio en que herramientas el me puede ofrecer para optimizar mi trafico
Aunque la verdad no es mi fuerte este tema es bastante interesante..
¿Cómo escalas?
Particionando todo. Separando por módulos el procesamiento de acuerdo a que tanto son requeridos, así por un lado estarán las búsquedas y por otro las preferencias de usuario. Donde las búsquedas tendrían las maquinas mas rápidas y las preferencias de usuario las menos rápidas debido a su poca frecuencia de uso.
¿Cómo haces una estrategia más a largo plazo para seguir creciendo?
Automatizando la escalabilidad donde los parámetros de rendimiento se determinan no en archivos de configuración estáticos, sino por condiciones de carga.
Bueno yo la verdad nunca me habia puesto a pensar en esto pero, yo lo haria seria usar mas de un servidor para poder dar abasto, y comenzar a buscar gente de confianza para que apoyen al proyecto, y para poder dar la atención necesaria al proyecto y que no este descuidado, agregaría a la aplicación un poco mas de interactividad entre usuarios para que no se les haga tan monotoma.
Y pues eso seria todo por que es todo lo que se me ocurre ahora.
Saludos.
yo creo que serian varias cosas
la primera es separar las 3 capas de una aplicacion: logica, presentacion y persistencia.
para el caso de la capa de presentacion o contenido estatico usaria el servicio de AWS de amazon.
para la capa de persistencia tendria un cluster de servidores que almacenaran toda la informacion y tendria unos servidores mirror que resguarden la información.
para la capa de aplicacion tambien un cluster que maneje toda la aplicacion y las consultas de la API hacia esta.
adiccional en este cluster tambien habria unos servidores cache a los que les agregaria un concepto que se llama mineria de datos (data mining) para poder determinar que es lo mas buscado en mi aplicacion (tendencias) y con estos datos podria tener una aplicacion que arroje estos datos de primera mano para ahorrar tiempo en consultas.
ademas de esto para garantizar disponibilidad global tendria al menos 3 datacenters en 3 lugares geograficamente bien ubicados en el mundo por si hay problemas con servidores DNS o el internet falla en alguno de los datacenter.
Considero que ese proceso ya deberia ser considerado desde los bocetos iniciales de cualquier proyecto y por lo tanto crear el proyecto desde el principio orientado a la escalabilidad del proyecto. La respuesta, en resumen es: SIMPLIFICAR
SIMPLIFICAR
No usar 3 o 4 APIs distintas o en distintos lenguajes. Intentar crear un api generica que ahorre recursos en las tareas simples, exprimiendo hasta el ultimo bit de codigo que se necesite cargar al navegador.
Disminuir la cantidad de querys al minimo para descongestionar lo maximo los servidores asi como separar lo que BBDD de lo que es la parte enfocada totalemente al cliente.
Considerar que informacion realmente necesitan las apis internas eliminar el transtio de informacion que no sea totalemente necesario y centralizar todas las peticiones pesadas que no sean repetitivas para desplazarlas a la franja horaria de menor uso.
Por ultimo si es necesario comprar servidores mas potentes obiamente se tendria que hacer, eso si, si ya estamos hablando de un proyecto enfocado a muuuchas consultas yo creo que desde un inicio ya se tendria un servidor competente o incluso 2.
Estrategia a futuro.
Hay un punto que creo que del lado programacion, planteamiento de BBD etc. ya no es mas simplificable ya que se hizo todo lo que se podia hacer. Si se hace bien ese trabajo, lo unico que queda para preocuparse a futuro sera la necesidad de mas servidores por el augmento de consultas y subdividir las BBDD en distintos servers.
Por fin el último trabajo.. siempre ando apretado de tiempo para responder, pero igual he aprendido.
Corto Plazo.
Asumo que al ser LAMP, la BD es MySQL por lo que evitaría usar o mantener lo común de una BD de este tipo; es decir no usar joins, foreign keys, ordenamiento, entre otras. Al trabajar con diferentes lenguajes lo mejor es trabajar orientado a servicios y dividir la aplicación en módulos con funciones específicas. Restringir los campos a consultar dentro del query así poder tener los datos en varias tablas o BD organizadas de acuerdo a algún criterio.
Largo Plazo.
Migrar la BD a un servidor diferente al de Aplicaciones y cambiar a una de tipo NoSQL. Dependiendo del tipo de contenido con mayor consultas dividir esta tabla/DB en varios hosts. Cachear los archivos que sean estáticos. En lo posible evitar que un módulo sea dependiente de otro para funcionar. Tener un buen control de errores para saber que fallo es el que se produce. Y balancear la carga de trafico y procesamiento entre servidores.
Se que es demasiado tarde pero tuve varios problemas.
Bueno en pocas palabras y para poder resumirlo por que se que estoy en falta por no poder entregar a tiempo mi solucion es la siguiente
Dividir mis servidores para coda cosa por separado dividir para base de datos para aplicaciones y para la misma web tener todo por separado dividir las base de datos por secciones analizar cuales son las consultas con mayor ingreso y separarlas en otro servidor, si es una web con muchas entradas separar las base de datos por meses o por años y usar Amazon uno de los mas recomendados.
Espero se me pueda tener en consideracion mil disculpas, siempre estuve al dia en todas las tareas, pero se me a dificultado mucho ultimamente, Gracias.