Active-Standby와 Active-Active 이중화의 실제 차이

서버 이중화를 이야기하면 가장 자주 등장하는 구조가 Active-Standby와 Active-Active다.

둘 다 서버 한 대에 문제가 생겼을 때 서비스를 계속 유지하기 위한 구조라는 점에서는 비슷하다.

하지만 실제 동작 방식은 크게 다르다.

Active-Standby는 평소 한 대가 서비스를 처리하고 다른 서버는 장애에 대비해 대기한다. 반면 Active-Active는 여러 서버가 동시에 실제 트래픽을 처리한다.

겉으로 보면 Active-Active가 서버 자원을 모두 활용하기 때문에 무조건 더 좋아 보일 수 있다.

하지만 운영 환경에서는 장애 감지 방식, 세션 처리, 데이터 동기화, Load Balancer 구성, 복구 과정까지 함께 봐야 한다.

구조가 복잡해질수록 장애가 났을 때 확인해야 할 지점도 많아진다.

이번 글에서는 두 이중화 구조가 실제로 어떻게 동작하고 서버 한 대에 장애가 발생했을 때 어떤 차이가 나타나는지 살펴본다.

서버 이중화가 필요한 이유

서버 한 대만으로 서비스를 운영하면 구조는 단순하다.

Client
  ↓
Server A

하지만 Server A에 장애가 발생하면 서비스 전체가 영향을 받는다.

장애 원인은 다양하다.

OS 장애
프로세스 비정상 종료
네트워크 장애
디스크 장애
하드웨어 장애
애플리케이션 오류

이런 단일 장애 지점을 일반적으로 Single Point of Failure라고 부른다.

이를 줄이기 위해 동일한 역할을 수행할 수 있는 서버를 추가한다.

Server A
Server B

하지만 서버를 두 대 설치했다고 자동으로 고가용성이 만들어지는 것은 아니다.

어떤 서버가 실제 요청을 받을지, 장애를 어떻게 감지할지, 장애 서버를 어떻게 제외할지, 복구된 서버를 언제 다시 투입할지까지 정의돼 있어야 한다.

이때 대표적으로 사용하는 두 가지 방식이 Active-Standby와 Active-Active다.

Active-Standby는 어떻게 동작할까?

Active-Standby 구조에서는 서버 두 대 가운데 한 대만 실제 서비스를 처리한다.

구조를 단순화하면 다음과 같다.

          Server A
        Active
Client ────────→

          Server B
        Standby

정상 상황에서는 Server A가 요청을 처리하고 Server B는 대기한다.

Standby 서버는 완전히 꺼져 있는 서버를 의미하지는 않는다.

운영 방식에 따라 서비스 프로세스가 실행되고 있을 수도 있고, 데이터 동기화나 상태 확인 작업을 수행할 수도 있다.

핵심은 정상 상황에서 실제 사용자 트래픽을 담당하는 서버가 Active 한 대라는 점이다.

Server A에 장애가 발생하면 Server B가 Active 역할을 넘겨받는다.

Server A
장애

Server B
Standby → Active

이 과정을 Failover라고 한다.

따라서 Active-Standby 구조에서는 장애 자체보다 장애를 얼마나 빨리 감지하고 Standby 서버로 전환하느냐가 매우 중요하다.

Failover는 어떻게 발생할까?

Active-Standby 구조에서는 두 서버 사이 또는 별도의 관리 시스템에서 상대 서버가 정상인지 계속 확인한다.

예를 들어 일정 주기로 다음과 같은 상태를 확인할 수 있다.

Network 응답
서비스 Port 상태
프로세스 상태
Health Check URL

Active 서버가 일정 시간 동안 응답하지 않으면 장애로 판단하고 Standby 서버가 서비스를 인계한다.

VIP, 즉 Virtual IP를 사용하는 구조라면 장애 전에는 Server A가 VIP를 가지고 있다가 Failover 후 Server B가 VIP를 넘겨받을 수 있다.

정상 상태:

VIP
 ↓
Server A

장애 후:

VIP
 ↓
Server B

클라이언트 입장에서는 동일한 서비스 IP로 접속하기 때문에 서버가 바뀌었다는 사실을 직접 알 필요가 없다.

하지만 여기서 중요한 문제가 있다.

장애 판단 기준을 너무 민감하게 설정하면 일시적인 네트워크 지연만으로도 불필요한 Failover가 발생할 수 있다.

반대로 너무 느슨하게 설정하면 실제 장애가 발생했는데도 상당 시간 Active 서버로 요청이 계속 전달될 수 있다.

그래서 Failover 구성에서는 단순히 “자동 전환된다”는 사실보다 무엇을 장애로 판단할 것인가가 더 중요하다.

Active-Active에서는 두 서버가 동시에 일한다

