Taeyoung Kim

Platform

클라우드 네트워크 주소 설계와 라우팅 기초

2진수, CIDR, 서브넷 마스크, 게이트웨이, VNet, Load Balancer 개념을 클라우드 네트워크 설계 흐름으로 연결해 정리합니다.

클라우드 네트워크 주소 설계와 라우팅 기초

클라우드 네트워크를 처음 볼 때는 VNet, Subnet, NSG, Route Table, Gateway, Load Balancer 같은 리소스 이름이 먼저 눈에 들어온다. 하지만 장애를 따라가거나 구조를 설계하다 보면 결국 IP 주소와 서브넷 계산으로 돌아온다. 어떤 리소스가 같은 네트워크에 있는지, 어느 요청이 게이트웨이를 넘어가야 하는지, 로드밸런서가 어느 서브넷의 어떤 백엔드로 트래픽을 보내는지 판단하려면 주소 체계를 읽을 수 있어야 한다.

네트워크 기초를 따로 공부할 때는 10진수와 2진수 변환, 서브넷 마스크, TCP/IP, 게이트웨이가 각각 다른 주제처럼 보인다. 클라우드에서는 이 개념들이 VNet 주소 공간, Subnet 분리, 라우팅, 보안 규칙, 고가용성 구성으로 이어진다. 그래서 이 글은 계산 자체보다, 주소 설계가 운영 구조에 어떤 영향을 주는지 중심으로 정리한다.

IP 주소는 사람이 읽는 10진수와 장비가 계산하는 2진수 사이에 있다

IPv4 주소는 보통 192.168.1.10처럼 점으로 나뉜 10진수 네 개로 표현한다. 각 숫자는 0부터 255까지 가능하고, 내부적으로는 8비트 2진수다.

192      .168      .1        .10
11000000 .10101000 .00000001 .00001010

10진수를 2진수로 바꿀 때는 2로 나누며 나머지를 기록하고, 마지막에 거꾸로 읽는다. 예를 들어 10은 1010이고, 8비트로 맞추면 00001010이다.

10 / 2 = 5 ... 0
5  / 2 = 2 ... 1
2  / 2 = 1 ... 0
1  / 2 = 0 ... 1

reverse: 1010
8-bit:   00001010

이 계산이 중요한 이유는 서브넷 마스크가 비트 단위로 네트워크와 호스트 영역을 나누기 때문이다. 클라우드 콘솔에서는 CIDR 표기만 입력하지만, 실제로는 비트 경계가 주소 범위를 결정한다.

CIDR은 네트워크 경계를 짧게 표현한다

10.0.0.0/16에서 /16은 앞의 16비트가 네트워크 영역이라는 뜻이다. 나머지 16비트는 호스트 영역이다. 10.0.1.0/24는 앞의 24비트가 네트워크 영역이고, 마지막 8비트가 호스트 영역이다.

10.0.1.0/24

network bits: 24
host bits:     8
addresses:   256
usable idea: 10.0.1.1 - 10.0.1.254

클라우드에서는 제공자마다 예약 주소가 있다. Azure는 각 서브넷에서 일부 IP를 예약한다. 그래서 이론상 주소 수와 실제 사용할 수 있는 주소 수가 다를 수 있다. 그래도 CIDR 감각이 있으면 서브넷을 너무 작게 만들어 나중에 확장하지 못하는 실수를 줄일 수 있다.

VNet: 10.16.0.0/16

10.16.1.0/24  gateway subnet
10.16.2.0/24  web subnet
10.16.3.0/24  api subnet
10.16.4.0/24  data subnet
10.16.5.0/27  bastion subnet

주소를 나누는 기준은 보기 좋은 이름이 아니라 역할이다. 외부 진입점, 웹/API 계층, 데이터 계층, 관리 접속 계층은 서로 다른 통신 규칙을 가진다. 역할이 다른 리소스를 같은 서브넷에 넣으면 NSG와 Route Table도 거칠어진다.

서브넷 마스크는 “같은 네트워크인가”를 판단한다

서브넷 마스크는 IP 주소 중 어디까지가 네트워크 영역인지 알려준다. 255.255.255.0은 2진수로 앞의 24비트가 1이고, CIDR로는 /24다.

IP:      192.168.1.10
Mask:    255.255.255.0
CIDR:    /24
Network: 192.168.1.0

