고가용성 클러스터

가용성은 시스템이 정상적으로 서비스를 제공할 수 있는 시간의 비율을 의미하며, 일반적으로 백분율로 표현한다. 예를 들어, 연간 99.999%의 가용성은 "다섯 개의 9(Five Nines)"로 불리며, 이는 1년 중 약 5분 15초의 계획된 또는 계획되지 않은 다운타임만 허용된다는 것을 뜻한다. 가용성을 높이기 위한 접근 방식은 주로 장애 조치와 부하 분산을 통해 서비스 중단 시간을 최소화하는 데 초점을 맞춘다.

내결함성은 시스템의 구성 요소 일부에 장애가 발생하더라도 전체 시스템이 정상적으로 작동을 계속할 수 있는 능력을 말한다. 이는 하드웨어 중복 구성, 소프트웨어의 자가 치유 알고리즘, 데이터의 다중 복제본 저장 등을 통해 달성된다. 내결함성 설계는 장애 발생 시 서비스의 연속성을 보장하는 것을 목표로 하며, 사용자에게 장애 자체를 인지시키지 않는 것이 이상적이다.

두 개념은 밀접하게 연관되어 있지만 미묘한 차이가 존재한다. 가용성은 서비스 중단 시간을 측정하는 지표라면, 내결함성은 그러한 중단을 방지하거나 완화하기 위한 시스템의 내재적 특성이다. 높은 가용성을 달성하기 위해서는 내결함성 메커니즘이 필수적이다. 그러나 모든 내결함성 설계가 100% 가용성을 보장하는 것은 아니며, 특정 유형의 장애나 다중 장애 시나리오에서는 여전히 서비스 중단이 발생할 수 있다.

따라서, 효과적인 고가용성 클러스터는 단순히 장애 발생 시 대체 자원을 제공하는 것을 넘어, 시스템 자체가 장애에 견고하도록 내결함성 원칙을 아키텍처에 깊이 통합하여 설계된다.

장애 조치(Failover)는 고가용성 클러스터에서 서비스의 연속성을 보장하기 위한 핵심 메커니즘이다. 이는 클러스터 내 한 노드(서버)에 장애가 발생했을 때, 해당 노드가 담당하던 워크로드(예: 애플리케이션, 데이터베이스, 네트워크 서비스)를 사전에 정의된 대로 정상적인 다른 노드로 자동 또는 수동으로 전환하는 과정을 의미한다. 장애 조치의 목표는 사용자에게 서비스 중단을 최소화하거나 거의 인지하지 못하도록 하는 것이다. 이 과정은 클러스터 관리 소프트웨어에 의해 제어되며, 노드의 하트비트(heartbeat) 신호 손실, 서비스 프로세스 종료, 하드웨어 오류 등 미리 설정된 장애 조건이 감지되면 트리거된다.

장애 조치는 크게 계획된(Planned) 장애 조치와 계획되지 않은(Unplanned) 장애 조치로 구분된다. 계획된 장애 조치는 서버 유지보수, 하드웨어 교체, 소프트웨어 업그레이드와 같이 예정된 작업을 위해 서비스를 정상적으로 다른 노드로 이동시키는 것이다. 반면, 계획되지 않은 장애 조치는 실제 하드웨어 고장, 운영체제 충돌, 네트워크 단절 등의 예기치 않은 사고에 대한 대응이다. 성공적인 장애 조치를 위해서는 공유 스토리지를 통해 데이터의 일관성을 유지하거나, 데이터 복제(Replication) 기술을 활용하여 장애 노드의 데이터를 대기 노드와 동기화하는 것이 필수적이다.

장애 복구(Failback)는 장애 조치가 발생한 후, 원래의 주 노드(primary node)가 복구되었을 때 워크로드를 다시 원래 노드로 되돌리는 절차를 말한다. 이는 시스템을 초기 구성 상태로 복원하여 리소스 사용을 최적화하고, 향후 장애에 대비하기 위한 것이다. 장애 복구는 자동 또는 수동으로 수행될 수 있으며, 자동 장애 복구를 구성할 경우 주 노드가 클러스터에 재참여하고 정상 상태로 확인되면 관리 소프트웨어가 자동으로 서비스를 이전한다.

장애 조치와 복구 전략을 설계할 때는 다음과 같은 요소를 고려해야 한다.

효과적인 장애 조치 및 복구는 단순한 기술 구현을 넘어, 명확한 운영 절차와 정기적인 훈련을 통해 그 신뢰성을 확보해야 한다.

