한재원

한재원

🛠️ 저는 커서 백엔드 개발자가 될래요!

[네트워크] 로드밸런싱, DNS

Updated: Categories:

웹 통신 흐름에 대해 알아보자

로드밸런서

  • 다수의 트래픽이 발생할 때, 부하를 분산하여 여러대의 서버가 처리하도록 하는 기술
  • 트래픽이 적다면 한대의 서버로 부하를 감당할 수 있지만, 트래픽이 많아진다면 ?
    • Scale Up
      • 서버 자체의 성능을 향상시키는 것
      • CPU나 메모리를 늘리는 것
    • Scale Out
      • 동일한 서버를 여러개 더 만드는 것
      • 트래픽 분산을 위해 로드밸런싱이 필요함


로드밸런싱 알고리즘

라운드로빈 (Round Robin)

  • 서버에 들어온 요청을 순서대로 돌아가며 공평하게 분배
  • 여러대의 서버가 동일한 스펙 + 연결이 오래 지속되지 않는 경우 적합

가중 라운드로빈 (Weighted Round Robin)

  • 각각 서버가 가중치를 가지며 가중치가 높은 서버에 우선 분배
  • 서버의 스펙이 서로 다른 경우 적합

IP 해시 방식 (IP Hash)

  • 사용자 IP를 해싱하여 특정 서버로 매핑하여 분배하는 방식
  • 사용자는 항상 동일한 서버로 연결됨

최소 연결 방식 (Least Connection)

  • 요청 시점에 가장 놀고있는 서버로 분배
  • 요청 처리 시간이 모두 상이하거나 트래픽이 일정하지 않은 경우에 적합

최소 리스폰타임 (Least Response Time)

  • 서버의 현재 연결 상태 + 응답시간을 모두 고려하여 분배
  • 가장 적은 연결상태와 가장 짧은 응답시간을 보이는 서버가 우선순위


계층별 로드밸런싱

L2

  • 데이터링크 계층
  • Mac 주소로 로드밸런싱

L3

  • 네트워크 계층
  • IP 주소로 로드밸런싱

L4

  • 전송 계층
  • 포트번호로 로드밸런싱
  • NLB(Network LoadBalancer)

L7

  • 응용 계층
  • 패킷 내용 확인후 그 내용에 따라 로드밸런싱
    • URL이나 HTTP 헤더 쿠키값에 따라 부하 분산 가능
  • ALB(Application LoadBalancer)


DNS(Domain Name System)

  • 도메인(호스트) 주소를 IP주소로 변환하는 시스템
  • UDP로 통신함 -> 빠른 속도, 가벼운 헤더가 더 중요하기 때문
  • DHCP 프로토콜 사용
  • 53번 포트 사용


동작원리

  • local DNS server : 기지국 DNS 서버 (통신사별로 각자 가지고 있음), DNS 주소를 캐싱할 수 있음
  • root DNS server : 최상위 도메인 서버
  • TLD(Top Level Domain) DNS server : 최상위 도메인 주소를 알고있는 서버
  • authoritative DNS server : 목적 IP 주소를 알고있는 서버

기본 동작

  1. 사용자가 www.naver.com 접속
  2. local DNS 서버에 주소를 물어봄 -> 만약 안다면 바로 알려줌
  3. 모른다면 root DNS 서버에 주소를 물어봄 (local DNS 서버는 root DNS 서버 주소를 원래 저장하고 있음)
  4. root DNS 서버는 정확한 주소를 모르지만 .com - TLD DNS 서버 주소를 알려줌
  5. 다시 .com - TLD DNS 서버에 주소를 물어봄
  6. TLD DNS 서버는 정확한 주소를 모르지만 naver.com - authoritative DNS 서버 주소를 알려줌
  7. 다시 naver.com - authoritative DNS 서버에 주소를 물어봄
  8. naver.com authoritative DNS 서버는 정확한 주소를 모르지만 www.naver.com - authoritative DNS 서버 주소를 알려줌
  9. www.naver.com - authoritative DNS 서버에 주소를 물어봄
  10. 서버는 IP를 알려줌

Iterative Query

image

  • 기본 동작임
  • local DNS 서버에서 반복적으로 DNS Query를 날림

Recursive Query

image

  • local DNS 서버에서 한번만 물어봐도 DNS Query를 타고타고 끝까지 감


웹 통신 흐름 총정리

image

  • www.naver.com을 브라우저에 검색한다면 어떤 일이 일어날까?
  • 모든 동작을 설명하기 위해 3가지로 분류해보았다
    • 웹이 SPA + Rest API 구조로 되어있다고 가정함

검색!

  1. 사용자가 www.naver.com 접속
  2. 캐싱된 DNS 기록 탐색
    1. 브라우저 캐시 확인
    2. 운영체제 캐시 확인
    3. 라우터 캐시 확인
  3. DNS 쿼리 탐색 시작
    1. local DNS 서버에 주소를 물어봄 -> 만약 캐싱되어 있다면 바로 알려줌
    2. 모른다면 root DNS 서버에 주소를 물어봄 (local DNS 서버는 root DNS 서버 주소를 원래 저장하고 있음)
    3. root DNS 서버는 정확한 주소를 모르지만 .com - TLD DNS 서버 주소를 알려줌
    4. 다시 .com - TLD DNS 서버에 주소를 물어봄
    5. TLD DNS 서버는 정확한 주소를 모르지만 naver.com - authoritative DNS 서버 주소를 알려줌
    6. 다시 naver.com - authoritative DNS 서버에 주소를 물어봄
    7. naver.com authoritative DNS 서버는 정확한 주소를 모르지만 www.naver.com - authoritative DNS 서버 주소를 알려줌
    8. www.naver.com - authoritative DNS 서버에 주소를 물어봄
    9. DNS 서버에서 IP 주소를 알려줌
  4. 알아낸 프론트엔드 IP 주소에 페이지 요청
    1. 3-way Handshake로 TCP 연결 (HTTPS 주소라면 SSL Handshake 추가됨)
    2. 연결되면 HTTP로 프론트엔드(웹서버)에서 html, css, js를 받아오고 화면 렌더링
  5. 백엔드(Rest API/WAS)에 데이터 요청
    1. Rest API의 IP 주소로 HTTP 요청 (만약 도메인주소라면 다시 DNS 쿼리 탐색)
    2. 로드밸런서(웹서버)에서 HTTP를 리다이렉트 or 로드밸런싱
    3. 서버에서 HTTP 응답