281. 가용성 (Availability) - 결함 탐지, 복구, 예방 전술

핵심 인사이트 (3줄 요약)

1. 본질: 가용성(Availability)은 시스템에 결함(Fault)이 발생했을 때, 이것이 사용자가 겪는 장애(Failure)로 번지지 않도록 막고, 시스템이 정상적으로 서비스를 제공하는 시간의 비율(Uptime)을 극대화하는 아키텍처 품질 속성이다.
2. 가치: 아무리 성능이 뛰어난 시스템이라도 서버가 죽어있으면 가치는 0이다. 가용성은 금융, 통신, 클라우드 인프라 등 현대 24/365 엔터프라이즈 시스템의 가장 핵심적인 생명줄(Lifeline)이다.
3. 융합: 가용성을 달성하기 위한 아키텍처 전술(Tactic)은 결함이 일어나는 시간적 흐름에 따라 **탐지(Detect) → 복구(Recover) → 예방(Prevent)**의 3단계 메커니즘으로 구성되며, 이는 이중화(Redundancy), 헬스체크, 분산 합의 알고리즘 등 고가용성(HA) 시스템 설계의 핵심 교리가 된다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념: 가용성은 "시스템이 요청된 작업을 수행할 준비가 되어 있는 확률"이다. 수학적으로는 가용성 = MTBF / (MTBF + MTTR)로 계산된다. (MTBF: 평균 무고장 시간, MTTR: 평균 수리 시간)

• 필요성: 시스템은 인간이 짜는 코드와 물리적인 하드웨어로 구성되므로, 디스크 고장, 메모리 누수, 네트워크 단절 등 **결함(Fault)은 피할 수 없는 필연(Inevitable)**이다. 중요한 것은 이 결함을 숨기거나 재빨리 수리하여 사용자가 불편함(장애, Failure)을 느끼지 못하게 하는 아키텍처적 방어막이다. 아마존이나 넷플릭스가 1시간 멈추면 수백억 원의 손실이 발생하기 때문이다.

• 💡 비유: 항공기가 하늘을 날고 있습니다. 엔진 1개에 새가 빨려 들어가 고장(Fault) 나는 것은 막을 수 없습니다. 하지만 쌍발 엔진(이중화)으로 설계되어 나머지 엔진 1개로 무사히 공항에 착륙한다면, 추락이라는 장애(Failure)는 막은 것입니다. 이것이 가용성입니다.

• 등장 배경 및 발전 과정:

  1. 단일 장애점(SPOF)의 공포: 초창기 메인프레임 시절에는 중앙 서버 하나가 죽으면 회사 업무가 올스톱되는 단일 장애점(Single Point of Failure) 문제가 심각했다.
  2. 하드웨어 이중화 (HA Cluster): 서버를 2대로 늘려 Active-Standby 구조를 만드는 고가용성(HA) 클러스터가 엔터프라이즈의 표준이 되었다.
  3. 클라우드 네이티브와 카오스 엔지니어링: 현대에는 무조건 서버가 안 죽게(Prevent) 하는 것을 넘어, "서버는 언제든 죽는다"고 가정하고 마이크로서비스들이 알아서 복구(Recover)하게 만드는 회복 탄력성(Resiliency) 중심의 설계로 진화했다.

• 📢 섹션 요약 비유: 가용성은 찰과상(결함)을 아예 안 당하려고 무거운 갑옷을 입는 것이 아니라, 찰과상을 당하더라도 1초 만에 딱지를 앉게(복구) 해서 출혈(장애)로 이어지지 않게 하는 울버린의 재생 능력과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

가용성 시나리오 (6요소)

가용성 요구사항은 다음 6가지 요소로 구체화된다.

• 자극원: 내부 하드웨어, 운영체제, 외부 사이버 공격, 작업자의 실수
• 자극: 크래시(Crash), 응답 지연(Timing Fault), 잘못된 데이터 산출
• 환경: 정상 운영 중, 피크 타임, 재난 상황
• 대상: 시스템 프로세스, 스토리지, 네트워크 채널
• 응답: 결함을 로깅하고, 관리자에게 알리고, 예비 시스템으로 전환(Failover)함
• 응답 척도: 가동률(99.999%), 최대 복구 시간(RTO 5분 이내), 데이터 손실량(RPO 0건)