단일 장애 지점은 시스템 내에서 해당 구성 요소가 실패할 경우 전체 시스템의 작동이 중단되거나 서비스가 불가능해지는 지점을 의미한다. 고가용성 클러스터 설계의 근본적인 목표 중 하나는 이러한 단일 장애 지점을 식별하고 제거하여 시스템 전체의 내결함성을 높이는 것이다.

SPOF는 하드웨어, 소프트웨어, 네트워크 구성 요소 등 다양한 형태로 존재할 수 있다. 대표적인 예는 다음과 같다.

SPOF를 제거하기 위한 접근 방식은 주로 이중화와 분산이다. 하드웨어 구성 요소는 물리적으로 중복 배치하고, 소프트웨어 서비스는 여러 노드에 분산하여 실행한다. 또한, 쿼럼 장치와 같은 클러스터 조정 메커니즘도 단일 장애 지점이 되지 않도록 홀수 개로 구성하거나 디스크 기반 쿼럼 대신 다수결 기반의 쿼럼을 사용하는 등의 설계가 필요하다. 효과적인 SPOF 제거를 위해서는 정기적인 장애 모의 실험을 통해 잠재적인 취약점을 지속적으로 점검하고 보완하는 과정이 필수적이다.

액티브-패시브 클러스터는 고가용성 클러스터를 구성하는 가장 일반적인 아키텍처 중 하나이다. 이 구성에서는 특정 시점에 하나의 노드만이 실제 작업(액티브)을 처리하고, 나머지 하나 이상의 노드는 대기(패시브) 상태로 유지된다. 액티브 노드는 클라이언트의 모든 요청을 처리하며 서비스를 제공하는 반면, 패시브 노드는 액티브 노드의 상태를 지속적으로 모니터링하며 대기한다.

주요 동작 원리는 장애 조치에 있다. 액티브 노드에 하드웨어 고장, 소프트웨어 오류, 네트워크 단절 등의 장애가 발생하면, 클러스터 관리 소프트웨어가 이를 감지하고 사전에 정의된 절차에 따라 서비스 제어권을 대기 중인 패시브 노드로 자동으로 이전한다. 이 과정에서 패시브 노드는 필요한 애플리케이션과 데이터를 활성화하여 새로운 액티브 노드가 되어 서비스 중단 시간을 최소화한다.

이 아키텍처의 장점과 단점은 다음과 같이 정리할 수 있다.

액티브-패시브 구성은 데이터 무결성이 매우 중요하거나, 애플리케이션이 여러 노드에서 동시에 실행되도록 설계되지 않은 전통적인 데이터베이스 및 ERP 시스템에서 널리 사용된다. 또한, 장애 조치 후 원래의 액티브 노드가 복구되면 서비스가 자동 또는 수동으로 복귀되는 장애 복구 절차를 포함할 수도 있다.

액티브-액티브 클러스터는 클러스터를 구성하는 모든 노드가 동시에 워크로드를 처리하는 아키텍처이다. 이 방식은 액티브-패시브 클러스터와 달리 대기 상태의 유휴 자원이 없어 자원 활용도를 극대화한다. 모든 노드가 서비스를 제공하므로 부하 분산이 가능하며, 이론적으로는 시스템 전체의 처리 용량이 노드 수에 비례하여 증가한다.

이 아키텍처의 구현은 애플리케이션의 상태 공유 방식에 따라 복잡도가 달라진다. 상태 비저장(stateless) 서비스의 경우, 로드 밸런서를 통해 사용자 요청을 모든 노드에 분배하는 비교적 간단한 구성이 가능하다. 그러나 상태 저장(stateful) 서비스, 특히 데이터베이스의 경우, 모든 노드가 동일한 데이터에 대한 읽기 및 쓰기 작업을 조정해야 하므로 데이터 일관성 유지가 핵심 과제가 된다.

액티브-액티브 클러스터의 주요 장점과 고려사항은 다음과 같다.

따라서 액티브-액티브 구성은 읽기 작업이 많은 웹 서버 계층이나 캐시 서버에 적합하며, 쓰기 작업이 빈번한 데이터베이스에 적용할 때는 Oracle RAC와 같은 특수한 클러스터링 기술이 필요하다. 설계 시 네트워크 대역폭과 지연 시간, 그리고 공유 스토리지의 성능이 병목 현상이 되지 않도록 주의해야 한다.

