들어가기 전
안녕하세요. 오랜만에 글을 작성하게 되었습니다.
최근에 이것저것 바쁘기도 했고, 마땅히 정리해서 적고 싶은 주제가 잘 떠오르지 않아 한동안 글을 쉬게 되었네요.
요즘은 단순한 개발을 넘어서 인프라 쪽에 조금 더 관심을 가지고 공부하고 있습니다.
특히 서버(서비스)의 가용성을 높이기 위한 고가용성(High Availability) 에 대해 학습하고,
서버에 적용해보는 작업을 자주 하고 있어요.
그래서 이번 글에서는 서버 고가용성을 구성하는 방식 중
Active-Active, Active-Standby와 같은 서버 이중화 구조에 대해 정리해보려고 합니다.
서버의 고가용성이 왜 중요할까?
개발을 하고 서비스를 배포하는 것으로 모든 작업이 끝나는 것은 아닙니다.
서버가 안정적으로 운영되면 사용자는 끊김 없이 서비스를 이용할 수 있고,
이는 자연스럽게 서비스에 대한 만족도와 신뢰도로 이어집니다.
또한 장애 대응에 소모되는 시간이 줄어들면서 개발자 입장에서도 운영에 대한 부담을 크게 줄일 수 있습니다.
하지만 서버는 언제든지 장애가 발생할 수 있습니다. (정말 정말 진짜입니다.)
하드웨어 문제, 네트워크 장애, 예기치 못한 트래픽 증가, 혹은 단순한 설정 실수 하나만으로도 서비스는 쉽게 중단될 수 있어요.
(정말 식은 땀이 납니다.)
이러한 장애가 발생했을 때 서버가 완전히 중단된다면 사용자는 서비스를 이용할 수 없게 되고,
이는 곧 서비스 신뢰도 하락으로 이어지게 됩니다.
특히 24시간 운영되는 서비스일수록 짧은 장애 시간조차 큰 영향을 미칠 수 있습니다.
이러한 상황을 대비하기 위해 등장한 개념이 바로 고가용성(High Availability) 입니다.
고가용성은 일부 서버에 장애가 발생하더라도 서비스 전체는 중단되지 않도록 구성하는 것을 목표로 해보겠습니다.
용어 정리
앞서 말한 개념들을 이해하기 전에, 먼저 자주 등장하는 용어들을 정리해보려고 합니다.
특히 인프라 관련 작업을 하다 보면 용어를 정확히 알고 있어야 소통이 훨씬 수월해지는 경우가 많더라고요.
그럼 고가용성과 관련된 주요 용어들을 하나씩 정리해보겠습니다.
고가용성 (High Availability)
고가용성(High Availability, HA) 은 시스템이 장시간 중단 없이 지속적으로 운영될 수 있는 능력을 의미합니다.
가용성 목표는 일반적으로 99.9%(3 nines)부터 99.999%(5 nines) 수준을 목표로 하며,
‘9의 개수(nines)’로 가용성을 표현하기도 합니다.
- 99.9% (3 nines) → 연간 약 8.76시간 다운타임
- 99.99% (4 nines) → 연간 약 52분 다운타임
- 99.999% (5 nines) → 연간 약 5분 다운타임
단일 장애 지점 (SPOF, Single Point of Failure)
시스템 내에서 해당 컴포넌트에 장애가 발생하면 서비스 전체가 중단될 수 있는 단일 지점을 의미합니다.
예시
- 서버가 1대만 존재하는 구조
- 로드 밸런서가 1대만 있는 구조
- DB가 단일 인스턴스로만 구성된 경우
이러한 구조에서는 해당 컴포넌트에 장애가 발생하면 다른 부분이 정상이라 하더라도 서비스 전체가 중단됩니다.
즉, “이것 하나만 죽어도 서비스가 멈춘다면 그 지점이 SPOF” 입니다.
중복성 (Redundancy)
단일 장애 지점(SPOF)을 제거하기 위해 서버, 네트워크, 컴포넌트 등을 중복 구성하는 것을 의미합니다.
예시
- 동일한 역할을 수행하는 서버를 여러 대 구성
- 이중화된 로드 밸런서 구성
- Master-Replica 형태의 데이터베이스 구성
중복성을 통해 하나의 컴포넌트에 장애가 발생하더라도 다른 컴포넌트가 동일한 역할을 수행할 수 있게 됩니다.
다만, 중복 구성만으로는 충분하지 않으며 장애를 감지하고 전환할 수 있는 메커니즘이 함께 필요합니다.
페일오버 (Failover)
운영 중인 시스템에 장애가 발생했을 때 대기 중인 시스템으로 자동 전환하는 메커니즘을 의미합니다.
예시
- Active 서버 장애 발생 시 Standby 서버로 자동 전환
- 헬스 체크 실패 시 로드 밸런서가 트래픽을 다른 서버로 전달
- DB Master 장애 시 Replica가 승격되는 경우
페일오버가 정상적으로 동작하면 서비스 중단 시간을 최소화할 수 있으며, 사람의 개입 없이 장애에 대응할 수 있습니다.
헬스 체크 (Health Check)
서버나 시스템의 상태를 주기적으로 확인하여 정상 여부를 판단하는 메커니즘입니다.
헬스 체크 결과에 따라 장애가 감지된 서버는 트래픽 대상에서 제외되거나 페일오버가 수행됩니다.
헬스 체크가 없다면 장애 여부를 즉시 판단할 수 없어 페일오버가 지연되거나 서비스 중단 시간이 길어질 수 있습니다.
즉, 헬스 체크는 고가용성 구성에서 자동 장애 대응의 출발점입니다.
로드 밸런서 (Load Balancer)
여러 서버에 트래픽을 분산시키는 컴포넌트입니다.
Active-Active 구조에서는 필수적인 요소이며, 헬스 체크와 연계하여 장애 서버를 자동으로 제외합니다.
로드 밸런서 자체 또한 단일 장애 지점이 될 수 있으므로 이중화 구성이 필요합니다.
서버 이중화
이제 가장 기본적인 개념이라고 생각하는 서버 이중화에 대해 이야기해볼게요.
서버 이중화는 왜 필요할까요?
하나의 서버로만 서비스를 운영할 경우, 해당 서버에 장애가 발생하면 모든 서비스가 중단될 수 있기 때문입니다.
이러한 문제를 해결하기 위해 우리는 서버를 이중화합니다.
여러 대의 서버를 구성함으로써 특정 서버에 장애가 발생하더라도 서비스 전체가 중단되지 않도록 할 수 있습니다.
서버 이중화를 통해 서비스의 안정성을 높일 수 있으며,
트래픽을 여러 서버로 분산할 경우 성능 측면에서도 이점을 얻을 수 있습니다.
다만, 서버 이중화는 장점만 있는 것은 아닙니다.
서버 간 데이터 동기화, 설정 관리, 운영 복잡도 증가 등 추가로 고려해야 할 요소들도 함께 발생합니다.
(관리의 포인트가 증가할수 있습니다.)
이러한 서버 이중화는 구성 방식에 따라 서버들이 동시에 트래픽을 처리할 수도 있고,
하나는 대기 상태로 두었다가 장애 시 전환될 수도 있습니다.
다음 섹션에서는 이러한 서버 이중화 방식 중
Active-Active와 Active-Standby 구조에 대해 자세히 살펴보겠습니다.
Active-Standby
Active-Standby 구조는 하나의 서버만 실제로 트래픽을 처리하고,
다른 서버는 장애에 대비해 대기 상태로 유지되는 방식입니다.
┌─────────────┐ ┌─────────────┐
│ Client │ │ Client │
└──────┬──────┘ └──────┬──────┘
│ │
└───────────┬───────────┘
│
┌──────▼──────┐
│Load Balancer│
└──────┬──────┘
│
┌───────────┴───────────┐
│ │
┌──────▼──────┐ ┌─────▼──────┐
│ Active │◄───────►│ Standby │
│ (PRIMARY) │ Health │ (BACKUP) │
└─────────────┘ Check └────────────┘
평상시에는 Active 서버가 모든 요청을 처리하며, Standby 서버는 헬스 체크에만 응답합니다.
Active 서버에 장애가 발생하면 Standby 서버가 Active 역할을 대신 수행하게 됩니다.
특징
- 평상시에는 Active 서버만 트래픽 처리
- Standby 서버는 대기 상태로 유지
- 장애 발생 시 자동으로 Standby → Active 전환
- 구조가 단순하고 운영이 비교적 쉬움
- 대기 서버로 인해 리소스 활용률은 낮은 편
이런 경우에 적합
- 서버 간 데이터 동기화가 복잡한 경우
- 상태(State)를 많이 가지는 애플리케이션
- 안정성과 단순한 운영이 더 중요한 시스템
Active-Active
Active-Active 구조는 모든 서버가 동시에 트래픽을 처리하는 방식입니다.
┌─────────────┐ ┌─────────────┐
│ Client │ │ Client │
└──────┬──────┘ └──────┬──────┘
│ │
└───────────┬───────────┘
│
┌──────▼──────┐
│Load Balancer│
│(Round Robin)│
└──────┬──────┘
│
┌───────────┴───────────┐
│ │
┌──────▼──────┐ ┌─────▼──────┐
│ Active 1 │◄───────►│ Active 2 │
│ (SERVING) │ Sync │ (SERVING) │
└─────────────┘ └────────────┘ 로드 밸런서를 통해 요청이 여러 서버로 분산되며, 각 서버는 평상시에도 실제 서비스를 제공합니다.
한 서버에 장애가 발생하더라도 나머지 서버들이 트래픽을 계속 처리할 수 있습니다.
특징
- 모든 서버가 동시에 트래픽 처리
- 부하 분산을 통해 성능 향상 가능
- 한 서버 장애 시 나머지 서버가 부하를 흡수
- 리소스 활용률이 높음
- 세션, 데이터 동기화 등 설계 복잡도 증가
이런 경우에 적합
- 트래픽이 많고 수평 확장이 필요한 서비스
- Stateless 구조의 애플리케이션
- 읽기 요청이 많은 시스템
마무리
최근 인프라 공부를 열심히 해보고 있는데요.
AI의 무서운 발달로 인해 점점 개발자가 개발을 제외한 다른 영역까지
확실히 알아야 하는 시대가 오는거 같더라고요.(너무 무섭습니다 ㅠㅠ)
개발적인 요소에 대한 학습 뿐 아니라 인프라에 있어서도 강점을 가진 개발자로 성장 해야겠어요.
그럼 오랜만에 이번 글은 마무리하고 다음 글은 로드 밸런서로 돌아와 보겠습니다.
그럼 감사합니다~ 안녕~
'인프라' 카테고리의 다른 글
| 무중단 배포에 대해 공부해보자 (0) | 2026.03.28 |
|---|---|
| 인프라 구성 로드 밸런서의 이해 (0) | 2026.02.15 |