[Infra Ops] WEB/WAS/DB 망 분리와 이중화 구조 설계

망 분리는 보안 요구사항처럼 느껴지지만, 실제로는 침해 범위를 제한하기 위한 인프라 설계 원칙입니다. Web 서버가 뚫렸을 때 DB까지 직선 경로가 있다면 단 한 번의 침해로 전체 데이터가 노출되지만, 구간 사이에 방화벽이 있으면 피해가 그 계층에서 멈춥니다. 이 구조를 이해해야 신규 서버 구성 요청을 받을 때 어느 구간에 어떤 방화벽 정책을 요청해야 하는지 판단할 수 있습니다.

확대

Web 서버가 해킹됐는데 DB 서버까지 접근이 됐다는 보고가 왔습니다. 망 분리 없이 모든 서버가 같은 네트워크에 있었기 때문입니다. 이 한 번의 침해로 고객 전체 데이터가 노출됐습니다. DMZ에 있는 Web 서버가 뚫리더라도 내부망 WAS나 DB망까지 이동할 수 없도록 구간을 나누는 것이 피해를 한 계층으로 제한하는 방법입니다.

서비스 인프라는 외부 노출 정도에 따라 세 구간으로 분리합니다.

DMZ (Demilitarized Zone, 비무장지대)

인터넷에서 직접 접근이 허용되는 구간입니다. Nginx, Apache 같은 Web 서버가 위치합니다. 방화벽은 외부에서 80/443 포트만 허용하고 나머지는 전부 차단합니다. DMZ 서버가 뚫려도 내부망에는 바로 접근할 수 없도록 구간 간 방화벽이 존재합니다.

내부망 (Internal Network)

WAS 서버가 위치하는 구간입니다. 외부 인터넷에서 직접 접근할 수 없습니다. Web 서버(DMZ)가 8080 포트로 WAS에 요청을 전달하는 것만 허용합니다. 개발자나 운영자의 직접 접근도 Bastion Host(점프 서버)를 경유해야 합니다.

DB망 (Database Network)

가장 폐쇄적인 구간입니다. WAS 서버에서 DB 포트(MySQL 3306, PostgreSQL 5432, Oracle 1521)로의 접근만 허용합니다. Web 서버에서 DB망으로의 직접 통신은 차단됩니다.

구간별 방화벽 허용 정책 예시:

실무 원칙 — 포트 오픈 최소화:

방화벽 오픈 요청이 들어오면 "왜 필요한가?"를 반드시 확인합니다. "일단 전체 오픈해주세요"는 절대 수용하지 않습니다. 실제 통신에 필요한 IP와 포트만, 방향을 지정해서 오픈합니다.

방화벽 오픈 요청 양식 예시:
- 출발지 IP: 10.10.1.11 (WAS01)
- 목적지 IP: 10.10.3.10 (DB Primary)
- 포트: TCP 3306
- 목적: WAS → DB MySQL 연결
- 신청자: 홍길동 (개발팀)
- 승인자: 팀장 김철수

앞 절에서 계층을 왜 나누는지(심층 방어)를 봤다면, 이제 요청 하나가 그 세 계층을 어떻게 통과하고 역순으로 돌아오는지를 봅니다. 이 경로를 단계로 쥐고 있으면, 장애 알림이 왔을 때 "어느 계층 경계에서 막혔나"를 바로 좁힐 수 있습니다 — 경계마다 방화벽·타임아웃·커넥션 풀이라는 서로 다른 조절 지점이 있기 때문입니다.

[클라이언트]  주문 조회 요청 (HTTPS)
   │
   ① DMZ · Web(Nginx) 수신 — TLS 종단, 정적이면 여기서 직접 응답
   │
   ② 경계1 · Nginx → 내부망 WAS(8080) 중계   (구간 방화벽 8080 허용 필요)
   │
   ③ WAS · 스레드 배정 → 비즈니스 로직 → DB 커넥션 풀에서 커넥션 1개 획득
   │
   ④ 경계2 · WAS → DB망 DB(3306) 쿼리 전송   (구간 방화벽 3306 허용 필요)
   │
   ⑤ DB · 쿼리 실행 → 결과를 WAS로 반환 → 커넥션 풀에 반납
   │
   ⑥ WAS가 결과를 HTML/JSON으로 조립 → Nginx → 클라이언트
   ▼
[클라이언트]  200 OK   (역순: DB → WAS → Web → 클라이언트)

각 단계와 경계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:

정리하면 "연결 자체가 안 된다"는 대개 경계(②의 8080, ④의 3306)의 방화벽·기동 문제이고, nc -zv DB_IP 3306으로 그 경계부터 확인합니다. 반면 "연결은 되는데 느리다·일부만 실패한다"는 대개 ③↔⑤의 커넥션 풀-DB 축입니다 — 슬로우 쿼리가 커넥션을 오래 물면(⑤) 풀이 마르고(③), 스레드가 대기하다 504로 번집니다. 계층을 나눈 이유가 여기서 드러납니다: 경계마다 독립된 방화벽·타임아웃·풀 크기라는 손잡이가 생겨, 장애를 한 계층에 가두고 계층별로 스케일·격리할 수 있습니다.

