하드웨어 기초 #6 네트워크 — 대역폭과 지연시간, NIC에서 데이터센터까지
#5에서 NAS와 SAN, 클라우드의 EBS가 모두 네트워크를 거친다고 했습니다. 이제 서버 바깥으로 나가 그 네트워크를 정리합니다. 네트워크에서 가장 자주 일어나는 혼동은 “빠르다"를 한 단어로 뭉뚱그리는 것입니다. 대역폭이 넓은데도 느린 경우가 있고, 그 이유를 모르면 엉뚱한 곳에 돈을 씁니다. 두 축으로 나눠 보겠습니다.
하드웨어 기초 시리즈에서 이번 글의 위치입니다.
- #1 컴퓨터를 움직이는 네 가지 자원 — CPU / 메모리 / 스토리지 / 네트워크
- #2 CPU — 코어 / 스레드 / 클럭 / 캐시, 그리고 vCPU의 정체
- #3 메모리 — RAM과 계층 구조, 스왑이 시작되면 벌어지는 일
- #4 스토리지 ① 장치 — HDD / SSD / NVMe와 IOPS / 처리량 / 지연시간
- #5 스토리지 ② 구성과 연결 — RAID와 DAS / NAS / SAN
- #6 네트워크 — 대역폭과 지연시간, NIC에서 데이터센터까지 ← 이번 글
- #7 가상화와 컨테이너 — 물리 서버 한 대가 여러 대가 되는 원리
- #8 클라우드 — 소유에서 임대로, 온프레미스부터 IaaS / PaaS / SaaS까지
- #9 클라우드 인스턴스 사양 읽는 법 — 워크로드에 맞춰 고르기
대역폭과 지연시간은 다른 축이다 #
네트워크 성능은 두 가지로 갈립니다. 둘을 섞으면 진단이 어긋납니다.
- 대역폭(Bandwidth) — 한 번에 얼마나 많이 보낼 수 있는가. 단위는 Gbps입니다.
- 지연시간(Latency) — 데이터 하나가 도착하기까지 얼마나 걸리는가. 단위는 ms입니다.
도로에 빗대면, 대역폭은 도로의 차선 수이고 지연시간은 출발지에서 목적지까지의 거리입니다. 차선이 아무리 많아도 거리가 멀면 한 대가 도착하는 시간은 줄지 않습니다.
| 상황 | 대역폭 | 지연시간 |
|---|---|---|
| 큰 파일 하나 전송 | 클수록 빠름 | 영향 작음 |
| 작은 요청을 자주 주고받음 | 영향 작음 | 낮을수록 빠름 |
| 화상 통화 | 어느 정도 필요 | 낮아야 자연스러움 |
웹 서비스의 응답 속도는 대체로 대역폭보다 지연시간에 민감합니다. 한 페이지를 그리려고 작은 요청을 여러 번 주고받기 때문입니다.
NIC — 서버의 네트워크 입구 #
서버가 네트워크에 연결되는 부품이 **NIC(Network Interface Card)**입니다. NIC의 속도가 그 서버가 낼 수 있는 대역폭의 상한을 정합니다. 1Gbps NIC는 아무리 좋은 회선을 붙여도 1Gbps를 넘지 못합니다.
여기서 단위에 주의합니다. 네트워크 속도는 비트(bit) 단위, 파일 크기는 바이트(byte) 단위입니다. 1바이트는 8비트이므로, 1Gbps 회선의 실제 전송 속도는 약 125MB/s입니다. “1기가 회선인데 다운로드가 100MB/s밖에 안 나온다"는 대부분 이 단위 차이 때문입니다.
1 Gbps (기가비트/초) ÷ 8 ≈ 125 MB/s (메가바이트/초)지연시간은 거리에서 온다 #
지연시간의 상당 부분은 물리적 거리입니다. 신호는 빛의 속도를 넘지 못하고, 광케이블 안에서는 그보다 더 느립니다. 그래서 서울에서 미국 동부까지는 아무리 회선이 좋아도 일정 시간 이상이 반드시 걸립니다.
한 번 갔다 오는 시간을 **RTT(Round Trip Time)**라고 합니다. 요청을 보내고 응답을 받기까지의 왕복 시간입니다. AWS 기초 #1의 리전 거리 표가 그대로 이 지연시간의 예입니다.
| 출발 → 도착 | 대략적인 RTT |
|---|---|
| 같은 데이터센터 안 | 1ms 미만 |
| 서울 → 도쿄 | 약 30~50ms |
| 서울 → 싱가포르 | 약 70~100ms |
| 서울 → 미국 동부 | 약 180~200ms |
여기에 중간을 거치는 라우터,스위치마다 약간씩 시간이 더해집니다. 이 중간 거점을 **홉(hop)**이라고 하고, 홉이 많을수록 지연이 쌓입니다.
거리는 처리량까지 줄인다 #
지연시간이 크면 큰 파일 전송조차 느려질 수 있습니다. 데이터를 한 묶음 보내고 확인 응답을 기다린 뒤 다음 묶음을 보내는 구조라, 왕복이 길면 회선이 비어 있어도 다음 묶음을 못 보내고 기다립니다.
대역폭 넓음 + 지연 큼
보냄 ──────▶ (응답 기다림 ...) ──────▶ (또 기다림 ...)
└ 이 기다리는 동안 넓은 회선이 비어 있음그래서 멀리 떨어진 곳으로 대용량을 보낼 때는 대역폭만 키운다고 빨라지지 않습니다. 한 번에 더 많이 보내도록 설정을 조정하거나, 애초에 거리를 줄이는 편이 효과적입니다.
데이터센터 네트워크 — 같은 AZ, 리전 간, 인터넷 #
클라우드에서 통신은 어디를 거치느냐에 따라 속도와 비용이 다릅니다. AWS 기초 #1의 리전과 AZ가 여기서 의미를 가집니다.
| 구간 | 지연 | 비용 |
|---|---|---|
| 같은 AZ 안 | 가장 낮음 | 대체로 무료 |
| 같은 리전, AZ 간 | 낮음 | 소액 과금 |
| 리전 간 | 거리만큼 큼 | GB당 과금 |
| 인터넷으로 나감(egress) | 경로에 따라 다름 | GB당 과금, 보통 가장 비쌈 |
그래서 서로 자주 통신하는 서버와 데이터베이스는 같은 AZ에 두는 것이 지연과 비용 모두에 유리합니다. 동시에 한 AZ 장애를 견디려면 여러 AZ에 나눠야 하므로, 지연,비용과 가용성 사이의 절충이 생깁니다.
CDN — 거리를 줄이는 방법 #
지연이 거리에서 온다면, 답 하나는 콘텐츠를 사용자 가까이 미리 가져다 두는 것입니다. 이것이 **CDN(Content Delivery Network)**입니다. 전 세계 곳곳의 거점에 이미지,동영상,정적 파일을 복제해 두고, 사용자는 가장 가까운 거점에서 받습니다.
AWS의 CloudFront가 그 예입니다. 한국 사용자가 미국 서버의 이미지를 매번 받는 대신, 가까운 거점에서 받아 RTT를 크게 줄입니다. 자세한 동작은 AWS 중급 #7 CloudFront에서 다룹니다.
자주 만나는 함정 #
“느리니까 대역폭을 늘리자” #
응답이 작은 요청을 자주 주고받는 구조라면 대역폭을 키워도 거의 효과가 없습니다. 원인이 지연시간이면 거리를 줄이거나(CDN,가까운 리전) 왕복 횟수를 줄여야 합니다.
“1기가 회선인데 100MB/s밖에 안 나온다” #
정상입니다. 1Gbps는 약 125MB/s이고, 오버헤드를 빼면 실제는 그보다 조금 낮습니다. 비트와 바이트의 차이입니다.
“리전 간 통신은 그냥 빠르겠지” #
리전 간은 거리만큼 지연이 크고, GB당 비용이 붙습니다. 멀리 떨어진 리전끼리 대량으로 데이터를 주고받는 설계는 느리고 비쌉니다.
“egress 비용을 신경 안 썼다” #
클라우드 밖으로 나가는 트래픽(egress)은 보통 가장 비싼 구간입니다. 들어오는 트래픽은 대체로 무료지만 나가는 트래픽이 과금되므로, 대용량을 외부로 자주 내보내면 비용이 크게 나옵니다.
정리 #
이번 글에서 잡은 그림입니다.
- 네트워크 성능은 대역폭(한 번에 얼마나)과 지연시간(도착까지 얼마나)이라는 다른 두 축입니다.
- NIC가 대역폭의 상한을 정합니다. 속도는 비트, 파일은 바이트이고 8배 차이가 납니다.
- 지연시간은 상당 부분 거리에서 옵니다. 왕복 시간이 RTT이고, 지연이 크면 처리량까지 줄어듭니다.
- 클라우드 통신은 같은 AZ → AZ 간 → 리전 간 → 인터넷 순으로 지연과 비용이 커집니다.
- CDN은 콘텐츠를 사용자 가까이 두어 거리를 줄입니다.
다음 — 가상화와 컨테이너 #
지금까지 한 대의 서버를 이루는 자원을 모두 봤습니다. 그런데 클라우드는 물리 서버 한 대를 수십 대처럼 나눠 팝니다. 어떻게 가능할까요. #7 가상화와 컨테이너 — 물리 서버 한 대가 여러 대가 되는 원리에서는 하이퍼바이저가 하드웨어를 나누는 방식, 가상 머신과 컨테이너가 자원을 공유하는 방식의 차이, 그리고 그것이 도커와 쿠버네티스로 어떻게 이어지는지 정리하겠습니다.