공유 디스크 아키텍처는 클러스터 내의 모든 노드가 동일한 스토리지 디스크 어레이에 직접 접근할 수 있는 구조이다. 각 노드는 자체적인 CPU와 메모리를 가지지만, 데이터는 중앙 집중식 스토리지 영역 네트워크(SAN)와 같은 공유 스토리지에 저장된다. 이 방식은 데이터의 일관성을 유지하기 쉬우며, 한 노드에 장애가 발생하면 다른 노드가 공유 디스크의 데이터를 즉시 접근하여 서비스를 이어갈 수 있다. 그러나 공유 스토리지 자체가 단일 장애 지점(SPOF)이 될 수 있으며, 모든 노드가 단일 스토리지에 접근하려고 할 때 발생하는 입출력 병목 현상과 확장성의 한계가 주요 단점이다.

반면, 공유 무 아키텍처는 각 노드가 독립적인 CPU, 메모리, 그리고 전용 스토리지를 보유하는 구조이다. 노드 간에는 데이터가 공유되지 않으며, 필요 시 네트워크를 통해 통신하고 데이터를 복제한다. 각 노드는 전체 데이터의 일부를 책임지므로, 시스템 전체의 처리량을 높이고 수평적 확장(스케일 아웃)이 비교적 용이하다. 또한, 스토리지 장치가 분산되어 있어 SPOF가 줄어들고, 일반적으로 더 비용 효율적인 상용 서버 하드웨어로 구성할 수 있다. 그러나 데이터 일관성을 유지하기 위한 복제 메커니즘과 노드 간 조정이 복잡해질 수 있으며, 한 노드가 가진 데이터에 다른 노드가 접근하려면 네트워크를 통한 요청이 필요하다.

두 아키텍처의 선택은 워크로드의 특성과 요구사항에 따라 달라진다. 아래 표는 주요 특징을 비교한 것이다.

일반적으로 트랜잭션 처리 성능과 강한 데이터 일관성이 중요한 전통적 관계형 데이터베이스 관리 시스템에서는 공유 디스크 방식이, 대규모 데이터 처리와 가용성을 위한 분산 시스템에서는 공유 무 방식이 더 널리 채택되는 경향이 있다.

클러스터 관리 소프트웨어는 고가용성 클러스터의 두뇌 역할을 수행하는 핵심 구성 요소이다. 이 소프트웨어는 클러스터 내 모든 노드의 상태를 지속적으로 모니터링하고, 구성원 간의 통신을 관리하며, 자원과 서비스를 제어한다. 주요 기능에는 노드 간 하트비트 신호 교환을 통한 장애 감지, 사전 정의된 정책에 따른 자동 장애 조치 실행, 클러스터 자원(예: IP 주소, 디스크 볼륨, 데이터베이스 인스턴스)의 시작/중지/이동 관리 등이 포함된다.

이 소프트웨어는 일반적으로 분산된 노드들 사이에서 일관된 클러스터 멤버십과 상태 정보를 유지하기 위해 합의 알고리즘을 사용한다. 널리 알려진 오픈소스 스택으로는 통신 계층을 담당하는 Corosync와 자원 관리자 역할을 하는 Pacemaker의 조합이 있다. 상용 솔루션에는 윈도우 서버 장애 조치 클러스터(WSFC)의 클러스터 서비스, VMware의 vSphere HA, 그리고 다양한 벤더의 독점 클러스터 관리자가 있다.

클러스터 관리 소프트웨어의 구성과 정책은 매우 중요하다. 관리자는 소프트웨어를 통해 스토니스케일러(STONITH) 같은 장치를 설정하여 장애가 발생한 노드를 안전하게 격리하거나, 자원 그룹 간의 의존성과 시작 순서를 정의할 수 있다. 또한, 쿼럼 투표를 구성하여 클러스터의 의사 결정 정족수를 관리하고, 네트워크 분할(스플릿 브레인) 상황에서 클러스터의 무결성을 보호한다.

네트워킹 및 통신 계층은 클러스터 내 노드 간의 상태 정보 교환, 하트비트 신호 전송, 장애 감지, 그리고 장애 조치를 위한 명령 전달을 담당하는 핵심 인프라입니다. 이 계층의 안정성과 성능은 전체 고가용성 클러스터의 신뢰도와 응답 속도를 직접적으로 결정합니다.

일반적으로 전용 물리 네트워크 링크를 구성하여 클러스터 통신을 분리하는 것이 권장됩니다. 이는 공용 네트워크의 혼잡이나 장애로 인해 클러스터 노드 간의 통신이 끊기는 것을 방지하기 위함입니다. 노드 간 통신은 멀티캐스트(Multicast) 또는 유니캐스트(Unicast) 방식을 사용하며, TCP/IP 또는 UDP 프로토콜을 통해 이루어집니다. 주요 통신 내용은 다음과 같습니다.

