배포 흐름으로 이해하는 AWS 인프라 구조

배포 환경 운영 시 역할이 상이한 개념들의 동시 등장 상황. ALB, Listener, Listener Rule, Target Group, Auto Scaling Group, Launch Template, User Data, EC2, Security Group 등의 용어가 실제 배포 흐름 내에서 혼용되는 사례 빈번.

특히 다음과 같은 지점에서의 의문 발생.

• 신규 서버 추가 시 EC2 생성 주체에 대한 혼동
• ALB와 Target Group의 개별 역할 모호
• Target Group 포트의 정확한 정의 인지 부족
• User Data의 역할(서버 생성 vs 설정)에 대한 불분명한 구분
• Security Group의 inbound, outbound 영향 범위에 대한 이해 미비

해당 내용은 요청 흐름과 배포 흐름을 병행하여 각 구성요소의 역할을 연결하기 위한 정리.

---

1. 전체 구조 개요

핵심 구성 요소

• Client: 요청 시작점
• ALB: 요청 수신 진입점
• Listener / Listener Rule: 요청 분기 규칙
• Target Group: 실제 대상 묶음 및 상태 관리 담당
• EC2 및 애플리케이션: 실제 요청 처리 수행

개념적 분리

• 요청 흐름: 사용자 요청의 전달 경로 구조
• 배포 흐름: 신규 서버 생성 및 서비스 편입 구조

상호 연결성 존재하나 개별적 개념으로 관리.

---

2. Listener와 Listener Rule

ALB는 요청을 받기만 하는 장비가 아니라, 들어온 요청을 조건에 따라 다른 Target Group으로 분기하는 장비.

Listener

ALB 요청 수신 입구 개념. 요청 수신 관문 해당.

• 80 포트로 HTTP 요청 수신
• 443 포트로 HTTPS 요청 수신

Listener Rule

수신 요청을 특정 조건에 따라 분기하는 규칙.

