클라우드와 컨테이너 네트워크
현대 서비스는 대부분 클라우드 위에서 운영됩니다. AWS, GCP, Azure 같은 클라우드 환경에서 네트워크를 구성하는 방법은 물리 네트워크와 개념은 같지만, 가상화라는 추상화 계층이 추가됩니다. Docker와 Kubernetes 같은 컨테이너 환경은 또 다른 네트워크 추상화를 제공합니다.
AWS VPC 기본 구성
┌─────────────────── VPC: 10.0.0.0/16 ──────────────────────┐
│ │
│ ┌─── AZ-a ────────────┐ ┌─── AZ-b ────────────┐ │
│ │ │ │ │ │
│ │ 퍼블릭 서브넷 │ │ 퍼블릭 서브넷 │ │
│ │ 10.0.1.0/24 │ │ 10.0.2.0/24 │ │
│ │ ┌──────┐ ┌──────┐ │ │ ┌──────┐ │ │
│ │ │ Web │ │ NAT │ │ │ │ Web │ │ │
│ │ │ S1 │ │ GW │ │ │ │ S2 │ │ │
│ │ └──────┘ └──────┘ │ │ └──────┘ │ │
│ │ │ │ │ │
│ │ 프라이빗 서브넷 │ │ 프라이빗 서브넷 │ │
│ │ 10.0.3.0/24 │ │ 10.0.4.0/24 │ │
│ │ ┌──────┐ ┌──────┐ │ │ ┌──────┐ │ │
│ │ │ API │ │ DB │ │ │ │ API │ │ │
│ │ │ S1 │ │ 주 │ │ │ │ S2 │ │ │
│ │ └──────┘ └──────┘ │ │ └──────┘ │ │
│ └─────────────────────┘ └─────────────────────┘ │
│ │
│ [ 인터넷 게이트웨이 ] │
└─────────────────────────┬─────────────────────────────────┘
│
인터넷VPC를 생성할 때 CIDR 블록을 지정합니다. 10.0.0.0/16이라면 65,536개의 IP 주소를 사용할 수 있는 가상 네트워크가 만들어집니다.
VPC 안에 서브넷을 만듭니다. 퍼블릭 서브넷은 인터넷에서 직접 접근할 수 있는 영역이고, 프라이빗 서브넷은 인터넷에서 직접 접근할 수 없는 영역입니다. 웹 서버는 퍼블릭에, 데이터베이스는 프라이빗에 배치하는 것이 일반적입니다.
인터넷 게이트웨이(IGW)는 VPC를 인터넷에 연결합니다. 퍼블릭 서브넷의 라우팅 테이블에 0.0.0.0/0 → IGW를 추가하면, 해당 서브넷의 인스턴스가 인터넷과 통신할 수 있습니다.
NAT 게이트웨이는 프라이빗 서브넷의 인스턴스가 인터넷으로 나가는 트래픽(소프트웨어 업데이트 다운로드 등)을 허용하되, 인터넷에서 프라이빗 인스턴스로 들어오는 연결은 차단합니다.
보안 그룹과 NACL
인터넷
│
┌────┴────┐
│ NACL │ ← 서브넷 수준, 상태 비저장(stateless)
│ (번호순 │ 인바운드/아웃바운드 각각 설정
│ 평가) │
└────┬────┘
│
┌────┴────┐
│ 보안 │ ← 인스턴스 수준, 상태 기반(stateful)
│ 그룹 │ 허용 규칙만 (거부 불가)
│ │ 인바운드 허용 → 응답 자동 허용
└────┬────┘
│
┌────┴────┐
│ EC2 │
│ 인스턴스│
└─────────┘| 비교 | 보안 그룹 | NACL |
|---|---|---|
| 적용 대상 | 인스턴스(ENI) | 서브넷 |
| 상태 | Stateful | Stateless |
| 규칙 유형 | 허용만 | 허용 + 거부 |
| 규칙 평가 | 모든 규칙 적용 | 번호 순서대로 |
| 기본값 | 아웃바운드 전체 허용 | 모든 트래픽 허용 |
일반적으로 보안 그룹으로 주요 접근 제어를 하고, NACL은 서브넷 레벨의 추가 방어벽으로 사용합니다.
Docker 네트워크
Docker 컨테이너는 격리된 네트워크 네임스페이스를 가집니다.
┌──────────── 호스트 ─────────────────────┐
│ │
│ 호스트 eth0: 192.168.1.100 │
│ │ │
│ ┌──────┴──────────┐ │
│ │ docker0 │ 가상 브리지 │
│ │ 172.17.0.1 │ (NAT) │
│ └──┬──────────┬───┘ │
│ │ │ │
│ ┌──┴──┐ ┌─┴───┐ │
│ │veth │ │veth │ │
│ └──┬──┘ └──┬──┘ │
│ ┌──┴──────┐ ┌──┴──────┐ │
│ │컨테이너A│ │컨테이너B│ │
│ │172.17. │ │172.17. │ │
│ │ 0.2 │ │ 0.3 │ │
│ │ :80 │ │ :3000 │ │
│ └─────────┘ └─────────┘ │
│ │
│ -p 8080:80 → 호스트 8080 → 컨테이너A:80│
└─────────────────────────────────────────┘| 드라이버 | 설명 | 사용 시나리오 |
|---|---|---|
| bridge | 가상 브리지+NAT, 기본값 | 단일 호스트 컨테이너 간 통신 |
| host | 호스트 네트워크 직접 사용 | 성능 중요, 포트 충돌 감수 |
| none | 네트워크 비활성화 | 배치 처리, 보안 격리 |
| overlay | 멀티 호스트 가상 네트워크 | Swarm, 멀티 노드 클러스터 |
| macvlan | 컨테이너에 MAC 주소 부여 | 레거시 시스템 연동 |
Kubernetes 네트워크 모델
Kubernetes는 Docker보다 한 단계 높은 추상화를 제공합니다. 핵심 네트워크 규칙은 세 가지입니다.
- 모든 파드(Pod)는 고유한 IP 주소를 가집니다.
- 모든 파드는 NAT 없이 다른 파드와 직접 통신할 수 있습니다.
- 노드의 에이전트(kubelet 등)는 해당 노드의 모든 파드와 통신할 수 있습니다.
┌────────── Kubernetes 클러스터 ──────────┐
│ │
│ [Ingress Controller] │
│ api.example.com/api → API Service │
│ example.com → Web Service │
│ │ │
│ ┌──────┴──────┐ │
│ │ Service │ │
│ │ ClusterIP: │ │
│ │10.96.0.100 │ │
│ │ :80 │ │
│ └──┬──────┬───┘ │
│ │ │ kube-proxy가 iptables로│
│ ┌──┴──┐ ┌─┴──┐ 부하 분산 │
│ │PodA │ │PodB│ │
│ │10. │ │10. │ CNI 플러그인이 관리 │
│ │244. │ │244.│ (Calico, Cilium 등) │
│ │1.5 │ │2.3 │ │
│ └─────┘ └────┘ │
└─────────────────────────────────────────┘이 규칙을 구현하는 것이 CNI(Container Network Interface) 플러그인입니다.
| CNI 플러그인 | 특징 | 적합한 사용처 |
|---|---|---|
| Calico | BGP 기반, NetworkPolicy 지원 | 대규모 클러스터 |
| Flannel | 단순, VXLAN overlay | 소규모, 학습용 |
| Cilium | eBPF 기반, 관측성 | 보안, 관측 중시 |
| Weave | 암호화 내장 | 멀티 클라우드 |
Service는 여러 파드를 하나의 가상 IP(ClusterIP)로 묶습니다. 파드가 생성되고 삭제될 때마다 IP가 바뀌지만, Service의 ClusterIP는 변하지 않습니다.
| Service 타입 | 접근 범위 | 사용 사례 |
|---|---|---|
| ClusterIP | 클러스터 내부만 | 내부 마이크로서비스 |
| NodePort | 노드IP:포트로 외부 접근 | 개발, 테스트 |
| LoadBalancer | 클라우드 LB 자동 생성 | 프로덕션 외부 서비스 |
| ExternalName | DNS CNAME 매핑 | 외부 서비스 참조 |
Ingress는 외부 트래픽을 클러스터 내부 서비스로 라우팅합니다. L7 로드 밸런서 역할을 하며, 도메인과 URL 경로에 따라 다른 서비스로 트래픽을 분배합니다.
결국 VPC의 서브넷, Docker의 브리지 네트워크, Kubernetes의 Service 모두 앞서 배운 네트워크 기본 개념 — IP 주소, 서브넷, NAT, 라우팅, 로드 밸런싱 — 의 가상화된 적용입니다.
다음 장에서는 네트워크 문제를 체계적으로 진단하는 트러블슈팅 방법론과 도구를 다루겠습니다.