가용성 3대 전술 (Availability Tactics)

가용성 전술은 결함을 탐지하고, 복구하며, 애초에 장애로 번지는 것을 예방하는 3가지 카테고리로 나뉜다.

  ┌─────────────────────────────────────────────────────────────┐
  │                 결함 발생 흐름과 가용성 3대 전술                │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │     [예방 전술]                   [탐지 전술]      [복구 전술]   │
  │          │                          │             │        │
  │ 정상 운영 ─┼─▶ 결함(Fault) 발생 ──────┼────▶ 탐지 ──┼─▶ 복구  │
  │          │ (메모리 릭, 디스크 고장)    │             │        │
  │          ▼                          ▼             ▼        │
  │   - 예외 처리 (Exception)      - Ping/Echo     - Active/Standby│
  │   - 트랜잭션 롤백               - Heartbeat     - Active/Active │
  │   - 예측 모니터링               - Exception     - 롤백/재시도     │
  │                                                             │
  │   ※ 핵심: 결함(Fault)이 장애(Failure)로 전파되기 전에 끊어내야 한다!  │
  └─────────────────────────────────────────────────────────────┘

1. 결함 탐지 (Detect Faults) 전술

결함이 발생했음을 알아채는 기술이다. 알아채야 복구를 할 수 있다.

• Ping / Echo: 중앙 모니터링 서버가 각 노드에게 "살아있니?"라고 묻고 "살아있다"는 답을 확인하는 양방향 방식.
• Heartbeat (심장박동): 각 노드가 중앙 서버에게 "나 살아있어"라고 주기적으로 메시지를 보내는 단방향 방식. (오버헤드가 적음)
• 예외(Exception) 탐지: 코드 레벨에서 오류를 Try-Catch로 잡아내어 시스템 크래시를 막고 에러 로그를 남기는 방식.
• 타임아웃 (Timeout): 요청을 보낸 후 정해진 시간 내에 응답이 없으면 결함으로 간주하는 네트워킹 전술.

2. 결함 복구 (Recover from Faults) 전술

결함이 발견되었을 때 정상 상태로 돌려놓는 기술이다.

• Active / Passive (Standby) 이중화: 주 서버(Active)가 죽으면, 놀고 있던 예비 서버(Passive)가 역할을 이어받는(Fail-over) 고전적 방식.
• Active / Active 클러스터링: 두 대 이상의 서버가 동시에 트래픽을 처리하다가 하나가 죽으면 남은 서버가 트래픽을 전부 감당하는 현대적 로드 밸런싱 방식.
• 스페어(Spare) / 재부팅: 쿠버네티스(k8s)처럼 노드가 죽으면 죽은 노드를 버리고 빈 공간에 새 노드를 즉시 띄워(Restart/Replace) 복구하는 클라우드 네이티브 전술.
• 상태 복구 (State Restore): 체크포인트나 트랜잭션 로그를 활용해 데이터가 오염되기 직전의 안전한 상태(Rollback)로 되돌리는 방식.

3. 결함 예방 (Prevent Faults) 전술

아예 결함 자체가 장애로 번지지 않도록 사전에 싹을 자르는 기술이다.

• 서비스에서 해제 (Removal from Service): 디스크 배드 섹터나 메모리 릭이 감지되어 "곧 죽을 것 같은" 서버를 L4 로드밸런서에서 미리 빼버리는 전술.

• 트랜잭션 (Transactions): 여러 단계의 작업 중 하나라도 실패하면 전체를 취소(ACID 보장)하여 데이터 오염을 예방하는 전술.

• 예측적 상태 모니터링: AI나 임계치 모니터링을 통해 디스크 용량이 95% 찼을 때 미리 알람을 울려 용량 부족 장애를 예방하는 기법.

