클라우드 네트워크 설계 · CIDR 과 주소 계획 · 이론

/24 가 왜 254대인가

LabHub 에서 이어서 보기

한 줄 요약

CIDR 은 IP 주소의 앞쪽 몇 비트가 네트워크인지를 적는 표기입니다.
이 숫자 하나가 그 네트워크에 몇 대가 들어갈 수 있는지를 정합니다.

왜 이게 필요했나

VPC 를 만들 때 10.0.0.0/16 을 넣으라는 안내를 그대로 따라 하면 당장은
됩니다. 문제는 2년 뒤입니다.

다른 팀 VPC 와 주소가 겹쳐 피어링이 안 된다
온프레미스 대역과 겹쳐 VPN 연결이 안 된다
인수한 회사와 겹쳐 통합이 막힌다

주소 대역은 나중에 못 바꿉니다. 자원을 전부 새로 만들어 옮겨야 합니다.
그래서 처음에 계획을 세우는 값이 다른 어떤 결정보다 큽니다.

비트로 세는 법

IPv4 주소는 32비트입니다. /24 는 앞 24비트가 네트워크라는 뜻이고,
남은 8비트가 호스트 자리입니다.

10.0.1.0/24└─ 네트워크 24비트 ─┘└ 호스트 8비트 ┘호스트 자리 = 32 − 24 = 8비트  →  2^8 = 256개 주소

256개인데 왜 254대일까요. 첫 주소는 네트워크 주소, 마지막은
브로드캐스트 주소라 쓸 수 없습니다. 그래서 254.

클라우드는 여기서 더 뺍니다. AWS 는 서브넷마다 5개를 예약합니다
(네트워크, VPC 라우터, DNS, 예비, 브로드캐스트). 그래서 /24 서브넷의
실제 가용 IP 는 251개입니다. 이걸 모르고 250대를 계획하면 아슬아슬해집니다.

| CIDR | 전체 주소 | AWS 가용 |
| --- | --- | --- |
| /28 | 16 | 11 |
| /27 | 32 | 27 |
| /26 | 64 | 59 |
| /24 | 256 | 251 |
| /22 | 1,024 | 1,019 |
| /20 | 4,096 | 4,091 |
| /16 | 65,536 | — (VPC 최대) |

외우는 요령: /24 가 256이고, 프리픽스가 1 줄어들 때마다 두 배입니다.
/23 = 512, /22 = 1,024. 반대로 1 늘면 절반입니다.

사설 대역

RFC 1918 이 정한 세 구간만 사내에서 씁니다.

| 대역 | 크기 | 흔한 용도 |
| --- | --- | --- |
| 10.0.0.0/8 | 1,677만 | 큰 조직. 클라우드 VPC 대부분 |
| 172.16.0.0/12 | 104만 | 도커 기본 브리지가 여기 |
| 192.168.0.0/16 | 6.5만 | 가정용 공유기 |

172.17.0.0/16 이 도커의 기본 브리지 대역이라는 사실이 실무에서 자주
사고를 냅니다 — 사내망을 172.17.x.x 로 쓰면 컨테이너 안에서 그 주소로
못 갑니다.

계획을 세우는 순서

1. 전체 예산을 크게 잡는다 — 조직 전체에 10.0.0.0/8 을 배정해 두고
시작합니다. 주소는 공짜입니다. 아끼는 것이 이득이 아닙니다.
2. 환경별로 자른다 — 운영 10.0.0.0/12, 스테이징 10.16.0.0/12,
개발 10.32.0.0/12 처럼 겹치지 않게.
3. 리전별로 자른다 — 리전마다 다른 대역. 나중에 리전 간 연결이 쉬워집니다.
4. VPC 는 넉넉하게 — /16 이 기본값처럼 쓰입니다. 6.5만 주소면 대개 충분합니다.
5. 서브넷은 용도별로 — 아래에서 다룹니다.
6. 온프레미스·파트너 대역을 문서에 적는다 — 나중에 연결할 대역과 겹치면 안 됩니다.

겹치면 무슨 일이 생기나

두 VPC 가 같은 10.0.0.0/16 을 쓰면 피어링이 불가능합니다. 라우팅
테이블이 같은 목적지를 두 곳으로 보낼 수 없기 때문입니다. 해결책은 한쪽을
새 대역으로 옮기는 것뿐이고, 그건 사실상 재구축입니다.

그래서 조직에 IP 대역 대장이 있어야 합니다. 스프레드시트 한 장이면
충분하고, 없으면 반드시 사고가 납니다.

현장에서 만나는 모습

두 팀이 각자 10.0.0.0/16 으로 VPC 를 만들었고, 1년 뒤 두 서비스를 붙여야 할 때 피어링이 거부됐습니다. 한쪽을 새 대역으로 재구축했습니다.
사내망을 172.17.x.x 로 쓰는 회사에서 컨테이너 안에서만 사내 API 가 안 됐습니다. 도커 기본 브리지와 겹친 것이었고, 증상이 컨테이너에서만 나타나 원인을 찾는 데 며칠이 걸렸습니다.
서브넷을 /28 로 잘게 잘라 두었다가 파드가 늘면서 IP 가 말랐습니다. 16개처럼 보였지만 실제로 쓸 수 있는 것은 11개였습니다.
인수한 회사와 대역이 겹쳐 시스템 통합이 반년 밀렸습니다. 스프레드시트 한 장만 있었으면 처음부터 피했을 일입니다.

다음에 볼 것

VPC 안을 서브넷으로 쪼개고, 무엇을 어디에 놓을지 정합니다.