Infrastructure Architecture

본 프로젝트는 On-Premise 환경과 AWS를 연동한 Hybrid Infrastructure를 직접 설계하고 구축하는 것을 목표로 한다. 단순한 애플리케이션 배포를 넘어, 실제 운영 환경을 가정한 네트워크 분리, 보안 계층, CI/CD, 관측(Observability), GitOps 구조를 구현하였다.

특히 ESXi 기반의 On-Premise 환경을 중심으로 Management, CI/CD, Service, LAB 영역을 명확히 분리하고, AWS는 외부 트래픽 진입점 및 보안 계층으로 활용하는 구조를 채택하였다.

본 인프라는 크게 다음 두 영역으로 구성된다.

• AWS Cloud 영역

  • 외부 사용자 트래픽 수신
  • TLS 인증, WAF, CDN, DDoS 방어
  • 실습 환경 제공

• On-Premise (ESXi 기반) 영역

  • 실제 서비스 운영
  • CI/CD, 모니터링, 인증

외부 사용자는 On-premise를 통해 서비스에 접근하고, AWS에서 실습 환경을 제공받는다. AWS와 On-Premise 간에는 Site-to-Site VPN으로 안전한 통신을 구성하였다.

이 구조를 통해:

• 외부 공격 표면을 최소화
• 내부 서비스 직접 노출 방지
• 실제 기업 환경과 유사한 Hybrid 구조 구현 을 목표로 하였다.

On-Premise 환경은 VMware ESXi Host 위에서 구성되었다.

• 물리 서버 자원 효율적 사용
• VM 단위 역할 분리
• 네트워크/보안 실험에 용이

ESXi 상의 VM들은 기능별로 명확히 분리하였다.

• Management VM
• CI/CD VM
• Kubernetes Worker / Control Plane VM
• LAB VM
• Network Gateway VM (pfSense)

이러한 분리는 장애 대처를 빠르게 대응하고, 운영 관점에서 책임 범위를 명확히 하기 위함이다.

On-Premise 환경의 핵심 네트워크 장비로 pfSense를 사용하였다.

pfSense의 주요 역할:

• Default Gateway
• NAT
• Firewall
• 내부망 ↔ 외부망 트래픽 제어

• Management Zone
• Service Zone
• CI/CD Zone
• LAB Zone

각 영역은 논리적으로 분리되며, 필요한 트래픽만 방화벽 규칙을 통해 허용하였다.

• AWS VPC ↔ On-Premise pfSense 간 Site-to-Site VPN
• AWS 내부 리소스에서 On-Prem 서비스로 안전한 접근 가능

AWS는 외부 진입점 및 보안 계층으로 활용된다.

• Route53

  • 도메인 관리

• ACM (AWS Certificate Manager)

  • TLS 인증서 발급

• CloudFront

  • CDN 및 HTTPS 종단점

• WAF

  • 웹 공격 방어

• Shield

  • DDoS 보호

1. User → Route53
2. CloudFront (TLS 종료)
3. WAF / Shield 보안 검사
4. VPN을 통해 On-Premise 서비스로 전달

AWS를 전면에 배치함으로써 On-Prem 서비스는 외부에 직접 노출되지 않는다.

Management 영역은 운영 및 관측 전용 영역이다.

• Prometheus

  • 메트릭 수집

• Grafana

  • 시각화 대시보드

• Loki

  • 로그 수집

• Keycloak

  • 인증 및 사용자 관리

• 운영 도구와 서비스 영역의 책임 분리
• 장애 발생 시 관리 시스템 독립성 유지
• 보안 사고 시 영향 범위 최소화

CI/CD 영역은 애플리케이션 빌드부터 배포까지의 자동화 파이프라인을 담당한다.

• GitLab

  • 소스 코드 저장소

• Jenkins

  • CI 파이프라인 실행

• Cosign

  • 컨테이너 이미지 서명

• Harbor

  • Private Container Registry

1. GitLab에 코드 Push
2. Jenkins 빌드 및 테스트
3. 이미지 빌드
4. Trivy 보안 스캔
5. Cosign 서명
6. Harbor에 이미지 저장

Service 영역은 실제 사용자 서비스가 동작하는 영역이다.

• Kubernetes Cluster
• Ingress Controller
• ArgoCD 기반 GitOps

• Next.js (Frontend)
• Spring Boot (Backend)
• MySQL (Database)

• Git 저장소의 선언적 YAML이 단일 진실 소스(Single Source of Truth)
• ArgoCD가 지속적으로 클러스터 상태 동기화

이를 통해 배포 이력 추적과 롤백이 용이한 구조를 구현하였다.

LAB 영역은 실습 및 테스트 전용 환경이다.

• Apache Guacamole

  • 웹 기반 원격 접속 환경

