고가용성 (High Availability)

고가용성이란

고가용성(High Availability) 은 일부 구성 요소에 장애가 생겨도 서비스 전체가 계속 동작하도록 설계하는 방식입니다.

핵심은 “장애가 아예 없다”가 아니라 다음에 가깝습니다.

장애가 나도 서비스가 완전히 멈추지 않도록 만들기
장애 범위를 작게 가두기
복구 시간을 짧게 만들기

즉, 고가용성은 완전무결함이 아니라 장애를 전제로 한 설계입니다.

왜 고가용성이 중요한가

서비스가 성장할수록 장애 비용은 크게 늘어납니다.

매출 손실: 결제, 주문, 광고, 구독이 바로 멈출 수 있음
신뢰 하락: 사용자는 장애를 기능 버그보다 더 크게 기억함
운영 부담: 복구 과정에서 온콜과 배포 일정 전체가 흔들릴 수 있음

면접에서는 보통 “가용성을 높인다”는 말을 추상적으로 하지 말고,
무엇을 지키고 싶은지 같이 말하는 편이 좋습니다.

로그인은 잠시 느려져도 되는가
결제는 일부 기능보다 더 강하게 보호해야 하는가
조회는 살아 있어야 하고 쓰기는 제한해도 되는가

이런 우선순위가 정해져야 고가용성 전략도 자연스럽게 선택됩니다.

단일 장애점 제거

고가용성 설계의 첫 단계는 단일 장애점(Single Point of Failure, SPOF) 을 찾는 것입니다.

대표 예시는 다음과 같습니다.

애플리케이션 서버 1대
데이터베이스 primary 1대만 존재
캐시 노드 1대
로드 밸런서 1대
한 리전에만 존재하는 배포 구조

단일 장애점을 줄이는 일반적 방법은 다음과 같습니다.

이중화: 같은 역할의 인스턴스를 여러 개 둠
분산 배치: 서로 다른 실패 도메인에 나눠 배치
자동 전환: 장애 감지 후 수동 개입 없이 우회
상태 외부화: 특정 인스턴스가 죽어도 상태를 유지할 수 있게 함

중요한 점은 “서버 수를 늘렸다”가 곧 고가용성은 아니라는 것입니다.
같은 랙, 같은 AZ, 같은 데이터베이스에 묶여 있으면 장애가 같이 날 수 있습니다.¹

Active-Active와 Active-Passive

고가용성 구조는 보통 Active-Active 와 Active-Passive 로 많이 설명합니다.

항목	Active-Active	Active-Passive
트래픽 처리	여러 노드가 동시에 처리	평소에는 주 노드만 처리
장점	자원 활용률이 높고 즉시 분산 가능	구조가 비교적 단순하고 일관성 관리가 쉬움
단점	데이터 동기화와 충돌 관리가 어려움	대기 자원이 놀 수 있고 전환 시간이 필요
적합한 경우	읽기 트래픽이 크고 다중 노드 운영이 자연스러운 서비스	강한 일관성이 중요하고 전환 로직이 명확한 서비스

예를 들어:

웹 애플리케이션 서버는 Active-Active 구성이 일반적입니다.
데이터베이스는 primary-standby 구조의 Active-Passive가 더 흔합니다.

면접에서는 “무조건 Active-Active가 더 좋다”는 식으로 말하면 위험합니다.
상태 공유와 쓰기 충돌이 복잡한 시스템에서는 Active-Passive가 오히려 더 현실적일 수 있습니다.

멀티 AZ와 멀티 리전 전략

가용성을 높일 때 자주 보는 단위는 AZ와 리전입니다.

멀티 AZ: 같은 리전 안의 여러 가용영역에 분산 배치
멀티 리전: 서로 다른 리전에 서비스 복제

전략	장점	비용/복잡도	주요 목적
멀티 AZ	지연 증가가 상대적으로 작고 운영이 단순한 편	리전 전체 장애는 막기 어려움	존 장애 대응
멀티 리전	리전 단위 장애와 재해 대응 가능	데이터 복제와 운영 복잡도 큼	광역 장애 대응, DR

클라우드 문서도 리소스를 여러 실패 도메인에 나눠 배치하면 더 높은 가용성을 기대할 수 있다고 설명합니다.¹²

실무에서는 보통 다음 순서를 많이 택합니다.

