고가용성(High Availability) 시스템을 위한 5가지 전략

Introduction

고가용성, 보통 HA(High Availability)라고 많이들 부를 텐데요. 비즈니스가 잘 되기 시작하면서 대용량 트래픽을 뒷받침할 요소들을 넣다보면 가용성에 대한 고민이 깊어질 수밖에 없어집니다. 특히 마이크로서비스 아키텍처(MSA)를 설계할 때 많은 소프트웨어 엔지니어들이 고민하는 부분이 바로 이 고가용성인데요. 서비스 간의 느슨한 결합과 독립적인 배포라는 MSA의 장점을 살리면서도 시스템 전체의 안정성과 가용성을 확보하는 것이 쉽지 않은 과제이기 때문입니다. 이번에 소개해 드릴 글은 System Design Codex의 "5 Strategies for High-Availability Systems"라는 제목의 글로, 고가용성 시스템을 설계하는 데 도움이 될 만한 5가지 핵심 전략을 다루고 있습니다.

가용성(Availability)은 사용자 경험에 있어 매우 중요합니다. 매 분마다 비행기가 이륙하고 착륙하는 바쁜 공항을 운영하고 있다고 가정해봅시다. 우리가 가장 원하지 않는 것은 관제탑이 고장 나서 혼란과 지연이 일어나는 것일 겁니다.

이와 비슷하게, 24시간 온라인 서비스가 제공되는 시대에 고가용성은 일종의 성배와도 같게 되었습니다. 여러분이 주말에 친구 및 가족과 하이킹을 갈 때조차도 시스템은 항상 작동하고 운영되도록 보장해야 합니다.

그렇다면, 이를 어떻게 해야 할까요? 당연히 여러분은 휴가나 가족과의 시간을 망치고 싶지 않겠죠. 그러니 시스템의 고가용성을 확보하기 위한 몇 가지 전략을 적용해야 합니다.

아래에 소개한 5가지 중요한 전략을 살펴보겠습니다.

1. 로드 밸런싱(Load Balancing, LB)

다시 공항 예시로 돌아가보죠. 우리의 시스템이 바쁜 공항이고, 들어오는 리퀘스트가 착륙을 요청하는 비행기와 같다고 가정해 봅시다. 그런데 활주로가 단 2개밖에 없다면 어떨까요?

바로 이때 관제사가 해야 할 일은 비행기를 다른 활주로로 유도하고, 각 활주로의 부하를 관리하며, 혼잡을 야기하지 않으면서 교통량을 계속 처리하는 것일 겁니다.

로드 밸런서는 곧 애플리케이션의 항공교통관제사와 같습니다. 로드 밸런서는 CPU 사용률, 메모리 사용량, 응답 시간 등 여러 요소를 분석하여 요청을 가장 가용성이 높고 응답성이 좋은 서버로 라우팅합니다. 부하를 분산시킴으로써 단일 서버가 과부하되는 것을 방지하여 피크 부하 시에도 원활한 운영 흐름을 보장합니다.

2. 격리를 통한 데이터 복제(Data Redundancy with Isolation)

만약 특정 노선의 비행기에 문제가 생겨 운항할 수 없게 되면 어떻게 될까요? 탁월한 고객 서비스를 제공하는 효율적인 항공사를 운영하고 있다면, 승객들을 목적지까지 데려다 줄 예비 항공기를 갖추고 있을 것입니다.

애플리케이션의 데이터 복제도 마찬가지입니다. 여기서 데이터 복제(Redundancy, 혹은 Replication)란, 여러 데이터 센터나 클라우드 리전(region)에 걸쳐 데이터의 복사본을 여러 개 저장하는 것을 포함합니다.이렇게 하면 한 데이터 센터에서 장애나 중단이 발생하더라도 사용자는 다른 위치에서 데이터에 계속 엑세스할 수 있습니다.

