TIL - 20260319

juni·2026년 3월 19일

TIL

목록 보기
297/316

0319 스프링 부트 프로젝트 (11/N): AWS 배포 아키텍처 총정리


✅ 1. 전체 아키텍처 목표: 분리, 확장성, 고가용성

  • 오늘의 학습은 개발이 완료된 Spring Boot 애플리케이션을 AWS 클라우드 환경에 배포하여, 실제 운영 환경과 같이 안정적이고 확장 가능하며, 안전하게 서비스하는 전체 아키텍처를 종합적으로 이해하는 것입니다.

  • 핵심 원칙:

    • 분리 (Decoupling): 애플리케이션 서버(EC2)와 데이터베이스 서버(RDS)를 물리적으로 분리하여 독립적으로 관리하고 확장합니다.
    • 확장성 (Scalability): 트래픽 변화에 유연하게 대응할 수 있도록 Auto Scaling을 적용합니다.
    • 고가용성 (High Availability): 단일 장애 지점(SPOF)을 제거하기 위해 리소스를 여러 가용 영역(AZ)에 분산 배포합니다.

✅ 2. 인프라 구성: VPC와 핵심 서비스 배치

  • VPC (Virtual Private Cloud): AWS 클라우드 내에 구축하는 논리적으로 격리된 나만의 가상 네트워크입니다. 보안과 네트워크 제어의 기본 단위입니다.

  • 서비스 배치 전략:

    1. 퍼블릭 서브넷 (Public Subnet):

      • 인터넷 게이트웨이(IGW)와 연결되어 외부 인터넷과 직접 통신하는 영역입니다.
      • 배치 대상:
        • Application Load Balancer (ALB): 외부 사용자의 모든 요청을 받는 단일 진입점.
        • NAT 게이트웨이: 프라이빗 서브넷의 아웃바운드 통신을 위한 출구.
    2. 프라이빗 서브넷 (Private Subnet):

      • 외부에서 직접 접근할 수 없는, 보안이 강화된 내부 네트워크 영역입니다.
      • 배치 대상:
        • EC2 인스턴스 (애플리케이션 서버): 실제 Spring Boot 애플리케이션이 동작하는 서버.
        • RDS 인스턴스 (데이터베이스 서버): 중요한 데이터를 저장하는 관리형 데이터베이스.

✅ 3. 아키텍처 흐름 및 주요 컴포넌트 역할

  • 아키텍처 흐름: 사용자Route 53ALB (HTTPS 처리)EC2 Auto Scaling GroupEC2 인스턴스RDS
  1. Route 53 (DNS 서비스):

    • api.mydomain.com과 같은 API 도메인 요청을 ALB의 DNS 주소로 연결해주는 교통경찰 역할을 합니다.
  2. ALB (Application Load Balancer):

    • 역할: 들어오는 트래픽을 여러 EC2 인스턴스에 자동으로 분산하고, 헬스 체크를 통해 장애가 발생한 인스턴스를 격리하여 고가용성을 확보합니다.
    • HTTPS 처리 (SSL Offloading): ACM(AWS Certificate Manager)에서 발급받은 SSL 인증서를 통해 HTTPS 요청을 받아 복호화한 후, 내부적으로는 HTTP를 사용하여 EC2와 통신합니다.
  3. EC2 Auto Scaling Group:

    • 역할: CPU 사용률과 같은 지표를 모니터링하여, 정의된 조정 정책에 따라 EC2 인스턴스의 수를 자동으로 늘리거나(Scale-out) 줄여(Scale-in) 탄력성을 제공합니다.
    • 자가 치유(Self-healing): 헬스 체크 실패 등으로 특정 인스턴스가 비정상 상태가 되면, Auto Scaling Group은 해당 인스턴스를 종료하고 건강한 새 인스턴스를 자동으로 생성하여 교체합니다.
  4. EC2와 RDS의 안전한 연동:

    • 핵심: RDS의 보안 그룹에서, EC2의 보안 그룹 ID를 소스로 지정하여, 오직 허가된 EC2 인스턴스 그룹만이 데이터베이스에 접근할 수 있도록 설정합니다. 이를 통해 DB를 외부 위협으로부터 안전하게 보호합니다.

✅ 4. 배포 자동화: CI/CD 파이프라인 연계

  • 이러한 복잡한 인프라에 애플리케이션을 배포하는 과정은 CI/CD 파이프라인을 통해 자동화되어야 합니다.

  • 배포 흐름 복습:

    1. [CI] 개발자가 코드를 Git에 푸시하면, GitHub Actions가 이를 감지하여 프로젝트를 빌드하고 Docker 이미지를 생성합니다.
    2. [CI] 생성된 이미지를 AWS ECR(Elastic Container Registry)과 같은 중앙 이미지 레지스트리에 푸시합니다.
    3. [CD] GitHub Actions가 CodeDeploy와 같은 AWS 배포 서비스를 호출하거나, SSH를 통해 EC2 인스턴스에 직접 접속합니다.
    4. [CD] EC2 인스턴스에서 최신 이미지를 Pull 받고, 기존 컨테이너를 내린 후 새 컨테이너를 실행하여 배포를 완료합니다. (무중단 배포 전략 적용)

📌 요약

  • 안정적인 Spring Boot 애플리케이션 배포를 위해, VPC 내에 퍼블릭 서브넷프라이빗 서브넷을 구성하여 네트워크를 분리합니다.
  • 사용자 요청은 Route 53을 통해 ALB로 전달되며, ALB는 HTTPS 처리부하 분산을 담당한 후 EC2 인스턴스로 트래픽을 보냅니다.
  • EC2 인스턴스Auto Scaling Group에 의해 관리되어 트래픽에 따라 자동으로 확장/축소되며, 프라이빗 서브넷RDS보안 그룹을 통해 안전하게 통신합니다.
  • 이 모든 인프라 구성과 애플리케이션 배포 과정은 CI/CD 파이프라인을 통해 자동화되어, 신속하고 안정적인 서비스 운영을 가능하게 합니다.```

0개의 댓글