1.5.1.1.3 시스템 가용성(Availability) 임계점 설정 및 장애 복원력(Resilience) 설계

1.5.1.1.3 시스템 가용성(Availability) 임계점 설정 및 장애 복원력(Resilience) 설계

상용 소프트웨어 서비스에서 “장애가 절대 나지 않는 완벽한 시스템(100% Availability)“이라는 목표는 기술적 허구이자 막대한 자본의 낭비를 초래하는 경영론적 오류이다. 최고기술책임자(CTO)는 아마존 웹 서비스(AWS)의 CTO 베르너 보겔스(Werner Vogels)의 명언인 “모든 것은 끊임없이 실패한다(Everything fails, all the time)“는 대전제를 시스템 설계의 기본 철학으로 수용해야 한다.

따라서 기술 상용화 아키텍처의 목표는 실패를 완벽히 차단하는 것이 아니라, 허용 가능한 가용성의 ’임계점(Threshold)’을 설정하고, 장애가 발생했을 때 연쇄적인 시스템 붕괴를 막는 복원력(Resilience)을 구조화하는 것이다.

1. 가용성(Availability) 임계점의 현실적 스코어링

SLA(Service Level Agreement) 상징되는 가용성은 9(Nine)의 개수로 표현된다. 99.9%(Three Nines)의 가용성은 1년에 약 8.7시간의 다운타임(Downtime)을 허용하지만, 99.99%(Four Nines)는 단 52분의 다운타임만을 허용한다.

가용성 지표를 소수점 첫째 자리에서 두 번째 자리로 올리기 위해서는 서버 이중화(Active-Active), 다중 리전(Multi-Region) 구축, 데이터베이스의 실시간 글로벌 레플리케이션(Global Replication) 등 인프라 아키텍처 비용이 기하급수적으로 폭증한다. B2B 의료 금융 솔루션이 아닌 일반적인 스타트업의 B2C 서비스 웹 애플리케이션이라면, 99.9% 수준에 맞춘 “에러 버짓(Error Budget)“을 설정하고, 남는 리소스를 기능 개발과 영업(Sales)에 투자하는 것이 전략적으로 올바른 임계점 투사이다.

2. 장애의 연쇄 전파를 막는 복원력(Resilience) 설계 패턴

아키텍처의 복원력은 시스템 일부의 고장이 전체 시스템 파산으로 번지지 않도록 막는 ‘방파제’ 역할을 한다. CTO는 다음과 같은 대표적 패턴을 기술 스택의 핵심에 내재화시켜야 한다.

2.1 서킷 브레이커 (Circuit Breaker) 패턴

웹 서비스가 메일 발송이나 결제 승인을 위해 외부 API(예: PG사 API, AWS SES)를 호출할 때, 외부 API 자체가 다운(Down)되거나 응답 지연(Timeout)이 발생할 수 있다. 이때 응답을 무작정 기다리는 동기식(Synchronous) 대기를 지속하면, 내부 서버의 스레드(Thread) 자원이 고갈되어 해당 API와 전혀 상관없는 다른 정상적인 사용자 요청까지 거부당하는 전면 장애가 발생한다.

서킷 브레이커 패턴은 외부 API의 실패율이 특정 임계치를 넘으면 전기 회로의 차단기를 내리듯(Open State) 요청을 더 이상 보내지 않고 즉시 에러를 반환(Fail Fast)하여 내부 시스템 자원을 보호하는 설계 기법이다.

stateDiagram-v2
    [*] --> Closed: 정상 상태
    Closed --> Open: 에러율 임계치 초과 (차단)
    Open --> HalfOpen: 일정 시간(Timeout) 경과 후 재시도
    HalfOpen --> Closed: 요청 성공률 회복 (복구)
    HalfOpen --> Open: 요청 다시 실패 (차단 유지)

2.2 벌크헤드 (Bulkhead) 패턴

배(Ship)의 선체를 여러 격벽(Bulkhead)으로 나누어, 한 구역에 구멍이 뚫려 침수되더라도 다른 구역이 침수되지 않아 배가 가라앉지 않도록 설계하는 방식에서 차용한 개념이다. 특정 모듈(예: 무거운 배치 처리 로직)이 서버의 CPU와 메모리 풀(Pool)을 100% 점유해 다른 일반 API 호출이 봉쇄되는 현상을 막기 위해, 기능별로 리소스 스레드 풀(Thread Pool)이나 인스턴스를 격리형으로 분할 할당하는 아키텍처를 뜻한다.

2.3 우아한 저하 (Graceful Degradation)

일부 기능이 마비되었을 때 시스템 전체를 ’HTTP 500 에러 페이지’로 안내하기보단, 핵심 비즈니스 로직(예: 비디오 스트리밍 플레이어)은 유지한 채 주변부 기능(예: 사용자의 추천 목록 섬네일 렌더링)만 비활성화된 상태로 서비스를 이어가는 방어적 UI/UX 설계 기술이다.

3. 선제적 재난 관리: 카오스 엔지니어링 (Chaos Engineering)

장애 복원력 설계의 최종 완성 단계는 시스템이 실제로 오류 상황에서 견디는지 프로덕션(Production) 환경에서 능동적으로 실험하는 카오스 엔지니어링(Chaos Engineering)이다.

넷플릭스의 툴인 카오스 몽키(Chaos Monkey)처럼 무작위로 활성 서버 인스턴스를 강제 종료하거나 네트워크 지연을 인위적으로 발생시킴으로써,

  1. 로드 밸런서(Load Balancer)가 즉시 트래픽을 다른 인스턴스로 자동 전환하는지 (Auto-Healing)
  2. 데이터베이스의 페일오버(Failover)가 데이터 유실 없이 정상 가동되는지
    등 시스템의 강건성(Robustness)을 실제 장애가 발생하기 전 평시에 검증할 수 있어야 한다.

4. 결론

“장애가 발생하지 않기를 기도하는 것“은 전략이 아니다. CTO의 아키텍처 결정은 반드시 ’시스템은 실패한다’는 비관적 대전제 위에서 낙관적인 서비스를 제공하기 위한 공학적 설계여야 한다. 명확한 가용성 목표치(SLA)를 정립하고 에러 버짓(Error Budget) 내에서 무중단 페일오버 메커니즘을 설계함으로써, 불가피한 외부 충격에도 서비스를 유지할 수 있는 안티프래질(Antifragile)한 아키텍처를 완성해야 한다.

참고 문헌 및 추천 논문:

  • Nygard, M. (2018). Release It!: Design and Deploy Production-Ready Software (2nd ed.). Pragmatic Bookshelf.
  • Rosenthal, C., et al. (2020). Chaos Engineering: System Resiliency in Practice. O’Reilly Media.
  • Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media.