• Host = admin.example.com
• Path = /api/*
• Path = /static/*

요약

• Listener = 요청을 받는 문
• Listener Rule = 요청을 어디로 보낼지 정하는 규칙

---

3. Target Group 정의

Target Group은 ALB가 실제로 요청을 전달하는 대상들의 묶음.

 

주요 역할

• 그룹 내 멤버 관리
• 대상 정상 상태 확인용 Health Check 수행

단순 EC2 목록이 아닌, 트래픽 수신 가능 활성 대상 집합으로 정의.

 

Target Group의 포트는 무엇인가

Target Group을 만들 때 포트를 입력한다고 해서, AWS가 그 포트를 사용하는 EC2만 자동으로 찾아서 묶어주는 것은 아님.

• TG 이름: tg-stage3-mo-a
• target type: instance
• port: 8080

이 뜻은:

이 TG에 등록된 EC2들에게는
8080으로 health check / 요청 전달을 하겠다

 

즉,

• Target Group이 누굴 멤버로 가질지 자동 판별하는 기준이 아님
• 이미 등록된 대상에게 몇 번 포트로 붙을지를 정하는 값임

TG-web-a의 포트가 8080
TG-web-b의 포트가 8089

TG-web-a에 등록된 인스턴스에게는 8080으로 요청과 Health Check 수행
TG-web-b에 등록된 인스턴스에게는 8089로 요청과 Health Check 수행

 

즉, Target Group의 포트는 멤버 자동 선택 규칙이 아니라 등록된 멤버에 대한 접속 포트라는 이해가 정확.

 

▶ 배포시 TG 전환

TG 를 하나로 / 세트별로

세트별로

어떤 EC2가 어떤 Target Group에 들어가는가

어떤 EC2가 어떤 Target Group에 속할지는 설계와 등록 방식에 따라 결정되는 사항

• 수동 등록
• ASG 연동 등록
• 배포 스크립트 등록 ✨ : 배포 도구가 태그나 이름 규칙 등으로 특정 EC2를 찾고, 그 EC2를 특정 Target Group에 등록하는 방식.

---

4. Listener 포트와 Target Group 포트 분리

외부에서 들어오는 포트와, ALB가 백엔드로 붙는 포트는 같을 필요가 없음.

구성 예시

• Client → ALB: 443 포트
• ALB → Target Group: 8080 포트
• Target Group → EC2 App: 8080 포트

 

• 사용자는 HTTPS 443으로 접속
• ALB는 내부적으로 백엔드 8080으로 전달 가능

이 차이를 구분하지 않으면 ALB 포트, TG 포트, 애플리케이션 포트가 한 번에 뒤섞이기 쉬운 편.

---

5. Auto Scaling Group과 Launch Template

배포 과정 내 ASG와 Launch Template 역할 분리.

Auto Scaling Group

서버 개수를 유지하고 교체를 관리하는 주체.

대표 역할

• desired capacity 유지
• min / max 범위 유지
• instance refresh 수행
• 서버군 상태 관리

Launch Template

EC2를 어떤 사양으로 만들지 정의하는 설계도.
ASG가 EC2를 만들 때 기준으로 삼는 것이 Launch Template.

대표 항목

• AMI
• Instance Type
• Security Group
• IAM Role
• User Data

ASG
  ├─ desired: 2
  ├─ min: 2
  ├─ max: 4
  └─ Launch Template v5 참조

Launch Template v5
  ├─ AMI
  ├─ Instance Type
  ├─ Security Group
  ├─ IAM Role
  └─ User Data

 

핵심 포인트

ASG = 몇 대를 유지할지 관리

Launch Template = 어떤 사양으로 만들지 정의

배포 도구가 EC2를 직접 만드는 것이 아니라, 보통 ASG가 Launch Template을 기준으로 EC2를 생성하는 구조

 

---

6. User Data 정확한 위치

User Data의 서버 생성 도구 오인 주의.

실행 프로세스

1. ASG의 신규 인스턴스 생성 요청
2. EC2 생성
3. EC2 부팅
4. User Data 실행
5. 앱 설정 완료
6. 서비스 시작

• 생성 담당: ASG
• 초기화 담당: User Data

User Data에서 주로 하는 일

• 배포 파일 다운로드
• 설정 파일 반영
• 웹서버 설정
• 환경변수 파일 생성
• 애플리케이션 기동
• 로그 디렉터리 준비

따라서 User Data의 본질은 이미 생성된 EC2를 서비스 가능한 상태( WEB/WAS 역할 )로 만드는 초기화 스크립트라는 이해.

---

7. 배포 흐름 전체 연결

배포 흐름 내 구성 요소 상호 연결 순서.

1. 베포도구의 빌드 job 실행 -> 파라미터 정보 (어떤 브랜치? 어떤 어플리케이션? ) 넘김 -> 결과물 zip을 파라미터 정보에 맞는 S3 경로에 업로드
2. 배호 도구 job 에 파라미터 정보를 넘겨서 파라미터에 해당하는 ASG 결정
3. 배포 도구의 업데이트/refresh 요청
4. ASG의 Launch Template 참조
5. ASG의 신규 EC2 생성
6. EC2 부팅 및 User Data 실행 (User Data가 S3에서 파일을 가져옴)
7. 신규 인스턴스의 Target Group 등록 (이것도 배포도구의 job으로 수행)
   1. 어플리케이션, 배포 환경 등 파라미터 정보와 맞는 EC2를 추출한 뒤 
      태그 : 태그는 보통 두 군데에서 정해짐
      - ASG 레벨 태그
      - Launch Template/인스턴스 생성 시 지정되는 태그
      
      즉, 어플리케이션 종류, 배포 환경과  같은 값이 EC2에 붙는다면,
      👉  배포도구가 parameter에 맞는 ASG를 선택했고, 그 ASG/Launch Template이 그 태그가 붙도록 설정
      - parameter = 베포도구가 어느 배포 대상을 고를지 결정하는 입력값
      - tag = AWS 리소스가 자기 정체성을 표시하는 표식
      
      
   2. 해당 파라미터와 맞는 TG를 찾아서 등록
8. Target Group의 Health Check 수행
9. ALB의 healthy 대상 트래픽 전달

 

핵심 요약

배포 도구(지시) - ASG(생성) - Launch Template(기준) - User Data(초기화) - Target Group(상태 관리) - ALB(트래픽 전달)

 

---

8. Security Group: 유입과 송출

Security Group은 네트워크 통신 허용 범위를 정하는 방화벽

한쪽만 열려 있어서는 통신 성립 불가.

inbound

리소스 유입 트래픽 허용 규칙.

• ALB에서 EC2로 들어오는 8080 허용
• 내부 서버에서 들어오는 8089 허용

outbound

리소스 외부 송출 트래픽 허용 규칙.

• EC2가 S3 접근
• EC2가 내부 ALB 호출
• EC2가 다른 내부 서버 호출

핵심 포인트

출발지 outbound 및 목적지 inbound 동시 충족 시 통신 성립

---

9. 포트 정합성 별도 확인 필수

요청 실패 원인: “Target Group 등록” 자체보다 “포트 정합성” 문제인 경우 다수.

체크 포인트 네 가지

• Listener 포트 확인
• Target Group 포트 확인
• 애플리케이션 리슨 포트 확인
• Security Group 허용 포트 확인

예시 상황

• TG의 8080 접속 시도
• 앱의 8089 실행
• SG의 8080 허용

위 상황 시 등록 가능하나 healthy 상태 미도달 또는 요청 실패 상황 발생.

 

상태 구분

• 등록됨: 명단 등재
• healthy: 실제 트래픽 수신 준비 완료

두 상태 간의 명확한 구분 필수.

---

10. 웹 계층 뒤 내부 ALB 구조

외부 ALB - Web EC2 - 내부 ALB 계층 구조 보편적.

전체 경로

• Client → 외부 ALB 요청 전달
• 외부 ALB의 TG-web 분기
• Web EC2의 Reverse Proxy 역할 수행
• Web EC2의 내부 ALB 요청 전달
• 내부 ALB의 TG-app 분기
• App EC2의 실제 비즈니스 로직 처리

사용자 요청의 내부적 다단계 계층 및 포트 경유 구조.

 

구조적 장점

• 웹/앱 계층 책임 분리
• 앱 계층 로드밸런싱 가능
• 내부 라우팅 정책 분리 가능
• 서버 교체 및 확장 시 유연성 증가

---

11. 외부 및 내부 ALB 역할 차이

위치 및 목적에 따른 역할 분담.

External ALB

• 인터넷 요청 진입점
• 도메인 기반 라우팅
• 사용자 요청 최초 수신
• 웹 계층 전달

Internal ALB

• 내부 서비스 라우팅
• 애플리케이션 계층 로드밸런싱
• 서비스별 Target Group 분기
• 내부 요청 분산

---

12. 다단계 구조 장애 추적 방식

계층 증가에 따른 구간별 실패 지점 분석 체계 필요.

점검 순서

• External ALB Listener/Rule 확인
• TG-web Health Check 확인
• Web EC2 Reverse Proxy 설정 확인 (conf 파일에 저장되어있음. 어디로 보낼지)
• Internal ALB 라우팅 확인
• TG-app Health Check 확인
• App EC2 애플리케이션 기동 상태 확인

다단계 구조 내 hop 단위 구간 확인 방식 권장.

---

13. 최종 정리

구성 요소 간 상호 연결성에 따른 복잡성 기인.

 

🌞 핵심 요약

• ALB: 요청 수신 진입점
• Listener/Rule: 분기 규칙
• Target Group: 실제 대상의 묶음과 상태 관리 담당
• ASG: 서버 수량 유지와 교체 담당
• Launch Template: EC2 설계도
• User Data: 부팅 직후 초기화 스크립트
• EC2: 실제 서비스 인스턴스
• Security Group: 통신 허용 범위 관리

포트 정의 핵심

Target Group의 포트는 멤버 자동 선택 기준이 아니라, 등록된 멤버에게 몇 번 포트로 붙을지를 정하는 값

 

배포 흐름 핵심

배포 도구는 지시하고,
 ASG는 만들고, 
Launch Template은 기준을 주고, 
User Data는 세팅하고, 
Target Group은 건강한 대상을 관리하고, 
ALB는 그 대상으로 트래픽을 보냄