Active-Active 구조에서는 두 서버 모두 정상 상황에서 사용자 요청을 처리한다.

             ┌─ Server A
Client → LB ─┤
             └─ Server B

41번과 42번에서 살펴본 Load Balancer 구조가 대표적인 예다.

Server A와 Server B가 모두 Backend Pool에 포함되고 Load Balancer가 요청을 분산한다.

정상 상태에서는 두 서버의 자원을 모두 사용할 수 있다.

예를 들어 트래픽이 다음처럼 분산될 수 있다.

Server A : 50%
Server B : 50%

Server B에 장애가 발생하면 Load Balancer가 Health Check를 통해 B를 제외한다.

이후 요청은 Server A로만 전달된다.

Server A : 100%
Server B : 제외

이 구조에서는 Standby 서버를 Active로 변경하는 과정보다 정상 Backend만 남기고 장애 서버를 Pool에서 제거하는 과정이 핵심이다.

Active-Active에서 한 대가 죽으면 남은 서버는 정말 괜찮을까?

Active-Active의 가장 흔한 착각은 서버가 두 대이므로 한 대가 장애 나도 문제가 없다고 생각하는 것이다.

예를 들어 정상 상황에서 각 서버 CPU 사용률이 다음과 같다고 하자.

Server A : 65%
Server B : 65%

두 서버가 비슷하게 요청을 처리하고 있다.

이 상태에서 Server B가 장애로 제외되면 B가 처리하던 트래픽까지 A가 담당해야 한다.

결과적으로 Server A의 부하가 급격하게 증가할 수 있다.

Server A
CPU 65% → 95% 이상

실제 상황에서는 CPU뿐 아니라

Worker 사용량
DB Connection
Memory
Network Bandwidth
Connection 수

도 동시에 증가할 수 있다.

즉 Active-Active는 장애 시 자동으로 다른 서버가 처리해준다는 것만 볼 것이 아니라 한 대가 전체 트래픽을 감당할 수 있는가도 확인해야 한다.

평소 두 서버를 각각 한계에 가까운 수준으로 사용하면 한 대 장애가 발생하는 순간 남은 서버도 연쇄적으로 느려질 수 있다.

Active-Standby의 실제 장애 증상은 어떻게 나타날까?

Active-Standby에서는 Failover 순간에 짧은 서비스 끊김이 발생할 수 있다.

기존 Connection이 Active 서버에 연결돼 있었다면 해당 서버가 갑자기 사라지는 순간 Connection이 끊긴다.

클라이언트에서는 다음과 같은 증상이 나타날 수 있다.

Connection reset
Timeout
일시적인 접속 실패
재시도 후 정상 접속

특히 장시간 유지되는 TCP Connection이라면 Failover 후 자동으로 다른 서버에 이어 붙는다고 생각하면 안 된다.

기존 Connection은 Server A와 만들어진 연결이기 때문이다.

Server B가 Active가 되더라도 기존 TCP 상태까지 자동으로 그대로 이전되는 것은 아니다.

클라이언트나 애플리케이션의 재연결 로직이 필요할 수 있다.

따라서 이중화 구조를 테스트할 때는 단순히 새로운 접속이 가능한지만 볼 것이 아니라 장애 순간 기존 Connection이 어떻게 되는지도 확인해야 한다.

Active-Active에서는 Session 문제가 중요하다

웹 애플리케이션에서는 사용자 로그인 상태나 장바구니 같은 Session 정보를 서버 메모리에 저장하는 경우가 있다.

예를 들어 사용자가 처음 Server A로 요청을 보냈고 로그인 Session이 A의 Memory에만 존재한다고 가정해보자.

다음 요청이 Server B로 전달되면 B에는 해당 Session이 없다.

사용자 입장에서는 갑자기 로그인이 풀린 것처럼 보일 수 있다.

첫 요청
Client → Server A
Session 존재

다음 요청
Client → Server B
Session 없음

이 문제를 해결하는 방법 가운데 하나는 Session Persistence를 이용해 동일 사용자를 같은 서버로 보내는 것이다.

또 다른 방법은 Redis 같은 외부 Session Store에 Session 정보를 저장해 여러 서버가 공유하도록 만드는 것이다.

Server A ─┐
          ├→ Shared Session Store
Server B ─┘

Active-Active 구조에서는 애플리케이션 자체도 여러 서버에서 동시에 동작할 수 있도록 설계해야 한다.

그렇지 않으면 Load Balancer는 정상적으로 동작하지만 애플리케이션 레벨에서 이상 현상이 발생할 수 있다.

데이터 동기화 문제도 구조에 따라 달라진다

웹서버가 정적 파일만 제공한다면 두 서버를 동일하게 유지하는 것이 상대적으로 단순하다.

하지만 서버 로컬 디스크에 사용자가 업로드한 파일이나 애플리케이션 데이터를 저장한다면 문제가 생긴다.

