Samsung Cloud Platform(SCP)을 활용한 클라우드 DR 구축

DR의 필요성

매스컴을 통해 아래의 대표적인 IT 서비스 중단 사건들에 대해 들어본 적 있으신가요?

첫 번째는 2017년 직원 오타로 인한 A사 북부 버지니아 Region 서비스 중단
두 번째는 2022년 판교 IDC 화재로 인한 메신저 서비스 불가
세 번째는 2023년 전산 장비 결함으로 인한 국가 행정망 서비스 마비

세 차례의 사건은 인적 실수, 화재 또는 장비 결함이라는 서로 다른 원인으로 발생했지만, 결과적으로 재해복구 시스템 및 프로세스의 부재로 오랜 시간 동안 서비스 중단을 야기하였고, 이로 인해 사용자의 불편을 초래했을 뿐만 아니라 기업의 신뢰도를 실추시켰다는 공통점을 지니고 있습니다.

이와 같이, 평상시에는 존재의 필요성을 느끼지 못하지만 재난 재해로 인한 장애가 발생했을 때에는 서비스의 연속성 유지와 더 나아가 기업의 가치를 유지시켜 주는 것이 바로 재해 복구, Disaster Recovery(이하 DR)라고 볼 수 있겠습니다.

[그림1] IT 서비스 중단 사건들

DR 구성 시 고려 사항

위의 사례를 통해 알 수 있듯이 DR의 목적은 서비스의 연속성이라고 볼 수 있으며 이를 위해 DR의 구성 목표와 구성 레벨을 정하는 과정이 필요합니다.

1) DR 구성 목표

DR 구성 목표는 크게 RPO(Recovery Point Objective)와 RTO(Recovery Time Objective) 2가지로 나눌 수 있습니다.

RPO는 재해 발생시 감수할 수 있는 데이터 손실 수준을 의미합니다. 예를 들어, 금융 서비스와 같이 주요한 트랜잭션이 상시 발생되는 워크로드의 경우에는 RPO를 Near Zero에 가깝게 유지하는 것이 중요하고, 시스템의 비 중요 정보성 로그 저장 서비스의 경우에는 수 시간의 RPO도 수용할 수 있습니다.

RTO는 재해 발생 시 서비스를 복구하는 데까지 소요되는 서비스 중단 시간을 의미합니다. 예를 들어, 3시간의 서비스 중단을 허용할 수 있는 시스템의 경우에는 RTO를 3시간으로 설정할 수 있으며, 24시간의 서비스 중단을 허용할 수 있는 시스템의 경우에는 RTO를 24시간으로 설정할 수 있습니다.

이처럼 RPO와 RTO는 재해 발생시 서비스를 복구하기 위해 사용되는 주요한 개념으로, 기업은 재해 복구 전 워크로드를 분석하여 적합한 RPO와 RTO를 선정하는 것이 매우 중요합니다.

[그림2] RPO와 RTO

2) DR 구성 레벨

DR 구성 레벨은 위에서 언급한 RTO와 RPO를 기반으로 크게 Cold, Warm, Hot, Mirror의 4가지 종류로 나눌 수 있습니다.

① Mirror Level: 실시간 복제 기반인 Active-Active 상태로 구축하는 방식입니다. 재해가 발생하더라도 DR 센터에서 서비스를 지속적으로 운영할 수 있습니다. 하지만, 가장 높은 초기 투자와 유지 보수 비용이 발생하기 때문에 미션 크리티컬한 워크로드에 적합합니다.
② Hot Level: 실시간 복제 기반인 Active-Standby 상태로 구축하는 방식입니다. 재해가 발생하면 복제를 중단하고, DR 센터로 운영을 전환하여 서비스를 재개할 수 있기 때문에 중요 시스템에 적합합니다.
③ Warm Level: 서비스의 중요도가 높은 시스템을 위주로 DR 센터에 구축하는 방식입니다. 또한, 주 센터와 DR 센터 간 실시간 복제가 이루어지지 않기 때문에 주기적으로 동기화하는 과정이 요구됩니다. 단, 재해 발생 시 나머지 시스템의 자원을 할당하고 증설한 뒤에 서비스를 재개할 수 있어 데이터 손실이 발생할 수 있고, 서비스 복구까지 오랜 시간이 소요될 수 있습니다. 하지만 상대적으로 Mirror Site와 Hot Site 대비 초기 투자 및 유지보수 비용이 저렴한 장점을 지니고 있습니다.
④ Cold Level: 핵심 서비스의 백업 데이터만 DR 센터에 보관하며, 재해 발생 시 백업해 놓은 데이터를 기반으로 서비스 복구하는 방식입니다. 초기 투자 비용 및 유지 보수가 가장 저렴하나 백업 주기에 따라 데이터 손실이 발생할 가능성이 큽니다. 또한 재해 복구 시 DR 센터에 신규로 시스템 자원을 할당하고 구성해야 하므로 복구에 오랜 시간이 소모될 수 있어 중요도가 낮은 워크로드에 적합합니다.