네트워크 구성 시 단일 장애 지점(SPOF)을 제거하기 위해 이중화 또는 다중화가 필수적입니다. 이는 네트워크 인터페이스 카드(NIC)의 팀링(Teaming) 또는 본딩(Bonding), 이중 스위치 구성, 그리고 별도의 라우팅 경로를 포함합니다. 또한, 네트워크 지연 시간(latency)과 대역폭(bandwidth)은 특히 동기식 복제를 사용하는 공유 디스크 클러스터나 지리적으로 분산된 클러스터에서 중요한 고려 사항이 됩니다. 과도한 지연은 성능 저하를 일으키거나 오작동성 장애 감지를 유발할 수 있습니다.

공유 스토리지는 고가용성 클러스터의 핵심 구성 요소로, 클러스터 내의 여러 노드가 동일한 데이터에 접근할 수 있도록 하는 저장 장치 또는 저장 장치 네트워크이다. 이는 장애 조치가 발생했을 때, 대기 노드가 활성 노드가 사용하던 데이터를 즉시 접근하여 서비스를 이어갈 수 있도록 보장하는 역할을 한다. 공유 스토리지가 없으면 각 노드는 자신의 로컬 디스크에 데이터를 저장하게 되며, 이 경우 장애 발생 시 데이터 접근성과 일관성을 유지하는 것이 매우 복잡해진다.

주요 공유 스토리지 유형으로는 DAS, NAS, SAN이 있다. DAS는 서버에 직접 연결된 저장 장치이지만, 특수한 구성(예: 듀얼 포트 SAS)을 통해 제한적으로 공유가 가능하다. NAS는 네트워크를 통해 파일 수준의 데이터를 제공하는 반면, SAN은 블록 수준의 데이터를 고속 전용 네트워크를 통해 제공한다. SAN은 일반적으로 파이버 채널 또는 iSCSI 프로토콜을 사용하며, 데이터베이스와 같은 성능이 중요한 애플리케이션에 선호된다.

공유 스토리지를 설계할 때는 단일 장애 지점을 피하는 것이 중요하다. 이를 위해 스토리지 컨트롤러, 전원 공급 장치, 연결 경로, 스위치 등 모든 구성 요소를 이중화한다. 또한, 쿼럼 장치를 구성하기 위해 공유 스토리지 자체에 특별한 디스크 영역(쿼럼 디스크)을 할당하는 경우도 흔하다. 이 디스크는 클러스터의 구성원 정보와 상태를 저장하여, 네트워크 분할 상황에서도 클러스터가 정상적으로 의사 결정을 내릴 수 있게 돕는다.

공유 스토리지의 성능과 안정성은 전체 클러스터의 성능과 가용성을 직접적으로 결정한다. 따라서 스토리지 네트워크의 대역폭, 지연 시간, IOPS를 신중히 설계해야 하며, 정기적인 성능 모니터링과 장애 조치 테스트가 필수적이다.

쿼럼 장치는 클러스터 내에서 노드 간의 통신 장애가 발생했을 때, 클러스터의 일관성과 가용성을 유지하기 위해 사용되는 결정 메커니즘이다. 네트워크 분할(스플릿 브레인) 상황에서 양쪽 파티션이 모두 활성 상태가 되어 데이터 무결성을 해치는 것을 방지하는 것이 주요 목적이다. 쿼럼은 일반적으로 클러스터 구성원의 과반수(50% 초과) 투표를 기반으로 하여, 어떤 노드 그룹이 클러스터 서비스를 계속 소유할 권한을 가질지 결정한다.

쿼럼을 구현하는 방식은 여러 가지가 있다. 가장 기본적인 방식은 과반수 노드 쿼럼으로, 각 노드가 한 표를 가지며 살아있는 노드의 수가 총 노드 수의 절반을 초과해야 클러스터가 운영된다. 소규모 클러스터(예: 2-노드)에서는 과반수를 달성하기 어려우므로 별도의 쿼럼 디스크나 쿼럼 감시 장치를 도입한다. 쿼럼 디스크는 공유 스토리지에 위치한 특정 디스크 영역으로, 이를 성공적으로 점유한 노드 그룹이 승리한다. 쿼럼 감시 장치는 클러스터 외부에 위치한 독립적인 서버나 네트워크 장치이며, 노드들은 정기적으로 이 감시 장치에 하트비트를 보낸다. 감시 장치와의 연결을 유지하는 노드 그룹이 쿼럼을 획득한다.

적절한 쿼럼 전략을 선택하고 구성하는 것은 고가용성 클러스터의 안정성을 보장하는 데 필수적이다. 잘못된 구성은 예기치 않은 서비스 중단이나 데이터 손상을 초래할 수 있다. 따라서 클러스터 설계 시 예상되는 장애 시나리오(노드 다운, 네트워크 분할, 스토리지 연결 손실)를 고려하여 가장 견고한 쿼럼 모델을 채택해야 한다.

