고가용성(HA) 아키텍처: Active-Active vs Active-Standby 구성 전략

 멈추지 않는 서비스의 비밀, 고가용성(HA)

"서버가 죽었습니다." IT 담당자에게 이보다 끔찍한 말은 없을 것입니다. 서비스 중단은 곧 매출 하락과 신뢰도 추락으로 이어지기 때문입니다. 이를 방지하기 위해 시스템이 24시간 365일 정상적으로 운영되도록 설계하는 것을 고가용성(HA, High Availability)이라고 합니다.

HA 아키텍처의 기본 원리는 간단합니다. '하나가 고장 나면 다른 하나가 대신한다'는 이중화(Redundancy)입니다. 하지만 이 두 개의 시스템을 평소에 어떻게 운영하느냐에 따라 전략은 크게 두 가지로 나뉩니다. 바로 Active-Active와 Active-Standby입니다.


1. Active-Standby: 든든한 예비군 전략

가장 전통적이고 보편적인 방식입니다. '주(Primary) - 부(Secondary)' 구조라고도 불립니다.


작동 원리

평상시에는 메인 서버(Active)만 트래픽을 처리하고, 대기 서버(Standby)는 가동 중이지만 실제 트래픽은 받지 않는 상태로 대기합니다. Active 서버와 Standby 서버는 실시간으로 데이터를 동기화(Replication)하며 서로의 상태를 주기적으로 확인(Heartbeat)합니다.

만약 Active 서버에 장애가 발생하면, 시스템이 이를 감지하고 즉시 Standby 서버를 Active 상태로 전환하여 서비스를 이어받습니다. 이를 페일오버(Failover)라고 합니다.


장점

  • 구축 용이성: 구조가 단순하여 설계 및 구현이 비교적 쉽습니다.
  • 데이터 정합성: 하나의 서버에서만 데이터를 쓰기 때문에 데이터 충돌 문제가 거의 발생하지 않습니다.
  • 비용 절감: Standby 서버는 트래픽을 처리하지 않으므로, 상황에 따라 Active 서버보다 낮은 사양으로 구성하거나 전원을 꺼두는(Cold Standby) 방식으로 비용을 아낄 수 있습니다. (단, 즉각적인 복구를 위해선 Hot Standby가 권장됩니다.)


단점

  • 자원 낭비: 멀쩡한 서버 한 대를 놀리고 있는 셈이므로 리소스 활용 효율이 떨어집니다.
  • 다운타임 발생: 장애 감지 후 Standby가 가동될 때까지 짧게는 수초에서 길게는 수분의 서비스 중단이 발생할 수 있습니다.


2. Active-Active: 두 마리 토끼를 잡는 전략

모든 서버가 동시에 일하는 구조입니다. '부하 분산(Load Balancing)'이 핵심입니다.


작동 원리

두 대 이상의 서버가 모두 Active 상태로 실제 트래픽을 처리합니다. 앞단에 있는 로드 밸런서(Load Balancer)가 사용자 요청을 적절히 나누어 각 서버에 전달합니다. 만약 서버 A가 고장 나면, 로드 밸런서는 A를 제외하고 서버 B에게만 모든 트래픽을 보냅니다.


장점

  • 성능 극대화: 모든 자원을 100% 활용하므로 처리 용량(Throughput)이 두 배가 됩니다.
  • 무중단 서비스: 하나의 서버가 죽어도 다른 서버가 이미 가동 중이므로, 사용자는 장애를 거의 느끼지 못합니다.
  • 유연한 확장성: 트래픽이 늘어나면 Active 서버를 계속 추가(Scale-out)하기만 하면 됩니다.


단점

  • 복잡한 구성: 여러 서버가 동시에 데이터를 쓰고 읽기 때문에 데이터 동기화가 매우 까다롭습니다. DB 설계가 잘못되면 데이터 충돌이 발생할 수 있습니다.
  • 비용 증가: 모든 서버가 고성능으로 가동되어야 하며, 장애 발생 시 남은 서버가 전체 트래픽을 감당해야 하므로 충분한 여유 자원(Over-provisioning)을 확보해야 합니다. 즉, 비용이 많이 듭니다.


3. 결정적 차이: 우리 서비스엔 무엇이 맞을까?

두 아키텍처 중 우열을 가리는 것은 의미가 없습니다. 비즈니스의 특성과 예산에 맞춰 선택해야 합니다.


Active-Standby 추천 대상

  • 예산이 제한적인 중소규모 서비스: 두 배의 리소스를 항상 켜두는 비용이 부담스러운 경우.
  • 내부 시스템(Admin): 1~2분의 짧은 다운타임이 비즈니스에 치명적이지 않은 경우.
  • 데이터 무결성이 최우선인 금융/결제 시스템: 복잡한 동기화보다 안정적인 데이터 보관이 중요한 경우.


