코드 저장소.

AWS EC2 기반 Spring Boot 분산 인프라 구축기 1 본문

포폴/일정관리 프로젝트

AWS EC2 기반 Spring Boot 분산 인프라 구축기 1

slown 2026. 4. 17. 13:05

목차

1.아키텍처 개요 

2.인프라 구축

3.회고

 

1.아키텍처 개요 

전환 배경 및 동기

 

기존에는 AWS Lightsail 환경에서 정해진 예산 내로 서비스를 운영하고 있었습니다. 하지만 프로젝트 규모가 커질수록 Lightsail 환경에서는 몇 가지 한계가 분명해졌습니다.

 

 

  • 고정 비용 구조
    Lightsail은 인스턴스 실행 여부와 관계없이 월 단위 고정 요금이 발생합니다.
    테스트하지 않는 시간에도 비용이 계속 발생해 학습 단계에서는 부담이 되었습니다.
  • 제한적인 네트워크 제어
    VPC, Subnet, 보안 그룹을 세밀하게 구성하기에는 Lightsail의 네트워크 제어 범위가 제한적이었습니다.
  • 단일 장애점(SPOF) 문제
    하나의 서버에 모든 컴포넌트가 집중된 구조는 장애 발생 시 전체 서비스 중단 가능성이 높았습니다.
  • 분산 환경 검증 한계
    Kafka ISR 테스트나 리밸런싱과 같은 분산 시스템 실험을 단일 인스턴스 환경에서 수행하기 어려웠습니다.

    이러한 이유로 인프라 구성 요소를 직접 제어할 수 있는 AWS EC2 기반 분산 인프라 구조로 이전하게 되었습니다.

다음은 이번에 만들 AWS 아키텍처의 구성도 입니다. 

 

 

이번 구성은 다음과 같은 역할로 분리했습니다.

Infrastructure
외부 요청은 인프라 서버의 Nginx Reverse Proxy가 수신하고, 두 대의 서비스 서버로 라운드로빈 방식으로 분산하고 카프카와 레디스로 비동기 처리와 캐싱을 담당합니다. 

Application
서비스 서버는 Spring Boot 애플리케이션을 실행합니다.

Monitoring
별도의 모니터링 서버에서 Prometheus, Loki, Grafana를 운영해 전체 서버 상태와 로그를 수집하도록 구성했습니다.

 

2.인프라 구축

위의 아키텍처를 구축을 하기 위해서는 다음과 같은 순서로 진행을 하겠습니다. 

 

VPC 생성 -> 서브넷 생성 -> IGW(인터넷 게이트 웨이) 생성 -> 라우팅 테이블 생성 -> 보안 그룹 생성 -> EC2 생성 및 Elastic Ip발급 -> 도메인 DNS 업데이트 순으로 진행을 해보겠습니다.

 

구조는 터넷 게이트웨이 하나만 붙이고, 4대 다 퍼블릭 서브넷에 놓는 방식입니다.

 

2-1.VPC 생성

 

우선은 VPC를 구성을 하도록 하겠습니다. 우선은 AWS 대시보드 화면에서 검색어에 VPC를 입력하고 VPC를 생성을 합니다. 

 

설정을 다음과 같이 한 다음에 생성을 누르면 아래와 같이 나옵니다.

 

2-2. 서브넷 생성

 

비용 최적화를 위해 NAT Gateway와 Private Subnet 구성은 제외했습니다. 대신 단일 Public Subnet 환경에서 보안 그룹을 통해
서버별 접근 범위를 제한하는 방식으로 구성했습니다.

실무 환경에서는 Private Subnet 구성이 일반적이지만, 이번 프로젝트에서는 제한된 예산 안에서 분산 환경 자체를 직접 구축하는 데 초점을 두었습니다.

 

2-3.인터넷 게이트 웨이(IGW) 생성

 

서브넷까지 생성을 했다면 외부의 인터넷 통신을 위해서 IGW를 구축을 해보겠습니다.  좌측의 메뉴에서 인터넷 게이트 웨이를 클릭 후 인터넷 게이트 웨이를 생성을 합니다.

 

게이트 웨이를 생성을 했으면 해당 게이트웨이를 생성된 VPC에 연결을 합니다. 

2-4. 라우팅 테이블 설정

 

다음으로는 서브넷이 인터넷 게이트웨이를 통해 외부와 통신할 수 있도록 라우팅 테이블을 설정했습니다. 우선은 좌측 메뉴에서 라우팅 테이블을 클릭후 라우팅 테이블 생성을 누른 다음 아래와 같이 한 후 생성을 합니다. 

 

라우팅을 인터넷 게이트웨이와 연결을 한 다음 기존에 만들었던 서브넷과 연결을 합니다. 

 

2-5. 보안그룹 생성

 

라우터까지 연결을 마쳤으면 다음은 보안그룹을 생성을 하겠습니다. 보안 그룹은 가상 방화벽 역할을 하므로 최소 권한 원칙에 따라 필요한 포트만 허용했습니다. 특히 Kafka와 RDS는 외부에 직접 노출하지 않고 내부 통신만 허용하도록 설정했습니다.

 