리눅스 생태계에서 고가용성 클러스터를 구축하기 위한 핵심 오픈 소스 기술 스택은 주로 Pacemaker, Corosync, DRBD로 구성된다. 이들은 함께 작동하여 서버 장애 시 자동으로 애플리케이션과 데이터를 정상 노드로 이전하는 완전한 장애 조치 솔루션을 제공한다. Corosync는 클러스터 구성원 간의 통신과 멤버십, 쿼럼 계산을 담당하는 메시징 및 멤버십 계층이다. Pacemaker는 Corosync 위에서 동작하는 클러스터 리소스 관리자로, 서비스(IP 주소, 웹 서버, 데이터베이스 등)를 리소스로 정의하고 이들의 상태를 모니터링하며, 사전 정의된 정책에 따라 리소스를 시작, 중지, 마이그레이션하는 역할을 한다.

스토리지 계층의 고가용성을 위해 DRBD(Distributed Replicated Block Device)가 널리 사용된다. DRBD는 네트워크를 통해 두 개의 서버의 블록 장치(예: 하드 디스크 파티션)를 실시간으로 동기화하는 소프트웨어 RAID-1 솔루션이다. 주 서버(primary)의 모든 디스크 쓰기 작업은 네트워크를 통해 보조 서버(secondary)의 디스크에 복제되어, 한 서버의 스토리지 장애 시에도 데이터의 일관성과 가용성을 보장한다. Pacemaker는 DRBD 리소스의 상태를 관리하고, 주 노드 장애 시 보조 노드를 새로운 주 노드로 승격시키는 작업을 조율한다.

이 기술들을 활용한 일반적인 구성은 다음과 같다.

이러한 스택은 액티브-패시브 클러스터를 구성하는 데 가장 일반적으로 사용되며, LVM, GFS2, 다양한 데이터베이스 등과 통합될 수 있다. 설정은 주로 pcs(Pacemaker/Corosync Configuration System)나 crm(Cluster Resource Manager) 쉘 같은 명령줄 도구를 통해 이루어진다. 이 오픈 소스 스택은 유연성과 비용 효율성으로 인해 많은 기업의 중요 업무 시스템 기반을 이루고 있다.

윈도우 서버 장애 조치 클러스터(Windows Server Failover Cluster, WSFC)는 마이크로소프트 윈도우 서버 운영 체제에서 제공하는 고가용성 및 재해 복구 솔루션이다. 이 기술은 물리적 서버 또는 가상 머신 노드 그룹을 단일 시스템처럼 관리하여, 애플리케이션과 서비스의 가용성을 유지한다. 하나의 노드에 장애가 발생하면 WSFC는 해당 노드에서 실행 중인 워크로드(클러스터 역할)를 클러스터 내 다른 정상 노드로 자동으로 이동시킨다. 이 과정을 장애 조치라고 한다.

WSFC는 주로 SQL Server Always On 가용성 그룹, 파일 서버, 가상 머신, 그리고 마이크로소프트 익스체인지 서버와 같은 중요 업무 애플리케이션을 호스팅하는 데 사용된다. 클러스터를 구성하려면 최소 두 대 이상의 서버 노드와 노드 간 상태 신호를 교환하고 쿼럼을 유지하기 위한 전용 네트워크 연결, 그리고 애플리케이션 데이터를 저장할 공유 스토리지가 필요하다. 공유 스토리지는 iSCSI, 파이버 채널 SAN 또는 SMB 3.0 파일 공유를 통해 제공될 수 있다.

클러스터의 구성, 모니터링, 관리 작업은 대부분 장애 조치 클러스터 관리자(Failover Cluster Manager)라는 그래픽 도구를 통해 수행된다. 이 도구를 통해 노드 추가/제거, 클러스터 역할(서비스 또는 애플리케이션) 구성, 장애 조치 테스트, 리소스 의존성 설정 등을 관리할 수 있다. 또한 파워셸 cmdlet을 사용한 스크립트 기반 자동화 관리도 광범위하게 지원된다.

WSFC의 핵심 구성 요소 중 하나는 쿼럼 모델이다. 쿼럼은 클러스터가 정상적으로 작동하기 위해 필요한 과반수 투표를 결정하는 규칙 집합으로, 노드 간 통신 장애 시 스플릿 브레인 현상을 방지하고 데이터 무결성을 보장한다. 윈도우 서버는 노드 과반수, 디스크 감시, 파일 공유 감시, 클라우드 감시 등 다양한 쿼럼 구성을 지원하여 다양한 환경에 맞게 유연하게 배포할 수 있다.