이중화 방식을 잘못 선택하면 "서버가 두 대인데 한 대가 고장나자 서비스가 전체 다운됐다"는 역설적인 상황이 생깁니다. 세션을 로컬 메모리에 두는 Stateful 서비스를 Active/Active로 구성하면 로드밸런서가 다른 서버로 요청을 보내는 순간 세션이 사라지고, 쓰기 일관성이 중요한 DB를 Active/Active로 묶으면 Split-Brain으로 데이터가 분기됩니다. 어떤 방식이 맞는지는 서비스가 Stateful인지 Stateless인지, 쓰기 충돌이 발생할 수 있는지에 따라 달라집니다.

확대

새벽에 DB 서버 한 대가 다운됐는데 서비스가 멈췄습니다. Standby 서버가 있었지만 systemctl enable을 빠뜨려 자동으로 뜨지 않았기 때문입니다. 이중화 구성 자체보다 "장애 시 어떤 흐름으로 전환되는가"를 이해하지 못하면, 이중화를 만들어놓고도 작동하지 않는 상황이 됩니다.

Active/Standby (장애 대기 방식)

평시에는 Active 서버 한 대가 모든 트래픽을 처리합니다. Standby 서버는 대기 상태로 Health Check만 수행합니다. Active 서버에 장애가 발생하면 VIP가 Standby로 이동(Failover)하고 Standby가 서비스를 인계받습니다.

• 장점: 구성 단순, 세션 동기화 부담 적음
• 단점: Standby 서버 리소스 낭비, Failover 중 수십 초의 순단 발생 가능
• 적합한 상황: DB 서버(Primary/Standby), 스케줄러, 상태 유지가 중요한 서비스

Active/Active (부하 분산 방식)

두 대 모두 실제 트래픽을 나눠서 처리합니다. 한 대가 장애 나면 남은 서버가 전체 트래픽을 받습니다.

• 장점: 리소스 효율적, 평시 처리 용량 2배
• 단점: 세션 동기화 필요(Stateful 서비스), 구성 복잡도 상승
• 적합한 상황: Stateless한 Web 서버, 로드밸런서 뒤의 WAS

세션 동기화 — Stateful vs Stateless:

WAS가 로그인 세션을 메모리에 저장하면(Stateful), 로드밸런서가 요청을 다른 WAS로 보낼 때 "로그아웃됐다"는 현상이 발생합니다. 이를 해결하는 방법은 두 가지입니다.

1. 세션 외부화: Redis 같은 중앙 세션 저장소에 세션을 저장 → Stateless WAS 구현
2. Sticky Session(세션 고정): 같은 사용자의 요청은 항상 같은 WAS로 보내도록 로드밸런서 설정

Split-Brain 문제:

Active/Standby 구성에서 두 노드 간 Heartbeat 통신이 끊기면, 두 노드가 모두 "내가 Active"라고 판단하는 Split-brain이 발생합니다. DB 같은 쓰기 서비스에서 Split-brain이 발생하면 데이터가 분기됩니다. STONITH(Shoot The Other Node In The Head) — 즉, 상대 노드를 강제로 끄는 메커니즘 — 로 이를 방지합니다.

Failover가 됐는데도 서비스가 살아나지 않는다면 VIP 개념을 모른 채 설정한 경우가 대부분입니다. 실제 서버 IP가 아닌 VIP로 접속하도록 구성해두면 Active 서버가 교체될 때 클라이언트나 상위 로드밸런서는 아무것도 바꾸지 않아도 됩니다. VIP가 없으면 DB 접속 문자열에 Primary 서버의 실제 IP를 하드코딩하게 되고, Failover 직후 새 Primary로 자동 전환이 되지 않아 수동 개입이 필요한 상황이 반복됩니다.

확대

Failover가 됐는데 서비스가 살아나지 않았습니다. 확인해보니 WAS 설정에 DB 서버 IP가 실제 IP로 하드코딩되어 있었고, Failover 후 새로운 Primary IP로 자동 전환이 안 됐습니다. VIP를 쓰면 실제 서버가 바뀌어도 접속 IP는 변하지 않습니다. 이 차이를 모르면 이중화 구성이 완성돼 있어도 장애 복구가 안 됩니다.

VIP란:

실제 서버 NIC에 할당된 IP가 아닌, 소프트웨어로 관리되는 가상 IP입니다. 클라이언트나 로드밸런서는 항상 VIP로 접속합니다. Active 서버가 바뀌면 VIP만 새 Active 서버로 이동합니다.

keepalived와 VRRP:

Linux 환경에서 VIP를 구현하는 가장 일반적인 방법입니다. keepalived는 VRRP(Virtual Router Redundancy Protocol) 프로토콜을 이용해 두 서버가 Heartbeat를 주고받으며 Master(Active)를 결정합니다.

