대규모 서비스는 어떻게 서비스되는가

1. 클라이언트 요청 시작

DNS 조회

• 사용자가 브라우저에 https://example.com을 입력하면, **DNS(Domain Name System)**가 도메인 이름을 서버의 IP 주소로 변환.
  • 브라우저 → 로컬 DNS 캐시에서 IP 확인 (이미 조회된 경우 바로 반환).
  • 로컬에 없으면 ISP DNS 서버로 요청.
  • ISP 서버에도 없으면 최종적으로 권한 있는 DNS 서버(Authoritative DNS)로 요청.
• DNS 서버의 역할:
  • 사용자 요청을 적합한 서버로 라우팅하기 위해 IP 주소를 반환.
  • 예: example.com에 대해 192.168.1.1 반환.

 

2. 트래픽 라우팅

로드 밸런싱

로드 밸런싱은 정적인 파일이든 동적인 요청이든 상관없이 모든 요청에 대해 트래픽을 분산하는 방식으로 동작합니다

1. DNS 기반 로드 밸런싱:
   • DNS 서버가 사용자 위치에 따라 적합한 서버 IP를 반환.
   • 예: 사용자 위치가 아시아라면 아시아 지역의 서버 IP를 반환.
2. 클라이언트 요청이 CDN(Content Delivery Network)으로 전달:
   • CDN은 전 세계에 분산된 엣지 서버를 통해 정적 리소스(HTML, CSS, JS, 이미지 등)를 제공.
   • 브라우저가 가까운 엣지 서버로 요청 → 응답 속도 최적화.
   • 엣지 서버에 요청된 리소스가 없으면 **원본 웹서버(Origin Server)**로 요청을 전달.
3. L4 로드 밸런싱:
   • TCP/UDP 레벨에서 동작.
   • L4: WebSocket, FTP, DNS, VPN 등 비HTTP 트래픽. 
   • 사용처 : DB연결 등 비 Http요청, Http 서비스 로드밸런싱 후 내부적 로드밸런싱
   • 로드밸런서는 클라이언트가 보내는 요청을 "최초로 받는 엔드포인트" 역할을 함.  TCP 연결을 받아서 적절한 백엔드 서버(예: 웹 서버)로 중개. 백엔드 서버의 응답을 받아 다시 클라이언트에게 전달하는 역할. 
     • 1️⃣ 클라이언트 → 로드밸런서로 TCP 연결 요청 (SYN 패킷 전송)
     • 2️⃣ 로드밸런서 → 백엔드 서버 중 하나를 선택 후, 해당 서버로 TCP 연결 전달
     • 3️⃣ 백엔드 서버가 응답 (SYN-ACK 패킷 전송)
     • 4️⃣ 이후 로드밸런서는 TCP 패킷을 백엔드 서버와 클라이언트 사이에서 중계
   • IP 주소와 포트를 기반으로 서버 풀(Server Pool) 내 서버 중 하나에 요청을 전달.
   • 상태 정보를 보지 않고 빠르게 처리.

 

 

1. L7 로드 밸런싱:
   • 애플리케이션 레벨에서 동작.
   • L7: REST API, GraphQL, HTTPS, 동적 요청 처리.
   • HTTP 헤더, 쿠키, URL 경로 등의 정보를 분석하여 요청을 적합한 서버로 라우팅.
   • 사용처 :  Http 서비스 로드밸런싱
   • 예: /api/users 요청은 사용자 서비스로, /api/products 요청은 제품 서비스로 전달.
2. 로드 밸런서의 역할:
   • 요청을 **여러 WAS(Web Application Server)**로 분산하여 서버 부하를 줄임.
   • 장애가 발생한 서버는 제외하고 요청을 라우팅(Failover).
   • SSL 인증 처리를 통해 서버 부하를 줄일 수 있음.

 

3. 웹 애플리케이션 서버 (WAS)

WAS의 역할

• 클라이언트 요청을 처리하는 애플리케이션 로직을 수행.
• MSA(Microservices Architecture) 기반으로 설계:
  • 여러 서비스가 독립적으로 동작하며, 요청은 API Gateway를 통해 라우팅.

WAS의 내부 구조:

1. 프론트엔드 서버:
   • HTML 템플릿 제공 또는 SSR(Server-Side Rendering) 수행.
   • 예: Next.js, NGINX.
2. 백엔드 서비스:
   • 비즈니스 로직 처리.
   • REST API 또는 gRPC를 통해 클라이언트와 통신.

요청 흐름

1. 프론트엔드 서버에서 HTML 생성 요청.
2. 백엔드 API Gateway로 요청 전달.
   • Gateway는 요청을 분석하여 각 서비스로 라우팅.
   • 예: /api/users → 사용자 서비스, /api/orders → 주문 서비스.
3. 각 서비스는 필요한 데이터를 조회하거나, 비즈니스 로직 수행 후 응답.

캐싱 사용:

• Redis/Memcached를 통해 데이터베이스 요청 전에 캐싱 계층에서 데이터 조회.
• 캐시가 없으면 데이터베이스 요청 수행.

---

4. 데이터베이스 계층

DB 요청 흐름

1. WAS가 필요한 데이터를 데이터베이스에서 조회.
   • RDBMS(MySQL, PostgreSQL): 관계형 데이터베이스.
   • NoSQL(MongoDB, DynamoDB): 비정형 데이터 저장.
2. 샤딩 및 리플리케이션:
   • 데이터를 **샤딩(Sharding)**하여 트래픽 분산.
   • 읽기/쓰기 분리(Replication):
     • Primary DB는 쓰기 작업 담당.
     • Read Replica는 읽기 작업 담당.
3. 쿼리 최적화:
   • 인덱스 생성을 통해 조회 속도 개선.
   • 복잡한 쿼리를 캐싱하여 데이터베이스 부하 감소.

---

5. 클라이언트 응답

HTML 생성 및 반환

1. WAS는 최종적으로 HTML을 생성:
   • SSR(Server-Side Rendering):
     • 서버에서 동적으로 HTML 생성 후 클라이언트로 반환.
   • CSR(Client-Side Rendering):
     • WAS는 정적 HTML을 반환.
     • 클라이언트가 JavaScript를 통해 추가 데이터를 요청(API 호출).
2. HTML과 필요한 정적 리소스 경로를 반환:
   • 예: CSS, JS, 이미지 경로 포함.

정적 리소스 제공

1. 브라우저는 HTML에서 참조하는 리소스(CSS, JS, 이미지 등)를 요청.
2. CDN에서 리소스를 다운로드:
   • 엣지 서버에서 제공 → 빠른 응답.
   • 리소스가 없으면 원본 서버로 요청 전달.