VMware vSphere HA(High Availability)는 vSphere 환경에서 호스트 장애 발생 시 해당 호스트에서 실행 중이던 가스트 머신을 클러스터 내 다른 정상 호스트로 자동으로 재시작하여 가용성을 보장하는 기능이다. 이는 애플리케이션 수준의 상태를 모니터링하지 않고, 호스트 수준의 장애를 감지하여 물리적 서버 장애에 대한 보호를 제공한다. HA는 별도의 라이선스가 필요 없는 vSphere 기본 기능으로, 구성이 비교적 간단하고 스토리지 공유가 필수 조건이 아니라는 특징이 있다.

반면, VMware vSphere FT(Fault Tolerance)는 보다 높은 수준의 연속성을 제공한다. FT는 하나의 기본(primary) 가상 머신과 완전히 동일한 상태를 유지하는 보조(secondary) 가상 머신을 실시간으로 동기화하여 운영한다. 두 가상 머신은 서로 다른 물리적 호스트에서 실행되며, vLockstep 기술을 통해 명령어 단위로 동기화된다. 기본 가상 머신에 장애가 발생하면 보조 가상 머신이 즉시 인계받아 운영을 계속하므로 서비스 중단 시간이 거의 제로에 가깝다. 그러나 FT는 CPU 호환성 등 엄격한 요구사항이 있으며, 성능 오버헤드가 발생할 수 있다.

HA와 FT는 다음과 같은 주요 차이점을 가진다.

운영 환경에서는 비즈니스 연속성 요구사항과 예산에 따라 HA와 FT를 선택하거나 조합하여 사용한다. HA는 대부분의 워크로드에 적합한 경제적인 솔루션이며, FT는 중단이 허용되지 않는 가장 중요한 애플리케이션에 적용된다.

클라우드 네이티브 환경에서는 전통적인 고가용성 클러스터 접근 방식과는 다른 패턴과 원칙을 적용하여 가용성을 확보한다. 마이크로서비스 아키텍처, 컨테이너 오케스트레이션, 그리고 서비스 메시와 같은 기술을 기반으로, 애플리케이션 수준에서의 복원력과 자가 치유 능력을 설계의 중심에 둔다. 이 패러다임은 단일 서버나 가상 머신의 장애 조치에 집중하기보다, 서비스 전체가 분산되고 복제된 상태로 운영되도록 보장한다.

주요 패턴으로는 회로 차단기 패턴이 있다. 이는 서비스 간 호출이 반복적으로 실패할 경우, 일정 시간 동안 호출을 차단하여 시스템 자원을 보호하고 장애의 전파를 막는다. 벌크헤드 패턴은 시스템의 한 부분에 장애가 발생하더라도 다른 부분이 영향을 받지 않도록 자원(스레드, 연결 등)을 격리한다. 또한, 레디스 패턴은 서비스의 여러 인스턴스를 동시에 실행하고, 요청을 분산하여 단일 인스턴스 장애 시에도 서비스가 중단되지 않도록 한다. 이러한 패턴들은 주로 쿠버네티스와 같은 오케스트레이터 위에서 서비스 디스커버리와 로드 밸런싱과 결합되어 구현된다.

클라우드 네이티브 접근법은 상태 관리에도 특별한 주의를 기울인다. 스테이트풀 서비스의 경우, 상태를 퍼시스턴트 볼륨이나 외부 데이터베이스, 캐시 서비스에 저장하여 컨테이너 인스턴스의 일시적 특성과 분리한다. 쿠버네티스는 디플로이먼트, 스테이트풀셋과 같은 리소스 객체를 통해 파드의 복제본 수를 유지하고, 노드 장애 시 다른 노드에 파드를 재스케줄링하는 자동 복구 메커니즘을 제공한다. 이는 인프라 수준의 고가용성을 애플리케이션 배포 모델에 내재화한 것이다.

SQL Server Always On 가용성 그룹(Availability Group, AG)은 Microsoft SQL Server 2012 버전부터 도입된 고가용성 및 재해 복구 솔루션이다. 이 기술은 데이터베이스 단위로 장애 조치를 제공하며, 하나의 주 데이터베이스(주 복제본)와 최대 8개의 보조 데이터베이스(보조 복제본)로 구성된 그룹을 관리한다. 보조 복제본은 읽기 전용으로 구성하여 보고 작업의 부하를 분산시키는 용도로도 활용할 수 있다.