# keepalived 상태 확인
systemctl status keepalived

# 현재 VIP가 어느 인터페이스에 붙어 있는지 확인
ip addr show | grep -A2 'eth0'
# Active 서버: inet 10.10.1.100/24 scope global secondary eth0:vip
# Standby 서버: eth0:vip 항목 없음

Failover 발생 시: Active 서버에서 keepalived 응답이 끊기면 Standby가 자신을 Master로 선언하고 VIP를 자신의 인터페이스로 가져옵니다. 이 전환은 보통 1~3초 내에 완료됩니다.

L4 로드밸런서 vs L7 로드밸런서:

Health Check:

로드밸런서는 주기적으로 서버에 요청을 보내 응답 여부를 확인합니다. 일정 횟수 이상 실패하면 해당 서버를 분산 대상에서 제외합니다.

# Nginx upstream health check 설정 예시
upstream was_pool {
    server 10.10.2.10:8080;
    server 10.10.2.11:8080;
}
# HAProxy에서는 'check' 옵션으로 Health Check 활성화
# server was01 10.10.2.10:8080 check inter 3s fall 3 rise 2

이론으로만 배운 3-Tier 구조는 실제 서버 목록과 IP 대역을 눈으로 보기 전까지 추상적으로 느껴집니다. was02가 다운됐을 때 나머지 3대에 어떻게 트래픽이 재분배되는지, db01 장애 시 db-vip가 db02로 이동하는 흐름이 실제로 어떻게 동작하는지를 구체적인 숫자와 함께 보면 운영 중 받는 장애 알림과 판단이 실제 서버 구성과 연결됩니다. 특히 어느 서버의 방화벽이 열려있어야 하는지를 파악하는 것이 운영 엔지니어의 핵심 역량입니다.

확대

이론과 달리 실제 서버 목록과 IP를 보면 이해가 달라집니다. was02가 다운됐을 때 나머지 3대에 트래픽이 어떻게 분산되는지, db01 장애 시 db-vip가 db02로 이동하는 흐름이 어떻게 되는지 — 구체적인 숫자와 함께 보면 추상적인 이중화 개념이 실제 운영 판단과 연결됩니다.

서버 목록:

트래픽 경로:

인터넷 클라이언트
  → web-vip (10.10.1.100:443)
  → Nginx (web01 또는 web02, Active/Active)
  → WAS 로드밸런서 (Nginx upstream, 4대 분산)
  → WAS 01~04 (Active/Active)
  → db-vip (10.10.3.100:3306)
  → MySQL Primary (db01, Active/Standby)

장애 시나리오별 서비스 영향:

앞에서 keepalived가 Heartbeat로 Master를 정하고, Heartbeat가 끊기면 Split-Brain이 난다고 했습니다. 그 판정 방식을 한 단계 들여다보면 왜 Split-Brain이 이중화의 가장 위험한 함정인지가 보입니다.

• VRRP의 판정 방식: 각 노드는 우선순위(priority)를 갖고, Master는 주기적으로 VRRP advertisement를 멀티캐스트(224.0.0.18, IP 프로토콜 112)로 보냅니다. Backup은 이 광고를 '들으며' Master가 살아있다고 믿습니다. 광고가 일정 시간(대개 광고 주기의 3배) 안 들리면 Backup은 자신을 Master로 승격하고 VIP를 가져간 뒤, GARP(gratuitous ARP)를 뿌려 스위치의 MAC 테이블을 새 위치로 갱신합니다.
• 핵심 함정: 이 판정은 오로지 '광고가 들리는가'에만 의존합니다. 그런데 '광고가 안 들린다'는 두 가지를 구분하지 못합니다 — 상대가 정말 죽은 것과, 둘 사이 하트비트 경로만 끊긴 것. 후자라면 두 노드 모두 상대가 죽었다고 믿고 둘 다 Master가 되어 VIP를 동시에 보유합니다. 이것이 Split-Brain입니다. '나는 네가 안 들려' 는 '너는 죽었다' 와 결코 같지 않습니다.
• 그래서 설계에서 지켜야 할 것: ① 하트비트 경로를 서비스 트래픽 경로와 물리적으로 분리·이중화해 한 링크가 끊겨도 다른 경로로 서로를 확인. ② 노드 사이의 방화벽·보안그룹이 VRRP(멀티캐스트·프로토콜 112, 또는 unicast_peer 설정 시 그 경로)를 반드시 허용. ③ virtual_router_id를 같은 세그먼트 안에서 유일하게 — 다른 keepalived 쌍과 겹치면 서로를 같은 그룹으로 오인. ④ 쓰기 DB에는 STONITH/펜싱을 걸어 Split-Brain 순간 한 노드를 강제로 격리해 진짜 하나만 살아남게 함.

정리하면 이중화에서 '서비스 경로'만큼 중요한 것이 '하트비트 경로'입니다. 서비스는 멀쩡한데 노드끼리 서로를 확인하는 길만 막혀도, 이중화가 오히려 장애의 원인이 됩니다.