서버를 두 대 설치했는데도 서비스가 중단될 수 있습니다. 두 서버가 같은 스위치나 전원에 의존하거나, 대기 서버에 필요한 데이터가 준비되지 않았다면 장비를 추가한 효과가 제한되기 때문입니다.
서버 이중화는 다른 서버가 역할을 대신할 수 있도록 자원을 준비하는 방식입니다. 고가용성, 즉 HA(High Availability)는 이러한 자원과 장애 감지·전환 절차를 연결해 서비스 중단을 줄이는 설계 목표입니다. 중요한 것은 서버 수보다 어떤 장애를 견디고, 어떤 상태로 서비스를 이어가는지입니다.
서버 이중화 방식은 서비스의 상태와 처리 구조에 따라 선택합니다
Active-Standby는 평상시에 주 서버가 서비스를 처리하고 대기 서버가 장애에 대비하는 방식입니다. 주 서버에 문제가 생기면 대기 서버로 역할을 넘기는 장애 전환, 즉 Failover를 수행합니다. 전환 과정에는 장애 판단, 서비스 기동, 접속 경로 변경 등이 포함될 수 있어 중단 시간이 전혀 없다고 보장할 수는 없습니다.
Active-Active는 여러 서버가 동시에 업무를 처리하는 방식입니다. 웹 서비스에서는 로드밸런서가 정상 서버로 요청을 분산하는 구성이 대표적입니다. 다만 웹 서버가 여러 대라는 이유로 데이터베이스까지 동시에 쓰기를 처리하는 구조가 되는 것은 아닙니다. 계층마다 이중화 방식을 따로 확인해야 합니다.
| 구분 | Active-Standby | Active-Active |
|---|---|---|
| 평상시 처리 | 주 서버가 처리하고 대기 서버는 전환 준비 | 여러 서버가 동시에 처리 |
| 주요 확인 사항 | 대기 서버의 데이터·설정과 전환 준비 상태 | 세션·공유 데이터와 동시 처리 방식 |
| 장애 이후 확인 | 대기 서버가 실제 업무를 이어받는지 | 남은 서버가 전체 부하를 감당하는지 |
로그인 상태나 업로드 파일을 각 서버 내부에만 저장하면 서버가 바뀐 뒤 서비스 이용에 문제가 생길 수 있습니다. 어느 방식을 선택하든 사용자 상태와 데이터를 어디에 보관할지 함께 결정해야 합니다.
장애 감지와 안전한 서비스 전환은 구분해야 합니다
Heartbeat는 서버 사이에 주기적으로 신호를 주고받으며 연결 상태를 확인하는 수단입니다. 응답이 사라졌다는 사실만으로 상대 서버가 완전히 정지했다고 확정할 수는 없습니다. 서버는 정상인데 서버 사이의 네트워크만 끊겼을 가능성도 있습니다.
이때 양쪽이 모두 자신을 주 서버로 판단해 같은 데이터를 수정하면 Split-Brain이 발생할 수 있습니다.
Quorum은 투표 등의 규칙으로 어느 쪽이 클러스터 운영을 계속할 수 있는지 결정하는 장치입니다.
Witness는 이러한 판단에 참여하는 별도 자원이며, 업무 데이터를 복제하는 서버와는 역할이 다릅니다. 구체적인 투표 규칙은 제품과 구성에 따라 달라집니다. Microsoft의 Quorum 설명을 참고할 수 있습니다.
운영 권한을 결정하는 것과 이전 주 서버의 쓰기를 실제로 막는 것도 구분해야 합니다. 구성에 따라 전원이나 저장장치 접근을 차단하는 Fencing 같은 격리 수단을 함께 검토합니다. PostgreSQL의 장애 전환 문서도 이전 주 서버가 다시 주 서버로 동작하지 않도록 하는 장치의 필요성을 설명합니다.
서버 밖의 단일 장애 지점과 데이터 보호 범위도 확인합니다
서버 두 대가 하나의 스위치, 스토리지 또는 전원 경로에 의존한다면 해당 구성 요소의 장애가 두 서버에 함께 영향을 줄 수 있습니다.
이렇게 하나의 고장이 전체 서비스 중단으로 이어지는 지점을 SPOF(Single Point of Failure), 단일 장애 지점이라고 합니다.
점검할 때는 사용자 접속부터 데이터 저장까지 실제 경로를 따라갑니다. 로드밸런서와 인증 시스템, 데이터베이스, 스토리지 연결도 확인 대상입니다.
가상 서버 두 대가 같은 물리 호스트에 배치되어 있거나 전원 공급 장치 두 개가 같은 전원 계통에 연결되어 있다면 공통 장애의 영향을 받을 수 있습니다.
데이터 복제도 손실 방지를 자동으로 보장하지는 않습니다. 비동기 복제에서는 주 서버의 변경 사항이 대기 서버에 전달되기 전에 장애가 발생할 수 있습니다. 동기 복제는 설정된 확인 조건에 따라 데이터 보호 수준을 높일 수 있지만, 응답 지연과 복제 대상 장애 시 동작을 함께 검토해야 합니다. PostgreSQL의 복제 문서는 이러한 차이를 설명합니다.
또한 잘못 삭제한 데이터가 복제 대상에도 반영되면 이중화만으로 원래 데이터를 되찾기 어렵습니다. 서비스 지속을 위한 HA, 과거 데이터를 되살리는 백업, 큰 장애 범위에 대응하는 재해복구는 각각의 복구 목적에 맞춰 설계해야 합니다.
복구 목표를 정하고 사용자 기능으로 검증합니다
RTO는 서비스 중단 후 복구까지 허용하는 목표 시간입니다. RPO는 복구 가능한 데이터 시점을 기준으로 허용하는 데이터 손실의 시간 범위입니다. 둘 다 업무 담당자와 합의해야 하는 목표이며, 장비 사양만으로 정해지지 않습니다. AWS의 복구 목표 설명에서도 이를 조직이 결정하는 기준으로 다룹니다.
설계 검토에서는 “몇 분 안에 복구해야 하는가”와 함께 “그동안 입력된 데이터를 어디까지 잃어도 되는가”를 질문해야 합니다. 같은 장소의 서버 장애에 대비할지, 데이터센터 전체 장애까지 대비할지도 정해야 자원 배치와 복제 방식을 선택할 수 있습니다.
검증은 서버가 다시 켜지는지 확인하는 단계에서 끝나지 않습니다. 사전에 영향 범위와 복구 절차를 정한 시험 환경이나 승인된 점검 시간에 다음 항목을 확인합니다.
- 서버 또는 애플리케이션 장애가 감지되는지
- 전환 후 로그인·조회·저장 등 주요 기능이 동작하는지
- 데이터 누락이나 중복 처리, 복제 지연이 있는지
- 남은 서버가 업무 부하를 감당하는지
- 복구한 서버가 올바른 역할로 재합류하는지
가용성도 서버 전원 상태보다 사용자가 약속된 기능을 정상적으로 이용할 수 있는지를 기준으로 평가해야 합니다. AWS의 가용성 설명이 이러한 관점을 제시합니다.
자주 묻는 질문
대기 서버의 사양은 주 서버보다 낮아도 됩니까?
가능하지만 장애 시 필요한 업무 부하를 감당해야 합니다. 모든 기능을 유지할지, 일부 기능만 우선 제공할지에 따라 필요한 용량이 달라지므로 실제 부하를 기준으로 검증해야 합니다.
장애 전환 후에는 반드시 원래 서버로 돌아가야 합니까?
반드시 그럴 필요는 없습니다. 원래 서버로 되돌리는 Failback은 데이터 정합성과 재전환 영향을 확인한 뒤 운영 정책에 따라 수행할 수 있습니다.
클라우드를 사용하면 별도 HA 설계가 필요 없습니까?
클라우드에서도 자원 배치, 데이터 복제, 애플리케이션 상태와 외부 의존성을 확인해야 합니다. 관리형 서비스를 이용하더라도 선택한 구성의 장애 대응 범위와 복구 조건을 확인해야 합니다.
결론
서버 이중화와 고가용성은 장애를 감지하고, 안전하게 역할을 넘기고, 사용자 기능을 복구하는 전체 과정으로 이해해야 합니다. 서버가 두 대라는 사실만으로 이 과정이 완성되지는 않습니다.
먼저 허용 가능한 중단 시간과 데이터 손실 범위를 정한 뒤 서비스 경로의 단일 장애 지점을 확인하십시오. 이후 이중화 방식을 선택하고 장애 전환 시험 결과를 목표와 비교하면, 필요한 투자와 보완 항목을 구체적으로 판단할 수 있습니다.