• 실제 서비스 영역과 분리된 실습 환경 제공
• 보안 사고 또는 실험 실패가 운영 서비스에 영향을 주지 않도록 설계

LAB 영역은 교육·실습·테스트를 고려한 구조로, 실제 기업의 내부 실습망 개념을 반영하였다.

본 프로젝트에서는 인프라의 일관성과 재현성을 위해 Infrastructure as Code 개념을 적극 활용하였다.

• AWS 리소스(Route53, CloudFront, VPN 연계 등)를 코드로 관리
• 수동 설정으로 인한 환경 편차 제거
• 인프라 변경 이력 추적 가능

On-Premise 환경 특성상 모든 요소를 IaC로 관리하기는 어렵지만,

• AWS 영역은 Terraform으로 관리
• On-Premise는 표준화된 VM 템플릿과 설정 문서로 관리

하는 방식으로 현실적인 Hybrid IaC 전략을 적용하였다.

본 인프라는 **다계층 보안(Multi-Layer Security)**을 핵심 설계 원칙으로 삼았다.

• pfSense Firewall을 통한 영역 간 접근 통제
• AWS WAF를 통한 웹 공격 차단
• 외부에서 On-Prem 직접 접근 차단

• Keycloak 기반 중앙 인증
• 서비스별 인증 분리 가능 구조

• Trivy를 통한 이미지 취약점 검사
• Cosign을 통한 이미지 서명
• 신뢰되지 않은 이미지의 배포 방지

운영 환경에서의 장애 대응을 고려하여 **관측 가능성(Observability)**을 중심으로 설계하였다.

• Prometheus로 시스템/애플리케이션 메트릭 수집
• Grafana 대시보드를 통한 시각화

• Loki를 통한 중앙 로그 수집
• 장애 발생 시 시간대별 로그 추적 가능

• “장애를 막을 수는 없지만, 숨길 수는 없다”
• 빠른 원인 파악과 영향 범위 식별을 목표로 설계

현재 구조는 단일 클러스터 기반이지만, 확장을 고려한 설계를 적용하였다.

• Kubernetes 노드 수평 확장
• LAB 영역 분리 클러스터화
• AWS 비중 확대 시 EKS로 이전 가능

• 멀티 클러스터 GitOps 구조
• 중앙 로그/메트릭 장기 보관
• Zero Trust 네트워크 모델 일부 적용

초기 인프라 구성에서는 GitLab, Jenkins, Harbor, MySQL, Kubernetes Control Plane, LAB VM 등 대부분의 VM이 단일 ESXi 호스트에 집중되어 있었다.

이로 인해 여러 VM에서 동시에 빌드, 이미지 Push, DB Write, Kubernetes 작업이 발생할 경우 vCenter UI 지연, VM 응답 저하, CPU Ready Time 증가, Disk I/O Latency 증가 가능성이 확인되었다.

단일 ESXi 호스트에 약 18대의 VM이 집중되어 있었고, CI/CD 계열 VM과 DB 계열 VM처럼 CPU와 Disk I/O를 많이 사용하는 VM들이 동시에 동작하면서 리소스 경합이 발생할 수 있는 구조였다.

특히 GitLab, Harbor, MySQL Master와 같이 I/O가 집중되는 VM이 같은 Datastore와 동일 호스트 자원을 공유하면서 병목 가능성이 존재하였다.

vCenter 고급 성능 차트를 통해 다음 항목을 확인하였다.

• CPU 사용률
• CPU Ready Time
• Disk Latency
• VM별 리소스 사용량
• 특정 시간대의 응답 지연 여부

• VM별 CPU / Memory 리소스 재산정
• 불필요한 GUI 및 백그라운드 데몬 제거
• VMware Tools 및 Balloon Driver 상태 확인
• swappiness=10 적용
• 오래된 Snapshot 및 불필요한 로그 정리
• GitLab, Harbor, MySQL Master 등 주요 VM에 CPU / RAM Reservation 적용
• I/O가 집중되는 VM을 SSD Datastore로 우선 배치
• 외부 보조 서버와 WireGuard Site-to-Site VPN 연동 구조 검토

메인 ESXi 호스트와 외부 보조 서버를 WireGuard 기반으로 연결하여 일부 VM을 분산 배치하였다.

분산 대상 VM은 Jenkins, GitLab, Harbor등의 VM을 우선 고려하였다. 핵심 VM인 MySQL Master, Kubernetes Master는 메인 서버에 유지하고, CI/CD 및 보조 DB 계열 VM을 외부 서버로 이전하여 CPU 및 I/O 부하를 분산하는 방향으로 설계하였다.

🔗 Project Notion Workspace
👉 (https://www.notion.so/Infrastructure-297e338a90a2803c8ce5c18d5c153beb?source=copy_link)