인프라 보안 그룹 (schedule-sg-infra)

  • 역할: Nginx 로드밸런서 및 Kafka/Zookeeper 관리 인프라 보호.
  • 설정 특징: 아웃바운드 규칙에서 외부 통신(HTTP/HTTPS)은 허용하되, Kafka 관련 포트(9092~9094)는 외부에 공개하지 않고, 내부 서브넷 대역(10.0.1.0/24)에서만 접근 가능하도록 제한했습니다.

 

서비스 보안 그룹 (schedule-sg-service)

  • 역할: Spring Boot 애플리케이션 및 Redis 서버 보호.
  • 설정 특징:
    • 인바운드: 애플리케이션 포트(8082)를 전체 개방하지 않고, 내부 서브넷(10.0.1.0/24) 트래픽만 수용하도록 설정했습니다.
    • SSH: 관리용 접속 포트(22)는 보안을 위해 '내 IP'에서만 접근 가능하도록 제한했습니다.

 

모니터링 보안 그룹 (schedule-sg-monitor)

  • 역할: Prometheus, Grafana, Loki 모니터링 스택 보호.
  • 설정 특징:
    • Grafana(3000): 대시보드 확인을 위해 '내 IP' 접근 허용.
    • Prometheus(9090) / Loki(3100): 메트릭 수집을 위해 내부 서브넷(10.0.1.0/24)에서의 접근만 허용하여 모니터링 데이터의 외부 노출을 방지했습니다.

 

2-6. EC2 생성 및 .pem 키 생성 

 

이제 실제 서버 인스턴스를 생성할 차례입니다. 서버 접속의 핵심 보안 장치인 키 페어(.pem)를 먼저 생성하고, 용도에 맞는 EC2 4대를 순차적으로 구축했습니다.

  • 키 페어 생성: 보안을 위해 RSA 방식의 .pem 파일을 생성했습니다. 이 키는 한 번 잃어버리면 재발급이 까다로우니 별도의 안전한 장소에 보관해야 합니다.

 

  • 인스턴스 설정: 모든 서버는 t3.micro 사양과 Ubuntu 22.04 LTS 운영체제를 선택하여 프리티어 범위 내에서 최적의 성능을 낼 수 있도록 구성했습니다.
    • 인프라 서버: Nginx 및 메시징 브로커용

 

  • 서비스 서버 1, 2: 애플리케이션 실행용

  • 모니터링 서버: 시각화 및 로깅 도구 실행용

 

 

이렇게 작성을 하면 아래와 같이 인스턴스 4대가 완성이 되었습니다.

 

2-7. 탄력적 IP 생성

 

EC2 인스턴스는 중지 후 재시작 시 퍼블릭 IP가 변경되는 특성이 있습니다. 서비스의 연속성을 보장하고 도메인 연결(DNS)의 편의를 위해 각 서버에 고정된 IP인 탄력적 IP(EIP)를 발급하여 연결했습니다.

 

 

2-8. RDS 생성

 

데이터 영속성 관리를 위해 AWS RDS(MySQL)를 구성했습니다. RDS는 두 개의 가용 영역에 연결된 DB 서브넷 그룹을 사용하도록 설정했습니다. 비용을 고려해 `db.t3.micro` 인스턴스를 선택했고, 스토리지는 20GB로 설정했습니다. . 운영 단순화를 위해 퍼블릭 접근 옵션은 활성화했지만, 보안 그룹을 통해 서비스 서버에서만 접근 가능하도록 제한했습니다.

2-9. 도메인 설정 

 

기존 Lightsail DNS 관리 페이지 혹은 가비아 같은 도메인 대행 업체 설정에서 A 레코드의 값을 새로 발급받은 인프라 서버의 탄력적 IP로 변경했습니다. 이로써 사용자들은 기존 도메인 그대로 고도화된 EC2 인프라에 접속하게 됩니다.

 

여기까지 했으면 AWS의 아키텍처 구축은 완료가 되었습니다.

3.회고

이번 작업에서 가장 크게 느낀 점은 AWS에서는 단순히 서버를 생성하는 것보다 네트워크 흐름을 이해하는 것이 더 중요하다는 점이었습니다. 초기에는 서비스 서버에서 RDS 연결이 정상적으로 되지 않았는데, 문제 원인은 애플리케이션 설정이 아니라 보안 그룹 허용 범위 설정이었습니다.

이 과정을 통해 서버 구성 자체보다 서버 간 통신 관계를 명확히 설계하는 것이 인프라 안정성에 더  영향을 준다는 점을 체감했습니다. 이번 작업은 단순히 Lightsail에서 EC2로 이전한 것이 아니라, 이후 진행할 Kafka 클러스터링과 장애 테스트를 위한 기반 환경을 직접 구축한 경험이었습니다.

다음 포스팅 예고

다음 포스팅에서는 MobaXterm을 통해 생성한 각 EC2 인스턴스에 접속하여, 서비스의 핵심 엔진들을 하나씩 설치하고 설정하는 과정을 다루겠습니다.

  • 인프라 서버: Nginx 설치 및 로드밸런싱 설정, Kafka/Zookeeper 환경 구축
  • 서비스 서버: 헥사고날 아키텍처 기반의 Spring Boot 애플리케이션 배포
  • 모니터링 서버: Prometheus, Grafana, Loki를 활용한 통합 관제 시스템 구축