고가용성 아키텍처: 페일오버·로드밸런싱·핫스왑으로 무중단 서비스 만들기

장애·점검 중에도 서비스를 유지하는 고가용성(HA) 체계를 Fail-safe, Oracle 클러스터, 로드밸런싱, 핫스왑 하드웨어 기법으로 정리한다

2026-08-12 · 최초 발행 2025-12-09

서비스가 24시간 죽지 않아야 한다는 요구는 이제 당연하게 여겨지지만, 그 요구를 충족하는 방법은 계획된 점검과 예기치 못한 장애를 가리지 않고 여러 계층에서 동시에 다뤄야 하는 문제다. 고가용성(High Availability, HA)은 구성요소 일부가 멈추더라도 합의된 수준의 서비스를 계속 제공하도록 아키텍처와 운영 절차를 설계하는 체계를 가리킨다.

핵심 축으로 나눠 보는 HA

가용성은 SLA/SLO로 목표를 정하고, MTBF(평균 고장 간격)·MTTR(평균 복구 시간)로 "얼마나 안 죽고 얼마나 빨리 복구되는가"를 측정하며, RTO/RPO로 DR 상황의 복구 시간과 데이터 손실 허용 범위를 못박는다. 이 지표들을 뒷받침하는 장애 모델의 원칙은 단순하다 — 단일 장애점(SPOF)을 제거하고, 장애 영향 범위(failure domain)를 격리하며, 장애가 감지되면 자동으로 Failover가 일어나게 만드는 것이다.

가용성 목표는 99.9%(월 43.2분 다운)에서 99.99%(월 4.32분), 99.999%(월 26초)로 단계적으로 올라간다. MTTR은 핫스왑과 자동화를 통해 수십 분 단위에서 수십 초 단위로 줄이는 것이 목표다. 계획 작업을 무중단으로 처리하고 야간 작업 창을 축소할 수 있어 운영 비용과 SLA 위약 리스크도 함께 낮아진다.

장애가 사고로 번지지 않게 막는 Fail-safe

Fail-safe는 장애가 발생했을 때 추가 사고를 막고 시스템을 안전한 상태로 전이시키는 보호 장치다. 장애 노드를 격리(펜싱)하고 쓰기를 차단하거나 안전하게 종료시키는 식이다. 실제 동작 순서는 헬스 체크 → 쿼럼 판단 → 펜싱 → Failover로 자동화되며, 이 과정에서 데이터 일관성을 지키기 위한 저널링·트랜잭션 재처리 절차가 함께 따라붙는다.

Windows 위의 Oracle: WSFC + Oracle Fail Safe

Windows 환경에서 Oracle 워크로드의 고가용성은 WSFC(Windows Server Failover Clustering)와 Oracle Fail Safe를 조합한 Active-Passive 구성이 표준 경로다. Active 노드가 죽으면 가상 IP와 서비스, 스토리지 소유권이 이전되고 DB·리스너가 재기동되면서 빠르게 Failover가 일어난다. 운영이 단순하고 일관성을 보장하기 쉽다는 장점이 있지만, 활성 노드가 한 시점에 하나뿐이라 스케일아웃에는 한계가 있다. Oracle RAC의 Windows 지원 범위는 버전별로 다르므로 도입 전 최신 정보를 확인해야 한다.

트래픽을 분산시켜 장애를 흡수하는 로드밸런싱

L4/L7 로드밸런서는 트래픽을 여러 노드에 분산시키고, 장애가 감지된 노드는 자동으로 라우팅 대상에서 제외하며, 커넥션·세션 친화성 정책을 적용한다. Active-Active로 다중 인스턴스를 운영하는 애플리케이션에서는 로드밸런서가 수평 확장과 장애 흡수를 동시에 책임지는 핵심 구성요소가 된다.

하드웨어 계층: Hot Swap

Hot Swap은 시스템이 가동 중인 상태에서 디스크·전원·NIC 같은 결함 부품을 교체할 수 있게 하는 기능이다(일부 문헌에서 Hot Swop으로 표기하기도 하지만 표준 용어는 Hot Swap이다). 계획된 교체든 갑작스러운 고장이든 무중단으로 처리할 수 있어 MTTR을 줄이고 유지보수 창(maintenance window)을 축소하는 효과가 있다.

데이터 일관성과 쿼럼

