[기술이 장르가 되는 곳, kt cloud] 케클러 인터뷰 시리즈 #2 장애에도 서비스가 멈추지 않는 ‘Multi-AZ’ 엔지니어링 비하인드

 

 

[ kt cloud 마케팅커뮤니케이션팀 ]

📋 요약

‘기술이 장르가 되는 곳, kt cloud의 케클러 인터뷰 시리즈’는 케클러들의 목소리를 통해, 고객의 다음 문제를 먼저 고민하는 kt cloud의 기술적 지향점과 해법을 전합니다.

두 번째 호에서는 "장애를 전제로 설계한다"는 관점으로 kt cloud PLATFORM의 *Multi-AZ 아키텍처를 설계한 한승진 팀장의 고민과 엔지니어링 과정을 담았습니다.

#ktcloud #ktcloudPLATFORM #MultiAZ #DR #ActiveActive

---

케클러 인터뷰 시리즈 #2, kt cloud Foundation플랫폼팀 한승진 팀장

 

안녕하세요. kt cloud 마케팅커뮤니케이션팀입니다.

 

지난 인터뷰 시리즈의 첫 번째 호에서는 차세대 플랫폼 kt cloud PLATFORM을 밑바닥부터 다시 설계해야 했던 배경을 다뤘습니다. 이번 두 번째 이야기에서는 그 설계를 실제 아키텍처로 구현해 나가는 클라우드 플랫폼 조직의 한승진 팀장과 함께합니다.

 

클라우드 환경은 복잡해지고 있지만, 고객이 원하는 본질은 단순합니다. 바로 "서비스가 멈추지 않는 것"입니다.

특히 AI 시대의 클라우드는 단순한 인프라를 넘어, 장애 상황에서도 비즈니스가 계속 이어질 수 있어야 하는 기반입니다.

 

한승진 팀장은 여기서 한 가지 질문을 먼저 던졌습니다.

“장애가 발생한 이후 ‘복구’하는 것만으로 충분할까?”

 

그 고민 끝에 도출한 해답이 바로 kt cloud PLATFORM의 ‘Multi-AZ(Multiple Availability Zones, 다중 가용 영역)’입니다. Multi-AZ는 하나의 리전 안에서 여러 가용 영역(AZ)에 서비스를 분산 운영해, 특정 데이터센터에 장애가 발생하더라도 서비스 연속성을 유지할 수 있도록 만든 구조입니다.

 

한승진 팀장과 구성원들이 Multi-AZ 구조를 어떻게 설계했는지, 그 고민과 구체적인 엔지니어링 기록을 확인해 보세요.

 

💡 이야기를 시작하며

한승진 팀장 | kt cloud Cloud플랫폼팀

삼성SDS에서 *오픈스택(OpenStack), *쿠버네티스(Kubernetes), *셉(Ceph) 등 오픈소스 기반 클라우드 기술을 경험하며 기술 내재화 중심의 클라우드 아키텍처 역량을 쌓아왔습니다. 현재는 kt cloud에서 2026년 상반기 출시 예정인 kt cloud PLATFORM의 클라우드 아키텍처를 설계 및 고도화하며, 개발자 중심의 엔지니어링 문화와 기술 체계를 함께 만들어가고 있습니다.

이번 인터뷰의 주인공이 꼽은 ‘이 글이 필요한 분들’

↳ 데이터센터 장애 대응 시나리오를 설계해야 하는 인프라 리더 ↳ 클라우드 네이티브 기반의 Multi-AZ 구조와 실제 구현 사례가 궁금한 시니어 개발자·엔지니어 ↳ 비즈니스 연속성 확보를 고민하는 공공 및 금융 조직의 IT 리더

먼저 읽어보기

[기술이 장르가 되는 곳, kt cloud] 케클러 인터뷰 시리즈 #1 kt cloud PLATFORM 재설계 이야기

---

고객은 장애보다, 장애 이후의 복잡함을 더 싫어합니다

기존 Active-Standby DR 환경의 운영 부담과 한계

 

기존 *DR(재해 복구) 구조의 목적은 명확합니다. 장애가 발생하면 다른 *Region(리전)으로 서비스를 전환해 복구하는 것입니다.

 