[그림3] DR 구성 Level에 따른 특징

3) DR 구성 방식

이러한 DR 구성 목표와 DR 구성 레벨을 기반으로 Legacy와 Cloud 두 가지의 DR 구성 방식을 적용할 수 있습니다.

Legacy 방식의 경우, 주 센터와 일정 거리 이상 떨어진 DR 센터 및 상면 등의 물리적인 공간을 확보해야 하며, 주 센터와 호환성이 일치하는 H/W를 구매한 뒤 수주에서 수개월의 배송 기간을 기다린 뒤에나 시스템 세팅이 가능합니다. 뿐만 아니라 구매한 H/W에 대해 담당자의 지속적인 관리 및 유지보수가 필수로 요구되며 DR 센터의 자원을 상시 구동 시켜 놓아야 하는 특징이 있습니다. 이후 복잡한 과정을 거쳐 장애 복구 모의훈련을 진행할 수 있으며 자원을 증설하는데 확장성과 신속성이 떨어지는 단점을 지니고 있습니다.

Cloud 방식의 경우, 물리적인 DR 센터, H/W를 확보할 필요가 없으며 시스템 구성을 위한 대기 시간 없이 필요로 하는 가상화 자원에 대해 즉시 배포 가능한 특징을 지니고 있습니다. 뿐만 아니라, 가상화 자원이 구동되는 H/W에 대해서는 Cloud 서비스 사업자가 관리하기 때문에 사용자의 관리 및 유지보수 공수가 불필요하고, 사용자는 DR 구성 Level에 맞춰 최소한의 자원만 구동 시킬 수 있으므로 비용적으로 경제적입니다. 그리고 사용자 콘솔의 서비스 신청과 버튼 클릭 몇 번 만으로 장애 복구 모의 훈련이 가능하며 필요 시 자원 증설 또한 손쉽게 가능하므로 신속성과 확장성 면에서 장점을 지니고 있습니다.

[그림4] DR 구성 방식 비교

SCP DR 소개

Samsung Cloud Platform (이하 SCP)은 앞서 살펴본 Cloud 기반의 특징 외에도 다양한 DR 상품 및 서비스를 제공하고 있습니다. 또한, SCP는 국내 CSP 중에서 Compute, Networking, Storage, Database 등 가장 많은 DR Managed 상품과 서비스를 지원하고 있으며 특징을 요약하면 아래와 같습니다.

① 안정성
- 친환경, 고성능, 고보안 글로벌 최고 수준의 데이터센터 (상암, 수원, 동탄, 춘천)
② 가용성
- 데이터센터 간 고성능 네트워크 및 이중화 구성으로 문제 발생 시 중단없이 실시간 서비스 복구 가능
③ 경제성
- Virtual Server DR은 평소 Off하여 인스턴스 비용 Zero로 운영 가능
- 평상시 최소한의 인스턴스를 운영하고 재해/훈련 시 자동 확장 가능
④ 편의성
- All in one DRaaS 제공: 인프라뿐만 아니라 네트워크 연동을 위한 전용 회선 제공
- 폭 넓은 시스템 호환: 다양한 복제 S/W 제공(Marketplace), Oracle DB Service 제공
- DR Recovery Plan 기능 제공: 모의 훈련, 모의 훈련 자원 정리, 재해 복구 서비스
- 재해 복구/모의훈련 모니터링: 재해 복구/모의 훈련 진행 현황에 대한 모니터링 대시보드 제공

[그림5] SCP 상품의 DR 기능 및 특징

클라우드 DR 구축 Use Case (SCP 기반의 DR 구축 사례)

다양한 DR 상품 및 서비스를 가진 SCP를 활용한다면 SCP Region 간 DR 구축뿐만 아니라 On-Premise 또는 타 CSP에서 운영 중인 시스템의 DR 또한 효과적으로 구축할 수 있습니다. SCP를 활용한 DR 구축 방법 中 Hot, Cold Level의 주요한 Use Case에 대해 자세히 살펴보도록 하겠습니다.

[그림6] SCP DR 구축 Use Case 요약

1. SCP to SCP DR (Hot Level)