Active-Active 추천 대상

  • 대규모 트래픽을 처리하는 커머스/포털: 평소 트래픽이 많아 부하 분산이 필수적인 경우.
  • 미션 크리티컬(Mission Critical) 서비스: 단 1초의 중단도 허용되지 않는 의료, 관제, 실시간 주식 거래 시스템 등.
  • 글로벌 서비스: 여러 지역(Region)에 서버를 두고 가까운 곳에서 응답해야 하는 경우.


4. 하이브리드 전략과 클라우드의 이점

최근에는 클라우드(AWS, Azure 등) 환경이 보편화되면서 이 두 가지 방식의 경계가 유연해지고 있습니다.

예를 들어, 평소에는 최소한의 Active-Active로 운영하다가, 장애가 발생하거나 트래픽이 폭주할 때 오토스케일링(Auto-scaling) 기능을 통해 자동으로 서버를 늘리는 방식을 사용합니다. 이는 Active-Active의 고성능과 Active-Standby의 비용 효율성을 결합한 현대적인 전략입니다.


요약 및 결론

고가용성 아키텍처는 단순히 서버를 두 대 두는 것이 아닙니다. Active-Standby는 '안전한 보험'이고, Active-Active는 '고속도로 확장'입니다.

  • Active-Standby: 비용 효율적, 관리 용이, 짧은 다운타임 허용 시 적합.
  • Active-Active: 성능 최우선, 무중단 서비스 필수, 높은 비용 감수 시 적합.

현재 운영 중인 서비스의 목표 가동률(SLA, Service Level Agreement)이 99.9%인지, 99.999%인지 먼저 확인해 보세요. 그 숫자가 여러분이 선택해야 할 아키텍처를 말해줄 것입니다.


댓글

댓글 쓰기

이 블로그의 인기 게시물

VPC 네트워크 설계: 서브넷(Subnet)을 퍼블릭/프라이빗으로 나누는 기준

  클라우드 보안의 시작, 네트워크 격리 클라우드 인프라를 구축할 때 가장 먼저 마주하는 용어 중 하나가 바로 VPC(Virtual Private Cloud) 입니다. VPC는 클라우드 내에 만드는 우리만의 가상 데이터 센터입니다. 하지만 단순히 VPC를 만들었다고 끝이 아닙니다. 이 거대한 공간을 어떻게 쪼개고(Subnetting), 어떤 용도로 사용할지 결정하는 것이 보안과 효율성을 좌우합니다. 많은 초보 설계자가 범하는 실수는 모든 리소스를 인터넷에 노출된 하나의 서브넷에 몰아넣는 것입니다. 이는 마치 현관문 없이 금고를 길거리에 두는 것과 같습니다. 오늘은 안전하고 튼튼한 인프라를 위해 서브넷을 퍼블릭(Public)과 프라이빗(Private)으로 나누는 결정적 기준을 알아보겠습니다. 1. 서브넷 분리의 핵심 원리: 라우팅 테이블과 인터넷 게이트웨이 퍼블릭과 프라이빗을 나누는 기준은 물리적인 위치가 아닙니다. 바로 ' 인터넷과 직접 통신할 수 있는가?' 입니다. 이를 기술적으로 결정하는 것은 라우팅 테이블(Routing Table) 설정입니다. 퍼블릭 서브넷: 라우팅 테이블이 인터넷 게이트웨이(IGW, Internet Gateway) 를 향해 열려 있습 니다. 외부에서 들어오는 트래픽을 직접 받을 수 있고, 내부에서 밖으로 나갈 수도 있습니다. 프라이빗 서브넷: 인터넷 게이트웨이로 가는 경로가 없습니다. 외부에서 직접 접근할 수 없으며, 내부IP(Private IP)로만 통신합니다. 2. 퍼블릭 서브넷(Public Subnet): 외부와 소통하는 접점 퍼블릭 서브넷은 외부 사용자의 요청을 가장 먼저 받아내는 '안내 데스크' 역할을 합니다. 따라서 반드시 외부 인터넷 접근이 필요한 리소스 만 이곳에 배치해야 합니다. 퍼블릭 서브넷 배치 기준 로드 밸런서 (Load Balancer, ALB/NLB): 사용자의 트래픽을 받아 뒷단의 서버로 분산시켜주는 역할을 하므로 반드시 공인 IP를 가지고 외부에 노출되어야...
자세한 내용 보기

온프레미스 vs 클라우드: 인프라 아키텍처의 결정적 차이 5가지

