중소기업(SME) 인프라를 위한 실시간 멀티테넌트 관측성(Observability) 및 AI 장애 진단 서비스

Monittoring은 복잡한 설정 없이 에이전트 설치 파일 하나만으로 가상 머신(VM) 및 도커 컨테이너의 시스템 리소스와 실시간 로그를 수집하고, 안전하게 시각화 대시보드와 AI 기반의 시스템 장애 분석(LLM)을 제공하는 오픈스택 관측 서비스입니다.

기존의 엔터프라이즈 모니터링 아키텍처(Node Exporter + cAdvisor + Promtail)는 저사양 인프라를 운영하는 중소기업에게 **높은 리소스 소모(오버헤드)**와 복잡한 설치 과정, 그리고 방화벽 포트를 개방해야 하는 보안적 한계가 존재했습니다.

Monittoring은 이를 해결하기 위해 다음과 같은 아키텍처적 차별점을 제공합니다.

1. 에이전트 단일화 및 경량화: 메트릭과 로그를 GoLang 기반의 단일 데몬 프로세스에서 통합 수집하여 메모리 오버헤드를 10~20MB 이하로 제어합니다.
2. 인바운드 포트 완전 폐쇄 (Push 방식): 프로메테우스의 전통적인 Pull(수집 서버가 타깃 서버를 긁어가는 구조) 방식 대신, 에이전트가 외부로 데이터를 밀어 넣는 OTLP(OpenTelemetry) Push 방식을 채택하여 기업 방화벽 포트 개방 없이 안전한 관제를 보장합니다.
3. 완벽한 멀티테넌트(Multi-tenant) 및 보안 격리: 신규 기업 가입 시 AWS 상에 격리된 전용 모니터링 서버를 동적으로 프로비저닝하며, 모든 모니터링 DB 포트(9090, 3100)를 VPC Private Subnet 내부망에 숨겨 외부 직접 노출을 완전 차단합니다.
4. AI 지능형 장애 진단 지원: 수집된 오류 로그 패턴 및 지표 분석을 위해 OpenAI(Langchain4j)와 연동된 관제 전용 챗봇을 내장하여 인프라 담당자의 신속한 장애 조치(Troubleshooting)를 돕습니다.

• Public Subnet (ap-northeast-2a/c): 데이터 수집 수신용 ALB 및 백엔드 API용 ALB, NAT Gateway 등 퍼블릭 접점 인입 관문 배치.
• Private Subnet (ap-northeast-2a/c):
  • Spring App Subnet: 메인 백엔드 서버(Spring Boot) 격리 배치.
  • Database Subnet: RDS MySQL 마스터 및 Multi-AZ 이중화 대상 서버 배치.
  • Monitoring Subnet: 고객 기업 가입 시 동적 생성되는 전용 모니터링 EC2 인프라가 격리 배치되는 영역.

• www.monittoring.co.kr: 사용자 웹 대시보드 콘솔
• api.monittoring.co.kr: Spring Boot 백엔드 API 서비스 엔드포인트
• data.monittoring.co.kr: OTLP(OpenTelemetry) 에이전트 수집용 패킷 수신 관문 (Port 4318)
• agent.monittoring.co.kr: 에이전트 원클릭 설치 스크립트 배포용 AWS S3 정적 호스팅

• 역할: 관제 대상 호스트 및 컨테이너에 설치되는 경량 수집기.
• 핵심 구현:
  • Go Concurrency(고루틴) 비동기 처리를 도입해 블로킹 I/O(로그 파일 테일링)가 메인 10초 메트릭 수집 루프를 지연시키지 않도록 병렬 설계.
  • /proc 파일시스템 및 cgroup v2를 커널 수준에서 바이트 스트림 파싱하여 CPU/메모리 계측 오버헤드 최소화.
  • 수집한 로그/메트릭을 OTLP 규격으로 변환하여 data.monittoring.co.kr을 향해 Push 방식으로 전송.

