[Cloud & CERT] 조사 1. 3-Tier Architecture 설계(오병은)

1. 3-Tier Architecture 설계

1) 서버 한 대에 웹서버+애플리케이션+DB를 모두 설치

• 웹 서버(정적 파일 응답, 요청 라우팅) → 네트워크 I/O 위주

• 애플리케이션(주문 검증, 재고 계산 같은 비즈니스 로직) → CPU 연산 위주

• DB(조회, 쓰기, 인덱스 스캔) → 디스크 I/O + 메모리(캐시) 위주

• 각 서버의 지표(CPU/메모리/디스크)가 온전히 그 계층의 작업량만 반영하게 되어 원인 분리가 가능해짐

• 하나를 재시작해도 나머지 두 계층은 프로세스 자체가 물리적으로 분리돼 있어 영향을 안 받음

• 계층마다 필요한 리소스가 다르므로(웹은 네트워크, DB는 메모리·디스크 위주로), 각자에 맞는 사양으로 서버를 고를 수 있음

• 3-Tier Architecture: Presentation(표현) / Application(응용) / Data(데이터) 3개 계층으로 물리적·논리적으로 분리하는 설계

• 핵심 목적: 장애 격리(Isolation) + 원인 관측 가능성(Observability) + 계층별 독립적 확장

2) Web / Application / DB 세 대로 나눔

• 서버 1대의 CPU 코어 수, 메모리 용량을 올림 (예: AWS EC2라면 t3.medium → t3.2xlarge처럼 인스턴스 타입을 교체)

• 한계 ①: 아무리 좋은 인스턴스 타입도 물리적 상한선이 있음 (클라우드 제공사가 제공하는 최대 스펙까지만 가능)

• 한계 ②: 인스턴스 타입 변경은 보통 인스턴스 중지 → 타입 변경 → 재시작이 필요해서 몇 분간 서비스가 끊김(다운타임)

• 한계 ③: 트래픽이 다시 늘면 또 똑같은 작업을 반복해야 함 — 근본적 해결이 아니라 "미루는" 것

• 같은 사양의 서버를 여러 대로 늘림 (Application 서버 1대 → 3대, 5대…)

• 장점: 이론상 대수를 늘리는 데 제한이 거의 없고, 한 대를 새로 추가/제거해도 나머지는 서비스 중단 없이 계속 동작

• 다만 이 방식이 실제로 작동하려면, 여러 대의 서버를 "하나처럼" 다루기 위한 앞단 장치가 필요해짐 — 사용자가 서버 여러 대 중 어디로 접속해야 할지 모르는 문제가 새로 생기기 때문 (다음 단계로 이어짐)

• Scale-up: 서버 성능 자체를 올림. 빠르고 간단하지만 상한선·다운타임 존재

• Scale-out: 서버 대수를 늘림. 무중단·거의 무제한 확장 가능하지만 트래픽 분산 장치가 필수로 따라와야 함

3) Application 서버를 두 대로 늘림

1. 사용자는 로드밸런서의 주소 하나만 알고 접속함 (뒤에 App 서버가 몇 대인지는 전혀 모름)

2. 로드밸런서가 요청을 받아서, 미리 등록된 서버 목록(Target Group) 중 하나로 트래픽을 전달

3. 분배 기준(알고리즘)은 여러 가지가 있음:
• Round Robin: 순서대로 돌아가면서 배정 (서버1 → 서버2 → 서버1 → …)
• Least Connections: 현재 연결 수가 가장 적은 서버로 배정 (부하가 균등하지 않을 때 더 정교함)

4. 뒤에서 서버를 추가하거나 빼도(Auto Scaling으로 자동 증감해도), 로드밸런서의 Target Group만 갱신되면 되고 사용자 쪽 주소는 전혀 안 바뀜 — 이게 로드밸런서가 "추상화 계층" 역할을 한다는 의미

• Load Balancing: 여러 서버로 요청을 분산시키는 기법. Horizontal Scaling이 실제로 작동하기 위한 필수 전제조건

• AWS에서는 **ALB(Application Load Balancer)**가 이 역할 — HTTP/HTTPS 레벨(7계층)에서 URL 경로 기반 라우팅까지 가능

4) 앞단에 요청 분산 장치를 둠

• Stateful: 서버가 사용자별 상태(세션 등)를 자기 메모리/디스크에 들고 있음. 이 방식이면 같은 사용자의 다음 요청은 반드시 같은 서버로 가야만 정상 동작함(이걸 강제하는 걸 Sticky Session이라 하는데, 이러면 결국 그 서버에 부하가 쏠리는 문제가 다시 생김)

• Stateless: 서버 자체는 아무 상태도 안 갖고 있고, 매 요청마다 "이 사용자가 누구인지"를 확인하려면 외부의 공용 저장소를 조회함

• Stateful vs Stateless: 서버가 사용자 상태를 자기 안에 보관하는지 여부

• Horizontal Scaling이 되려면 애플리케이션 서버는 반드시 Stateless로 설계하고, 상태는 서버 밖 공용 저장소로 분리해야 함 (AWS라면 ElastiCache for Redis)

5) 세션을 서버 밖으로 뺌

1. 로드밸런서가 각 서버의 특정 경로(예: /health)로 HTTP 요청을 주기적으로 보냄

2. 정상이면 200 OK 응답, 서버가 죽었거나 응답이 없으면 실패로 판단

3. 연속으로 일정 횟수(예: 3회) 실패하면 → 그 서버를 자동으로 Target Group에서 제외, 이후 트래픽을 안 보냄

4. 서버가 다시 정상 응답하면 → 자동으로 다시 트래픽 대상에 포함

• Health Check: 로드밸런서가 서버 생존 여부를 주기적으로 확인하고, 죽은 서버를 자동으로 트래픽 대상에서 제외하는 메커니즘

• High Availability: 일부 구성 요소가 죽어도 서비스 전체는 계속 정상 동작하는 상태

• Redundancy: 여분의 자원(서버, 인스턴스 등)을 미리 확보해두는 것 — HA를 실현하는 방법

6) App 서버를 다중화함

• App1을 재시작·배포해도 DB는 별개 프로세스/인스턴스이므로 영향받지 않음

• App1이 죽어도 App2는 여전히 DB에 접근 가능해서 서비스 지속

• DB는 데이터(상태)를 들고 있는 유일한 계층이라, App(Stateless)보다 훨씬 신중하게 다뤄야 함 — 예를 들어 DB는 Multi-AZ(서로 다른 물리적 데이터센터) 복제로 별도의 이중화를 하기도 함

• Failure Domain: 하나의 장애가 전파되는 범위. 장애 범위를 독립적으로 최대한 작게 쪼개는 게 안정적인 설계의 기본 원칙

• App(무상태, 쉽게 늘리고 죽여도 됨) vs DB(상태 보유, 더 신중하게 관리) — 이 성격 차이 때문에 애초에 3-Tier에서 Data 계층을 별도로 분리하는 것

7) 구조가 정리됨 — AWS 서비스 매핑

✏️ 정리하면서 든 생각