같은 리전 내 멀티 AZ부터 적용
트래픽 규모와 비즈니스 요구에 따라 멀티 리전 검토
멀티 리전은 읽기 분산인지 DR인지 목적을 먼저 명확히 함

멀티 리전은 좋아 보이지만 항상 정답은 아닙니다.

데이터 일관성 문제가 커짐
쓰기 경로가 복잡해짐
운영 인력이 감당할 복잡도인지 따져야 함

데이터 계층에서의 고가용성

애플리케이션 서버보다 더 어려운 부분은 데이터 계층입니다.

주요 전략은 다음과 같습니다.

복제본(Replica) 구성: primary 장애 시 standby 승격
읽기 복제본(Read Replica): 읽기 부하 분산과 일부 장애 완화
다중 노드 합의: quorum, leader election 같은 분산 합의
백업과 복구: 가용성과 별개로 데이터 복원 경로 확보

여기서 자주 헷갈리는 점은 다음입니다.

복제는 가용성을 높일 수 있지만, 즉시 일관성을 항상 보장하지는 않습니다.
백업은 장애를 막지 못합니다. 대신 복구 가능성을 높입니다.
자동 failover는 유용하지만, 잘못된 감지로 불필요한 전환이 일어날 수도 있습니다.

그래서 데이터 계층을 설명할 때는 다음을 같이 말하는 편이 좋습니다.

failover 기준
replica lag 허용 범위
읽기와 쓰기의 분리 기준
백업 주기와 복구 목표

관련 주제는 데이터베이스 트랜잭션과 일관성, 데이터베이스 스케일링 문서와 연결됩니다.

장애 감지와 복구 설계

고가용성은 이중화만으로 완성되지 않습니다.
장애를 얼마나 빨리 감지하고, 얼마나 안전하게 복구하느냐가 중요합니다.

대표 설계 요소는 다음과 같습니다.

헬스 체크: 살아 있는 인스턴스를 판단
타임아웃: 언제 실패로 볼지 정함
재시도: 일시 장애를 흡수
서킷 브레이커: 장애 전파를 막음
페일오버: 정상 자원으로 자동 전환
런북: 수동 개입이 필요할 때 절차를 표준화

여기서 timeout, retry, circuit breaker 자체의 일반 설계 원칙은 복원력 패턴 (Timeout, Retry, Circuit Breaker) 문서가 더 직접적인 심화 자료입니다. 이 문서에서는 그 패턴들을 고가용성 목표와 복구 전략에 어떻게 연결할지에 집중하는 편이 좋습니다.

운영 목표를 설명할 때는 다음 개념도 자주 나옵니다.

RTO (Recovery Time Objective): 복구에 허용되는 최대 시간
RPO (Recovery Point Objective): 복구 시 허용 가능한 데이터 손실 범위

예를 들어:

결제 시스템은 RPO를 매우 작게 잡고 강한 데이터 보호를 우선
로그 분석 시스템은 RTO보다 비용 효율과 처리량을 우선할 수 있음

즉, 고가용성은 기술 조합이 아니라 비즈니스 중요도에 맞춘 복구 목표 설계입니다.

고가용성의 트레이드오프

장점: 장애 내성과 서비스 연속성이 좋아집니다.
단점: 비용, 운영 복잡도, 데이터 동기화 부담이 커집니다.
주의점: 가용성을 높일수록 관측성, 테스트, 런북 품질도 같이 올라가야 합니다.

특히 다음 오해를 피하는 것이 중요합니다.

서버를 여러 대 두면 자동으로 고가용성이 되는 것은 아님
멀티 리전이 항상 최선은 아님
failover가 자동이면 안전하다는 보장도 없음

좋은 답변은 “이중화했다”가 아니라
어떤 실패 도메인까지 버틸 수 있고, 그 대가로 무엇을 감수했는지를 말합니다.

면접 포인트

고가용성은 장애를 없애는 설계가 아니라, 장애가 나도 서비스가 계속 동작하게 만드는 설계입니다.
SPOF 제거가 첫 단계이고, 그 다음이 장애 감지와 자동 전환입니다.
Active-Active와 Active-Passive는 일관성, 비용, 운영 난이도 관점에서 비교해야 합니다.
멀티 AZ는 상대적으로 기본값에 가깝고, 멀티 리전은 분명한 목적이 있을 때 선택하는 편이 좋습니다.
백업, 복제, failover는 서로 다른 역할이므로 섞어서 설명하면 안 됩니다.