데이터베이스 복제, 객체 스토리지, 분산 파일 시스템은 바로 데이터 복제를 구현하는 데 일반적으로 사용되는 기술입니다.

3. 장애 조치(Failover)

스카이다이빙을 하러 갔다고 해봅시다. 땅으로 떨어지는 와중에 등에 매달린 유일한 낙하산에 결함이 있다는 것을 깨달은 적이 있나요? (아마도 그렇지 않겠지만) 만약 그런 상황이라면 쉽게 펼칠 수 있는 보조 낙하산이 있기를 간절히 바랄 테죠. 시스템 설계의 맥락에서 장애 조치(Failover)는 그 낙하산과 같습니다.

장애 조치란 주요 구성 요소가 실패할 때, 시스템이나 서비스를 주요 구성 요소에서 대기 또는 백업 구성 요소로 자동 전환하는 것을 의미합니다. 이는 네트워크 트래픽을 백업 서버로 전송하거나, 보조 데이터베이스로 전환하거나, 사용자를 미러링된 애플리케이션 인스턴스로 리디렉션하는 것을 포함할 수 있습니다.

장애 조치 메커니즘은 일반적으로 로드 밸런서, 애플리케이션 서버 및 데이터베이스 관리 시스템에 내장되어 있어 사용자의 가동 중단 시간을 최소화하면서 신속한 전환을 보장합니다.

4. 오토 스케일링(Auto scailing)

고가용성 관점에서 오토 스케일링은 전투 시나리오의 요구 사항에 따라 추진력을 조정할 수 있는 강력한 전투기에 비유할 수 있습니다.

시스템 설계에서 이 전략은 현재 부하 및 사용 패턴에 따라 컴퓨팅 자원(가상 머신, 컨테이너 또는 서버리스 기능 등)을 동적으로 할당하거나 할당 해제하는 것을 뜻합니다.

오토 스케일링은 CPU 사용률, 메모리 사용량 또는 들어오는 요청 비율과 같은 메트릭에 의해 트리거될 수 있으며, 종종 클라우드 플랫폼 서비스 또는 맞춤형 스케일링 알고리즘을 사용하여 구현됩니다.

사용자 트래픽이 변동할 때, 오토 스케일링은 시스템이 부하를 처리하는 데 필요한 용량을 항상 확보해 성능 저하나 중단을 방지합니다.

5. Rate Limiting(호출 제한)

매우 바쁜 공항의 활주로가 15분마다 단 두 번의 착륙만 처리할 수 있다고 상상해 보세요. 더 많은 착륙을 시도하면 사고가 발생해 활주로를 완전히 망가뜨리게 될 것입니다. 승객의 생명을 위험에 빠뜨리는 것은 말할 것도 없죠. 이 경우 관제사는 15분마다 2대의 비행기만 착륙할 수 있도록 들어오는 비행기를 조정함으로써 호출 제한기(Rate Limiter) 역할도 합니다.

사용자 요청과 관련하여 애플리케이션에도 동일한 개념이 적용됩니다. 이 전략은 초당 또는 분당 고정된 수의 요청과 같이 주어진 시간 프레임 내에서 사용자 또는 시스템이 요청할 수 있는 수에 제한을 두는 것을 포함합니다.

호출 제한은 로드 밸런서, 웹 서버 또는 애플리케이션 수준과 같은 다양한 계층에서 구현될 수 있습니다. 단일 사용자 또는 시스템이 모든 리소스를 사용하는 것을 방지함으로써 호출 제한은 모든 사용자에게 공정하고 안정적인 서비스를 보장하고 갑작스러운 트래픽 급증으로 인해 시스템이 과부하되는 것을 방지합니다.

자, 여러분들은 애플리케이션의 가용성을 향상시키기 위해 다른 어떤 전략을 사용해 보셨나요? 댓글을 남겨주세요 :)

Top 1% 개발자로 거듭나는 확실한 처방전, 데브필이었습니다.