두 IP가 같은 서브넷에 있으면 직접 통신할 수 있고, 다른 서브넷에 있으면 게이트웨이를 거쳐야 한다.

192.168.1.10/24 and 192.168.1.20/24
same network: 192.168.1.0/24

192.168.1.10/24 and 192.168.2.20/24
different network
gateway required

서브네팅은 큰 네트워크를 작은 네트워크로 나누는 작업이다. 192.168.1.0/24를 /26으로 나누면 네 개의 서브넷이 생긴다.

192.168.1.0/26     192.168.1.0   - 192.168.1.63
192.168.1.64/26    192.168.1.64  - 192.168.1.127
192.168.1.128/26   192.168.1.128 - 192.168.1.191
192.168.1.192/26   192.168.1.192 - 192.168.1.255

클라우드에서는 이 계산이 곧 리소스 배치 계획이 된다. 예를 들어 Azure Application Gateway는 전용 서브넷에 두고, 백엔드 VMSS는 다른 서브넷에 둔다. Bastion은 AzureBastionSubnet이라는 전용 이름과 충분한 주소 공간을 요구한다. Private Endpoint를 많이 만들 계획이라면 data subnet에 주소 여유가 필요하다.

게이트웨이는 다른 네트워크로 나가는 관문이다

게이트웨이는 서로 다른 네트워크 사이의 통신을 이어주는 관문이다. 같은 서브넷 안에서는 직접 통신할 수 있지만, 다른 네트워크로 나가려면 라우팅 테이블의 next hop이 필요하다.

client: 10.16.2.4/24
target: 10.16.3.4/24

source subnet: 10.16.2.0/24
target subnet: 10.16.3.0/24
next hop: virtual network router

가정용 네트워크에서는 기본 게이트웨이가 공유기인 경우가 많다. 클라우드 VNet에서는 Azure가 가상 라우터 역할을 하고, 필요에 따라 VPN Gateway, ExpressRoute Gateway, NAT Gateway, Azure Firewall, 사용자 정의 Route Table이 경로를 바꾼다.

Gateway라는 이름이 붙은 리소스도 여러 종류가 있다. VPN Gateway는 온프레미스와 VNet을 연결한다. Application Gateway는 L7 HTTP/HTTPS 진입점이다. NAT Gateway는 프라이빗 서브넷의 아웃바운드 인터넷 경로를 제공한다. 이름은 비슷하지만 역할이 다르다.

VPN Gateway          network-to-network private connectivity
Application Gateway  HTTP/HTTPS layer 7 entry point
NAT Gateway          outbound internet path for private subnet
Load Balancer        layer 4 traffic distribution

이 구분을 놓치면 “게이트웨이를 만들었다”는 말만 남고 실제 트래픽 경로를 설명하기 어려워진다.

Load Balancer와 Application Gateway는 계층이 다르다

Azure Load Balancer는 L4 계층에서 TCP/UDP 트래픽을 분산한다. 내부 Load Balancer를 만들면 VNet 안에서만 접근 가능한 프라이빗 IP를 진입점으로 쓸 수 있다.

Internal Load Balancer
- frontend IP: 10.16.3.99
- backend pool: 10.16.3.4, 10.16.3.5
- rule: TCP 80 -> TCP 80
- probe: HTTP /

Application Gateway는 HTTP/HTTPS를 이해하는 L7 진입점이다. Host header, path, TLS, WAF 같은 기능과 연결된다. 웹 서비스에서 외부 사용자의 첫 진입점으로 적합하다.

Application Gateway
- public frontend IP
- listener: HTTP/HTTPS 80/443
- backend pool: web VMs or VMSS
- routing rule: path/host based
- optional WAF

두 리소스는 서로 대체재가 아니라 다른 계층의 도구다. 외부 HTTP 요청은 Application Gateway에서 받고, 내부 API 계층에는 Internal Load Balancer를 둘 수 있다.

이 구조에서 NSG 규칙은 훨씬 읽기 쉬워진다. 인터넷에서 web VM으로 직접 들어오는 트래픽은 막고, Application Gateway에서 web subnet으로 가는 트래픽만 허용한다. web subnet에서 api subnet으로는 Internal Load Balancer 주소를 통해 필요한 포트만 허용한다.

VNet은 논리적 네트워크이자 보안 경계다

