클라우드 인프라 밑바닥 파헤치기: 랙, 스위치, 라우터 개념 잡기

 

맨날 AWS 콘솔에서 클릭으로 VPC 만들고, 테라폼으로 EC2 띄우고, 쿠버네티스 파드(Pod)만 만지다 보면 가끔 이런 생각이 듦.

 

"도대체 밑바닥 물리 장비들은 어떻게 생겨먹었고, 내 데이터는 어떤 선을 타고 나가는 걸까?"

 

 

 

클라우드도 결국 누군가의 거대한 컴퓨터(물리 서버)일 뿐임.

오늘은 인프라 엔지니어라면 머릿속에 꼭 그려져야 할 데이터센터의 3대장,

랙(Rack), 스위치(Switch), 라우터(Router)의 개념을 아주 쉽게 정리해 보겠음.

 

 

---

1. 랙 (Rack): 서버들의 거대한 아파트

 

우리가 흔히 아는 데스크탑 PC는 뚱뚱한 상자 모양임. 근데 데이터센터에 수백, 수천 대의 서버를 그런 식으로 바닥에 늘어놓으면 공간도 부족하고 열 관리도 절대 안 됨.

그래서 기업용 물리 서버는 공간 효율을 극대화하기 위해 납작한 피자 박스 모양(랙마운트 서버)으로 만듦.

 

• 랙(Rack)이란? 이 납작한 서버들을 차곡차곡 층층이 쌓아 넣을 수 있는 거대한 철제 캐비닛(서랍장)임.
• 어떻게 생겼나? 에어컨 빵빵한 데이터센터에 이 거대한 철제 책장들이 수십 개씩 줄지어 서 있음. 랙 하나에 피자 박스 모양의 깡통 서버를 20~40대씩 빽빽하게 밀어 넣고 나사로 고정함. (서버 두께에 따라 1U, 2U 단위로 부름)

 

결국 우리가 퍼블릭 클라우드에서 VM을 띄우면, 아마존이나 구글 데이터센터에 있는 이 수많은 랙 중 어딘가 빈칸에 꽂힌 물리 서버 자원을 쪼개서 할당받는 거임.

 

 

---

 

2. 스위치 (Switch): 똑똑한 멀티탭이자 동네 우체국

랙 하나에 서버 40대가 꽂혀 있다고 치자. 얘네들이 통신하려면 랜선이 필요한데, 40가닥을 일일이 데이터센터 메인 망까지 길게 끌고 갈 수는 없음. 그래서 등장한 게 스위치임.

 ToR 스위치 (Top of Rack)

• 보통 랙 맨 꼭대기 칸에 스위치 장비를 하나 달아둠 (그래서 Top of Rack임).
• 아래 40대 서버의 짧은 랜선들을 전부 끌어올려서 이 스위치 하나에 다 물리적으로 꽂음.
• 역할: "멀티탭"임. 40대의 트래픽을 하나로 싹 모은 다음, 엄청 빠르고 굵은 광케이블 한두 가닥만 상위 네트워크로 내보냄.

 Spine 스위치

• 데이터센터에 랙이 100개면 ToR 스위치도 100개임. 이 100개의 ToR 스위치가 뿜어내는 광케이블이 싹 다 모이는 중앙 교차로가 바로 Spine(척추) 스위치임.
• 역할: 데이터센터 "내부"에서 랙과 랙 사이(예: 1번 랙 웹 서버 ↔ 50번 랙 DB 서버)의 데이터를 길 잃지 않고 초고속으로 쏴주는 내부 물류 허브임.

 

스위치의 핵심: 스위치는 자기한테 연결된 장비들의 MAC 주소를 싹 다 기억함.
그래서 "어, 이 데이터는 5번 서버로 가는 거네?" 하고 정확히 5번 포트로만 데이터를 던져줌.

---

 

3. 라우터 (Router): 국경 수비대와 글로벌 내비게이션

스위치가 건물 내부 통신용이라면, 라우터는 건물 밖(외부 인터넷)으로 나갈 때 거치는 관문임.

데이터가 Spine 스위치를 거쳐서 "어? 이 목적지는 우리 데이터센터가 아니네? 외부망이네?" 하는 순간, 출구에 버티고 있는 라우터로 넘어감. 라우터는 크게 두 가지 핵심 역할을 함.

 

① 주소 바꿔치기 (NAT - Network Address Translation)

내부 서버들은 자기들끼리만 아는 사설 IP(예: 10.0.1.50)를 씀. 근데 이 주소표를 달고 인터넷에 나가면 아무도 못 알아보고 답장(Response)도 못 받음. 그래서 라우터가 바깥으로 나가는 문턱에서 사설 IP를 통신사한테 받아온 진짜 공인 IP로 싹 바꿔 치기 해서 내보내 줌. (AWS에서 NAT Gateway 설정하는 게 바로 이 작업임)

 

② 최적의 경로 찾기 (Routing)

전 세계에 43억 개의 IP가 있는데 라우터가 이걸 어떻게 다 알고 길을 찾아줄까? 전 세계 거대 통신사(ISP)들의 최상위 라우터들끼리는 BGP라는 자기들만의 단톡방(프로토콜)으로 연결되어 있음.

• "야, 우리 쪽 해저케이블 끊겼다. 당분간 일본 쪽 우회도로 써라!"
• "오케이 지도 업데이트 완료"

이런 식으로 1초에도 수만 번씩 자기들끼리 거대한 지도를 교환하고 실시간으로 길을 업데이트함. 라우터는 이 지도를 보고 "아, 이 데이터는 미국 구글 서버로 가니까 KT 망 광케이블로 던지는 게 제일 빠르겠다!" 하고 길을 찾아주는 거임.

---

 

3줄 요약 (End-to-End 데이터 흐름)

내 VM에서 쏜 데이터가 상대방 스마트폰에 꽂히기까지의 물리적 여정은 딱 이럼.

 

1. [우리 집] 내 서버 -> ToR 스위치(랙 꼭대기) -> Spine 스위치(중앙 허브) -> 방화벽/라우터(출구)
2. [고속도로] -> 지하에 묻힌 통신사 굵은 광케이블 -> 태평양 해저 케이블
3. [상대 집] -> 쟤네 라우터 -> 쟤네 Spine -> 쟤네 ToR -> 상대방 기기

 

이런 거대한 물리 장비들이 묵묵히 트래픽을 나르고 있다는 걸 좀 잡혀서 좋았다