1) 구성 목표
- SCP 내 구성되어 있는 서비스를 SCP DR Region에 동급의 가용성 기반으로 구축
- 데이터 손실 없으며 수 시간 내 복구 목표 (RPO: Near 0, RTO: 3 시간)
- 재해 시 복제를 중지하고 DR 센터에 있는 자원을 가동하여 서비스 재개

2) OS 구성
- SCP DR 센터 내 신규 Virtual Server DR 생성
- 평상시 Virtual Server DR OS의 Power Off 상태 유지하며 재해 발생시 Power On

3) Data 복제
- WEB/APP: Virtual Server DR 상품을 이용하여 Data 변경 분 복제
- DB: DBaaS Replica 기능을 이용하여 DB 변경 분 복제
- Storage: File/Object Storage DR 복제 기능을 활용하여 Storage 변경 분 복제

4) SCP 필요 상품 및 기능
- VPC 내에서 제공하는 VPC Peering 기능
- Virtual Server DR
- DBaaS의 Read Replica 기능
- File Storage의 DR 복제 기능
- Object Storage의 DR 동기화 기능

5) 고객 준비 요소
- N/A

6) 아키텍처

[그림7] SCP to SCP DR 구축 (Hot Level)

① SCP West Region(주 센터)과 SCP East Region(DR 센터)을 VPC Peering으로 연동한다.
② WEB/APP 용도의 Virtual Server의 경우, Virtual Server DR 상품을 통해 SCP East Region(DR 센터)에 DR Virtual Server를 생성한다. 재해 상황 또는 모의 훈련 진행 시 DR Virtual Server를 주 Virtual Server로 사용한다.
③ DBaaS 경우, 타 Region Replica 구성을 통해 데이터를 비동기 복제하며 재해 상황 시 DR Replica를 Master로 승격하여 주 Database로 사용한다.
④ File Storage의 경우, SCP West Region(주 센터)의 File Storage에서 DR 복제 기능을 이용하여 SCP East Region(DR 센터)에 복제 볼륨을 구성한다. 복제 주기와 동기화 정책 설정 후 볼륨이 복제된다. 재해 상황 시 동기화를 중단하고 복제 볼륨을 R/W 모드로 변경하여 사용한다.
⑤ Object Storage의 경우, SCP West Region(주 센터)의 Object Storage에서 DR 동기화 기능을 이용해 SCP East Region(DR 센터)의 Object Storage (DR)로 Bucket 단위 비동기 복제를 진행한다. 재해 상황 시 Object Storage (DR)의 Bucket (DR)을 End Point로 접근하여 사용한다.

2. SCP to SCP DR (Cold Level)

1) 구성 목표
- SCP West Region(주 센터) 내 저장되어 있는 데이터 中 소산이 필요한 데이터에 대해 백업 & 복구 방식으로 구축
- 사용자가 정의한 주기와 목표 일정 내 복구 (RPO & RTO: 사용자 정의)
- 재해 시 SCP East Region(DR 센터)에 백업해 놓았던 이미지를 복구하여 서비스 재개

2) OS 구성
- SCP East Region(DR 센터)에 신규 Virtual Server 생성 후 평상 시 전원 Off

3) Data 백업
- SCP West Region(주 센터)의 Object Storage에서 DR 동기화 기능을 이용해 SCP East Region(DR 센터)의 Object Storage (DR) 로 Bucket 단위 비동기 복제

4) SCP 필요 상품 및 기능
- VPC 내에서 제공하는 VPC Peering 기능
- Object Storage의 DR 동기화 기능

5) 고객 준비 요소
- N/A

6) 아키텍처

[그림8] SCP to SCP (Cold Level)

① SCP West Region(주 센터)과 SCP East Region(DR 센터)을 VPC Peering으로 연동한다.
② SCP East Region(DR 센터)에 DR용 Virtual Server를 생성 후 평상시 전원을 Off 시켜 놓는다.
③ SCP West Region(주 센터) 내 Virtual Server의 데이터를 Object Storage에 주기적으로 백업한다.
④ SCP West Region(주 센터)의 Object Storage에서 DR 동기화 기능을 이용해 SCP East Region(DR 센터)의 Object Storage (DR) 로 Bucket 단위 비동기 복제를 진행한다.
⑤ 재해 발생 시 SCP East Region(DR 센터) 내 Object Storage (DR)의 데이터를 복구하여 서비스를 재개한다.

3. On-Premise to SCP DR (HOT Level)

