| OSS - Web HA - Sitios Web Que No Se Caen Durante Los Cybers |
|
Enfóquese en su negocio, nosotros le ayudamos a mantener la operación tecnológica sin interrupciones… Con OSS HA Web, su empresa contará con todo lo necesario para que su sitio corporativo funcione sin problemas en los eventos de Cyber Day o Cyber Monday, CHILEOFFSHORE provee una arquitectura que ya está funcionando en muchos sitios exitosos, como La Polar o Servicio de Impuestos Internos. De esta forma ya no deberá recurrir a "Salas de Espera" y/o pantallas de advertencia para los casos de error. Este servicio provee todo el hardware necesario, como servidores, equipos de comunicación y las asesorías necesarias para que su sitio se mantenga operativo, sin caídas y con buen desempeño. Según nuestra experiencia, uno de los problemas más comunes es: No se cuenta con capacidad de crecimiento en forma horizontal. En general, esto ocurre en arquitecturas con 2 servidores, un servidor Web y otro servidor para Base de Datos, o en arquitecturas compuestas por un solo servidor, que contienen tanto al sitio Web como a la Base de Datos. 
Diagrama 1 - Arquitecturas típicas de desarrollo Este tipo de arquitectura es el adecuado para un sitio informativo, pero si su empresa requiere realizar ventas y ofertas en gran volumen durante los Cybers, estas dos arquitecturas no son suficientes para cumplir esta meta. La primera arquitectura (izquierda) fue usada en la primera versión de la Declaración Renta por Internet del SII a finales del año 90 y quedó completamente fuera de servicio en cuanto comenzó la declaración de Renta en forma masiva. La arquitectura de la derecha está en uso en muchos sitios actuales, incluso era la arquitectura de uno de nuestros clientes, el que funcionaba con muchas dificultades durante los Cybers. La solución al problema anterior es contar con una arquitectura que permita crecer en forma horizontal.  Diagrama 2 - Arquitectura que resuelve la saturación de la capa de presentación, pero traslada el problema a la capa de datos. Esta arquitectura puede solucionar problemas de saturación de construcción de las páginas, en otras palabras, problemas de la capa de presentación. Dependiendo de cómo está construido el sitio de su empresa, esta arquitectura puede funcionar sin problemas si las páginas de su sitio no requieren muchas consultas a la base de datos. Pero si su sitio está construido de tal forma que cada página requiere consultar a la base de datos, esta arquitectura no va a funcionar correctamente. En resumen, esta arquitectura resuelve el problema de saturación de la capa de presentación, pero traslada el problema a la capa de datos. Hay varias razones que pueden causar la saturación de base datos: [A] Efecto de "Portón de Entrada de un Estadio": cuando hay un partido de fútbol entre dos equipos importantes, habrá mucha gente que quiera entrar al estadio. Por lo tanto, un portón pequeño puede causar el efecto "cuello de botella" donde todos quieren entrar a la vez pero pocos lo logran. Este efecto puede pasar en un ambiente de base de datos que no cuenta con un control adecuado. Cuando un sistema es para uso interno de una empresa, la cantidad de usuarios es limitado. Pero cuando se dispone de una aplicación abierta a la web pública, no se puede estimar cuantos usuarios se van a conectar y se va a producir una caída en los momentos peak de los Cybers.  Diagrama 3 - Saturación de Personas en una Entrada sin Control (efecto "cuello de botella") [B] Repetición de operaciones que no son necesarias. Muchos sitios tienen consultas a la base de datos en forma directa, es decir, cada vez que van a la base de datos requieren: conectarse, autenticarse, realizar operaciones como select/update/delete/insert y cerrar conexión a la base de datos. En todas estas operaciones las acciones de conexión, autenticación (que son bastante costosas desde el punto de vista de la base de datos) y cierre de conexiones no son necesarias y se pueden ahorrar. Estas operaciones extras no son visibles cuando el sitio de su empresa está operando con una cantidad limitada de usuarios, pero una vez que entra a un Cyber podría llegar a fallar rápidamente.  Diagrama 4 - Operaciones clásicas de base de datos [C] Páginas estáticas que no son realmente estáticas: esto incluye contenidos que supuestamente deben ser estáticos (que no cambian nunca o muy pocas veces) pero en la realidad cambian bastante. Ejemplo, catálogo de productos que según la existencia de stock se muestra o no se muestra. En este tipo de catálogo, existen diseños de páginas, que por cada navegación, el programa va a ir a consultar el saldo del producto a la BD y luego toma la decisión si muestra o no el producto. Suena bastante razonable desde el punto de vista del negocio, pero según como se implemente va a causar una gran diferencia. Si por cada navegación de cada usuario de Internet va a ir la BD para saber el saldo de cada producto de una página tipo catálogo, se generará una gran demanda hacia la BD. Una de las posibles soluciones es implementar una técnica tipo "Push" que implica que la BD "publica" el saldo en forma regular en cada servidor web, de esta manera se logra evitar el acceso masivo a la BD.  Diagrama 5 - Sobre los accesos para mostrar catálogo a usuarios Internet [D] Página estática pero que abusan de la BD: existen desarrolladores que "abusan" la cantidad de uso hacia la BD. Un ejemplo real, cuando un usuario de Internet se autentica contra el sitio de la empresa, se genera un token que es una identificación única que registra la autenticación. Hay programas que validan este token cada vez que el usuario cambia de página durante su navegación por el sitio, esto no tiene ningún sentido. La forma correcta de uso de un token es cuando el usuario realiza operaciones del tipo consultar o actualizar datos, solo en esos casos el token debe ser validado contra la base de datos.  Diagrama 6 - Arquitectura Correcta En esta arquitectura, los programas de capa de presentación son los responsables de construir las páginas del sitio y de evitar el acceso a la base de dato en forma directa: Lo harán a través del ESB. Aunque en principio no se ven los beneficios directamente, la mayoría de las personas de TI terminan aceptando que ESB es la mejor arquitectura para ellos, debido a que ESB separa capas en forma clara, así los programadores que son responsables de construir páginas ya no tienen que preocuparse de cómo se extraen los datos desde la base de datos de su empresa o desde un servicio de otra empresa, especialmente cuando se extraen datos provenientes de otras empresas. Si su empresa ya es una empresa de nivel Enterprise que cuenta con diferentes áreas, como marketing, ventas, contabilidad, finanzas, informática (TI), etc., ya no es recomendable que los desarrolladores de TI manejen todos los temas. Cada programador tiene cierto perfil en el cual se desempeña mejor. Por ejemplo, Juan Pérez es bueno para construir interfaz de usuario, Cecilia Gonzalez es buena para el manejo de datos y con mucha experiencia en base de datos. Por lo tanto, ya es momento de considerar separarlos y especializarlos en las diferentes capas. Así se mejora el rendimiento total de TI. ESB-SOA se puede implementar 100% en estilo de SOA - Service Oriented Architecture (Arquitectura Orientada a Servicios), servicios capaces de contestar requerimientos a nivel de negocio. Por ejemplo, supongamos un servicio que se llame "EvalCredit", que evalúa la posibilidad de otorgar crédito a un posible cliente, tipo empleado dependiente, para esto se requiere saber su situación laboral (servicio de Previred en Chile) y comportamiento financiero (datos que provee Equifax o Cámara de Comercio de Santiago), por lo tanto, este servicio de SOA (EvalCredit) va a ser responsable de llamar a Previred y luego llamar a Equifax, si falla esta llamada intenta llamar a la Cámara de Comercio. De esta manera, el servicio EvalCredit, al encapsular todas las llamadas y manejo de errores, las hace transparentes para los programas de la capa de presentación. Un ejemplo real de EMBSiwtch/EMBIntegrator, es que uno de los servicios implementados realiza 60 pasos que incluyen llamadas internas a sistema TI de la empresa como también llamadas a varias empresas externas para entregar el resultado. EMBSiwtch/EMBIntegrator, es que uno de los servicios implementados realiza 60 pasos que incluyen llamadas internas a sistema TI de la empresa como también llamadas a varias empresas externas para entregar el resultado. ESB-LocalCaché, hay cierto tipo de servicios, especialmente servicios relacionados con proveedores externos, que son pagados. Esto implica que su empresa debe pagar a los proveedores de información como Equifax, Previred, etc. por cantidad de llamadas. Por lo tanto, debemos evitar las llamadas innecesarias para ahorrar gastos. En ciertos casos, el resultado de algunos servicios no cambia su resultado muy seguido, por lo tanto, el resultado de una llamada hace 10 minutos debe ser válido para una llamada en el tiempo actual para el mismo cliente. En este sentido, ESBLocalCaché entra en acción, grabando los resultados de las llamadas. Como ejemplo, si se detecta llamadas a EvalCredit para un mismo cliente, ESBLocalCaché retornará el mismo resultado sin hacer llamadas repetidas a las empresas externas. En la vida real de informática, se ven programadores que "abusan" de las llamadas, simplemente realizan copy-paste de un bloque de código que realiza llamadas, incorporándolos en muchos programas diferentes sin considerar el "sobre gasto" de recursos de la empresa. ESB te permite controlar sobrecarga de base de datos. En primer lugar, un ESB como ApiEMBSwitch de CHILEOFFSHORE, cuenta con control de acceso a las bases de datos con implementación de connection-pool. Esto significa que las operaciones extras de base de datos mencionadas anteriormente van a ser eliminadas:  Diagrama 7 - Acceso a Base de Datos con Connections Pool Una vez que el sistema ESB se levanta, se abre una cantidad de conexiones predefinidas a diferentes bases de datos, las que mantiene abiertas. Además se asigna una cantidad predefinida de "servicios" que son exclusivos para atender una necesidad específica de la base de datos, por lo tanto, para cada requerimiento de datos, cada "servicio" del ESB obtiene una conexión de una base de datos específica y realiza una operación y luego retorna la conexión al connection-pool. Así se eliminan 3 pasos innecesarios que son: conectar a la base de datos, autenticar y cerrar la conexión. Además se mejora la administración de accesos, como en el ejemplo de "Portón de Entrada de un Estadio", equivale a poner una cantidad de empleados del estadio para controlar acceso en forma paralela y así permitir al público entrar en forma controlada. Un ESB como ApiEMBSwitch HA de CHILEOFFSHORE, cuenta con capacidad de crecer en forma horizontal, lo que implica que puede fácilmente aumentar la cantidad de servidores y así aumentar la capacidad de procesamiento sin límite. Un ESB como ApiEMBSwitch HA de CHILEOFFSHORE, tal como el nombre lo indica, cuenta con tolerancia de fallas. Es decir, si falla uno de los servidores de ApiEMBSwitch HA, otro va a tomar el control completo y así asegura un 100% de uptime para su empresa. CHILEOFFSHORE ha logrado un 100% de uptime de ApiEMBSwitch HA en las instalaciones de nuestros clientes. CHILEOFFSHORE ofrece distintas arquitecturas[A] Solución rápida denominada “Arquitectura WEBHA1011” Con esta alternativa, dependiendo de cómo este construido su sitio actual, hay alta posibilidad de que su empresa no requiera hacer grandes cambios y así poder enfrentar mejor el siguiente Cyber. En CHILEOFFSHORE le ayudamos a cambiar la arquitectura a: Diagrama 8 – Arquitectura WEBHA1011 - Sitio balanceado sin hacer muchos cambios Con esta arquitectura, se puede lograr un crecimiento en forma horizontal sin límite de la capa de presentación, pero se podría llegar a saturar el servidor de base de datos según la forma en que estén construidas las páginas del sitio. Esta arquitectura, incluye por lo menos un servidor de balanceo de carga y opcionalmente puede agregar otro servidor de balanceo para tolerar fallas en forma automática. Por otra parte, 2 o más servidores para la capa de presentación, le permite crecer en capacidad de responder navegaciones de Internet durante el Cyber. Opcionalmente, dependiendo de cómo esté construido su sitio Internet actual, debe considerar como potenciar el o los servidores de base de datos. CHILEOFFSHORE puede ayudar a su empresa trayendo servidores más potentes con precios muy competitivos. [B] Solución Completa que requiere modificaciones (“Arquitectura: WEBHA1012”) En este caso, CHILEOFFSHORE le propone la solución WEBHA1012 que es una arquitectura casi perfecta y segmentación de la capa de datos.  Diagrama 9 - Arquitectura WEBHA1012 - Sitio balanceado con ESB y Múltiples Data Centers En esta arquitectura, el sitio de su empresa puede estar alojado en diferentes data center y así mejorar el uptime del sitio. Además con la ayuda de ESB (ApiEMBSwitch de CHILEOFFSHORE), se puede aumentar la capacidad de la capa de datos. Para implementar esta arquitectura casi casi perfecta, se requieren: servidores web para la capa de presentación y equipos para realizar el balanceo de carga de estos servidores, servidores para alojar los ApiEMBSwitch HA y equipamiento de balanceo de carga de estos, para distribuir carga de capa de datos, y opcionalmente nuevos servidores para base de datos. Con esta arquitectura y con la ayuda de un ESB, su empresa ya puede hacer un crecimiento en la capa de datos. Especialmente segmentación de datos casi no requiere cambio de aplicación. [C] Solución Personalizada para Su Empresa (“Arquitectura WEBHA1021”)
✓ Falencia de diseño de arquitectura 1 - Saturación de capa de presentación. Dependiendo de las necesidades de su empresa, CHILEOFFSHORE provee varias alternativas para resolver sus problemas de desempeño en los eventos Cyber o de alta carga de trabajo:Alternativa 1: Arriendo mensual de equipos.
Alternativa 2. Full service con housing de Data Center (DC) en CHILEOFFSHORE, esto incluye:
Full service con housing de Data Center (DC) de tercero como SONDA, Entel, o DC de su empresa, en este caso CHILEOFFSHORE provee:
|