하지만 실제 운영 환경에서는 여전히 두 가지 측면의 어려움이 남아 있었습니다.

 

첫째, 재해 복구를 위한 설계와 운영 부담이 고객에게 집중된다는 점입니다.

기존 DR 환경에서는 장애 발생 이후 어떤 데이터를 먼저 복구하고, 어떤 순서로 서비스를 재개할지 고객이 직접 판단해야 합니다. 백업 정책부터 복구 절차, 운영 기준까지 모두 사전에 설계해야 하므로 단순한 인프라 구성을 넘어 서비스 구조와 운영 프로세스 전반에 대한 이해가 필요합니다. 이는 별도의 전문 인력과 운영 체계를 마련해야 하는 부담으로 이어집니다.

 

둘째, 기존 *Active-Standby 기반 DR 구조의 비효율성입니다.

대부분의 DR 구조는 *Active-Standby 방식으로 운영됩니다. 평상시에는 거의 사용하지 않는 대기 시스템에도 지속적으로 인프라 비용이 발생합니다. 또한 실제 운영 트래픽을 처리하지 않기 때문에, 연 1회 수준의 모의 훈련만으로는 실제 장애 상황에서 시스템이 정상 동작할지에 대한 신뢰성을 확보하기 어려웠습니다.

 

결국 기존 DR 방식은 고객에게 복구에 대한 책임, 운영의 복잡성, 그리고 높은 비용 부담을 동시에 요구하는 구조적 한계가 있었습니다.

---

장애 이후 복구가 아니라, 장애를 전제로 설계하다

데이터센터 장애에도 서비스를 유지하는 Active-Active 아키텍처

 

장애는 피할 수 없는 예외가 아니라, 언제든 발생할 수 있는 전제로 두어야 합니다.

 

한승진 팀장이 Multi-AZ를 고민하기 시작한 이유도 여기에 있었습니다. 장애 발생 이후 복구하는 구조가 아니라, 장애 상황에서도 서비스가 지속되는 구조가 필요하다고 판단한 것입니다.

즉, 인프라 장애의 리스크를 고객이 직접 감당하는 것이 아니라, 플랫폼 레벨에서 서비스 연속성을 보장하는 방향으로 접근했습니다.

 

기존 DR 구조의 가장 큰 한계는 한쪽이 멈춰야 다른 한쪽이 가동되는 *Primary-Backup 방식에 있었습니다. 그 과정에서 발생하는 서비스 단절은 불가피합니다.

 

이에 kt cloud Cloud플랫폼팀은 *Active-Active 구조를 통해 이 문제를 해결했습니다. 평상시에도 여러 AZ가 동시에 서비스를 제공하므로, 특정 데이터센터에 장애가 생겨도 자연스럽게 서비스가 이어지도록 구현했습니다.

---

Multi-Region이 넘지 못한 물리적 ‘거리’

서울 리전 기반 Multi-AZ 환경과 서비스 연속성 구조

 

kt cloud는 이미 ‘서울-경북 리전 기반의 Multi-Region(다중 리전) 구조’를 구축해 운영하고 있었습니다. 이는 서로 다른 지역에 위치한 리전을 활용하기 때문에, 물리적 장애나 대규모 재해 대응에 강점이 있습니다.

그렇다면 왜 서울 리전 내부에 Multi-AZ 구조가 다시 필요했을까요?

 

핵심은 ‘거리’였습니다. 리전 간 거리가 멀어질수록 네트워크 지연 시간은 늘어나고, 데이터 동기화 구조는 복잡해집니다.

 

💡Multi-Region 구조에서 데이터센터 간 거리가 멀수록 고려해야 하는 기술적 요소

✅ 애플리케이션 응답 지연 ✅ 실시간 데이터 정합성 관리 ✅ 스토리지 복제 및 트래픽 라우팅 ✅ 장애 감지 및 우회 프로세스의 복잡도

 

 

특히 양쪽이 동시에 서비스를 제공하는 Active-Active 구조에서는 실시간에 가까운 데이터 동기화가 필수적입니다. Multi-Region만으로 이를 구현하면 기술적으로는 가능할지라도, 실제 서비스 관점에서는 성능 저하와 운영 복잡도가 커집니다.