VNet은 클라우드 안에서 만드는 논리적 네트워크다. VM, Database, Web App, Private Endpoint, Load Balancer 같은 리소스가 이 네트워크 경계 안에서 통신한다. 기본적으로 VNet은 서로 격리되어 있고, 필요하면 Peering, VPN, ExpressRoute로 연결한다.

VNet responsibilities
- IP address space
- subnet segmentation
- private IP communication
- DNS integration
- NSG and route table association
- peering or hybrid connectivity

VNet 설계에서 중요한 것은 처음부터 모든 것을 세분화하는 것이 아니라, 바뀌기 어려운 경계를 먼저 잡는 것이다.

Recommended separation
- ingress subnet
- application subnet
- data/private endpoint subnet
- management subnet
- optional firewall subnet

이렇게 나누면 보안 규칙과 라우팅이 자연스럽게 따라온다. 반대로 모든 리소스를 하나의 서브넷에 넣으면 나중에 특정 계층만 잠그거나 특정 경로만 방화벽으로 보내기가 어려워진다.

NSG 규칙은 주소 설계의 결과다

NSG(Network Security Group)는 “포트를 열어주는 설정”처럼 보이지만, 실제로는 네트워크 신뢰 경계를 표현하는 장치다. 같은 443 포트라도 인터넷에서 들어오는 443인지, Application Gateway에서 web subnet으로 가는 443인지, web subnet에서 api subnet으로 가는 443인지에 따라 의미가 다르다.

NSG 규칙은 보통 다음 요소로 읽는다.

priority
direction
source
source port
destination
destination port
protocol
action

예를 들어 외부 사용자는 Application Gateway까지만 접근하고, web subnet은 Application Gateway에서만 접근 가능하게 만들 수 있다.

allow
  source: Internet
  destination: ApplicationGatewaySubnet
  port: 443

allow
  source: ApplicationGatewaySubnet
  destination: WebSubnet
  port: 443

deny
  source: Internet
  destination: WebSubnet
  port: any

API 계층은 더 좁아진다. 사용자가 API VM으로 직접 접근하지 않고, web subnet이나 internal load balancer를 통해서만 접근하도록 구성한다.

allow
  source: WebSubnet
  destination: ApiSubnet
  port: 8080

allow
  source: ApiSubnet
  destination: DataSubnet
  port: 5432

deny
  source: Internet
  destination: ApiSubnet, DataSubnet
  port: any

Application Security Group(ASG)을 사용하면 IP 범위보다 애플리케이션 역할 중심으로 규칙을 읽을 수 있다.

asg-web
  -> asg-api : tcp/8080

asg-api
  -> asg-db : tcp/5432

주소 설계가 정리되어 있으면 NSG도 읽기 쉬워진다. 반대로 주소가 뒤섞여 있으면 NSG 규칙은 점점 예외 목록이 된다. 예외 목록이 늘어나면 장애 분석과 보안 검토가 모두 어려워진다.

Private Endpoint는 공용 진입점을 줄인다

Storage Account, SQL Database, Key Vault 같은 PaaS 리소스는 기본적으로 공용 엔드포인트를 가진다. 실습 단계에서는 편하지만, 운영에서는 공용 인터넷 경로를 줄이고 VNet 내부에서 접근하도록 만드는 구성이 필요할 수 있다. 이때 Private Endpoint가 사용된다.

Private Endpoint를 붙이면 애플리케이션은 공용 IP가 아니라 VNet 내부 private IP로 PaaS 리소스에 접근한다. 이때 DNS가 중요해진다. 같은 mystorage.blob.core.windows.net을 조회하더라도 내부 네트워크에서는 private endpoint IP로 해석되어야 한다.

public path
  app -> public internet -> storage public endpoint

private endpoint path
  app -> VNet private IP -> storage private endpoint

Private Endpoint는 보안을 강화하지만 운영 복잡도도 함께 늘린다. Private DNS Zone 연결, VNet peering 간 DNS 해석, 방화벽 예외, local 개발 환경 접근 방식을 함께 설계해야 한다.

VNet Peering과 라우팅 경계

서비스가 커지면 하나의 VNet에 모든 리소스를 넣기보다 hub-spoke 구조를 검토하게 된다. hub VNet에는 방화벽, Bastion, VPN Gateway, 공용 DNS/모니터링 같은 공통 리소스를 두고, spoke VNet에는 워크로드별 애플리케이션을 둔다.