주 복제본에서 발생하는 모든 트랜잭션 로그 레코드는 각 보조 복제본으로 비동기 또는 동기 방식으로 전송된다. 동기 커밋 모드를 사용하면 트랜잭션이 주 복제본과 보조 복제본 양쪽에 기록된 후에만 커밋이 완료되어 데이터 손실 없이 장애 조치를 보장한다. 비동기 커밋 모드는 성능을 우선시하지만 잠재적인 데이터 손실 위험이 있다.

가용성 그룹의 주요 구성 요소와 특징은 다음과 같다.

이 아키텍처는 자동 또는 수동 장애 조치를 지원하며, 재해 복구를 위해 지리적으로 분리된 데이터 센터에 보조 복제본을 배치할 수 있다. 또한, 페이지 복구 기능을 통해 주 복제본과 보조 복제본 간에 손상된 데이터 페이지를 자동으로 복구할 수 있다.

Oracle RAC는 Oracle Database의 고가용성 및 확장성 솔루션으로, 단일 데이터베이스를 여러 서버(노드)에서 공동으로 액세스하고 처리하는 공유 디스크 아키텍처를 기반으로 한다. 모든 노드가 동시에 데이터베이스 인스턴스를 실행하며, 하나의 통합된 데이터베이스 클러스터를 형성한다. 이 아키텍처는 애플리케이션의 연결을 여러 노드에 분산시켜 성능과 처리량을 확장할 수 있게 하며, 한 노드에 장애가 발생하더라도 다른 노드에서 데이터베이스 서비스를 계속 제공하여 가용성을 유지한다.

클러스터의 핵심은 공유 스토리지와 클러스터웨어이다. 모든 노드는 SAN이나 NAS와 같은 고속 네트워크를 통해 데이터 파일, 리두 로그 파일, 컨트롤 파일 등의 데이터베이스 파일을 공유한다. 동시에, Oracle Clusterware라는 특수 소프트웨어 계층이 노드 간의 통신, 멤버십 관리, 자원 모니터링, 장애 감지 및 복구를 담당한다. 클러스터웨어는 쿼럼을 유지하여 데이터 무결성을 보호하는데, 일반적으로 쿼럼 디스크나 쿼럼 파일을 사용한다.

주요 구성 요소와 작동 방식은 다음과 같다.

이 아키텍처는 수평적 확장을 통한 성능 향상과 내결함성을 동시에 제공하지만, 공유 스토리지와 고속 인터커넥트 네트워크라는 특수 하드웨어 구성이 필요하며, 라이선스 비용과 운영 복잡도가 상대적으로 높은 편이다. 또한, 모든 노드가 동일한 물리적 데이터에 접근하기 때문에 글로벌 캐시 락 관리와 같은 분산 데이터베이스의 고유한 과제를 안고 있다.

MySQL과 MariaDB는 오픈 소스 관계형 데이터베이스 관리 시스템으로, 고가용성과 내결함성을 달성하기 위해 복제와 클러스터링 기술을 제공한다. 이 기술들은 데이터의 중복성을 확보하고 서비스 중단 시간을 최소화하는 데 목적이 있다.

주요 고가용성 구성 방식은 다음과 같다. 첫째, 비동기 복제는 가장 일반적인 형태로, 소스 서버의 변경 사항을 레플리카 서버로 전송하지만 데이터 일관성에 약간의 지연이 발생할 수 있다. 둘째, 반동기 복제는 소스 서버가 트랜잭션을 커밋하기 전에 최소 하나의 레플리카로부터 수신 확인을 받도록 하여, 비동기 복제보다 강한 일관성을 보장한다. 셋째, Galera Cluster는 동기 복제를 기반으로 하는 다중 마스터 클러스터 솔루션이다. 모든 노드가 읽기와 쓰기를 처리할 수 있으며, 트랜잭션 커밋은 클러스터 내 대다수 노드에 동기적으로 적용되어야 한다. 이는 강한 데이터 일관성과 실시간 장애 조치를 가능하게 한다.

운영 관점에서, 고가용성을 위한 일반적인 구성은 소스-레플리카 비동기 복제와 함께 프록시 서버나 로드 밸런서를 사용하는 것이다. HAProxy나 MaxScale과 같은 도구는 애플리케이션과 데이터베이스 사이에 위치하여, 소스 서버에 장애가 발생하면 자동으로 레플리카 서버로 연결을 전환한다. 또한, GTID 기반 복제는 복제 토폴로지 관리와 장애 복구를 더욱 견고하게 만든다. 이러한 아키텍처는 단일 장애 지점을 제거하고 RTO를 단축시키는 데 기여한다.

RTO와 RPO는 재해 복구 및 고가용성 시스템 설계의 핵심 지표로, 비즈니스 연속성 요구사항을 정량화하는 데 사용된다. 이 두 지표는 서로 다른 측면을 측정하며, 시스템 설계와 백업 전략에 직접적인 영향을 미친다.