그래서 한승진 팀장은 서울 리전 내부의 물리적으로 분리된 센터들을 하나의 논리적 리전으로 묶는 방식을 선택했습니다. 물리적 장애는 확실히 격리하되, 논리적으로는 하나의 리전처럼 동작하는 구조입니다.

 

결과적으로 고객 입장에서는 리전을 전환해 사용하는 번거로움 없이, 동일한 서울 리전 안에서 여러 AZ를 활용해 가볍고 직관적인 방식으로 서비스 연속성을 확보할 수 있습니다.

---

하나의 Kubernetes 클러스터를 여러 데이터센터에 펼친다는 것

여러 데이터센터에 걸쳐 동작하는 Kubernetes 기반 통합 클러스터

 

kt cloud PLATFORM의 Multi-AZ는 단순히 여러 데이터센터를 연결한 구조가 아닙니다. 클라우드 플랫폼 관점에서 컴퓨팅, 네트워크, 스토리지뿐 아니라 OpenStack과 Kubernetes까지 단일 시스템처럼 유기적으로 동작합니다.

 

이를 위해 한승진 팀장은 ‘Stretched Cluster’ 방식을 도입했습니다. 독립된 클러스터들을 이어 붙이는 대신, 하나의 플랫폼 클러스터를 여러 데이터센터에 걸쳐 확장한 구조입니다.

 

각 데이터센터는 물리적으로는 독립되어 있지만, 플랫폼 관점에서는 하나의 통합된 클러스터로 움직입니다. 이를 구현하기 위해 인프라부터 애플리케이션 계층까지 관통하는 정교한 설계 과정을 거쳤습니다.

 

💡Stretched Cluster 설계 시 필수 검증 요소

✅ 데이터센터 간 안정적인 연결을 위한 네트워크 전용망 ✅ 초저지연 스토리지 데이터 동기화 기술 ✅ 레이턴시를 최적화한 서비스 호출 흐름 설계

 

하지만 이 설계는 단순히 클러스터의 범위를 물리적으로 확장하는 것에서 끝나지 않습니다.

 

특정 컴포넌트를 어느 AZ에 배치할지, 어떤 호출을 AZ 내부에서 처리할지, 어떤 데이터에 실시간 동기화를 적용할지 등 플랫폼 스택 전반에 걸친 세밀한 최적화 과정이 수반되었습니다.

---

2개의 AZ 환경에서도 쿼럼(Quorum)을 유지하는 해법

쿼럼 유지를 위한 3개 장애 도메인 기반 Multi-AZ 설계

 

Multi-AZ 설계 과정에서 마주한 기술적 병목은 *Raft 계열 클러스터가 요구하는 *쿼럼(Quorum, 과반수 정족수) 구조였습니다.

 

*ETCD, *OVN과 같은 시스템은 장애 상황에서도 데이터 정합성을 유지하기 위해 반드시 과반수 쿼럼의 합의가 필요합니다. 문제는 두 개의 데이터센터만으로 Active-Active 구조를 구성할 때 발생합니다. 이 경우, 한쪽 데이터센터에 장애가 생기거나 센터 간 네트워크 단절이 발생하면 과반수 판단이 불가능해져, 자칫 전체 리전의 장애로 이어질 수 있기 때문입니다.

 

한승진 팀장은 이 문제를 해결하기 위해 두 개의 서비스 AZ 외에, 별도의 데이터센터에 ‘Satellite Zone’ 개념을 도입했습니다.

‘Satellite Zone’은 고객 워크로드를 처리하지 않고, 오직 쿼럼 유지를 위한 ‘컨트롤 플레인 전용 존'으로 기능합니다. 즉, 고객 서비스는 두 개의 AZ에서 효율적으로 운영하되, 내부적으로는 세 번째 판단 지점(Satellite Zone)을 확보해 '총 3개의 장애 도메인’을 구성한 것입니다.

 

이로써 특정 데이터센터가 중단되더라도 남은 영역에서 과반수 쿼럼을 유지할 수 있고, 플랫폼 제어 기능이 지속될 수 있습니다.