1) 구성 목표
- On-Premise 또는 타 CSP에 구성된 이기종 시스템의 서비스를 SCP에 동급의 가용성 기반으로 구축
- 데이터 손실 없으며 수 시간 내 복구 목표 (RPO: Near 0, RTO: 3 시간)
- 재해 시 복제를 중지하고 SCP에 있는 자원을 이용해 서비스 재개

2) OS 구성
- SCP DR 센터 내 신규 Virtual Server 생성
- OS Migration S/W를 이용하여 주 센터 OS Migration (최초 1회 수행)

3) Data 복제
- WEB/APP: Data 복제 S/W를 이용하여 Data 변경 분 복제
- DB: DB 복제 S/W를 이용하여 DB 변경 분 복제

4) SCP 필요 상품
- Transit Gateway
- OS Migration S/W (SCP Market Place 제공, e.g. ZConverter)

5) 고객 준비 요소
- Customer Edge (라우터 또는 L3 스위치), 전용회선
- Replication Server
- Data 복제 S/W (고객 BYOL, e.g. Ark for FD, Arcserve 등)
- DB 복제 S/W (고객 BYOL, e.g. Ark for CDC, X-Log 등)

6) 아키텍처

[그림9] On-Premise to SCP (Hot Level)

① On-Premise (주 센터)과 SCP (DR 센터)의 Transit Gateway를 전용 회선으로 연동한다.
② SCP (DR 센터)에 DR용 Virtual Server를 생성한다.
③ OS Migration S/W를 이용해 On-Premise (주 센터)의 OS를 SCP (DR 센터)로 Migration한 뒤 초기 OS 구성을 완료한다.
④ WEB/APP 서버의 Data 복제 S/W를 이용하여, OS 구성 이후 On-Premise (주 센터)의 WEB & APP 서버에서 변경되는 데이터에 대해 비동기 복제를 수행한다. (이때 사용하는 Data 복제 S/W에 따라 Replication Server 구성 여부를 결정한다.)
⑤ DB 서버의 DB 복제 S/W를 이용하여, OS 구성 이후 On-Premise (주 센터)의 DB 서버에서 변경되는 데이터에 대해 비동기 복제를 수행한다. (이때 사용하는 DB 복제 S/W에 따라 Replication Server 구성 여부를 결정한다.)
⑥ 재해 발생 시 Data / DB 복제를 중단하고 SCP (DR 센터)의 자원을 이용하여 서비스를 재개한다.

4. On-Premise to SCP DR (Cold Level)

1) 구성 목표
- On-Premise 또는 타 CSP에 구성된 데이터 中 소산이 필요한 데이터를 SCP에 백업 & 복구 방식으로 구축
- 사용자가 정의한 주기와 목표 일정 내 복구 (RPO & RTO: 사용자 정의)
- 재해 발생 시 백업해 놓았던 데이터를 복구하여 서비스

2) OS 구성
- SCP DR 센터 내 신규 Virtual Server 생성 후 평상 시 전원 Off

3) Data 백업
- On-Premise (주 센터) 데이터를 전용회선으로 연결된 SCP (DR 센터)의 Object Storage에 백업

4) SCP 필요 상품
- Transit Gateway
- Object Storage

5) 고객 준비 요소
- Customer Edge (Router 또는 L3 Switch)
- 전용회선
- Backup Server

6) 아키텍처

[그림10] On-Premise to SCP (Hot Level)

① On-Premise (주 센터)과 SCP (DR 센터)을 전용 회선으로 연동한다.
② SCP (DR 센터)에 DR용 Virtual Server를 생성 후 평상시 전원을 꺼 놓는다.
③ On-Premise (주 센터) Backup Server를 SCP Region (DR 센터)의 Object Storage에 연결하고 주기적으로 백업한다.
④ 재해 발생 시 SCP (DR 센터)의 Virtual Server 전원을 켜고 Object Storage에 백업해 놓았던 데이터를 복구하여 서비스를 재개한다.

마무리

DR 구축은 단위 상품이 아닌 다양한 상품을 복합적이고 유기적으로 구성해야 하고, 동시에 경제성, 가용성, 확장성, 안정성 등의 여러 요소를 충족시켜야 하는 영역입니다. 이러한 관점에서 보면 Legacy 형태의 DR 구축 방식은 급변하는 비즈니스 환경을 대응하기에 많은 한계가 존재합니다. 가장 많은 DR 상품과 서비스를 보유하고 있는 SCP를 활용하여 기업의 DR을 구축한다면 앞서 언급한 한계점을 극복하고 고객의 비즈니스 가치를 향상시킬 수 있는 계기가 되리라 생각합니다.