기업의 운명을 가르는 선택, 인프라 아키텍처 디지털 전환(DX)이 가속화되면서 모든 기업은 중요한 기로에 서 있습니다. 바로 "데이터와 시스템을 어디에 둘 것인가?"라는 질문입니다. 과거에는 회사 내부에 서버실을 구축하는 것이 당연했지만, 이제는 클라우드가 강력한 대안으로 자리 잡았습니다. 하지만 무조건적인 클라우드 전환이 정답은 아닙니다. 이 글에서는 IT 인프라의 두 축인 온프레미스(On-Premise) 와 클라우드(Cloud) 의 개념을 명확히 하고, 의사 결정에 꼭 필요한 5가지 결정적 차이를 분석해 드립니다. 1. 개념의 차이: 소유할 것인가, 빌려 쓸 것인가? 본격적인 비교에 앞서 두 개념을 가장 쉽게 이해하는 방법은 '부동산'에 비유하는 것입니다. 온프레미스(On-Premise): 직접 땅을 사고 집을 짓는 '자가 주택'과 같습니다. 하드웨어부터 네트워크, 운영체제까지 기업이 직접 구매하여 사내 전산실이나 데이터 센터 에 구축하고 운용합니다. 모든 통제권이 나에게 있습니다. 클라우드(Cloud): 필요한 만큼 공간을 빌려 쓰는 '호텔'이나 '공유 오피스'와 같습니다. AWS, Azure, Google Cloud 같은 공급자가 구축해 둔 거대한 인프라 자원을 인터넷을 통해 필요한 만큼 빌려 쓰고, 쓴 만큼 비용을 지불합니다. 2. 비용 구조: 초기 투자비용(CAPEX) vs 운영 비용(OPEX) 가장 큰 차이는 돈을 쓰는 방식에 있습니다. 온프레미스: 초기 투자 중심 (CAPEX) 온프레미스는 시스템 구축 초기에 막대한 자본적 지출(CAPEX)이 발생합니다. 서버, 스토리지, 네트워크 장비를 직접 구매해야 하며, 이를 설치할 공간과 전력, 냉각 시스템도 갖춰야 합니다. 구축 후에는 감가상각을 통해 비용을 처리합니다. 장기적으로 시스템 변경이 거의 없다면 총비용 면에서 유리할 수 있습니다. 클라우드: 운영 비용 중심 (OPEX) 클라우드는 초기 구축비...
자세한 내용 보기

로드 밸런서(ELB/ALB)의 알고리즘: 라운드 로빈 vs 리스트 커넥션

  트래픽 폭주, 서버가 버티는 비결 웹 서비스 운영 중 사용자가 급격히 늘어날 때, 단 한 대의 서버로는 모든 요청을 처리할 수 없습니다. 이때 등장하는 구세주가 바로 로드 밸런서(Load Balancer) 입니다. AWS의 ELB(Elastic Load Balancing)나 ALB(Application Load Balancer)가 대표적인 예입니다. 로드 밸런서는 들어오는 트래픽을 여러 대의 서버(EC2 등)에 골고루 나눠주는 교통경찰 역할을 합니다. 하지만 무턱대고 나누는 것이 아닙니다. ' 어떤 규칙'으로 나눌 것인가 에 따라 서비스의 안정성과 속도가 완전히 달라집니다. 오늘은 가장 대표적인 두 가지 알고리즘, 라운드 로빈(Round Robin) 과 리스트 커넥션(Least Connection) 을 비교 분석해 봅니다. 1. 라운드 로빈(Round Robin): 공평하게 순서대로 가장 기본적이고 직관적인 방식입니다. ' 순차적 분산' 이라고도 부릅니다. 작동 원리 마치 카드 게임에서 딜러가 플레이어들에게 카드를 한 장씩 순서대로 나눠주는 것과 같습니다. 서버가 A, B, C 세 대가 있다면, 첫 번째 요청은 A, 두 번째는 B, 세 번째는 C, 네 번째는 다시 A에게 보냅니다. 현재 서버의 상태나 부하량은 고려하지 않고 오직 순서 에만 입각해 트래픽을 배분합니다. 장점 단순함: 구현이 매우 쉽고 이해하기 편합니다. 리소스 소모 적음: 로드 밸런서가 복잡한 계산을 할 필요가 없어 자체 부하가 적습니다. 동일 환경에 유리: 모든 서버의 스펙이 동일하고, 처리해야 할 요청의 성격(처리 시간)이 비슷할 때 가장 효율적입니다. 단점 부하 불균형: 어떤 요청은 1초 만에 끝나지만, 어떤 요청은 1분이 걸릴 수 있습니다. 라운드 로빈은 이를 무시하고 계속 요청을 보내기 때문에, 운 나쁘게 무거운 작업만 할당받은 특정 서버가 과부하로 뻗어버릴 수 있습니다. 2. 리스트 커넥션(Least Con...
자세한 내용 보기