• 📢 섹션 요약 비유: 탐지는 보초병이 "적군(결함) 발견!"이라고 외치는 것이고, 복구는 성문이 뚫렸을 때 예비 성문을 닫고 예비군(Active-Standby)을 투입하는 것이며, 예방은 아예 성벽에 접근하지 못하도록 해자를 파두는(트랜잭션) 것입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 가용성 9 (Nines)의 마법 (비용 vs 가용성 트레이드오프)

고객은 항상 100% 가용성을 원하지만, 소수점(Nine)이 늘어날수록 인프라 구축 비용은 10배씩 뛴다.

과목 융합 관점

• 운영체제 (OS): 디스크 이중화 기술인 RAID(1, 5, 6)가 물리적 수준에서의 복구(Recover) 전술인 Active/Active(또는 Parity 복구)의 전형이다.

• 네트워크 (NW): L4 스위치가 서버들에게 Health Check(Ping/Heartbeat)를 보내고, 죽은 서버를 트래픽 풀에서 빼버리는(Removal from Service) 행위가 탐지-예방 전술의 네트워크적 구현이다.

• 데이터베이스 (DB): 분산 DB에서 뗏목(Raft)이나 팍소스(Paxos) 알고리즘을 사용해 리더 노드가 죽었을 때 투표로 새로운 리더를 뽑는 과정이 클라우드 분산 가용성의 척수다.

• 📢 섹션 요약 비유: 99.9%에서 99.99%로 9를 하나 더 붙이는 것은, 자전거에 보조바퀴를 다는 수준이 아니라 자전거를 버리고 장갑차를 새로 사야 하는 어마어마한 비용의 벽(Trade-off)을 넘는 일입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — 좀비(Zombie) 프로세스로 인한 탐지(Detect) 실패: 웹 서버 프로세스가 죽지는 않았지만(포트는 열려 있음), DB 커넥션 풀이 꽉 차서 응답을 30초씩 지연시키고 있다. L4 로드밸런서의 단순 L3 Ping(ICMP) 체크는 무조건 "OK"를 반환한다. 트래픽은 계속 쏟아지고 서버는 좀비가 되어 전면 장애가 발생했다.

   • 아키텍트의 해결책: 가용성 탐지 전술의 고도화가 필요하다. 단순 Ping이 아니라, 애플리케이션 계층(L7)의 상태까지 확인하는 딥 헬스체크(Deep Health Check) 엔드포인트(/health)를 뚫어 DB 커넥션 상태까지 확인해야 한다. 또한 타임아웃(Timeout) 전술을 짧게(예: 3초) 설정하여 응답이 늦으면 과감히 결함으로 간주하고 트래픽을 잘라내야(Removal) 한다.

2. 시나리오 — Split-Brain (두뇌 분열)에 의한 Active-Active 데이터 오염: 두 대의 DB 서버가 동기화되며 돌아가던 중, 둘 사이를 연결하는 네트워크 케이블(Heartbeat 라인)만 톡 끊어졌다. 두 서버는 서로 "상대방이 죽었네! 내가 마스터다!"라며 둘 다 Active 상태로 변신해버렸고, 양쪽에서 데이터가 무결성을 잃고 쓰여지는 끔찍한 스플릿 브레인(Split-Brain) 사고가 났다.

   • 아키텍트의 해결책: 복구(Failover) 전술의 가장 큰 적이다. 이중화 클러스터를 구성할 때는 항상 **홀수 개의 노드(예: 3개)**를 유지하여 정족수(Quorum, 다수결)를 기반으로 마스터를 선출해야 한다. 짝수 대일 경우, 네트워크 단절 시 어느 한쪽이 확실히 죽었음을 보장하기 위해 펜싱(Fencing/STONITH - Shoot The Other Node In The Head: 상대 서버의 전원을 강제로 차단) 장비를 도입해야 완벽한 가용성 전술이 완성된다.

도입 체크리스트

