AWS 3-Tier 및 Data Pipeline 구축 With Terraform (1)

참고 자료: https://kujung.tistory.com/entry/AWS-3-Tier-Architecture-%EA%B5%AC%EC%B6%95%ED%95%B4%EB%B3%B4%EA%B8%B0-2-1

AWS 3 Tier Architecture 구축해보기 2-1

 

이번 글에서는 위와 같은 3-Tier 아키텍처를 Terraform을 이용하여 구현해보겠습니다.

해당 아키텍처에 대한 간략한 개요는 다음과 같습니다.

 

1. 고가용성을 위한 Multi-AZ 설계

• 다중 가용 영역(AZ-a, AZ-c): 하나의 가용 영역에 장애가 발생하더라도 서비스가 중단되지 않도록 인프라를 두 개의 영역에 분산 배치
• 로드 밸런싱: 외부 트래픽을 받는 Public ALB와 내부 App 계층으로 전달하는 Private ALB를 두어 트래픽을 효율적으로 분산

2. 계층별 보안 강화 (3-Tier)

• Public Subnet: 외부와 통신이 필요한 NAT Gateway와 웹 서버용 ALB만 배치하여 공격 노출 면을 최소화.
• Private Subnet: 실제 비즈니스 로직이 수행되는 EC2 인스턴스와 데이터베이스(RDS)를 프라이빗 영역에 격리하고 오직 로드 밸런서를 통해서만 접근을 허용.

3. Auto Scaling

• Auto Scaling Group: 트래픽 변화에 따라 EC2 인스턴스 개수를 자동으로 조절하여 비용 최적화와 안정적인 성능을 확보.

4. 코드 기반 자동화 배포 (CI/CD)

• GitHub & CodePipeline: 코드 변경 사항이 GitHub에 push되면 CodeBuild와 CodeDeploy를 거쳐 자동으로 인프라와 애플리케이션에 반영되는 DevOps 환경을 구축.

5. 운영 및 모니터링

• CloudWatch & Slack: 시스템 상태를 실시간 감시하고 이상 징후 발생 시 SNS와 Chatbot을 연동하여 관리자가 Slack으로 즉시 알림을 받을 수 있게 구성.
• 데이터 파이프라인: EventBridge와 Lambda를 활용해 데이터 처리를 자동화하고 RDS 데이터를 S3로 백업/저장하는 흐름을 포함.

 

트래픽 흐름

1. 외부 요청 흐름

사용자가 브라우저에 도메인을 입력했을 때 발생하는 흐름입니다.

1. Internet Gateway (IGW): 외부 트래픽이 VPC 내부로 들어오는 곳
2. Public ALB (1차 분산): Public Subnet에 위치하며, 들어온 트래픽을 첫 번째 Private Subnet에 있는 EC2(Web/App) 그룹으로 전달
3. Private ALB (2차 분산): 1차 EC2 서버들이 비즈니스 로직 처리를 위해 내부 서비스나 API가 필요할 때, Private ALB를 거쳐 두 번째 Private Subnet에 있는 EC2 그룹으로 트래픽을 넘김 (계층 간의 완전한 격리)
4. RDS (Database): 최종적으로 App 서버가 RDS(Active)에 데이터를 쿼리. 장애 시 Standby 인스턴스로 자동 전환되는 고가용성 구조

---

2. 내부 서버의 외부 통신

프라이빗 서브넷에 있는 EC2는 외부에서 직접 들어올 수는 없지만 패치나 라이브러리 업데이트를 위해 인터넷에 나가야 할 때가 있습니다.

• Flow: Private EC2 → NAT Gateway (Public Subnet에 위치) → Internet Gateway → 외부 인터넷
• NAT Gateway는 나가는 역할만 하기 때문에 보안을 유지하면서도 외부 리소스를 활용할 수 있게 해줌

---

3. 모니터링 및 알림 흐름

시스템에 문제가 생겼을 때 관리자에게 도달하는 경로입니다.

• CloudWatch: EC2나 RDS의 상태(CPU, 메모리 등)를 실시간 감시
• Alarm & SNS: 설정한 임계치를 넘으면 알람을 발생시키고 SNS(Simple Notification Service)로 메시지를 보냄
• Chatbot & Slack: SNS 메시지를 AWS Chatbot이 수신하여 Slack 채널로 예쁘게 포맷팅된 알림을 쏴줌. 덕분에 개발자는 즉시 상황을 파악

---

4. 데이터 파이프라인 및 백업

이미지 하단과 우측에 있는 데이터 관련 흐름입니다.

• S3 백업: RDS의 특정 데이터를 주기적으로 S3에 덤프하거나 로그를 저장
• EventBridge & Lambda: 정해진 스케줄(예: 매일 새벽 3시)에 따라 EventBridge가 트리거를 주면 Lambda가 실행되어 데이터를 가공하거나 특정 태스크를 수행

---

5. CI/CD 코드 배포 흐름

1. Source Stage (GitHub):
   • Developer가 로컬 PC에서 작업을 완료한 후 코드를 GitHub 레포지토리로 push.
   • 이 동작이 트리거가 되어 전체 파이프라인이 가동.
2. Orchestration (AWS CodePipeline):
   • CodePipeline은 이 모든 과정을 하나로 묶어주는 '관리자' 역할. 소스 코드를 가져와서 빌드하고, 배포하는 전체 프로세스를 제어
3. Build Stage (AWS CodeBuild & S3):
   • CodeBuild가 GitHub에서 코드를 가져와 컴파일하고 테스트를 수행하며 배포 가능한 파일(Artifact, 예: .zip 또는 .jar)로 만듬
   • 빌드가 완료된 파일은 S3 버킷에 저장
4. Deploy Stage (AWS CodeDeploy):
   • S3에 저장된 최신 빌드 파일을 가져와서 실제 EC2 인스턴스들에 배포를 진행