예를 들어 Server A에 업로드된 파일이 Server B에는 없다면 다음 요청이 B로 전달됐을 때 파일을 찾지 못할 수 있다.

Server A
image01.jpg 존재

Server B
image01.jpg 없음

따라서 Active-Active 환경에서는 공유 Storage나 Object Storage 같은 별도 저장 구조를 사용하는 경우가 많다.

DB 역시 더 복잡하다.

두 서버가 같은 DB를 사용하면 애플리케이션 서버 이중화와 DB 고가용성은 별개의 문제다.

웹서버를 두 대로 만들었더라도 DB가 한 대뿐이라면 DB가 새로운 Single Point of Failure가 된다.

그래서 실제 고가용성 구조를 볼 때는

Web
Application
Database
Storage
Load Balancer
Network

전체 경로를 확인해야 한다.

실제 서버에서 이중화 상태를 어떻게 분석할까?

먼저 현재 요청이 어느 서버로 들어오는지 확인한다.

Nginx를 사용하는 경우 Access Log를 통해 실제 요청 유입 여부를 볼 수 있다.

tail -f /var/log/nginx/access.log

Active-Standby라면 정상 상황에서는 Active 서버에 요청이 집중돼 있어야 한다.

Standby 서버에 일반 사용자 요청이 계속 들어오고 있다면 구성 의도와 실제 동작이 다른지 확인해야 한다.

Active-Active에서는 각 서버에 요청이 정상적으로 분산되는지 살펴본다.

다음으로 Connection을 확인할 수 있다.

ss -ant

현재 TCP Connection 상태를 확인하는 명령이다.

장애 전환 테스트에서는 Failover 이전과 이후 Connection 수와 상태가 어떻게 달라지는지 비교하면 도움이 된다.

서버 자원도 반드시 함께 봐야 한다.

top

또는

vmstat 1

을 이용해 한 서버가 제외된 이후 남은 서버의 CPU와 시스템 부하가 어느 정도까지 증가하는지 확인한다.

이 작업의 목적은 단순히 Failover 성공 여부를 보는 것이 아니다.

장애 후 남은 서버가 실제 서비스 트래픽을 안정적으로 처리할 수 있는지를 검증하는 것이다.

어떤 구조가 더 좋은 구조일까?

Active-Standby는 정상 상황에서 Standby 자원을 서비스 처리에 사용하지 않는다는 단점이 있다.

하지만 정상적인 요청 경로가 단순하고 Active 서버가 명확하기 때문에 구조를 이해하고 관리하기 상대적으로 쉬울 수 있다.

반면 Active-Active는 여러 서버 자원을 동시에 사용할 수 있고 트래픽 확장에 유리하다.

하지만 Session, 데이터 동기화, Load Balancer, 장애 시 용량 확보 등 고려해야 할 요소가 많다.

따라서 단순히

Active-Active가 최신 방식이다.
Active-Standby는 비효율적이다.

처럼 판단할 수는 없다.

서비스 구조와 애플리케이션 특성에 따라 적합한 방식이 달라진다.

특히 중요한 것은 정상 상태보다 장애 상태를 기준으로 설계하는 것이다.

정상적으로 서버 두 대가 잘 동작하는 것은 당연하다.

운영자가 확인해야 할 것은 서버 한 대가 사라졌을 때 서비스가 어떤 상태가 되는가다.

정리

Active-Standby와 Active-Active는 모두 서비스 가용성을 높이기 위한 이중화 방식이지만 실제 동작 원리는 다르다.

Active-Standby는 한 서버가 서비스를 담당하고 다른 서버가 대기하다가 장애 발생 시 역할을 넘겨받는다.

따라서 핵심은

장애 감지
Failover
서비스 전환 시간

이다.

Active-Active는 여러 서버가 동시에 서비스를 처리한다.

따라서 핵심은

Load Balancing
Health Check
Session 공유
데이터 일관성
장애 후 남은 서버의 처리 능력이다.

그리고 어느 구조를 선택하든 서버 두 대가 존재한다는 사실만으로 고가용성이 완성되는 것은 아니다.

Load Balancer나 DB가 단일 장애 지점으로 남아 있을 수도 있고, 장애 서버가 제거된 뒤 남은 서버가 전체 트래픽을 감당하지 못할 수도 있다.

이중화를 설계할 때 가장 중요한 질문은 “서버가 몇 대인가?”가 아니다.

한 구성 요소가 실제로 장애 났을 때 요청이 어디로 이동하고, 기존 Connection과 Session은 어떻게 되며, 남은 시스템이 전체 부하를 감당할 수 있는가​를 확인해야 한다.

이 흐름을 이해해야 Active-Standby와 Active-Active를 단순한 구성 방식이 아니라 실제 장애 대응 구조로 이해할 수 있다.