Introduction
2024년 7월 19일, 전 세계 기업들의 컴퓨터 화면이 파란색으로 물들었습니다. MS 클라우드 장애 사태였는데요. 크라우드스트라이크라는 보안 회사의 작은 실수가 마이크로소프트 소프트웨어를 사용하고 있는 글로벌 비즈니스를 마비시킨 순간이었죠.
이러한 사건은 MS뿐만이 아닙니다. 작년 6월 13일 저녁, 미국 동부 해안 리전에서 사용되고 있던 AWS의 수많은 서비스가 갑자기 멈췄습니다. 2시간 동안 지속된 이 장애로 넷플릭스, 에어비앤비 등 수많은 기업들이 서비스를 제공하지 못했고, AWS는 약 2억 달러의 손실을 입었다고 합니다. <2023년 최악의 서비스 중단 사고 7선>에 따르면 작년 한 해만 해도 쟁쟁한 IT 기업들이 줄줄이 서비스 중단을 겪었습니다. 단 몇 줄의 코드 변경이 전 세계 비즈니스를 마비시킬 수 있습니다. 우리는 항상 벼랑 끝에 서 있는 거죠.
이쯤에서 가용성에 대해 다시 생각해봅시다. "우리 서비스의 가용성은 99.9%입니다." 많은 IT 기업들이 자랑스럽게 내세우는 이 숫자, 과연 충분할까요? 얼핏 보면 완벽에 가까워 보이는 99.9%. 하지만 이는 연간 8시간 46분의 다운타임을 의미합니다. 99.9%의 가용성으로는 위의 AWS가 겪었던 장애보다 4배 이상 긴 시간 동안 서비스가 중단될 수 있다는 뜻입니다. 이제는 0.1%의 차이가 수백만 달러의 손실을 낳을 수 있습니다. 현대 비즈니스에서 '다섯 개의 9(99.999%)'는 더 이상 사치가 아닙니다
우리가 운영하는 시스템 역시, 언제든 같은 운명을 맞을 수 있다고 생각해보세요. 너무나 끔찍하지 않나요? 과연 무엇이 문제였을까요? 이들 사고에서 우리가 배워야 할 교훈은 무엇일까요? 우리의 서비스는 과연 안전할까요?
과연 0.099%의 차이가 이토록 큰 영향을 미칠 수 있을까요? 99.999%의 가용성은 연간 다운타임을 5분 이내로 줄입니다. 8시간에서 5분이라니...! 하지만 이를 달성하기란 결코 쉽지 않습니다. 99.9%와 99.999%의 가용성은 어떻게 다르며, 이를 달성하기 위해서는 어떤 전략이 필요할까요? 오늘은 시스템 설계의 핵심 중 하나인 '가용성(Availability)'에 대해 깊이 있게 파헤쳐 보겠습니다.
큰 온라인 쇼핑몰을 운영하고 있다고 상상해봅시다. 오늘은 연중 가장 바쁜 날(예컨대 블랙프라이데이같은)이라고 상상해 보세요. 많은 사람들이 최고의 할인을 받기 위해 여러분의 사이트를 방문하고 있습니다.
엇, 갑자기 서버가 다운됐습니다. 사이트가 먹통이 되어 고객들이 쇼핑을 할 수 없게 되는데요. 이런 사건들은 회사의 매출과 평판에 실제로 큰 타격을 줄 수 있습니다. 그래서 시스템이 항상 가용한 상태를 유지하는 것이 매우 중요합니다.
이 글에서는 가용성의 개념, 가용성 등급, 가용성을 향상시키는 전략, 그리고 높은 가용성을 달성하기 위한 모범 사례들을 살펴보겠습니다.
가용성이란 무엇인가?
보통 특정 기간 동안 시스템의 가동 시간을 나타내는 백분율로 표현됩니다. 가용성의 공식적인 정의는 다음과 같습니다:
- 가동 시간: 시스템이 기능하고 접근 가능한 기간.
- 중단 시간: 고장, 유지보수 또는 기타 문제로 인해 시스템을 사용할 수 없는 기간.
가용성 등급
가용성은 종종 "9의 개수"로 표현됩니다. 가용성이 높을수록 중단 시간이 적습니다.
추가되는 각 "9"는 가용성의 10배 향상을 나타냅니다.
가용성 향상을 위한 전략
1. 이중화(Redundancy)
이중화(다중화)는 주요 구성 요소가 실패할 때 대신할 수 있는 백업 구성 요소를 갖는 것을 의미합니다.
기법:
- 서버 다중화: 요청을 처리하기 위해 여러 서버를 배포하여 한 서버가 실패해도 다른 서버가 계속 서비스를 제공할 수 있도록 합니다.
- 데이터베이스 다중화: 주 데이터베이스가 실패할 경우 대신할 수 있는 복제 데이터베이스를 생성합니다.
- 지리적 다중화: 지역적 실패의 영향을 줄이기 위해 여러 지리적 위치에 자원을 분산합니다.
2. 부하 분산(Load Balancing)
부하 분산(로드 밸런싱)은 들어오는 네트워크 트래픽을 여러 서버에 분산시켜 단일 서버가 병목 현상이 되지 않도록 하여 성능과 가용성을 모두 향상시킵니다.
기법:
- 하드웨어 로드 밸런서: 미리 구성된 규칙에 따라 트래픽을 분산하는 물리적 장치.
- 소프트웨어 로드 밸런서: HAProxy, Nginx, 또는 AWS Elastic Load Balancer와 같은 클라우드 기반 솔루션 등 트래픽 분산을 관리하는 소프트웨어 솔루션.
3. 페일오버(Failover) 메커니즘
페일오버 메커니즘은 장애가 감지되면 자동으로 대기하고 있던 standby 시스템으로 전환합니다.
기법:
- Active-Passive 장애 조치: 주요 활성 구성 요소가 passive 대기 구성 요소로 백업되어 장애 발생 시 대신 작동합니다.
- Active-Active 장애 조치: 모든 구성 요소가 활성 상태이며 부하를 공유합니다. 하나가 실패하면 나머지 구성 요소가 원활하게 계속 부하를 처리합니다.
4. 데이터 복제(Replication)
데이터 복제는 한 위치에서 실패하더라도 데이터를 사용할 수 있도록 한 위치에서 다른 위치로 데이터를 복제하는 것을 포함합니다.
기법:
- 동기식 복제: 위치 간 일관성을 보장하기 위해 실시간으로 데이터가 복제됩니다.
- 비동기식 복제: 데이터가 지연되어 복제되며, 더 효율적일 수 있지만 약간의 데이터 불일치를 초래할 수 있습니다.
5. 모니터링 및 알람 시스템
지속적인 건강 모니터링은 시스템 구성 요소의 상태를 확인하여 조기에 장애를 감지하고 즉각적인 조치를 위한 알람을 발생시키는 것을 포함합니다.
기법:
- 하트비트 신호: 구성 요소 간에 상태를 확인하기 위해 정기적으로 보내는 신호.
- 상태 확인: 구성 요소에 대해 정기적인 상태 확인을 수행하는 자동화된 스크립트 또는 도구.
- 경고 시스템: PagerDuty나 OpsGenie와 같이 감지된 문제를 관리자에게 알리는 도구.
높은 가용성을 위한 모범 사례
- 장애를 고려한 설계: 시스템의 어떤 구성 요소라도 언제든 실패할 수 있다고 가정하고 그에 따라 시스템을 설계하세요.
- 상태 확인 구현: 정기적인 상태 확인을 통해 문제가 심각한 장애가 되기 전에 감지하고 대응할 수 있습니다.
- 여러 가용성 영역 사용: 지역화된 장애를 방지하기 위해 시스템을 여러 데이터 센터에 분산하세요.
- 카오스 엔지니어링 실천: 의도적으로 장애를 도입하여 시스템 복원력을 테스트하세요.
- 서킷 브레이커 구현: 문제가 있는 서비스를 빠르게 차단하여 연쇄적인 장애를 방지하세요.
- 캐싱을 현명하게 사용하기: 캐싱은 백엔드 시스템의 부하를 줄여 가용성을 향상시킬 수 있습니다.
- 용량 계획: 예상되는 부하 증가와 예상치 못한 부하 증가를 모두 처리할 수 있도록 시스템을 확보하세요.
이렇듯 가용성은 사용자가 서비스를 안정적이고 지속적으로 이용할 수 있도록 보장하는 시스템 설계의 중요한 측면인데요. 앞서 설명드린 다중화, 부하 분산, 페일오버 메커니즘, 데이터 복제와 같은 전략을 구현한다면 높은 가용성의 시스템을 설계할 수 있을 것입니다.
Top 1% 개발자로 거듭나는 확실한 처방전, 데브필입니다.
댓글
의견을 남겨주세요