Linux

HA (고가용성) 운영 관점 정리

HA 고가용성 운영 개념입니다. RTO/RPO, Active/Standby, Active/Active, load balancing, split-brain, quorum, fencing, 계층별 HA 점검과 리허설 기준을 정리했습니다.

devmes

• 조회 119

HA(High Availability, 고가용성)는 장애가 발생해도 서비스 중단 시간을 최소화하는 설계입니다. 중요한 점은 HA가 “절대 안 죽는 시스템”이 아니라, 장애를 감지하고 영향을 줄이며 복구 시간을 예측 가능하게 만드는 운영 방식이라는 점입니다.

RTO와 RPO

HA 설계는 먼저 목표를 숫자로 잡아야 합니다.

  • RTO: 장애 후 서비스를 다시 사용할 수 있을 때까지 허용 가능한 시간
  • RPO: 장애 시 잃어도 되는 데이터 시점 차이

웹 서버 HA는 RTO 몇 초가 가능해도, 데이터베이스 HA는 복제 지연과 split-brain 때문에 RPO/RTO를 더 조심스럽게 봐야 합니다.

대표 패턴

Active/Standby는 한 노드가 서비스하고 다른 노드가 대기합니다. Keepalived VIP, Pacemaker resource, DB standby 구성이 여기에 가깝습니다.

Active/Active는 여러 노드가 동시에 트래픽을 받습니다. stateless web/API는 load balancer 뒤에 두기 쉽지만, stateful DB나 파일시스템은 충돌 방지가 필요합니다.

Load Balancing은 장애 분산뿐 아니라 성능 분산도 담당합니다. 단, backend health check가 부정확하면 죽은 노드로 계속 트래픽을 보낼 수 있습니다.

split-brain과 quorum

클러스터에서 가장 위험한 상황은 split-brain입니다. 노드들이 서로 통신하지 못하면서 각자 active라고 판단하면 데이터 손상이 날 수 있습니다. Red Hat HA 문서도 quorum과 fencing을 split-brain 방지의 핵심으로 설명합니다.

  • Quorum: 다수결로 클러스터가 계속 동작해도 되는지 판단합니다.
  • Fencing: 문제가 된 노드를 전원 차단, 스토리지 차단 등으로 격리합니다.
  • STONITH: Shoot The Other Node In The Head의 약자로, fence 동작을 의미합니다.

계층별 HA 체크

  • 네트워크: VIP, routing, L4/L7 load balancer, DNS failover
  • 웹/API: stateless 설계, session externalization, health check
  • DB: replication, failover, backup, consistency check
  • 스토리지: multipath, replication, snapshot, restore test
  • 운영: monitoring, alert, 대응 문서, 장애 전환 리허설

점검 명령 예시

# VIP 확인
ip addr
arp -an

# 로드밸런서 뒤 backend 상태 확인
curl -I http://127.0.0.1/health

# 클러스터 계열 예시
pcs status 2>/dev/null || true
crm status 2>/dev/null || true

# DB 복제 지연 예시
mysql -e "SHOW REPLICA STATUS\\G" 2>/dev/null || true

운영 기준

HA는 구성보다 검증이 중요합니다. active 노드 중지, 네트워크 단절, 스토리지 지연, 프로세스 hang, DB replication lag 상황을 주기적으로 리허설해야 합니다. failover는 성공했는데 failback 절차가 없으면 장애 후 복구 단계에서 다시 장애가 날 수 있습니다.

문서 링크

BGM EVER