클러스터링으로 고가용성·부하분산·병렬 처리를 설계하는 법
클러스터링의 유형과 Heartbeat, Quorum, STONITH, 공유 스토리지, Failover 설계 원칙을 정리한다.
2026-08-14 · 최초 발행 2026-01-16
여러 노드를 하나의 서비스로 다루는 방식
클러스터링은 둘 이상의 독립적인 컴퓨터를 고속 네트워크로 연결해 하나의 시스템처럼 운영하는 방식이다. 외부에서는 통합된 서비스로 보이지만, 내부에서는 각 노드가 역할을 나누고 서로 상태를 확인하며 작업을 처리한다.
이 구조는 단일 시스템의 성능 한계를 넘는 데만 쓰이지 않는다. 장애가 발생했을 때 서비스를 계속 제공하고, 증가하는 워크로드에 맞춰 노드를 추가하는 기반이 되기도 한다.
클러스터에는 노드, 노드 간 통신을 맡는 인터커넥트, 상태 감시와 Failover를 수행하는 클러스터 관리자, 공유 스토리지, 그리고 클라이언트 접속을 위한 가상 IP(VIP)가 주로 포함된다.
| 구성 요소 | 설명 | 역할 |
|---|---|---|
| 노드(Node) | 클러스터를 구성하는 개별 서버 | 실제 서비스 처리 |
| 클러스터 인터커넥트 | 노드 간 통신 네트워크 | Heartbeat, 데이터 동기화 |
| 클러스터 관리자 | 클러스터 제어 소프트웨어 | 노드 상태 감시, Failover 관리 |
| 공유 스토리지 | 노드 간 공유 디스크 | 데이터 일관성 유지 |
| 가상 IP(VIP) | 클라이언트 접속용 IP | 서비스 연속성 보장 |
서비스 목표에 따라 달라지는 클러스터 형태
장애 시 서비스를 넘겨받는 HA 클러스터
HA(High Availability) 클러스터의 목적은 서비스 중단 시간을 최소화하는 것이다. Active-Standby 또는 Active-Active로 구성하며, 장애가 감지되면 서비스 리소스를 다른 노드로 자동 전환한다. 데이터베이스, 웹 서버, 메일 서버에 적용할 수 있다.
| 구성 | 설명 | 자원 효율 |
|---|---|---|
| Active-Standby | 대기 노드는 유휴 상태 | 낮음 (50%) |
| Active-Active | 모든 노드가 서비스 처리 | 높음 (100%) |
| N+1 | N개 Active, 1개 Standby | 중간 |
| N+M | N개 Active, M개 Standby | 가변 |
트래픽을 나눠 처리하는 부하분산 클러스터
부하분산 클러스터는 로드 밸런서가 여러 노드에 요청을 분배하는 구조다. 노드 하나에 장애가 나면 로드 밸런서는 남은 노드로 트래픽을 재분배한다.
| 알고리즘 | 설명 | 적합한 상황 |
|---|---|---|
| Round Robin | 순차적 분배 | 동일 스펙 서버 |
| Weighted RR | 가중치 기반 분배 | 성능 차이 있는 서버 |
| Least Connection | 연결 수 최소 서버 | 세션 시간 다양 |
| IP Hash | 클라이언트 IP 기반 | 세션 유지 필요 |
| Least Response | 응답 시간 최소 서버 | 성능 민감 서비스 |
병렬 연산을 위한 HPC 클러스터
HPC(High Performance Computing) 클러스터는 대규모 연산 작업을 병렬로 처리한다. 수백~수천 개 노드로 구성될 수 있으며, MPI(Message Passing Interface)로 노드 사이의 통신을 수행한다. 과학 시뮬레이션, AI/ML 학습, 렌더링이 대표적인 적용 대상이다.
Heartbeat가 끊겼을 때 무엇을 확인해야 하는가
Heartbeat는 노드가 서로의 생존 상태를 확인하는 신호다. 전용 네트워크를 Primary Heartbeat로 두고, Serial 또는 별도 NIC를 Secondary Heartbeat로 구성할 수 있다. 일반적으로 연속 3회 실패 시 장애로 판정한다.
Heartbeat 단절만으로 상대 노드가 완전히 멈췄다고 단정할 수는 없다. 네트워크 분할로 양쪽 노드가 모두 자신이 정상이라고 판단하면 Split-Brain이 발생할 수 있으며, 이는 데이터 손상으로 이어질 수 있다.
Quorum은 이 상태를 막기 위한 판단 기준이다. 과반수 원칙에서는 (N/2)+1 이상의 노드가 있어야 서비스를 유지한다. Quorum Disk를 공유 디스크 기반 중재자로 사용하거나, 홀수 노드 또는 외부 중재자를 Tie-breaker로 둘 수 있다.
STONITH(Shoot The Other Node In The Head)는 불확실한 상태의 노드를 확실히 격리하는 방식이다. IPMI나 iLO 같은 전원 제어를 통해 기존 Active 노드를 강제로 차단한 뒤, 대기 노드가 안전하게 VIP를 인수하게 한다. 데이터 손상과 Split-Brain을 막는 데 사용한다.
공유 데이터의 위치를 정하는 선택지
공유 스토리지는 노드 간 데이터 일관성을 유지하는 기반이다. SAN은 FC와 iSCSI 형태로 구성할 수 있고, NAS는 NFS 또는 CIFS로 파일 레벨 공유를 제공한다. SAN이 없는 환경에서는 DRBD를 네트워크 기반 미러링으로 활용할 수 있다.
| 유형 | 특징 | 적합한 상황 |
|---|---|---|
| SAN (FC) | 고성능, 고비용 | 대규모 엔터프라이즈 |
| SAN (iSCSI) | 중간 성능, 기존 네트워크 활용 | 중소규모 |
| NAS (NFS) | 파일 레벨 공유 | 웹 콘텐츠, 로그 |
| DRBD | 네트워크 기반 미러링 | SAN 없는 환경 |
Linux HA 스택과 Pacemaker 구성
Linux HA 환경에서는 Corosync가 클러스터 통신과 멤버십 관리를 맡고, Pacemaker가 리소스를 관리하며 Failover를 결정한다. DRBD는 블록 레벨 데이터 복제에 사용되고, Resource Agents는 서비스별 시작·중지·모니터링 스크립트를 제공한다.
다음은 Pacemaker에서 클러스터를 초기화하고, VIP와 Apache 리소스를 그룹으로 묶으며, STONITH를 설정하는 예시다.
# 클러스터 초기화
pcs cluster auth node1 node2
pcs cluster setup --name mycluster node1 node2
pcs cluster start --all
# VIP 리소스 생성
pcs resource create virtual_ip ocf:heartbeat:IPaddr2 \
ip=192.168.1.100 cidr_netmask=24 \
op monitor interval=10s
# Apache 리소스 생성
pcs resource create webserver ocf:heartbeat:apache \
configfile="/etc/httpd/conf/httpd.conf" \
op monitor interval=30s
# 리소스 그룹화 (VIP와 Apache 함께 이동)
pcs resource group add webgroup virtual_ip webserver
# STONITH 설정
pcs stonith create fence_node1 fence_ipmilan \
ipaddr=192.168.1.201 login=admin passwd=secret \
pcmk_host_list=node1
pcs stonith create fence_node2 fence_ipmilan \
ipaddr=192.168.1.202 login=admin passwd=secret \
pcmk_host_list=node2| 솔루션 | 벤더 | 특징 |
|---|---|---|
| Oracle RAC | Oracle | DB 클러스터링 특화 |
| Microsoft WSFC | Microsoft | Windows Server 통합 |
| Veritas Cluster Server | Veritas | 이기종 플랫폼 지원 |
| Red Hat Cluster Suite | Red Hat | RHEL 통합 |
| VMware vSphere HA | VMware | VM 레벨 HA |
장애 감지부터 서비스 인수까지
Failover는 장애 감지, 장애 확인, STONITH, 리소스 인수 순서로 진행된다. Split-Brain 여부와 Quorum을 먼저 확인해야 하며, Quorum이 없으면 서비스를 중지한다. 리소스 인수 뒤에는 VIP 활성화, 스토리지 마운트, 서비스 시작을 거쳐 클라이언트가 다시 연결된다.
총 Failover 시간 = 장애 감지 + 장애 확인 + STONITH + 리소스 인수
예시:
- 장애 감지: 3초 (Heartbeat Timeout)
- 장애 확인: 2초 (재확인)
- STONITH: 5초 (전원 차단)
- 리소스 인수: 10초 (VIP, 디스크, 서비스)
- 총 시간: 약 20초
원래 Primary 노드가 복구된 뒤의 Failback 정책도 사전에 정해야 한다. Auto Failback은 원래 노드가 더 고성능인 경우에 선택할 수 있다. 안정성을 중시하거나 장애 원인 분석이 필요한 경우에는 Manual Failback이 맞고, 운영 중 변경을 최소화하려면 No Failback으로 현재 상태를 유지한다.
웹과 데이터베이스에서의 구성 예
웹 서비스에서는 HAProxy를 로드 밸런서로 두고, 여러 Nginx 웹 서버를 MySQL Primary에 연결할 수 있다. MySQL Standby는 Primary와 Replication을 수행한다.
Oracle RAC는 여러 인스턴스가 공유 ASM Disk Group에 접근하는 Active-Active 데이터베이스 클러스터다. Cache Fusion으로 노드 간 데이터 블록을 공유하고, 노드 장애 시에는 다른 노드로 전환한다.
요구사항이 설계 선택을 결정한다
가용성 요구사항은 노드 수와 Failover 시간을, 성능 요구사항은 부하분산 알고리즘을 결정한다. 수평·수직 확장 요구사항은 Scale-out 가능 아키텍처에 영향을 주며, 하드웨어·소프트웨어·운영 비용 제약은 오픈소스와 상용 솔루션 선택으로 이어진다.
최소 노드 수는 Quorum 확보를 위해 3개로 두고, Heartbeat 네트워크는 Primary와 Backup으로 이중화한다. STONITH를 구성하고 스토리지를 이중화 또는 복제하며, 24/7 자동 알림이 가능한 모니터링을 마련하는 구성이 권장된다.
클러스터링은 HA의 서비스 연속성, 부하분산의 처리량 향상, HPC의 병렬 연산을 뒷받침한다. 클라우드에서도 Auto Scaling, Load Balancer, Multi-AZ 배포 형태로 같은 개념이 적용된다.