아주 쉽게 설명하는, 라우터와 VPC: 인터넷이 연결되는 방법
서버/인프라를 지탱하는 기술에서 ‘다중화’는 필수적입니다.
지금과 같은 클라우드 시대가 도래하기 이전에는 장비 하나 하나 다 최소 두 대씩은 뒀어야 했(다)는데요.
라우터도 장애시 대응이 필요한 장치 중 하나였습니다.
이 글에서는 라우터가 뭔지, 클라우드 시대에서의 라우터는 어떤 것인지 설명합니다.
- 📮 우선, 라우터가 뭔가요?
- 실생활 예시로 이해하기: 배달 앱 주문 여정
- 🏢 예전에는 어땠나요?
- ☁️ How about now? 클라우드!
- VPC란?
- 서브넷이란?
- IP 주소 관리 🔢
- VPC 실제 사용 예시 💼
- 라우트 테이블 ⚡
- VPC 사용 시 고려해야할 점
- 🎯 정리하면
📮 우선, 라우터가 뭔가요?
사실은 집에 하나쯤 다 있는 건데요, 공유기입니다.
비유적으로 설명하자면, 현실의 우체국과 같은 장치예요.
- 여러분이 편지를 보내면 우체국이 어디로 배달할지 결정하죠?
- 라우터는 인터넷의 우체국이에요.
- 데이터(편지)가 어디로 가야 할지 길을 안내해주는 장치입니다.
실생활 예시로 이해하기: 배달 앱 주문 여정
여러분이 어느 날, 햄버거가 먹고 싶어요. 날은 너무 춥고, 배달이나 시켜야겠습니다.
자연스럽게 뭘 킵니까? 배달의민족이죠. (쿠팡이츠, 요기요, 뭐든지..)
- 주문 시작 🏠 → ☁️
- 배민 앱에서 햄버거 주문 버튼 클릭
- 휴대폰 → 집 공유기(라우터) → 통신사 → 배달의민족 서버
- 가게 전달 ☁️ → 🏪
- 배민 서버 → 햄버거가게 POS/태블릿
- “○○○ 가게에 새로운 주문이 들어왔습니다”
- 주문 수락 🏪 → ☁️ → 🏠
- 햄버거가게 주문 수락 → 배민 서버 → 고객 휴대폰
- “가게에서 주문을 수락했어요!”
모든 과정에서 라우터들이 데이터의 교통정리를 해줍니다:
- 집 공유기: 주문 데이터를 인터넷으로 전송
- 통신사 라우터: 최적 경로로 데이터 안내
- 배민 서버 라우터: 적절한 서버로 요청 전달
- 가게의 라우터: POS/태블릿으로 주문 전달
🏢 예전에는 어땠나요?
온프레미스 인프라라고 하죠.
예전에는 클라우드가 아니라 회사 내 전산실에 서버와 라우터 등을 다 갖추고 있었습니다.
서버가 한 대도 아니었을 텐데, 어디로 전달할지 알려면 라우터도 고장나면 안됐겠죠.
현재 운용하고 있는 라우터와 동일한 설정의 예비 운용장비를 두고 있었습니다. Cold Standby라고 합니다.
장애가 발생하면, 수동으로 예비 장비로 교체했어야 했습니다.
☁️ How about now? 클라우드!
물론 여전히 온프레미스인 회사들도 많습니다. 회사 내에서 서버를 관리하는 게 아니라, 데이터 센터를 쓰고 있는 곳들도 있고요.
클라우드 환경에서도 라우터의 개념과 역할은 여전히 존재합니다.
다만, 그 형태가 물리적 하드웨어에서 가상화된 형태로 변화했어요.
하드웨어의 형태에서 가상 라우터/네트워크 형태로 변화했습니다.
- AWS의 Virtual Private Cloud (VPC) 라우팅 테이블
- Azure의 Virtual Network와 Route Tables
- GCP의 Cloud Router
위와 같은 서비스가 라우터의 역할을 합니다.
예비 운용 장비 두고 수동 교체하던 방식에서 자동화된 복구 방식으로 변화했습니다.
- 전통적인 Cold Standby 방식 대신 클라우드 네이티브한 방식 사용
- Auto Scaling을 통한 자동화된 복구
- 여러 가용영역(AZ)에 걸친 분산 구성
- 로드밸런서를 통한 트래픽 분산
위와 같은 방식으로 장애에 대응하게 되었습니다.
가상화되면서,
- 하드웨어 유지보수가 불필요해졌고,
- 설정 변경이 더 유연하고 빨라졌으며
- Infrastructure as Code(IaC)를 통한 구성을 관리할 수 있게 되었고
- 자동화된 백업과 복구가 가능해졌어요.
IaC에 보충 설명을 하자면
resource "aws_route_table" "main" {
vpc_id = aws_vpc.main.id
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.main.id
}
}
이런 코드만으로 라우팅 설정이 완료된다는 뜻입니다.
VPC란?
VPC(Virtual Private Cloud)는 AWS에서 제공하는 가상 데이터센터입니다.
- 클라우드 안에 있는 나만의 전용 네트워크
- 외부와 격리된, 안전한 공간
- 원하는 대로 구성할 수 있는 네트워크 환경
을 제공하죠.
왜 이런게 필요하냐면, 보안이 필요한 공간이 있을 수 있기 때문입니다.
여러분의 학교에, 회사에 아무나, 아무때나 출입할 수 있다고 생각해보세요.
영 신경쓰일 뿐더러, 위험할지도 모릅니다.
회사 건물을 생각해봅시다:
- 1층: 누구나 들어올 수 있는 로비
- 2층: 고객 상담실
- 3-4층: 직원들만 들어갈 수 있는 사무실
- 지하: 서버실, 금고 등 보안구역
클라우드도 이런 구분이 필요합니다.
- 누구나 접속 가능한 공개 서비스 (웹사이트 등)
- 직원만 접속 가능한 내부 시스템
- 보안이 필요한 데이터베이스
- 개발용 테스트 환경
그럼 이런 구분은 어떻게 하냐, 서브넷으로 네트워크를 쪼개서 사용합니다.
출처: Amazon VPC 작동방식
서브넷이란?
- VPC의 하위 단위로 VPC에 할당된 IP를 더 작은 단위로 분할한 개념
- 하나의 서브넷은 하나의 가용영역(AZ)안에 위치
- 위 사진에서 us-east-1a, us-east-1b와 같은 a,b가 가용영역
- CIDR block range로 IP 주소 지정
서브넷의 종류는 다음과 같습니다.
퍼블릭 서브넷
- 외부 인터넷과 직접 연결 가능
- 예: 회사 홈페이지 서버
- IGW(인터넷 게이트웨이)를 통해 외부 접속
프라이빗 서브넷
- 외부 인터넷 직접 연결 불가
- 예: 데이터베이스, 내부 시스템
- 보안이 중요한 리소스 배치
이러한 서브넷 덕분에 VPC가 그 목적대로 동작합니다.
- IP 대역을 자유롭게, 필요한 만큼 분할해서 사용할 수 있으며
- 그 IP Block 단위로 접근 제어가 가능하거든요.
IP 주소 관리 🔢
AWS VPC의 IP 주소는 이렇게 관리됩니다:
기본 VPC 주소 범위 예시 (10.0.0.0/24):
- 10.0.0.0: 네트워크 주소
- 10.0.0.1: VPC 라우터용
- 10.0.0.2: DNS 서버용
- 10.0.0.3: 예비로 예약됨
- 10.0.0.255: 브로드캐스트 주소
실제 사용 가능한 IP: 251개 (2^8 - 5)
Q. 8은 도대체 어디서 나왔습니까?
A. 이걸 아시려면 CIDR block range에 대해 알고 계셔야 하는데, /24 에서 나왔습니다. 구체적으로는 32-24=8에서 나왔어요. 32인 이유는, 그것이 IPv4임. 아무튼 그래서 /뒤에 있는 숫자가 작으면 작을수록 구체적인 주소임을 의미합니다. 타 회사와 협업하며 우리 회사의 Public IP 주소를 공유할 때, /32 까지는 굳이 보내지 않아도 되는 이유…
VPC 실제 사용 예시 💼
일반적인 기업 구성
1. 프론트엔드 층 (퍼블릭 서브넷)
- 웹 서버 (EC2)
- 로드 밸런서
2. 백엔드 층 (프라이빗 서브넷)
- 애플리케이션 서버
- 데이터베이스 (RDS)
- Lambda 함수
3. 보안 설정
- IP Block 기반 접근 제어
- 인터넷 노출 최소화
라우트 테이블 ⚡
이 이미지를 다시 봅시다. 지금까지 VPC, Subnet에 대해 얘기했어요. 그 다음은 라우트 테이블입니다.
라우트 테이블은 VPC의 트래픽 경로를 결정하는 규칙집입니다.
- 어디로 가야 할지 알려주는 이정표
- 서브넷별로 다른 규칙 적용 가능
- 트래픽 흐름 세밀하게 제어
이런 역할들을 합니다. VPC 생성시 기본으로 하나 제공돼요.
VPC 사용 시 고려해야할 점
- 설계 단계
- IP 대역을 넉넉하게 잡기 - 가용영역 분산 고려 - 확장성 고려한 서브넷 설계 - 보안 설정
- 프라이빗 서브넷 적극 활용 - 보안그룹 세분화 - 접근 로그 활성화
🎯 정리하면
- 물리적 라우터가 AWS의 VPC라는 가상 네트워크로 진화
- 장애 대응이 자동화된 가상 라우팅 시스템으로 변화
- AWS가 인프라 다중화와 장애 대응을 자동으로 처리
- 더 이상 백업 장비를 고민할 필요 없는 클라우드 네이티브한 환경
이런 세상에 우리가 지금 살고 있습니다.
AWS 없이 귀찮아서 어떻게 살죠?
여기까지.
안녕