RTO는 장애 발생 후 시스템이나 서비스가 정상적으로 복구되어 운영을 재개할 때까지 허용되는 최대 시간을 의미한다. 이는 주로 장애 조치 자동화 수준, 대체 시스템의 대기 상태, 복구 절차의 효율성에 의해 결정된다. 예를 들어, RTO가 5분이라면 장애 발생 5분 이내에 서비스가 다른 노드로 전환되어야 한다. 반면, RPO는 장애 발생 시점으로부터 복구된 데이터가 얼마나 최신 상태여야 하는지를 정의하며, 허용 가능한 최대 데이터 손실량을 시간 단위로 나타낸다. RPO는 데이터 백업 또는 복제의 빈도와 방식(예: 동기식/비동기식)에 크게 의존한다. RPO가 1시간이면, 최악의 경우 1시간 분량의 데이터가 손실될 수 있음을 의미한다.

이 두 목표는 서로 트레이드오프 관계에 있는 경우가 많다. 매우 짧은 RTO와 RPO(예: 0에 가까운 값)를 달성하려면 액티브-액티브 클러스터, 실시간 데이터 미러링, 고가의 인프라 등 복잡하고 비용이 많이 드는 솔루션이 필요하다. 반면, RTO와 RPO 목표가 느슨할수록(백업 테이프를 이용한 수동 복구 등) 솔루션의 복잡도와 비용은 낮아진다. 따라서 조직은 비즈니스 크리티컬한 애플리케이션과 중요도가 낮은 시스템에 대해 서로 다른 RTO/RPO 목표를 설정하고, 이에 맞는 적절한 고가용성 클러스터 아키텍처와 데이터 보호 전략을 선택한다.

고가용성 클러스터의 안정적인 운영을 위해서는 구성 요소들의 상태를 지속적으로 모니터링하고, 잠재적 장애를 조기에 발견하기 위한 체계적인 상태 점검이 필수적이다. 클러스터의 가용성은 구성 요소의 정상 작동 여부를 정확히 판단하는 능력에 직접적으로 의존한다.

상태 모니터링은 일반적으로 클러스터 관리 소프트웨어에 의해 수행된다. 관리 소프트웨어는 정기적인 "하트비트(heartbeat)" 신호를 통해 노드 간의 네트워크 연결 상태와 각 노드의 생존 여부를 확인한다. 또한, 애플리케이션 서비스, 공유 스토리지 접근성, 네트워크 인터페이스, 시스템 리소스(CPU, 메모리, 디스크) 사용률 등 핵심 자원의 상태를 지속적으로 점검한다. 이러한 점검은 스크립트나 에이전트를 통해 이루어지며, 사전 정의된 임계값을 초과하거나 서비스가 중단되면 장애로 판단하여 사전에 구성된 정책(예: 장애 조치)을 실행한다.

효과적인 모니터링을 위한 주요 고려사항은 다음과 같다.

정기적인 상태 점검은 계획된 유지보수의 일환으로도 수행된다. 이는 실제 장애 조치 프로세스가 예상대로 작동하는지, 공유 스토리지의 데이터 무결성은 유지되는지, 백업 시스템이 정상인지 등을 확인하기 위한 것이다. 이러한 프로액티브(proactive) 점검을 통해 시스템의 전반적인 건강 상태를 평가하고, 단일 장애 지점이 새로 생기지 않았는지 지속적으로 검증한다.

고가용성 클러스터의 신뢰성을 보장하기 위해서는 정기적이고 체계적인 테스트와 유지보수 절차가 필수적이다. 이러한 절차는 잠재적인 문제를 사전에 발견하고, 장애 조치 및 복구 프로세스가 설계대로 작동함을 검증하는 데 목적이 있다.

테스트 절차는 계획된 시나리오에 따라 진행되며, 주요 테스트 유형은 다음과 같다.

유지보수 절차는 클러스터의 장기적인 안정성을 유지하기 위한 활동을 포함한다. 이에는 운영 체제 및 클러스터 관리 소프트웨어의 정기적인 패치 적용, 하드웨어 펌웨어 업데이트, 구성 설정 백업 및 검토가 포함된다. 모든 유지보수 작업은 변경 관리 절차에 따라 진행되어야 하며, 반드시 비운영 시간에 실행하거나 롤백 계획을 수립한 상태에서 진행해야 한다. 또한, 각 테스트 및 유지보수 활동의 결과와 관찰 사항은 상세히 문서화하여 향후 문제 해결 및 절차 개선을 위한 참고 자료로 활용한다.