복제는 동기(싱크)와 비동기(비싱크) 두 방식이 있고, 저널·리두 로그 재적용이나 TAF(Transparent Application Failover) 같은 재연결 정책이 필요하다. 쿼럼 장치와 투표 정책은 스플릿 브레인(네트워크 분할로 두 노드가 각자 자신을 Primary라고 판단하는 상황)을 막는 안전장치다. 강한 일관성을 택할지 고가용성 쪽으로 기울지는 워크로드 특성에 따른 트레이드오프다.

헬스체크 실패조건 충족클라이언트 재시도/TAF헬스체크 성공 부하 증가세션 유지/드레이닝결과장애 감지 또는 계획 점검클러스터 매니저: 쿼럼확인·펜싱Failover 실행: VIP이전·스토리지 재마운트·DB재기동세션 복구 또는 재연결로드밸런서: 가중치조정·오토스케일모니터링: 지표 기록·사후 분석

구성 방식별 비교

구성/기능 성능 확장성 일관성 안정성 운영 편의
WSFC + Oracle Fail Safe (Active-Passive) 장애 전: 단일 노드 성능, 장애 시 Failover 지연 수십 초~수분 수평 확장 제한 강한 일관성 유지 용이 높은 안정성, 스플릿 브레인 위험 낮음 구성·운영 단순
Active-Active(DB: RAC 또는 앱 레벨) 병렬 처리 우수 수평 확장 우수 트랜잭션/락 설계 복잡 노드 다중화로 탄력성 높음 운영 복잡도 증가
L4/L7 Load Balancer 지연 최소, 오프로드 가능 백엔드 증설 용이 상태 관리 전략 필요 헬스체크로 장애 흡수 정책/관찰성 중요
Hot Swap 하드웨어 평시 성능 영향 없음 무관 데이터와 무관 부품 결함 영향 최소화 무중단 교체로 작업성 향상

계층별 실무 적용

Oracle DB on Windows 구성은 공유 스토리지·네트워킹 설계 → WSFC 클러스터 생성 → Oracle 설치 → Oracle Fail Safe 설치/구성 → DB·리스너를 클러스터 리소스로 등록 → 클라이언트 TNS Failover 구성 → 테스트·운영 순으로 진행한다. 쿼럼·펜싱 검증과 리스너·VIP 동시 이전, TAF 또는 애플리케이션 재시도 로직 적용이 핵심 점검 포인트다. Windows Server 2019·Oracle 19c·WSFC 조합이라면 New-Cluster -Name <ClusterName> -Node <N1>,<N2> -StaticAddress <VIP>로 클러스터를 만들고 Test-Cluster로 장애 전환 시나리오를 점검한다. tnsnames.ora에는 ADDRESS_LIST를 두 개 이상 두고 FAILOVER=ON, CONNECT_TIMEOUT/RETRY를 실환경에 맞춰 설정해 TAF 샘플을 구성한다.

웹/API 레이어에서는 L7 로드밸런싱과 헬스 체크·서킷 브레이커를 적용하고, 드레인 모드로 무중단 롤링 배포를 한다. 세션 같은 상태 저장 요소는 외부화하고, 커넥션 타임아웃·재시도 정책이 서로 정합적인지 검증해야 한다.

스토리지·하드웨어 레이어는 디스크·전원·NIC를 이중화하고 핫스왑으로 장애 시 무중단 교체를 지원한다. 펌웨어·드라이버 관리와 SMART/Telemetry 기반 예지 보전을 함께 연계하는 것이 일반적이다.

설계할 때 놓치기 쉬운 트레이드오프

RTO/RPO와 SLO를 먼저 문서화하고, 워크로드 특성에 맞춰 강한 일관성과 최종 일관성 중 하나를 선택해야 한다. 전원·네트워크·랙·가용영역(AZ) 레벨로 장애 도메인을 분리하고 쿼럼 장치는 별도로 배치한다. 헬스 체크·펜싱·재시작 순서는 반드시 자동화하고 Chaos·DR 훈련을 정례화해 검증해야 한다. 동기 복제는 일관성에 유리하지만 지연이 늘고, 비동기 복제는 지연에 유리한 대신 RPO 손실을 감수해야 한다는 점도 데이터 경로 설계에서 매번 다시 판단해야 하는 부분이다. 관리 평면 이중화, 최소 권한, 변경 승인·감사, 인증서·키 스토리지의 고가용성도 함께 챙겨야 할 항목이다.

기술 스택을 하나씩 조합한다고 고가용성이 완성되지는 않는다. 장애 모델과 데이터 일관성, 운영 자동화가 맞물려야 하는 체계적 설계의 문제다.

고가용성페일오버로드밸런싱클러스터링무중단 배포