3 tier 환경의 전반적인 프로세스 심화과정 (DNS, L7, LB, CDN까지)

 

 “3-Tier 아키텍처”에서
방화벽, DNS, L7, LB, CDN, DB Replication
등이 어떻게 작동하는지
전체 흐름을 맥락 중심으로 설명해주세요.

 

 

안녕하세요!

오늘은 실제 대규모 웹 서비스의 구조를 이해하는 데 핵심이 되는 부분인 3-Tier 아키텍처 심화과정에 대해서 알아보려고 합니다.

흐름을 이해하면서 같이 공부해봅시다 !

기본적인 3-Tier 아키텍처 구조

 

• Presentation Tier (프론트):
  사용자의 브라우저, 앱, React 앱 등 → CDN, Web Server 등
• Application Tier (백엔드):
  Express, Spring, Nest.js 같은 API 서버 → 인증, 로직 처리 등
• Data Tier (데이터베이스):
  MySQL, PostgreSQL, Redis, MongoDB 등

 

 

여기까지는 쉽죠 ! 

프론트에서 요청하는 부분과 백엔드에서 처리하는 부분 Data를 저장하는 공간을 분리해서 3-Tier 라고 생각하시면 됩니다.

클라이언트 요청부터 전체 흐름

1. 클라이언트 요청 발생

사용자가 브라우저에서 https://www.example.com에 접속해요.

2. DNS (도메인 이름 시스템)

• 사용자의 PC는 먼저 DNS에 www.example.com의 IP 주소를 물어봐요.
• 이때 DNS는 다음을 할 수 있어요:
  • 퍼블릭 서버를 직접 운영 중이면 → A 레코드로 내 서버 IP를 연결해서 사용
  • 클라우드/CDN/호스팅을 쓴다면 → CNAME으로 서비스 도메인에 위임해서 사용

중요: 이때부터 사용자의 요청은 CDN으로 향하게 돼요.

---

3. CDN (Content Delivery Network)

• CDN은 정적 리소스 (HTML, JS, CSS, 이미지 등)를 캐시해서 빠르게 응답합니다.
  • 역할 : 도메인에 들어오는 요청을 내 Nginx 서버(오리진 서버)로 전달하도록 하는 것
  • 좀 더 자세히 설명하면:
    1. 내 도메인(example.com)을 CDN 서비스에 연결
       • DNS에서 CNAME 또는 A 레코드를 CDN 도메인으로 설정
    2. CDN 콘솔에서 '오리진(Origin)'을 내 Nginx 서버 주소(IP나 도메인)로 지정
       • 예: origin.example.com (Nginx가 설치된 서버)
    3. CDN은 클라이언트 요청을 받아서 캐시에 없으면 오리진(Nginx)으로 요청을 보내고, 응답을 받아서 캐시함
    4. 다음 요청부터는 CDN 캐시에서 바로 응답
• 만약 캐시에 없다면 => 오리진 서버(예:nginx)로 요청을 전달

장점:

• 전 세계 어디서든 빠름
• 서버의 부하 줄임

4. 방화벽 (Firewall)

• CDN이나 클라이언트가 오리진 서버(Nginx 등)로 요청을 보낼 때,
• WAF (Web Application Firewall) 가 트래픽을 검사해요.
  • 악성 요청 필터링
  • IP 차단
  • Bot 요청 제한 등

예시: AWS WAF, Cloudflare WAF

5. L7 Load Balancer (7계층 로드밸런서)

• L7 LB는 요청의 URL, 헤더, 쿠키, 메서드 등을 보고 라우팅
• 예:
  • /api/* → 백엔드 서버 A
  • /admin/* → 백엔드 서버 B
  • 정적 리소스 → 캐시 서버

우리가 말하는 L3, L4, L7은
네트워크 통신을 계층화한 OSI 7계층 중 일부에요.

계층이름 주로 다루는 것 예시를 정리할 테니 참고해주세요.

L3	Network Layer	IP 주소, 라우팅	IP, ICMP, 라우터
L4	Transport Layer	포트, 연결 관리	TCP, UDP
L7	Application Layer	실제 사용자 요청/응답	HTTP, HTTPS, WebSocket 등

주로 사용하는 도구:

• Nginx, HAProxy, AWS ALB, GCP HTTP Load Balancer

6. Application Tier (API 서버)

• 이제 실제 백엔드 로직이 작동:
  • JWT 토큰 검증
  • DB 조회
  • 비즈니스 로직 처리
  • 결과를 JSON으로 반환

이 서버들도 여러 대가 있을 수 있고,

• L4 (TCP 기반) Load Balancer로 부하 분산됨 (L7 전에 올 수도 있음)

7. Database Tier (DB + Replication)

• 백엔드는 주로 Write는 Master DB, Read는 Replica DB에 요청해요.
• Master DB: 읽기 + 쓰기 가능 (INSERT, UPDATE, DELETE)
• Replica DB: 읽기만 가능 (SELECT만 가능)
  → 직접 데이터 수정하면 안 되고, 리플리케이션 깨짐
• DB Replication은:
  • 마스터 DB → 리플리카 DB로 변경사항을 자동 전파
  • MySQL의 Binary Log, PostgreSQL의 WAL 등을 이용

리플리케이션이 필요한 이유

읽기 성능 확장	사용자가 많을수록 SELECT가 늘어나는데, 이걸 복제 DB가 분산 처리
장애 대응 (Failover)	마스터가 죽으면, 리플리카를 승격(Promotion)해서 서비스 연속성 확보
지역 분산	전 세계에 복제본 두어 지연(Latency) 줄이기 (예: 일본 사용자는 도쿄 DB로 SELECT)

• API 서버에서는 아래와 같이 동작합니다.
  • POST /write → Master에 INSERT
  • GET /data → Replica에서 SELECT 

3줄 요약

 

• DNS는 도메인을 L7 로드밸런서나 CDN으로 연결해 사용자의 요청을 올바른 경로로 안내한다.
• L7 로드밸런서(Nginx 등)와 CDN은 클라이언트 요청을 받아 정적 콘텐츠를 캐시하거나 백엔드 애플리케이션 서버로 트래픽을 효율적으로 분산 처리한다.
• 애플리케이션 서버와 데이터베이스(리플리케이션 포함)는 비즈니스 로직과 데이터 저장/복제를 담당해, 읽기 부하 분산과 고가용성을 지원한다.

+ 소감..(?)

웹 아키텍처를 이해하면 뭔가 시야가 넓어지는 기분이 들고 재밌네요.

다음엔 AWS이나 NCP 같은 클라우드에서 어디까지 지원하는지 환경 분석 같은 것도 해보면서 더 공부해보고 또 공유해드릴게요.