• 역할: 기업별 관제용 격리 인프라 동적 프로비저닝 및 내부 보안 쿼리 중계.
• 핵심 구현:
  • 고객 기업 가입 시 AWS SDK를 통해 전용 관제 EC2 인스턴스를 자동으로 프로비저닝하고 Docker Compose 환경(Prometheus, Loki, OTel Collector, Alert Manager)을 스케줄링 및 빌드.
  • 공용 ALB의 Listener Rule을 제어하여, Host Header(data) 및 HTTP Custom Header(X-Server-Group: monitoringId) 조건 검사를 거치는 L7 동적 분기 라우팅 자동화.
  • Private Subnet 내부 IP 정보 기반으로 내부망 안에서 직접 Prometheus/Loki REST API에 프록시 쿼리를 수행하고 React DTO 포맷으로 데이터를 가공 반환하여 외부 보안성 강화.

• 역할: 관리자 관제 모니터링 통합 대시보드.
• 핵심 구현:
  • Webflow의 미적 기준을 준수한 5레이어 캐스케이드 그림자 시스템 및 translate 모션 기반 카드 레이아웃 대시보드 컴포넌트 설계.
  • CPU, Memory, Disk, Network 트래픽 시각화 및 실행 중인 컨테이너 상태 정보 대시보드 제공.
  • OpenAI 대화형 가상 진단 챗봇 창을 통한 대시보드 데이터 연동 및 시스템 디버깅/장애 대처(Q&A) 지원.

에이전트가 OTLP/HTTP 패킷을 data.monittoring.co.kr로 전송하면, ALB가 헤더 분석 후 일치하는 타깃 인스턴스 전용 Target Group으로 데이터를 전달합니다.

각 인스턴스의 OTel Collector가 데이터 경로를 파악하여 메트릭은 Prometheus로, 로그 스트림은 Loki 데이터 저장소로 각각 분류하여 보관합니다.

사용자가 화면을 통해 관제 정보를 요청하면 API ELB ➔ Spring Boot(Private Subnet)로 도달하며, VPC 내부 프라이빗 IP 경로를 타고 동적으로 Prometheus/Loki 데이터를 쿼리해와 시각화 화면으로 돌려줍니다.

본 서비스의 모든 인프라 배포 및 백엔드 업데이트는 Jenkins를 통해 자동화되어 설계되었습니다.

• 네트워크 구성:
  • Jenkins 빌드 서버는 외부의 직접적인 침입을 차단하기 위해 Private Subnet(capstone-private-cicd-a) 영역에 격리 배치되어 있습니다.
  • 외부(GitHub 코드 체크아웃 및 AWS ECR 이미지 푸시 등)로 나가는 아웃바운드 통신은 NAT Gateway를 경유하여 수행됩니다.
  • Jenkins 관리 UI에 접속하는 인바운드 트래픽은 ALB(Load Balancer)를 거치도록 설계하여 보안 위협을 제어합니다.
• 보안 및 권한 관리:
  • Jenkins가 기동되는 EC2 인스턴스에 필요한 AWS 정책이 부여된 IAM Role을 연결하여, 소스 코드 내부에 AWS Access Key / Secret Key 같은 민감 정보를 일절 기록하지 않고도 안전하게 Amazon ECR 및 ECS(Fargate) 서비스에 접근할 수 있도록 설계했습니다.
• 배포 파이프라인 단계:
  1. Trigger (Webhook): 개발자가 GitHub Main 브랜치에 코드를 Push하면 GitHub Webhook이 활성화되어 프라이빗 내부망에 격리된 Jenkins 빌드 서버를 깨웁니다.
  2. Checkout: Jenkins가 NAT Gateway를 경유하여 GitHub 리포지토리로부터 최신 소스코드를 안전하게 클론합니다.
  3. Build & Push (Amazon ECR): 애플리케이션 코드를 빌드하고 Docker 컨테이너 이미지로 패키징하여 Amazon ECR (Elastic Container Registry) 개인 전용 저장소로 Push합니다.
  4. Deploy (Amazon ECS): Jenkins가 AWS API를 호출하여 ECS 서비스를 강제 배포(aws ecs update-service --cluster [클러스터] --service [서비스] --force-new-deployment)합니다. Amazon ECS는 ECR로부터 최신 이미지를 다운로드받아 순차적으로 롤링 업데이트 배포 및 구버전 컨테이너 교체를 완료합니다.

5. 👥 팀 멤버 및 역할 (Team Members & Roles)

• 김홍석 : 리더 (Leader / Infrastructure & Agent Architect)
• 최종희 : 백엔드 개발 (Backend Developer)
• 최다빈 : 프론트엔드 개발 (Frontend Developer)
• 김채은 : 디자인 개발 (UI/UX Engineer)