상위 네트워크의 구조: 서버 확장에서 로드 밸런서, DNS, ISP, BGP, Anycast까지
서버 한 대에서 출발해 수평 확장과 MSA, 로드 밸런서, DNS, ISP, BGP, Anycast까지 대규모 서비스의 상위 네트워크 구조를 문답 형식으로 정리합니다.
일반 독자들이 잘 모르는 상위 네트워크의 구조
인터넷을 사용하는 사람이라면 누구나 한 번쯤 이런 생각을 해본 적이 있을 것이다.
"구글처럼 수천만 명이 사용하는 서비스는 도대체 어떻게 그 많은 요청을 처리하는 걸까?"
개발자라면 조금 더 구체적인 질문을 던질 수도 있다.
"서버가 늘어난다고 하는데, 서버를 여러 대 복제한다는 뜻인가?"
"그럼 모놀리스 서버를 여러 대 띄우는 건가, 아니면 MSA로 전환하는 건가?"
"구글은
www.google.com이라는 하나의 도메인으로 접속하는데, 수많은 서버가 있다면 IP 주소는 어떻게 처리되는가?""IP 하나로 수천만 명의 요청을 받을 수 있는가?"
"로드 밸런서 하나가 그 모든 트래픽을 처리하는 건가?"
"인터넷을 연결해주는 ISP는 이 과정에서 무슨 일을 하는가?"
"BGP와 Anycast는 도대체 어디에 등장하는가?"
이 질문들은 각각 별개의 주제처럼 보이지만, 실제로는 하나의 흐름으로 연결되어 있다.
이번 장에서는 작은 스타트업의 서버 한 대에서 출발해, 모놀리스의 수평 확장, MSA, 로드 밸런서, DNS, ISP, BGP, Anycast까지 차례대로 올라가 보자.
1. "서비스가 커지면 서버가 늘어난다"는 말은 무슨 뜻일까?
질문자: 서비스가 성장하면 "서버가 늘어난다"고 하잖아요. 정확히 무슨 의미인가요?
전문가: 가장 먼저 이 표현을 구분할 필요가 있습니다.
"서버가 늘어난다"와 "서비스 구조가 바뀐다"는 서로 다른 이야기입니다.
스타트업 A가 처음 쇼핑 서비스를 만들었다고 해보죠.
사용자
│
▼
Application Server
│
▼
PostgreSQL애플리케이션 서버 한 대가 회원, 상품, 주문, 결제, 게시판 등의 모든 기능을 가지고 있다고 합시다.
이것이 전형적인 모놀리스(Monolith) 구조입니다.
처음에는 사용자가 많지 않으니 서버 한 대로 충분합니다.
그런데 서비스가 성공해 사용자가 급격히 증가했다고 해봅시다.
처음에는 초당 50개의 요청을 처리하면 됐는데 어느 순간 초당 500개의 요청이 들어옵니다.
서버가 감당할 수 있는 한계를 넘어서는 순간부터 문제가 시작됩니다.
2. 서버를 늘리는 가장 단순한 방법
질문자: 그러면 서버를 늘리면 되는 건가요?
전문가: 방법은 크게 두 가지가 있습니다.
첫 번째는 **수직 확장(Scale-up)**입니다.
기존 서버가 4코어 CPU와 8GB RAM이었다면 이를 16코어, 64GB RAM으로 교체하는 것입니다.
4 Core / 8GB
↓
16 Core / 64GB쉽고 직관적이지만 한계가 있습니다.
아무리 좋은 서버를 사도 하드웨어에는 한계가 있기 때문입니다.
두 번째 방법이 **수평 확장(Scale-out)**입니다.
서버 한 대를 더 좋은 것으로 교체하는 대신, 동일한 애플리케이션 서버를 여러 대 실행합니다.
Load Balancer
/ | \
▼ ▼ ▼
Server1 Server2 Server3
\ | /
\ | /
DB여기서 중요한 점이 있습니다.
이 구조는 여전히 모놀리스입니다.
Server 1, Server 2, Server 3에 모두 똑같은 모놀리스 애플리케이션이 실행되고 있기 때문입니다.
따라서:
서버가 여러 대가 되었다 = MSA가 되었다
는 공식은 성립하지 않습니다.
3. 그렇다면 MSA는 언제 등장하는가?
질문자: 그럼 MSA는 서버를 늘리는 것과 다른 문제인가요?
전문가: 그렇습니다.
MSA는 서버의 개수보다 애플리케이션의 구조를 어떻게 나누느냐의 문제입니다.
처음에는 모든 기능이 하나의 애플리케이션에 들어있습니다.
Monolith
├── 회원
├── 상품
├── 주문
├── 결제
├── 검색
└── 알림서비스가 거대해지면 이것을 논리적으로 분리할 필요가 생길 수 있습니다.
User Service
Product Service
Order Service
Payment Service
Search Service이렇게 각 서비스를 독립적으로 배포하고 운영하는 것이 MSA의 방향입니다.
그러면 다음과 같은 구조도 가능합니다.
Load Balancer
│
┌───────────┼───────────┐
▼ ▼ ▼
User Service Product Order
Service Service
×2 ×10 ×5상품 서비스에 트래픽이 몰리면 상품 서비스만 10개, 20개로 늘릴 수 있습니다.
여기서 우리는 두 가지 개념을 분리해서 생각해야 합니다.
애플리케이션을 여러 서비스로 분리하는 것
→ MSA
하나의 서비스를 여러 인스턴스로 실행하는 것
→ 수평 확장
둘은 동시에 사용될 수 있지만 같은 개념은 아닙니다.
4. 그런데 여기서 새로운 질문이 생긴다
질문자: 알겠습니다. 모놀리스든 MSA든 서버를 여러 대 띄울 수 있다는 건 이해했습니다.
그런데 구글 같은 서비스는 서버가 도대체 몇 대인가요?
제가 www.google.com의 IP를 조회해보니 172.217.209.113이 나오는데요.
수천만 명이 동시에 Google을 사용한다면, 결국 그 수많은 요청이 이 IP로 들어오는 것 아닌가요?
전문가: 바로 여기서 우리가 평소 생각하는 "IP 주소 = 서버 한 대"라는 관념을 버려야 합니다.
172.217.209.113이라는 IP 주소가 있다고 해서 다음과 같은 구조라고 생각하면 안 됩니다.
172.217.209.113
│
▼
서버 한 대
│
NIC대규모 인터넷 서비스는 이렇게 동작하지 않습니다.
IP 주소는 물리적인 서버 한 대를 의미하는 이름표가 아닙니다.
IP는 네트워크에서 사용되는 논리적인 주소입니다.
5. 그렇다면 IP 하나로 여러 서버를 사용할 수 있는가?
질문자: 그렇다면 하나의 IP 주소를 여러 서버가 사용할 수도 있다는 건가요?
전문가: 그렇습니다.
다만 여기서 중요한 것은 어떤 방식으로 여러 서버에 분산시키느냐입니다.
우리가 가장 먼저 떠올릴 수 있는 것이 로드 밸런서입니다.
사용자
│
▼
Load Balancer
/ | \
▼ ▼ ▼
Server1 Server2 Server3사용자는 하나의 진입점을 바라보지만, 내부에서는 요청이 여러 서버로 분산됩니다.
그런데 Google 정도의 규모가 되면 여기서 한 단계 더 생각해야 합니다.
"그렇다면 Load Balancer 하나가 모든 Google 사용자의 요청을 받아야 하는 것 아닌가?"
당연히 그렇지 않습니다.
로드 밸런서 역시 여러 대이고, 네트워크 자체도 여러 지역에 분산되어 있습니다.
6. "로드 밸런서 하나의 NIC로 수천만 명을 처리하는가?"
질문자: 그러면 로드 밸런서 한 대의 NIC가 그 모든 요청을 처리하는 건가요?
전문가: 아닙니다.
대규모 서비스에서는 로드 밸런서도 분산되어 있습니다.
개념적으로는 다음과 같은 형태에 가깝습니다.
Internet
│
┌────────────┼────────────┐
▼ ▼ ▼
Edge/LB Edge/LB Edge/LB
│ │ │
┌──┼──┐ ┌──┼──┐ ┌──┼──┐
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
App App App App App App App App App따라서 "Google IP 하나"와 "Google 서버 한 대"를 1:1로 연결해서 생각하면 안 됩니다.
IP 하나가 존재하더라도 그 뒤에는 수많은 네트워크 장비와 서버가 있을 수 있습니다.
그렇다면 여기서 또 하나의 질문이 생깁니다.
"그런데 인터넷은 어떻게 IP 하나를 여러 지역으로 보낼 수 있는가?"
여기서 등장하는 것이 Anycast와 BGP입니다.
7. Anycast — 같은 주소를 여러 곳에서 사용하기
질문자: Anycast가 그 문제를 해결하나요?
전문가: 정확히는 Anycast는 동일한 IP 주소 또는 IP Prefix를 여러 네트워크 위치에서 서비스하는 방식이라고 이해하면 됩니다.
가상의 IP 8.8.8.8이 있다고 해봅시다.
8.8.8.8
/ | \
▼ ▼ ▼
한국 미국 유럽
Edge Edge Edge한국 사용자도 8.8.8.8로 접속하고,
미국 사용자도 8.8.8.8로 접속합니다.
하지만 실제 패킷이 도착하는 네트워크 위치는 서로 다를 수 있습니다.
즉,
같은 IP 주소를 가지고 있지만, 실제 서비스 지점은 여러 곳에 존재할 수 있습니다.
그런데 여기서 새로운 문제가 생깁니다.
"인터넷 라우터는 한국, 미국, 유럽 중 어디로 보내야 하는지 어떻게 알지?"
그 역할에 등장하는 핵심 기술이 BGP입니다.
8. BGP — 인터넷의 거대한 길 안내 시스템
질문자: BGP는 정확히 뭘 하는 건가요?
전문가: BGP는 인터넷의 서로 다른 네트워크들이 어떤 IP 대역으로 가는 경로를 서로 알려주는 프로토콜입니다.
인터넷은 하나의 거대한 네트워크가 아닙니다.
여러 조직의 네트워크가 서로 연결되어 있습니다.
예를 들어:
KT
SK Broadband
LG U+
Google
Cloudflare
Amazon
Microsoft등이 각각 거대한 네트워크를 운영합니다.
이런 네트워크를 **AS(Autonomous System)**라는 단위로 볼 수 있습니다.
그리고 AS와 AS 사이에서 경로 정보를 교환하는 대표적인 프로토콜이 BGP입니다.
9. ISP는 여기서 어디에 등장하는가?
질문자: 그러면 ISP는 어디에 들어가나요?
전문가: 우리가 집에서 사용하는 인터넷을 예로 들어봅시다.
내 PC
│
▼
집 공유기
│
▼
ISP
│
▼
Internet
│
▼
Google예를 들어 ISP가 KT라면:
내 PC
│
▼
집 공유기
│
▼
KT 네트워크
│
▼
다른 네트워크
│
▼
Google 네트워크가 됩니다.
ISP는 단순히 "인터넷을 판매하는 회사"가 아니라, 거대한 네트워크 자체를 운영하는 사업자입니다.
그리고 그 네트워크에는 수많은 라우터가 있습니다.
KT
┌───────────────────┐
│ Access Router │
│ ↓ │
│ Core Router │
│ ↓ │
│ Core Router │
│ ↓ │
│ Border Router │
└─────────┬─────────┘
│
▼
다른 네트워크10. 그렇다면 ISP가 BGP와 Anycast를 담당하는가?
질문자: 그러면 ISP 업체들이 BGP와 Anycast를 담당한다고 보면 되나요?
전문가: 여기서는 둘을 구분해야 합니다.
BGP
ISP는 BGP를 매우 중요하게 사용합니다.
하지만 BGP가 ISP 전용인 것은 아닙니다.
Google, Cloudflare, Amazon 같은 대형 네트워크 사업자 역시 BGP를 사용합니다.
BGP
│
┌───────┼───────┐
▼ ▼ ▼
ISP Google Cloudflare
AS AS ASAnycast
Anycast 역시 ISP 전용 기술이 아닙니다.
Google이나 Cloudflare처럼 여러 지역에 네트워크를 운영하는 사업자가 동일한 IP를 여러 위치에서 서비스하기 위해 Anycast 구조를 사용할 수 있습니다.
즉:
Anycast를 설계하고 운영하는 주체와, 그 Anycast 경로를 받아 인터넷을 전달하는 ISP는 구분해야 합니다.
11. 그렇다면 BGP와 Anycast는 어떻게 연결되는가?
이 둘의 관계를 이해하면 전체 그림이 완성됩니다.
Google이 여러 지역에서 동일한 IP 대역을 서비스한다고 해봅시다.
Google IP
│
┌─────────┼─────────┐
▼ ▼ ▼
서울 도쿄 미국
Google AS Google AS Google ASGoogle은 각 위치에서 해당 IP 대역으로 가는 경로를 BGP를 통해 광고할 수 있습니다.
그러면 인터넷의 다른 AS들이 이 경로를 학습합니다.
Google
│
│ BGP
▼
KT
│
▼
다른 ISP한국 사용자가 Google IP로 접속하면 한국 ISP의 라우터는 자신이 가지고 있는 BGP 경로 정보를 바탕으로 패킷을 적절한 방향으로 보냅니다.
미국 사용자는 미국 쪽 경로를 통해 Google 네트워크에 도착할 수 있습니다.
따라서 개념적으로:
Anycast
↓
"같은 IP를 여러 장소에서 서비스하자"
BGP
↓
"그 IP로 가는 경로가 여기에도 있다는 사실을
인터넷에 알려주자"
ISP
↓
"다른 네트워크에서 배운 경로를 바탕으로
패킷을 전달하자"라고 이해할 수 있습니다.
12. ISP 내부에서는 모든 것이 BGP일까?
질문자: 그러면 ISP 내부의 모든 라우터도 BGP로 움직이나요?
전문가: 그렇지는 않습니다.
이것도 흔한 오해입니다.
BGP는 주로 서로 다른 AS 사이의 라우팅에서 중요한 역할을 합니다.
AS 1 AS 2
┌────────────────┐ ┌────────────────┐
│ │ │ │
│ Router ────────┼── BGP ────┼──────── Router │
│ │ │ │
└────────────────┘ └────────────────┘AS 내부에서는 OSPF, IS-IS 등의 **IGP(Interior Gateway Protocol)**를 사용할 수 있습니다.
즉:
AS 1 AS 2
┌─────────┐ ┌─────────┐
│ │ │ │
│ IGP │──── BGP ────│ IGP │
│ │ │ │
└─────────┘ └─────────┘처럼 생각하면 됩니다.
13. 이제 인터넷 전체를 하나로 연결해보자
지금까지의 이야기를 모두 합치면 다음과 같습니다.
Google
┌─────────────────┐
│ Google AS │
│ Global Network │
└────────┬────────┘
│
BGP Advertisement
│
"이 IP Prefix는 우리에게 있다"
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
Google Korea Google Japan Google US
Anycast Edge Anycast Edge Anycast Edge
│ │ │
▼ ▼ ▼
Load Balancer Load Balancer Load Balancer
│ │ │
App × N App × N App × N
사용자
│
▼
집 공유기
│
│ NAT
▼
┌──────────────────────┐
│ ISP │
│ │
│ Access Network │
│ ↓ │
│ Core Network │
│ ↓ │
│ Border Router │
└──────────┬───────────┘
│
│ BGP
▼
Internet / IX
│
│ BGP
▼
Google AS이 그림에서 각각의 역할은 명확하게 다릅니다.
14. 그러면 Google까지 패킷 하나가 어떻게 이동할까?
마지막으로 실제 사용자의 요청 하나를 따라가 보겠습니다.
사용자가 브라우저에:
https://www.google.com을 입력합니다.
① DNS
먼저 도메인을 IP 주소로 해석합니다.
www.google.com
↓
DNS
↓
Google IP② 집
PC의 패킷은 공유기를 거칩니다.
PC
↓
공유기
↓
NAT③ ISP
공유기에서 ISP로 들어갑니다.
공유기
↓
ISP Access Network
↓
ISP Core Network④ 인터넷
ISP의 경계 라우터에서 다른 AS와 연결됩니다.
ISP AS
│
│ BGP
▼
Internet / IX / Peering / Transit
│
▼
Google ASGoogle의 네트워크에 도착한 뒤:
Google Edge
↓
Load Balancer
↓
Application Server
↓
Cache / Search System / Database등을 거쳐 실제 응답을 만들어냅니다.
15. 결국 인터넷을 "도로"라고 생각하면 쉽다
마지막으로 비유 하나만 남겨두겠습니다.
인터넷을 거대한 도로망이라고 생각해봅시다.
ISP
도로망을 운영하는 대형 교통 회사입니다.
KT
SKB
LGU+
...각자 자신들의 도로망을 가지고 있습니다.
BGP
도로망 운영자들이 서로 주고받는 길 안내 정보입니다.
"Google로 가려면 우리 네트워크를 통해 갈 수 있습니다."
Anycast
전국 여러 지역에 같은 목적지 이름을 붙여놓는 방식입니다.
"Google이라는 목적지가 서울에도 있고 도쿄에도 있고 미국에도 있습니다."
Load Balancer
도착한 뒤 어느 주차장으로 들어갈지 결정하는 안내 시스템입니다.
Google Edge
│
├── Server 1
├── Server 2
├── Server 3
└── Server 4Application Server
실제로 요청을 처리하는 곳입니다.
마무리 — 우리가 처음 가졌던 의문으로 돌아가 보자
처음에는 아주 단순한 질문에서 출발했습니다.
"Google은 수천만 명이 사용하는데,
www.google.com의 IP가 하나 보인다면 그 IP의 서버 한 대가 모든 요청을 받는 것 아닌가?"
이제는 이 질문에 답할 수 있습니다.
아니다.
IP 주소는 서버 한 대와 1:1로 대응하지 않습니다.
대규모 서비스에서는:
도메인
↓
DNS
↓
IP
↓
인터넷 라우팅(BGP)
↓
여러 지역의 Edge / Anycast
↓
Load Balancer
↓
수많은 Application Server
↓
Cache / Database / Storage라는 여러 계층을 거칠 수 있습니다.
그리고 그 과정에서 ISP는 사용자의 인터넷 접속을 담당하면서 자신의 네트워크를 운영하고, 다른 AS와 BGP를 통해 경로를 교환합니다.
결국 우리가 브라우저에서 보는 것은:
www.google.com이라는 아주 단순한 주소 하나지만, 그 뒤에는 수많은 네트워크와 라우터, 데이터센터, 서버가 계층적으로 연결된 거대한 시스템이 존재합니다.
인터넷을 처음 배울 때는 흔히 "내 컴퓨터가 서버의 IP로 접속한다"고 배웁니다.
틀린 말은 아닙니다.
하지만 인터넷의 규모가 커지면 "IP = 서버"라는 사고방식으로는 더 이상 설명할 수 없습니다.
그때부터 IP는 하나의 서버를 가리키는 주소가 아니라, 거대한 네트워크 시스템으로 들어가기 위한 논리적인 목적지로 보이기 시작합니다.
그리고 바로 그 지점에서 DNS, ISP, BGP, Anycast, Load Balancer라는 서로 다른 개념들이 하나의 그림으로 연결됩니다.