En esta semana, profundizaremos en la construcción de una buena arquitectura de datos. Aprenderemos cómo la arquitectura de datos se integra en el contexto más amplio de la arquitectura empresarial y exploraremos ejemplos específicos de arquitectura. También discutiremos principios orientadores para pensar como un arquitecto de datos.
Pensar como un arquitecto es crucial para el éxito en el trabajo de un ingeniero de datos.
Ejemplos de Arquitectura
Se discutirá cómo traducir las necesidades de los interesados en decisiones tecnológicas para los sistemas de datos.
Principios Orientadores
Se compartirán principios que ayudarán a desarrollar una mentalidad arquitectónica.
Laboratorio Práctico
Análisis de una arquitectura de datos en la nube de AWS.
Marco de Trabajo Bien Arquitectado de AWS
Al final de la semana, los participantes estarán equipados con herramientas útiles para todas las etapas de su trayectoria en ingeniería de datos.
Prepárate para un aprendizaje profundo sobre la arquitectura de datos y cómo aplicar estos conceptos en el mundo real. ¡Únete al próximo video para comenzar!
En este documento se resumen los conceptos clave sobre la arquitectura de datos y su relación con la arquitectura empresarial, así como la importancia de la toma de decisiones flexibles y reversibles en el contexto de la ingeniería de datos.
La arquitectura empresarial se define como el diseño de sistemas que apoyan el cambio en una organización, logrado a través de decisiones flexibles y reversibles, evaluando cuidadosamente los compromisos. Esta definición se alinea estrechamente con la arquitectura de datos, que se define como el diseño de sistemas para satisfacer las necesidades de datos en evolución de una empresa.
La arquitectura empresarial abarca varios dominios, que se pueden clasificar en cuatro áreas principales:
| Dominio | Descripción |
|---|---|
| Arquitectura de Negocios | Estrategia de producto o servicio y modelo de negocio de la empresa. |
| Arquitectura de Aplicaciones | Estructura e interacción de las aplicaciones clave que satisfacen las necesidades del negocio. |
| Arquitectura Técnica | Componentes de software y hardware necesarios para soportar la implementación de sistemas de negocio. |
| Arquitectura de Datos | Soporte a las necesidades de datos en evolución de la empresa. |
La gestión del cambio es un concepto crucial en la arquitectura empresarial y de datos. Las necesidades de una organización están en constante evolución, y la arquitectura de datos debe adaptarse a esos cambios.
Jeff Bezos introdujo la idea de decisiones de puerta de una vía y dos vías:
Las decisiones reversibles permiten a las organizaciones iterar y mejorar rápidamente cómo recopilan, utilizan y almacenan datos. La toma de decisiones flexible y reversible es fundamental para la arquitectura empresarial y de datos.
Los ingenieros de datos deben pensar como arquitectos, creando soluciones técnicas que apoyen directamente los objetivos comerciales. La arquitectura no se trata solo de mapear procesos, sino de resolver problemas comerciales y crear nuevas oportunidades.
Antes de avanzar a los principios de una buena arquitectura de datos, es importante mencionar la Ley de Conway, que influye en la arquitectura de todos los sistemas de datos. Esta ley sugiere que la estructura de una organización afecta la forma en que se diseñan sus sistemas.
Este resumen proporciona una visión general de la arquitectura de datos y su contexto dentro de la arquitectura empresarial, destacando la importancia de la flexibilidad y la adaptabilidad en la toma de decisiones.
En este documento se presenta un resumen de la Ley de Conway, un principio fundamental que influye en la arquitectura y los sistemas de datos dentro de las organizaciones. Se explora cómo la estructura de comunicación de una organización afecta el diseño de sus sistemas.
La Ley de Conway, formulada por Melvin Conway, establece que:
"Cualquier organización que diseña un sistema producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización."
Consideremos una empresa con cuatro departamentos: ventas, marketing, finanzas y operaciones. Si estos departamentos operan de manera aislada, sus patrones de comunicación también lo serán. Esto resultará en la creación de sistemas de datos igualmente aislados:
Si, en cambio, los departamentos se comunican de manera transversal, comparten ideas y colaboran, los sistemas de datos que desarrollen reflejarán esta cultura de colaboración. Esto resulta en un sistema más integrado y eficiente.
Como ingeniero de datos, es crucial entender que:
Para aquellos interesados en profundizar en la Ley de Conway, se ha incluido un enlace en la sección de recursos al final de la semana.
La Ley de Conway es un principio poderoso que resalta la importancia de la comunicación en el diseño de sistemas. En el próximo video, se explorarán los principios clave de una buena arquitectura de datos.
En este documento se resumen los principios fundamentales que deben considerarse al abordar la arquitectura de datos. Estos principios se agrupan en tres categorías y se discuten en detalle, centrándose en su impacto en la organización y la evolución de la arquitectura a lo largo del tiempo.
Las plataformas en la nube son ideales para adoptar estos componentes, permitiendo la separación de almacenamiento computado, lo que facilita el acceso a los datos por diferentes equipos.
La Arquitectura es Liderazgo
La arquitectura de datos no solo se trata de elegir las herramientas adecuadas, sino también de fomentar la colaboración entre equipos y adaptarse a las necesidades cambiantes de la organización. En el próximo video, se explorarán los principios relacionados con la flexibilidad en la arquitectura.
En este módulo, se exploran conceptos clave sobre la toma de decisiones en la arquitectura de sistemas de datos, haciendo énfasis en la importancia de las decisiones reversibles y el uso de interfaces de programación de aplicaciones (APIs). Se discute cómo estas prácticas permiten a los equipos adaptarse y evolucionar en un entorno tecnológico en constante cambio.
La capacidad de adaptarse y evolucionar es fundamental en la ingeniería de datos. En el próximo video, se abordarán las mejores prácticas relacionadas con el costo, la seguridad, la escalabilidad y los modos de falla de los sistemas que se construyen.
En este módulo, se abordan los principios fundamentales para construir sistemas de datos que no solo satisfacen las necesidades de los interesados, sino que también son escalables y seguros. Se enfatiza la importancia de anticipar fallos y se presentan conceptos clave como disponibilidad, confiabilidad y durabilidad de los sistemas de datos.
Planificar para el fracaso, arquitectar para la escalabilidad, priorizar la seguridad y adoptar FinOps son principios esenciales para servir mejor a las necesidades de la organización, tanto en situaciones normales como en casos de fallo.
En el siguiente video, se explorarán enfoques arquitectónicos específicos para diferentes tipos de sistemas de datos, centrándose en arquitecturas por lotes.
En este documento se resumen los conceptos clave sobre las arquitecturas de procesamiento por lotes, un enfoque tradicional en la ingeniería de datos. Se discutirán los patrones de arquitectura, las diferencias entre ETL y ELT, y consideraciones importantes al diseñar sistemas de datos.
El procesamiento por lotes es un enfoque tradicional donde se ingesta, transforma y almacena datos en bloques o lotes. Este método es más práctico cuando el análisis en tiempo real no es crítico.
En una empresa de comercio electrónico, un analista de datos podría estar interesado en analizar las ventas diarias de un producto específico. En este caso, se podría establecer una arquitectura por lotes que ingeste y procese los datos una vez al día.
Después de procesar los datos, se sirven para diferentes casos de uso, que pueden incluir: - Análisis - Aprendizaje automático - Reverse ETL: donde los datos procesados se envían de vuelta a los sistemas de origen.
Un data mart es un subconjunto más refinado de un almacén de datos, enfocado en un departamento o área de negocio específica. Facilita el acceso a los datos para analistas y la creación de informes.
Al diseñar una arquitectura de datos, es importante considerar:
Las decisiones tecnológicas al construir sistemas de datos presentan riesgos y oportunidades que pueden agregar valor a la organización. En el próximo video, se explorarán arquitecturas de streaming.
Este documento proporciona una visión general de las arquitecturas por lotes en la ingeniería de datos, destacando su importancia y las consideraciones clave al implementarlas.
En este documento se resumen los conceptos clave sobre arquitecturas de streaming en el contexto de la ingeniería de datos, abordando las diferencias entre procesamiento por lotes y en tiempo real, así como las arquitecturas Lambda y Kappa. También se discuten las herramientas y enfoques actuales para manejar datos en tiempo real y por lotes.
Los datos pueden ser procesados en lotes o en tiempo real.
Procesamiento por Lotes vs. Streaming:
Streaming: Los datos se ingieren y se proporcionan a sistemas downstream de manera continua y casi en tiempo real, a menudo en menos de un segundo.
Componentes de un Sistema de Streaming:
Capa de Servicio: Proporciona una vista combinada de los resultados de ambas capas.
Desafíos: Manejo de sistemas paralelos con diferentes bases de código.
La ingeniería de datos moderna enfrenta el desafío de unificar el procesamiento por lotes y el streaming. Las arquitecturas Lambda y Kappa han proporcionado inspiración, pero los ingenieros de datos deben seguir innovando y adaptándose a las nuevas herramientas y enfoques para manejar estos desafíos.
En el siguiente video se abordará la arquitectura para el cumplimiento normativo en sistemas de datos.
Este documento resume los conceptos clave sobre la importancia del cumplimiento normativo en la ingeniería de datos, destacando regulaciones relevantes como el GDPR y la HIPAA, y su impacto en el trabajo de un ingeniero de datos.
El cumplimiento normativo puede parecer un tema aburrido, pero es crucial para los ingenieros de datos. La falta de cumplimiento puede resultar en demandas y multas significativas para las organizaciones. Este documento aborda las regulaciones más relevantes y cómo los ingenieros de datos deben adaptarse a ellas.
El cumplimiento normativo es un aspecto esencial en la arquitectura de datos. Los ingenieros de datos deben estar al tanto de las regulaciones que afectan su trabajo y construir sistemas que cumplan con las normativas actuales y futuras. En la próxima lección, se explorarán las tecnologías adecuadas para la arquitectura de datos.
| Regulación | Área de Aplicación | Requisitos Clave |
|---|---|---|
| GDPR | Protección de Datos | Consentimiento, eliminación de datos |
| HIPAA | Datos de Salud | Protección de datos sensibles |
| Sarbanes-Oxley | Datos Financieros | Informes financieros, mantenimiento de registros |
Recuerda que el cumplimiento normativo es parte integral de la ingeniería de datos y debe ser considerado en cada etapa del desarrollo de sistemas.
En esta lección, se abordará cómo seleccionar las herramientas y tecnologías adecuadas para construir una arquitectura de datos efectiva. Se discutirá la importancia de considerar los compromisos entre diferentes opciones de diseño y cómo estas decisiones impactan en la calidad de los productos de datos.
| Tipo de Herramienta | Descripción |
|---|---|
| Open Source | Software de código abierto, accesible y modificable. |
| Managed Open Source | Soluciones de código abierto gestionadas por terceros. |
| Software Propietario | Soluciones comerciales con soporte y características específicas. |
La elección de herramientas y tecnologías es un proceso crítico en la ingeniería de datos. Es esencial tener en cuenta los principios de una buena arquitectura de datos y los ciclos de vida de la ingeniería de datos para asegurar el éxito en la implementación de soluciones efectivas.
Únete al siguiente video para profundizar en estos temas y prepararte para tomar decisiones informadas en la elección de herramientas y tecnologías.
En este módulo, se explora la evolución de los sistemas de datos desde soluciones locales (on-premises) hacia plataformas en la nube. Se discuten las ventajas y desventajas de cada enfoque, así como las tendencias actuales en la industria.
Responsabilidad operativa de aprovisionar, mantener, actualizar y escalar los recursos.
Sistemas en la Nube:
La industria se está moviendo hacia un mayor uso de la nube y menos hacia sistemas on-premises. Como aspirante a ingeniero de datos, es fundamental centrarse en el aprendizaje de la construcción de sistemas de datos en la nube.
Este documento resume las ideas clave del video sobre la evolución de los sistemas de datos y la importancia de la nube en la ingeniería de datos moderna.
En este documento se exploran las diferencias entre arquitecturas monolíticas y modulares en el contexto de la ingeniería de datos. Se discuten las ventajas y desventajas de cada enfoque, así como su impacto en la flexibilidad y mantenimiento de los sistemas.
Utiliza una sola tecnología y generalmente un único lenguaje de programación.
Ventajas:
Simplicidad: Fácil de entender y gestionar, ya que toda la funcionalidad está en un solo lugar.
Desventajas:
Emergen con el auge de los microservicios, donde cada servicio se despliega como una unidad independiente.
Ventajas:
| Característica | Monolítica | Modular |
|---|---|---|
| Acoplamiento | Fuerte | Débil |
| Mantenimiento | Difícil a medida que crece | Más fácil, actualizaciones independientes |
| Despliegue | Único | Servicios individuales |
| Flexibilidad | Limitada | Alta |
| Ejemplo de uso | Pipeline ETL monolítico | Microservicios |
La elección entre una arquitectura monolítica y modular depende de las necesidades específicas del proyecto y del equipo. La tendencia actual en la ingeniería de datos se inclina hacia un enfoque modular, que permite una mayor flexibilidad y adaptabilidad a los cambios tecnológicos.
En el siguiente video, se abordará la optimización de costos en la implementación de arquitecturas modulares.
En este documento se resumen los conceptos clave sobre la optimización de costos en el ciclo de vida de la ingeniería de datos, centrándose en el Costo Total de Propiedad (TCO), el Costo Total de Oportunidad de Propiedad (TOCO) y la importancia de FinOps. Se discuten las implicaciones de las decisiones tecnológicas en el presupuesto y el retorno de la inversión.
En cada etapa del ciclo de vida de la ingeniería de datos, existen múltiples herramientas y tecnologías disponibles. Cada elección conlleva un costo que no solo incluye el precio del software o servicio, sino también costos de implementación y costos de oportunidad.
El TCO es el costo total estimado de un proyecto o iniciativa a lo largo de su ciclo de vida. Incluye:
Tarifas de licencias de software.
Costos Indirectos:
| Tipo de Costo | Descripción |
|---|---|
| Costos Directos | Gastos fácilmente identificables relacionados con el desarrollo. |
| Costos Indirectos | Gastos no directamente atribuibles al desarrollo, como soporte y tiempo de inactividad. |
Los gastos se dividen en dos categorías principales:
Común en sistemas de datos antes de la nube.
Gastos Operativos (OpEx):
El TOCO se refiere al costo de las oportunidades perdidas al elegir una herramienta o tecnología específica. Es más difícil de cuantificar, pero implica que cada elección excluye otras posibilidades.
Para minimizar el TCO y el TOCO, es crucial construir sistemas flexibles y desacoplados que sean fáciles de actualizar.
SQL como lenguaje de consulta.
Tecnologías Transitorias:
FinOps se centra en minimizar los costos asociados con los sistemas de datos (TCO y TOCO) mientras se maximiza la generación de ingresos.
La elección de herramientas y tecnologías en ingeniería de datos tiene un impacto significativo en los costos y el retorno de la inversión. En el próximo video, se explorarán las compensaciones entre construir componentes de sistemas de datos propios y comprar soluciones prefabricadas.
En este documento se resumen las ideas y conceptos discutidos en el video "14_Build vs Buy" del curso de Introducción a la Ingeniería de Datos, Módulo 3. Se abordan las consideraciones sobre la elección de herramientas y tecnologías en la arquitectura de datos, así como las ventajas y desventajas de construir soluciones personalizadas frente a utilizar servicios existentes.
La decisión entre construir o comprar herramientas y tecnologías en ingeniería de datos debe basarse en un análisis cuidadoso de las capacidades del equipo, los costos involucrados y el valor que se puede obtener. En el próximo video, se explorarán las diferencias entre opciones sin servidor y con servidor para herramientas y tecnologías.
| Opción | Ventajas | Desventajas |
|---|---|---|
| Código Abierto | Comunidad de soporte, personalización | Requiere tiempo y recursos para mantenimiento |
| Comercial de Código Abierto | Gestión simplificada, soporte profesional | Costo potencialmente más alto |
| Propietario | Soporte completo, fácil de implementar | Menos flexibilidad, costos de licencia |
| Construcción desde cero | Solución completamente adaptada a necesidades | Alto costo y esfuerzo, riesgo de reinventar la rueda |
¡Únete al próximo video para explorar las diferencias entre opciones sin servidor y con servidor!
En este documento se resumen las principales ideas y conceptos sobre las opciones de cómputo disponibles para alojar aplicaciones de software, centrándose en tres enfoques: servidores, contenedores y soluciones serverless. Se discuten las diferencias, ventajas y desventajas de cada opción, así como consideraciones de costos y uso.
Para alojar cualquier aplicación de software, se necesita un servidor, que es esencialmente una computadora o un conjunto de computadoras que proporciona recursos de cómputo como CPU, memoria (RAM), almacenamiento en disco, y posiblemente GPU y conectividad de red. Los servidores ofrecen recursos de cómputo a través de una red, generalmente a través de Internet.
Para la mayoría de las aplicaciones modernas de ingeniería de datos en la nube, se puede optar por herramientas serverless o contenedorizadas. Se recomienda comenzar con soluciones serverless y, si es necesario, pasar a contenedores y orquestación.
Es fundamental entender los detalles de la fijación de precios en la nube para predecir los costos de las implementaciones serverless y decidir si son más rentables que las opciones de servidor. La monitorización de las tasas de eventos, duración y costo por evento es crucial para modelar el costo total de los servicios utilizados.
| Opción | Responsabilidad del Usuario | Escalabilidad | Costo | Ideal para |
|---|---|---|---|---|
| Servidor | Alta | Manual | Fijo | Aplicaciones complejas |
| Contenedor | Moderada | Automática | Variable | Aplicaciones modulares |
| Serverless | Baja | Automática | Pago por uso | Tareas simples y discretas |
En el siguiente video, se explorarán los aspectos del ciclo de vida de la ingeniería de datos que influyen en la elección de herramientas y tecnologías para la arquitectura de datos.
En esta lección, se exploran los subcorrientes del ciclo de vida de la ingeniería de datos y su impacto en la elección de herramientas y tecnologías para construir una arquitectura de datos. Se revisan seis subcorrientes clave: seguridad, gestión de datos, operaciones de datos, arquitectura de datos, orquestación e ingeniería de software.
| Subcorriente | Consideraciones Clave |
|---|---|
| Seguridad | - Comprender las características de seguridad de las herramientas. |
| - Implementar tecnologías de autenticación adecuadas. | |
| - Usar software de organizaciones reputadas y comunidades de código abierto confiables. | |
| Gestión de Datos | - Preguntar cómo se implementan las prácticas de gobernanza de datos. |
| - Asegurarse de que los datos estén protegidos contra brechas. | |
| - Verificar el cumplimiento con regulaciones de privacidad de datos como GDPR. | |
| Operaciones de Datos | - Evaluar las características de automatización y monitoreo de las herramientas. |
| - Entender el Acuerdo de Nivel de Servicio (SLA) del proveedor si se opta por un servicio gestionado. | |
| Arquitectura de Datos | - Buscar modularidad e interoperabilidad entre herramientas. |
| - La buena modularidad permite flexibilidad y desacoplamiento entre componentes. | |
| Orquestación | - Apache Airflow es el líder en orquestación, pero hay otras opciones como Prefect, Dagster y Mage. |
| - Comprender los objetivos de tu arquitectura de datos para elegir la herramienta adecuada. | |
| Ingeniería de Software | - Evaluar la capacidad y experiencia de tu equipo para decidir entre construir o usar herramientas existentes. |
| - Evitar el "trabajo pesado no diferenciado" que no agrega valor a la organización. |
Es fundamental tener en cuenta cada uno de estos subcorrientes al seleccionar herramientas y tecnologías para tu arquitectura de datos. A medida que avanzamos, se abordarán conceptos prácticos y se explorará el marco arquitectónico bien diseñado de AWS para evaluar las elecciones arquitectónicas en tu propia arquitectura de datos.
Únete a la próxima lección para explorar el marco arquitectónico bien diseñado de AWS y evaluar las elecciones arquitectónicas para tu propia arquitectura de datos en AWS.
En esta lección, se presenta el Marco de Arquitectura Bien Diseñada de AWS, que proporciona un conjunto de principios y mejores prácticas para construir arquitecturas escalables y robustas en la nube de AWS. Este marco complementa los principios y prácticas discutidos previamente en el curso sobre fundamentos de arquitectura de datos.
El Marco de Arquitectura Bien Diseñada de AWS se basa en varios principios que son esenciales para el diseño de una buena arquitectura de datos. Estos principios son:
Al buscar "AWS Well-Architected Framework", se pueden encontrar diversos recursos útiles, tales como:
En el próximo video, Morgan ofrecerá una introducción a los seis pilares clave de este marco y mostrará dónde se puede aprender más y practicar con él. Posteriormente, se realizará un ejercicio práctico en el laboratorio para aplicar los principios de una buena arquitectura de datos en la nube de AWS.
El Marco de Arquitectura Bien Diseñada de AWS es una guía valiosa para cualquier ingeniero de datos que busque construir arquitecturas efectivas y eficientes en la nube. La comprensión y aplicación de estos principios son fundamentales para el éxito en la ingeniería de datos.
El Marco de Referencia Bien Arquitectado de AWS es una guía que ayuda a los arquitectos y desarrolladores a construir soluciones efectivas en la nube de AWS. Este marco se basa en la experiencia acumulada de AWS trabajando con miles de clientes y se centra en evaluar y mejorar las soluciones para asegurar que se construyan de manera correcta.
El Marco de Referencia Bien Arquitectado se compone de seis pilares fundamentales:
| Pilar | Descripción |
|---|---|
| Excelencia Operacional | Se enfoca en desarrollar y ejecutar cargas de trabajo de manera efectiva, monitoreando sistemas y mejorando procesos. |
| Seguridad | Se centra en proteger datos, sistemas y activos utilizando tecnologías en la nube y fomentando una cultura de seguridad. |
| Confiabilidad | Trata sobre el diseño de sistemas que funcionen correctamente y se recuperen rápidamente de fallos. |
| Eficiencia de Rendimiento | Se basa en un enfoque basado en datos para construir arquitecturas de alto rendimiento y mantener la eficiencia. |
| Optimización de Costos | Busca maximizar el valor empresarial al menor costo posible, utilizando herramientas como AWS Cost Explorer. |
| Sostenibilidad | Se enfoca en reducir el consumo de energía y aumentar la eficiencia en todos los componentes del sistema. |
Mejorar continuamente procesos y procedimientos.
Seguridad
Fomentar una cultura de seguridad en el equipo.
Confiabilidad
Planificar para fallos y adaptarse a cambios.
Eficiencia de Rendimiento
Mantener la eficiencia a medida que cambian las demandas.
Optimización de Costos
Utilizar servicios como AWS Cost Explorer para recomendaciones de optimización.
Sostenibilidad
El Marco de Referencia Bien Arquitectado no proporciona diseños específicos para copiar, sino que actúa como un conjunto de principios y preguntas que facilitan conversaciones productivas sobre soluciones existentes. Esto permite diseñar y operar sistemas confiables, seguros, eficientes, rentables y sostenibles en la nube.
Existen aplicaciones específicas del Marco de Referencia llamadas "Lentes", que se centran en áreas, industrias o tecnologías particulares. Cada lente ofrece preguntas, mejores prácticas y planes de mejora específicos. Se recomienda explorar la Lente de Análisis de Datos, que se enfoca en consideraciones específicas de datos.
Para más información sobre cada uno de los pilares y para explorar la herramienta Bien Arquitectado que permite evaluar arquitecturas, se pueden seguir los enlaces proporcionados en la sección de recursos al final del curso.
Ahora es tu turno de aplicar los principios discutidos en tu propia arquitectura de datos en AWS. A través de los próximos videos, se te guiará en un ejercicio práctico para implementar estos conceptos. ¡Buena suerte!
En este laboratorio, se explorará la arquitectura de una aplicación web diseñada para servir datos analíticos a clientes externos. Se utilizarán instancias EC2 y se aplicarán principios de arquitectura de datos, así como el marco bien arquitectado de AWS. El objetivo es garantizar que la aplicación sea escalable, eficiente en el uso de recursos y segura.
La aplicación web está diseñada con una arquitectura de tres capas:
| Capa | Descripción |
|---|---|
| Capa de Datos | Representada por un bucket S3, donde se extraen los datos. |
| Capa de Lógica | Compuesta por instancias EC2 y un balanceador de carga (ALB) que procesa las solicitudes de los clientes. |
| Capa de Presentación | Interfaz que muestra los resultados a los clientes, como los dashboards analíticos. |
Este laboratorio proporcionará una comprensión práctica de cómo escalar y monitorear una aplicación web en AWS, aplicando principios de arquitectura de datos y optimización de recursos. En el siguiente video, se explorarán más detalles sobre la monitorización de los recursos de la aplicación.
En este documento se resumen las tareas del laboratorio relacionadas con el monitoreo de instancias EC2 en un grupo de escalado automático y las actividades de red a través del balanceador de carga de aplicaciones. Se utilizarán herramientas como Amazon CloudWatch y Apache Benchmark para simular tráfico y monitorear el rendimiento de la aplicación.
Localizar el balanceador de carga y obtener la dirección de la página web de la aplicación.
Simulación de Tráfico
Utilizar Apache Benchmark para realizar pruebas de estrés enviando múltiples solicitudes HTTP a la aplicación.
Monitoreo de Recursos
bash
ab -n 7000 -c 50 http://<DIRECCIÓN_DE_LA_APLICACIÓN>
Donde <DIRECCIÓN_DE_LA_APLICACIÓN> es la dirección copiada del balanceador de carga.| Métrica | Descripción |
|---|---|
| Utilización de CPU | Muestra el uso de recursos para procesar las solicitudes. |
| Actividad de Red Entrante | Monitorea el tráfico de datos que llega a la aplicación. |
| Actividad de Red Saliente | Monitorea el tráfico de datos que sale de la aplicación. |
En el siguiente video, se explorarán aspectos de seguridad, disponibilidad, escalabilidad y costos de la aplicación web.
En este video, se presenta un recorrido por el laboratorio donde se aplican principios de arquitectura de datos para asegurar la seguridad, disponibilidad y escalabilidad de aplicaciones, optimizando costos. Se revisan configuraciones de seguridad, confiabilidad, optimización de costos y escalabilidad en un entorno de AWS.
| Puerto | Protocolo | Descripción |
|---|---|---|
| 80 | HTTP | Acceso permitido |
| 90 | Privado | Acceso bloqueado |
| Tipo de Instancia | Capacidad de Memoria | Costo |
|---|---|---|
| T3 Micro | Alta | Alto |
| T3 Nano | Baja | Bajo |
Al finalizar el laboratorio, es importante seguir las instrucciones cuidadosamente y enviar el trabajo antes de que expire el entorno del laboratorio. Se recomienda revisar los videos de recorrido si es necesario.