---

Multi-Region이 비즈니스의 생존이라면, Multi-AZ는 운영 연속성이다

장애 상황에서도 운영 연속성을 지원하는 kt cloud PLATFORM

 

한승진 팀장은 마지막으로 “Multi-Region이 비즈니스의 생존을 책임졌다면, Multi-AZ는 비즈니스의 ‘완벽함’을 책임집니다.”라고 덧붙였습니다.여기서 말하는 ‘완벽함’은 장애가 없는 상태가 아닙니다. 오히려 장애가 발생하더라도 고객의 서비스와 비즈니스의 흐름이 끊기지 않는 ‘운영 연속성’을 의미합니다.

 

한승진 팀장과 Cloud플랫폼팀은 Multi-AZ를 통해 고객이 인프라 장애를 의식하지 않고 비즈니스 본질에만 집중할 수 있도록, 플랫폼 최하단에서 서비스가 지속될 수 있는 환경을 만들었습니다.

 

이는 단순히 여러 데이터센터를 연결하거나 인프라를 이중화한 개념이 아닙니다. 컴퓨트, 네트워크, 스토리지, 보안, 관측성, 자동화, 장애 대응 체계, 운영 관점까지 유기적으로 연결한 아키텍처입니다. 특히 kt cloud가 수년간 다양한 고객 워크로드를 직접 운영하며 축적한 장애 패턴과 성능 요구사항이 설계의 밑거름이 되었습니다.

 

기술은 그 자체가 목적이 아닙니다. 고객의 비즈니스에 어떤 변화를 만들 수 있는지를 고민하는 출발점이어야 합니다.

기술을 하나의 장르로 만들어가는 kt cloud의 여정은 앞으로도 계속됩니다.

 

 

---

📚 관련 용어 설명

Multi-AZ(Multiple Availability Zones): 다중 가용 영역으로 하나의 리전 내에서 여러 AZ에 애플리케이션을 분산 배치하여, 한 곳의 데이터센터가 재해로 마비되어도 다른 AZ가 서비스를 받아 가용성을 보장할 수 있는 구조입니다. 쿠버네티스(Kubernetes): 클라우드 환경에서 애플리케이션의 배포·운영·확장을 자동화하는 글로벌 표준 오픈소스 기술입니다. 오픈스택(OpenStack): 클라우드용 서버(VM), 네트워크, 저장 공간을 만들어주는 오픈소스 플랫폼입니다. DR(Disaster Recovery, 재해 복구): 지진, 화재, 사이버 공격 등 재난으로 시스템이 중단되었을 때 데이터를 복구하고 서비스를 정상화하는 기술 및 프로세스를 말합니다. 셉(Ceph): 단일 클러스터에서 블록, 파일, 오브젝트를 제공하는 오픈소스 SDS(Software Defined Storage) 플랫폼입니다. Region(리전): 클라우드 서비스가 운영되는 도시/국가 단위의 물리적 장소 및 영역입니다. Active-Standby 방식의 DR 서비스: 한 리전이 주로 운영되고 다른 리전은 대기하면서 복제만 수행합니다. Primary-Backup 방식: 평상시에는 주 시스템만 운영하고, 대기 시스템은 장애 상황에서만 사용하는 구조입니다. Active-Active 방식의 DR 서비스: 2개의 리전 기반으로 서비스 운영 자원을 동시에 운영합니다. Raft 계열 클러스터: 여러 대의 서버가 하나의 팀처럼 움직이며, 중요한 결정을 내릴 때 투표를 통해 합의하는 시스템입니다. 쿼럼(Quorum, 과반수 정족수): 시스템이 정상 동작 여부를 판단하기 위해 필요한 최소 과반수 동의 기준입니다. ETCD: Kubernetes와 같은 플랫폼에서 설정 정보와 상태 데이터를 저장·관리하는 분산 키-값 저장소입니다. OVN(Open Virtual Network): OVS 위에서 동작하는 가상 네트워크 오케스트레이션 플랫폼으로 네트워크 리소스를 자동 생성 및 관리합니다.