Peering은 두 VNet을 사설망처럼 연결하지만, 모든 문제가 자동으로 해결되는 것은 아니다. 주소 공간이 겹치면 peering 자체가 어렵고, 라우팅 경로가 명확하지 않으면 트래픽이 의도하지 않은 경로로 흐를 수 있다. 또한 보안 규칙은 여전히 각 subnet의 NSG와 route table에서 별도로 관리해야 한다.

avoid overlap
  hub:    10.0.0.0/16
  spoke1: 10.10.0.0/16
  spoke2: 10.20.0.0/16

problem
  spoke1: 10.10.0.0/16
  spoke2: 10.10.0.0/16

주소 중복은 나중에 VPN, ExpressRoute, M&A, 외부 파트너 연동에서 큰 제약이 된다. 그래서 작은 프로젝트라도 10.0.0.0/16 전체를 무심코 쓰기보다, 앞으로 연결될 네트워크를 고려해 주소 공간을 예약하는 습관이 필요하다.

Traffic Manager는 DNS 기반 라우팅이다

Azure Traffic Manager는 L7 reverse proxy가 아니라 DNS 기반 트래픽 라우팅 서비스다. 이 차이를 이해해야 장애 분석이 쉬워진다. 사용자가 도메인을 조회하면 Traffic Manager가 정책에 맞는 엔드포인트를 DNS 응답으로 돌려주고, 이후 실제 HTTP 요청은 해당 엔드포인트로 직접 간다.

라우팅 방식에 따라 운영 목적이 달라진다.

Priority
  primary/secondary failover

Weighted
  gradual rollout or traffic split

Performance
  route to low-latency region

Geographic
  route by user region

MultiValue
  return multiple healthy endpoints

Subnet
  route by client IP range

Traffic Manager를 사용할 때는 DNS TTL을 함께 봐야 한다. 장애가 발생해도 클라이언트나 ISP DNS 캐시에 이전 응답이 남아 있으면 전환이 즉시 보이지 않을 수 있다. 그래서 global failover를 설계할 때는 health probe, TTL, 애플리케이션 세션, 데이터 복제 지연을 같이 고려해야 한다.

주소 설계는 장애 분석 시간을 줄인다

주소 체계가 일관되면 장애 상황에서 판단이 빨라진다. 10.16.1.0/24가 gateway, 10.16.2.0/24가 web, 10.16.3.0/24가 api라는 규칙이 있으면 로그에 찍힌 IP만 봐도 어느 계층인지 짐작할 수 있다.

10.16.1.12 -> Application Gateway instance
10.16.2.4  -> web VM
10.16.3.5  -> api VM
10.16.3.99 -> internal load balancer

장애를 좁혀갈 때는 다음 순서가 도움이 된다.

1. DNS resolves to the expected entry point?
2. Entry point health probe is green?
3. NSG allows the source and destination?
4. Route table sends traffic to the intended next hop?
5. Backend process listens on the expected port?
6. Application logs show request arrival?

이 순서는 도구보다 사고방식에 가깝다. curl, dig, nslookup, ss, NSG Flow Logs, Load Balancer probe, Application Gateway backend health가 모두 같은 질문을 다른 위치에서 확인한다.

정리

네트워크 기초는 클라우드에서 추상화되어 사라지는 것이 아니라, 더 많은 리소스 이름 뒤에 숨어 있을 뿐이다. 10진수와 2진수는 IP 주소의 비트 경계를 이해하게 해주고, CIDR과 서브넷 마스크는 같은 네트워크인지 다른 네트워크인지 판단하게 해준다. 게이트웨이는 다른 네트워크로 나가는 경로이고, Load Balancer와 Application Gateway는 서로 다른 계층에서 트래픽을 분산한다.

VNet과 Subnet을 설계할 때는 주소를 예쁘게 나누는 것보다 역할과 보안 경계를 나누는 것이 중요하다. 사용자의 진입점, 애플리케이션 계층, 데이터 계층, 관리 접속 경로를 분리하면 NSG, Route Table, Bastion, Private Endpoint, Load Balancer 구성이 자연스럽게 따라온다. 결국 좋은 네트워크 설계는 장애가 났을 때 “이 트래픽은 어디서 어디로 가야 하는가”를 빠르게 설명할 수 있는 구조다.

이 글의 무단 복제, 재배포, 자동 수집을 허용하지 않습니다. 인용이 필요한 경우 출처와 원문 링크를 함께 남겨주세요.