• 기술적: Active-Standby 구조에서, 대기 중인 Standby 장비가 진짜 작동하는지 정기적으로 모의 장애 훈련(D/R Test)을 하고 있는가? 장애가 나서 넘겼는데 대기 장비도 옛날 설정값 때문에 안 켜지면 2배의 재앙이 된다.
• 경영적: RTO(목표 복구 시간)와 RPO(목표 복구 시점)가 비즈니스 부서와 정확히 합의되었는가? "데이터 1분 치는 날아가도 되니까 복구만 빨리 해라"와 "1시간이 걸려도 1원도 날아가면 안 된다"는 아키텍처(비동기 복제 vs 동기 복제)를 완전히 다르게 만든다.

안티패턴

• 단일 장애점(SPOF)의 방치: 웹 서버는 100대로 오토스케일링을 해놓고, 정작 그 앞의 로드밸런서(L4)나 뒷단의 마스터 DB는 달랑 1대만 두는 행위. 시스템의 전체 가용성은 가장 약한 고리의 가용성을 절대 넘지 못한다. 돈을 낭비하는 꼴이다.

• 📢 섹션 요약 비유: 두뇌 분열(Split-Brain)은 배의 선장과 부선장 사이의 무전기가 고장 나자, 서로 자기가 진짜 선장이라며 배를 왼쪽, 오른쪽으로 동시에 몰아 배가 반으로 찢어지는 사고와 같습니다. 다수결(홀수 노드)이라는 확실한 규칙이 있어야 막을 수 있습니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• 마이크로서비스와 Circuit Breaker: 현대 가용성 설계의 꽃은 넷플릭스가 유행시킨 '서킷 브레이커(Circuit Breaker)' 패턴이다. 뒷단 서버가 아프면(결함), 앞단 서버가 계속 찔러서 완전히 죽이기 전에 아예 전기 차단기를 내리듯 통신을 끊어버리고 미리 준비된 캐시나 에러 화면을 띄워 장애 전파(Cascading Failure)를 예방한다.
• 자가 치유 (Self-Healing) 인프라: 쿠버네티스(k8s)의 핵심 철학은 탐지-복구의 극단적 자동화다. 파드(Pod)의 Liveness Probe(탐지)가 실패하면, k8s 마스터가 즉시 해당 파드를 죽이고 새 파드를 띄워 버린다(복구). 인간의 개입이 아예 사라졌다.

참고 표준

• IEEE 1044: 시스템 안정성 및 신뢰성(Reliability & Availability) 관련 용어 표준
• ITIL / ITSM: IT 서비스 관리의 연속성 관리 및 가용성 관리 프레임워크 (SLA, MTBF 관리)

가용성 아키텍처의 철학은 **"실패를 막는 완벽한 시스템은 없다. 오직 실패를 우아하게 견뎌내는 시스템만 있을 뿐이다"**라는 회복 탄력성(Resiliency)으로 귀결된다. 기술사는 무결점(Zero Defect)이라는 환상을 버리고, 장애가 발생했을 때 격벽을 쳐서 배가 침몰하는 것을 막고(예방), 예비 양수기를 즉각 돌려 물을 퍼내는(복구) 가장 빠르고 자동화된 선박 시스템(Architecture)을 설계해야 한다.

• 📢 섹션 요약 비유: 가용성 설계는 타이타닉 호를 만들면서 "이 배는 절대 안 가라앉아!"라며 구명보트를 빼버리는 오만함이 아니라, "암초에 부딪히더라도 배에 물이 안 차도록 16개의 독립된 방수 격벽을 만들고 구명보트를 꽉꽉 채워두는" 겸손하고 안전한 엔지니어링입니다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 여러분이 컴퓨터로 아주 중요한 숙제를 하고 있어요. 갑자기 정전(결함)이 되면 숙제가 다 날아가겠죠?(장애)
2. 이걸 막으려고 컴퓨터 배터리(UPS)를 달아 정전이 돼도 10분은 버티게 하고(예방), 5분마다 자동 저장(탐지/복구)을 켜두는 거예요.
3. 이렇게 어떤 나쁜 사고가 터져도 내가 하던 일이 멈추지 않고 끄떡없이 돌아가게 만드는 튼튼한 방어막을 **'가용성 전술'**이라고 한답니다!