CASO DE ESTUDIO
Corporación Financiera más grande de Colombia
Compañía colombiana líder en servicios financieros, enfocada en inversión, crédito e intermediación financiera, que presta servicios a algunas de las mayores corporaciones y sectores estratégicos de Colombia y la región. Con más de 60 años de experiencia, la organización desempeña un papel clave en la estructuración, gestión y administración de inversiones corporativas, financiación de proyectos y operaciones de tesorería, contribuyendo al crecimiento económico sostenible en sectores como infraestructura, energía y agroindustria.
Desafío del Cliente
Vista simplificada del proceso
PRINCIPAL
Planteamiento del problema
La arquitectura de la plataforma del cliente no utiliza Amazon ECS. En su lugar, la solución se basa en instancias de Amazon EC2 implementadas en múltiples zonas de disponibilidad. La arquitectura incluye varios servidores de aplicaciones Liferay (Liferay Server A y Liferay Server B) y un servidor de administración Liferay dedicado. Estos servidores de aplicaciones operan en subredes privadas, mientras que los servidores web Apache se implementan en subredes públicas para actuar como puntos de entrada seguros. Este diseño mejora la seguridad al aislar la lógica de la aplicación y garantizar que los sistemas backend nunca estén expuestos directamente a internet, pero también añade complejidad adicional para la observabilidad y la recopilación de registros.
Sin una solución de observabilidad centralizada, el cliente se enfrentaba a una visibilidad limitada del comportamiento de los widgets y de los problemas de ingesta de datos. Las fallas en la actualización de datos o en la conectividad ascendente eran difíciles de detectar, ya que los widgets podían seguir renderizándose mientras proporcionaban silenciosamente datos obsoletos o incompletos. La detección manual no era viable debido al volumen y la granularidad de la información financiera. Si no se abordaban, estas limitaciones planteaban riesgos operativos y de reputación, como la detección tardía de incidentes, la prolongación de los ciclos de resolución de problemas, la reducción de la confianza en los datos financieros y un posible impacto en la confianza de los clientes y en los informes regulatorios. El cliente necesitaba una solución de monitoreo y registro que proporcionara información práctica sobre el comportamiento de la plataforma sin comprometer los límites de seguridad ni exponer la infraestructura interna.
CÓMO
se utilizó AWS como parte de la solución.
Para resolver los desafíos de observabilidad y visibilidad operativa, nuestra organización diseñó e implementó una solución centralizada de monitoreo y análisis de registros utilizando Amazon OpenSearch Service como plataforma principal de observabilidad. La solución se adaptó a la arquitectura basada en EC2 del cliente, donde las cargas de trabajo de las aplicaciones se ejecutan en múltiples servidores Liferay implementados en subredes privadas, sin usar Amazon ECS ni mecanismos de registro nativos de contenedores.
Para habilitar la telemetría a nivel de aplicación sin modificar la lógica de la aplicación existente, se instaló el agente Java de AWS Distro for OpenTelemetry (OTEL) en cada instancia EC2 de Liferay (OpenTelemetryAgent.jar). El agente opera directamente dentro del proceso JVM de Liferay y captura automáticamente registros, métricas y datos de telemetría en tiempo de ejecución. Este enfoque permitió al cliente instrumentar sus aplicaciones de forma consistente en todos los servidores, manteniendo al mismo tiempo el código y la infraestructura de la aplicación completamente aislados.
Los datos de telemetría recopilados por los agentes OTEL se reenvían de forma segura mediante el protocolo OpenTelemetry (OTLP) a un recopilador OpenTelemetry centralizado, implementado como una tarea de Amazon ECS mediante la imagen de contenedor aws-otel-collector. Este recopilador actúa como una capa de agregación y procesamiento, desvinculando las cargas de trabajo de las aplicaciones de los servicios de análisis posteriores. Desde el recopilador, los registros se enrutan a través de una canalización de ingesta de Amazon OpenSearch, que enriquece, normaliza y distribuye los datos a índices de OpenSearch específicos del servicio.
Amazon OpenSearch Service funciona como motor centralizado de almacenamiento y análisis de registros. Los registros se indexan por servicio, lo que permite un control de acceso preciso y una clara separación de las cargas de trabajo. A través de los paneles de OpenSearch y el complemento Observability, el cliente obtiene acceso seguro de solo lectura a los datos operativos. Mediante Event Explorer, Query Workbench y paneles personalizados, el cliente puede analizar de forma independiente patrones de error, supervisar el crecimiento del volumen de registros e identificar problemas operativos recurrentes sin necesidad de acceder a los servidores backend ni a la infraestructura de AWS.
Para garantizar la escalabilidad y el control de costes, se implementaron políticas de gestión del estado del índice (ISM) en OpenSearch para gestionar automáticamente la retención de registros. Los índices de registros se mantienen activos para su análisis y se eliminan automáticamente tras un periodo de retención definido, lo que evita el crecimiento descontrolado de los datos y conserva suficiente historial para la resolución de problemas operativos y la auditoría.
Durante la implementación, nuestra organización proporcionó el diseño arquitectónico, el aprovisionamiento de infraestructura mediante servicios nativos de AWS y la capacitación del cliente mediante una incorporación guiada y paneles de ejemplo. Esto garantizó que el cliente no solo recibiera una solución de observabilidad técnicamente sólida, sino también la capacidad operativa para monitorear de forma independiente el comportamiento de la plataforma, detectar anomalías en la ingesta de datos y responder eficazmente a incidentes, manteniendo estrictos límites de seguridad y responsabilidad.
PRINCIPAL
Resultados
La implementación de Amazon OpenSearch Service con el complemento Observability mejoró significativamente la capacidad de Corficolombiana para monitorear, analizar y responder a problemas operativos que afectan su plataforma de widgets financieros. Al centralizar los registros de aplicaciones de múltiples servidores Liferay que se ejecutan en Amazon EC2 y exponerlos a través de una capa de observabilidad segura y de autoservicio, el cliente obtuvo visibilidad continua del comportamiento de las aplicaciones y los patrones de ingesta de datos que anteriormente estaban fragmentados en servidores individuales.
Gracias a la solución, el cliente redujo el tiempo necesario para detectar la ingesta de datos y errores a nivel de aplicación, pasando de la investigación manual y reactiva a la identificación casi en tiempo real mediante paneles de control y análisis de registros. Los equipos operativos ahora pueden identificar problemas recurrentes, como fallos de conexión, picos de errores y crecimiento anormal de registros, en minutos en lugar de horas. El esfuerzo de investigación de incidentes para problemas recurrentes se redujo aproximadamente entre un 40 % y un 60 %, ya que los ingenieros ya no necesitan acceder manualmente a los servidores, recopilar registros ni correlacionar eventos en múltiples sistemas.
Además, el modelo de observabilidad de autoservicio redujo significativamente la dependencia operativa del socio para los diagnósticos rutinarios. Al permitir que los equipos de los clientes exploraran registros de forma independiente, analizaran tendencias de errores y validaran problemas de datos externos antes de escalarlos, la solución acortó los ciclos de escalamiento y mejoró la coordinación con los proveedores de datos externos. La retención automatizada de registros mediante la Gestión del Estado del Índice redujo aún más el crecimiento del almacenamiento y la sobrecarga operativa, lo que contribuyó a una mayor previsibilidad de los costos operativos. En general, la solución mejoró la resiliencia operativa, aceleró la respuesta a incidentes y aumentó la confianza en la fiabilidad de los widgets financieros sin ampliar el acceso a la infraestructura de la plataforma interna.
