티스토리 뷰
DR 개요
Public Cloud와 Hybrid Cloud의 확대는 최근 IT 판도를 돌려놓고 있다. 수 많은 기업들이 차세대 프로젝트와 함께 어플리케이션 현대화(Application Modernization)를 추구하고 있고, 이를 실현하기 위해 Cloud Native으로 전환을 시도하고 있다. Cloud Native Application은 확장성, 민첩성, 복원성, 유연성, 장애복구성 등을 제공하는 분산 트랜잭션/분산 컴퓨팅 환경에 맞게 어플리케이션을 설계 및 개발하는 방식을 의미하며, 이는 Legacy System과는 다른 요소들을 포함하고 있다. 그 중 하나가 바로 이번 포스팅의 주제인 클라우드 DR의 변화이다.
Public Cloud는 DR이라는 개념을 Multi AZ(Availiable Zone)으로 상쇄시켰고(Public Cloud는 Availiable Zone을 최소 2개 이상으로 구분하여 운영환경을 Multi AZ 즉 Multi DataCenter 구조로 구성되게 구축한다. 이는 별도 DR 환경이 필요 없는 고 가용성 아키텍처를 제공한다고 볼 수 있다), Private Cloud는 기존 방식과 같은 데이터 센터의 분리(망 분리)는 물론 Public cloud를 활용하는 전략까지 다양해졌다.
우리는 지금부터 이와 같은 다양한 DR 환경에 대한 전략을 살펴보고 재해복구 환경에서 대비해야 할 부분들에 대해 알아보도록 하자.
DR 전략
DR 환경을 구성함에 따라 얻을 수 있을 것이라 기대하는 비즈니스 목표와 요구사항을 확정하는 것은 매우 중요한 일이다. 현실적으로 비용과 목표(빠른 전환, 낮은 손실 등)는 반비례하게 작용하기 때문에 명확한 비즈니스 목표를 수립하고, 이를 기준으로 적합한 아키텍처를 선정하는 작업이 선행되어야 한다.
1) DR 환경 구축 목표
DR 환경을 구축하고자 하는 목표 수준을 정의한다.
- "재해 발생 시" < 재해에 대한 수준 정의 필요
- 재해 복구 환경을 통해 얻고자 하는 목표 정의 필요
예를 들어 회사의 수익 감소 대비 재해 복구 시스템 운영 비용의 비율이나, 단순 회사의 이미지에 영향을 줄수 있다는 점 등을 상세히 기입해야 한다.
DR 환경 구축 기간에 대한 목표도 제시해야 한다.
예를 들어 현 운영 중인 DR 시스템의 복구 시간이 얼마나 걸리고 이를 개선하기 위해 어떠한 인프라와 솔루션을 도입하여 얼마의 기간동안 구축하겠다는 명시적인 목표를 상세히 기입한다.
2) DR 환경 대상 선정
복제 대상, 데이터 복제 방식 기준을 정의한다.
- "DR 대상 서비스"를 선정하는 기준 정의 필요
예를 들어 비용 관점의 서비스는 Critical 기준을 수립하고, 사용자 관점에서 긴급하게 확인이 필요한 정보, 판매자 관점에서 긴급하게 변경이 필요한 정보 등을 대상으로 선정함 등의 상세한 기준 수립이 필요하다.
- "DR 대상 서비스 데이터 복제" 방식 기준 정의 필요
예를 들어 비용관점의 정보는 유실이 발생하지 않아야 하므로, 미러링 방식을 선택하고, 배송정보나, 판매중인 상품 변경 서비스는 소급 적용 등을 통해 변경이 가능하여 비용/성능 관점에서 이점을 갖기 위해 DataSync를 사용
3) DR 복제 환경
선택하게 된 기준에 대한 기준을 정의한다.
- 비용 관점에서 DRaaS를 이용할 경우, DR Center 운영 또는 Public Cloud 운영 대비 어떤 이득이 있는지?
- 데이터 유실 관점에서 DRaaS를 사용할 경우 비용정보 서비스의 디스크 미러링에는 대응할 수 없는데 어떤 방안이 있는지
등 다각도의 선정 사항에 대한 분석이 필요하다. 특히 인프라의 결정은 이후 되돌리기 어려운 사항이므로, 신중한 검토를 진행해야 한다.
4) DR 복구 시간
RTO 시간은 재해를 선언하는데 소요되는 시간을 포함하지 않기 때문에 그 시간에 대한 정의는 온전히 다음 절차만의 시간을 포함해야 한다.
- 재해 발생 선언 이후 인프라 기동, 솔루션 기동, 어플리케이션 배포에 소요되는 시간
- 어플리케이션 검증 시간
- 데이터 검증 시간
- 네트워크 절체 시간 (DNS 라우팅 처리 등)
즉 RTO는 빠를 수록 좋지만, 정확한 검증 없는 DR 서비스 오픈은 Side-Effect를 나타낼 수 있기 때문에, 현실적인 목표를 정의하는 것이 중요하다.
5) DR 복구 데이터
RPO에 대한 시간은 서비스 유실이 발생해도 되는지 여부, 발생가능하다면, 얼마까지 허용가능한지에 대한 여부를 통해 정의한다.
- 예를 들어,
- 핵심서비스의 경우 데이터 손실은 허용되지 않음.
- 중요서비스는 10분의 데이터 손실을 허용하되 다음 날 운영환경 복원 시 일괄 복구 절차를 진행 (배치 처리, 소급 적용)
- 비핵심서비스는 데이터 손실을 8시간으로 정의
- 정보성서비스는 데이터 복제를 수행하지 않음
와 같은 서비스 별 데이터 복제 방식을 정의할 필요가 있다.
6) DR 복구 절차
DR 복구 절차는 실 고객이 수행해야 하는 절차서로 최대한 상세하게 작성해야 하며, 절차에 대한 수행 테스트 즉 재해복구 테스트가 정기적으로 수행되어 변화 사항에 대응할 수 있어야 한다.
특히 현재 대부분의 내용은 PROD to DR 환경에 대한 복제에 대해서만 다루고 있지만, 결국 PROD 환경은 복원 될 것이고, 복원된 이후 DR 환경의 데이터를 반영하는 방법에 대한 정의 역시 고려되어야 한다.
예를들어,
- MariaDB Replication 복제 방식에 대한 역 방향 복제
- DataSync 파일 역 방향 복제
- 그 밖의 솔루션 레벨의 역 방향 복제 기능 검증 (GitLab, Harbor 이미지 Replication 등)
위와 같은 DR 전략을 수립한 이후 DR 환경에 대한 세부 설계에 들어가게 된다.
7) DR 환경 구축 성공 여부 측정
마지막으로 DR 전략에 대한 성공 판단 여부를 수립해야 한다. 성공적인 DR 전략을 수립하려면 조직에서 성공적인 전략이 무엇인지 정의하고 명확하게 설명해야 한다.
DR은 서로 다른 비즈니스 및 아키텍처 목표로 인해 서로 다른 목표를 갖을 수 있다.
- 구현을 위해 정의된 예산, 시간에 대한 달성 여부
- 중요 비즈니스 서비스 또는 어플리케이션에 대한 복구 전략
- 특정 시간까지 복구 대상 아플리케이션에 대한 구현 및 테스트
DR 고려사항
최근 차세대 프로젝트를 Cloud Native로 진행했던 사이트는 재해복구 환경을 구성하기 위해 많은 고민을 했을 것이다. As-Is 시스템의 경우 운영환경과 DR환경에 대한 망 분리 규칙에 따라 데이터센터 분리를 우선적으로 고려하여 On-Premise 환경에 구성하였다. 이와 더불어 Public Cloud를 DR 환경으로 선택하는 것은 최선의 선택이 될 수 있지만, 아래와 같은 고려사항들에 대해 고민해야 한다.
바로 어디로 어떻게 복제할 것인지에 대한 부분을 고려해야 하며, 서두에서 이야기 했듯이 Public Cloud는 이미 AZ에 대한 고가용성을 확보하고 있고, Private Cloud의 DR에 대한 부분을 고려한다는 점을 인지하고 다음을 참고하기 바란다.
※ 3rd Party 솔루션 구축 제약
먼저, 퍼블릭클라우드에 적용 가능한 3rd party 솔루션의 제약사항이 있다. On-premise에 적용된 솔루션들은 때때로 해당 도메인에서 충족해야 하는 컨플라이언스를 구현한 기능들을 탑재하고 있다.
예를 들어 금융기관의 금융감독원에 제출하기 위한 자료를 추출하기 위해 형상관리 솔루션에 운영이관 이력, 감사 로그, 승인 여부, 체크인/체크아웃 이력 등을 저장하는 기능을 만들었다고 했을때, 해당 솔루션이 public cloud 환경을 지원하지 않는다면, 대체하는 솔루션을 찾아내는 것은 쉽지 않을 것이다.
이는 특정 국가의 특정 도메인에 특정 기능을 커스터마이징한 것이기 때문에 범용 기능이라 보기 어렵고, 오랜 기간 누적된 기술에 대한 분석 및 커스터마이징에 적지 않은 시간이 소모될 수 있다.
※ RTO / RPO Zero
RTO/RPO 제로를 요구하는 시스템의 경우 적합하지 않다. Cloud DR을 사용할 경우 복구 시간과 복구 데이터에 대한 유실이 제로로 유지될 수 있는가? 이를 달성하기 위해서는 아래와 같은 조건이 만족되어야 한다.
DR 시스템은 상시 기동된 상태로 유지되어야 한다.
DR로 복제되어야 할 데이터/파일 등은 실시간 복제가 이루어져야 하며, 이는 운영 시스템에 영향을 줄 수도 있다.
Rto/rpo 제로를 달성하기 위해서는 위과 같은 선행 조건이 필요하지만, 이는 public cloud가 추구하는 지향점과는 거리가 멀다. On-Premise와 Public Cloud DR 사이에는 몇가지 조건에 따라 복구 시간과 복구 데이터에 대한 유실을 최소화 할 수 있지만, 이는 Public Cloud를 DR 환경으로 사용하는 비용효율성 측면(매몰 비용 감소)에 반대되는 설계가 될 것이고, 그럴 경우 굳이 Public Cloud를 사용해야 하는가에 대한 의문이 발생할 수 있다.
※ 대규모 환경 구축
비용 효율적인 측면에서 Public Cloud가 장점이 있다고 했지만, 이는 일반적인 상황이며, 수백/수천대의 VM 환경이 필요한 시스템의 경우 Public Cloud를 사용하면, 그 비용이 예상치를 뛰어 넘을 수 있다. Public Cloud의 매몰비용이라는 측면은 온전히 EC2와 같은 VM에 대한 비용적인 이점이 있지만, 사용량 기반의 비용을 지불해야하기 때문에 규모에 따라 비용이 증가할 수 있다.
※ 운영 방식의 변화
결국은 퍼블릭 클라우드의 도입은 운영 방식의 다변화를 의미한다. 결과론적으로 비용을 감소하는 만큼 운영관리하는 인력의 증가를 의미하며, 이는 인력적인 측면의 비용 감소를 감안해야 한다.
DR 재해복구 환경은 단순하게 운영 환경의 복제 환경이 아니다. 운영하고 있는 환경을 얼마나 빠르게 동일한 환경으로 복구해 낼 수 있는가를 평가의 가치로 생각하기 때문에 고려되어야 할 부분이 다수 존재한다. 지금부터는 DR를 설계하기 위해 고려해야 할 부분과 DR의 대상은 어떤 것들이 포함되어야 하는지 고민해 보자.
※ DR 고려사항
- 비즈니스 영향도 분석 : 비즈니스에서 허용하는 범위와 이를 실현할 수 있는지 고민해야 한다. 예를 들어 데이터에 대한 정합성과 데이터 실시간 복제가 필요하지 않은 서비스를 위해 불필요한 데이터 복제에 비용을 낭비할 필요가 없으며, 반대로 반드시 이를 준수해야 하는 시스템에는 이를 구현할 수 있는지를 고민하여 설계해야 한다.
- 클라이언트의 변화 최소화 : 가능한 클라이언트의 변화 즉 클라이언트가 인지할 수 없는 수준의 변화를 통해 DR을 구성해야 한다. 예를 들어, 주 센터가 무너지고, DR 센터가 가동된다고 했을때 이를 연결하는 도메인의 변화는 발생하지 않아야 한다. 이를 위해 라우터의 변동 방식에 대한 정의가 필요하며, 도메인을 지원하는 인증서에 대한 동기화 역시 사전에 이루어져야 한다.
- 비용 효율적인 접근 : DR 시스템은 필수요소이지만, 현실적으로 DR이 가동되는 현상은 매우 드물다. 즉 DR은 어찌보면 필수 아키텍처이자, 매몰 비용으로 작용하는 것이 현실이다. 이와 같이 매몰비용을 최소화 할 수 있는 방안 마련이 시급하다. 이는 Public Cloud를 DR로 활용하는 것이 최선의 선택지가 될 수 있으며, 이를 구현하기 위한 DR 환경 복제 방안과 오케스트레이션 방안을 마련해야 한다.
- 자동화 방안 마련 : 클라우드 기술은 복잡도가 높다. 현재 국내 사용되는 대부분의 재해복구자동화 솔루션(대체로 베리타스와 같은 DR 복제 솔루션과 사전 정의된 스크립트를 실행하는 솔루션, 그리고 디스크 복제 솔루션 등이 있다.)을 적용하여 DR 상황 발생 시 절체 과정을 간소화 하고 있지만, 클라우드 기술에는 아직 이를 적용하기 어려운 것이 사실이다. 따라서 가능한 간소화할 수 있는 작업들이 선행되어야 한다. 이는 스크립트화 할 수도 있고, multi cluster를 관리하는 대시보드를 통해 구현할 수도 있다.
- 지속적인 테스트 : DR 재해복구 테스트의 경우 시스템의 SLA가 중요한 서비스를 운영하는 사이트는 최소 연 1회 이상 시행하고 있다. 이는 환경적인 요소, 네트워크적인 요소, External Service의 변화적인 측면 등 서비스 내적인 부분이외의 부분을 검증하기 위해 반드시 시행되어야 한다. 또한, DR 테스트를 통해 복제 데이터에 대한 정합성을 검증하고, 네트워크, 스토리지에 대한 장애 복구 능력을 검증하기 위한 용도로써 활용되어야 한다.
※ DR 서비스의 대상
DR 서비스의 대상은 운영 관리하는 모든 시스템이 대상이 되겠지만, 긴급성과 RTO/RPO에 따라 범위는 변경될 수 있다. 즉, DR 서비스의 대상은 DR 재해복구를 통해 달성할 것이라 기대하는 기회비용의 가치에 달려 있다고 볼 수 있다.
결국 DR 시스템은 비용과 직결되는 시스템으로 DR 시스템에 포함해야 하는 어플리케이션을 다음과 같은 조건을 가지고 평가하여 대상 선정해야 한다.
- 비즈니스 영속성이 얼마나 중요한 서비스인가?
- 허용 가능한 데이터 손실 범위 (시간 또는 데이터 사이즈)
- Critical 시스템의 정의 (우선순위 정의 즉 RTO에 대한 순서의 정의)
결과적으로 금융권 시스템의 경우 비용과 관련된 서비스의 우선순위가 높고, 플랫폼 기업의 경우 개인정보에 대한 정보의 복구가 우선순위가 높을 것이며, 이를 다루는 서비스가 Critical 서비스로 운영되는 것이 현실적이다. 반대로 고객의 경험치를 향상 시키기 위해 도입된 서비스의 경우 약간의 불편함을 감수하지만, 서비스 처리에 영향을 주지 않는 서비스를 하위 복구 절차에 포함할 수 있다. 또한, 재해 상황이 복원된 이후 데이터 복원이 필요하지 않은 (DR 환경의 데이터를 다시 운영환경으로 복원할 필요가 없는)서비스는 재해복구 서비스 대상에서 제외할 수도 있다.
DR 상세 설계
지금까지 DR 재해복구 환경을 선택하는 기준에 대해 알아보았다면, 이제 본격적인 DR 아키텍처에 대해 알아보자. DR 환경은 서비스의 중요도에 따라 다양한 설계 요소를 반영할 수 있다.
특히나 이는 단순히 Infra Architecture를 선택하는것 뿐만 아니라, 솔루션에 대한 선정을 포함한다. 지금부터 아래 두가지 케이스에 대해 알아보도록 하자.
- Case 1: On-Premise 데이터 센터 → On-Premise 데이터 센터로의 DR
- Case 2: On-Premise 데이터 센터 → Public Cloud DR
※ Case 1: On-Premise 데이터 센터 → On-Premise 데이터 센터로의 DR
대부분의 조직은 여전히 자체 데이터 센터 또는 코로케이션을 기반으로 기존의 온-프레미스 인프라를 배포한다. DR을 다른 온-프레미스 데이터 센터로 구성하는 것은 가장 일반적이고 잘 알려져 있다. 메인프레임 및 UNIX 플랫폼을 포함하여 사용 가능한 모든 애플리케이션 및 플랫폼에 대한 DR 솔루션을 지원하며, 다중 복제 기술도 지원한다. 또한, 데이터 유실 제로 달성을 위한 디스크 미러링 기술 역시 지원한다. 이는 Active-Active 구성을 통해 완전한 데이터 동기화 환경을 구성할 수 있다. 이와 반대로 데이터 센터를 유지 관리하기 위해 비용(매몰 비용), 유지보수 인력 확보가 필요하다.
On-Premise to On-Premise Data Center의 경우 가장 많은 사례를 기반으로 안정성 측면에서 가장 큰 장점이 있다.
<장점>
- 베어메탈 및 VM을 포함한 모든 플랫폼, 엔터프라이즈 애플리케이션 및 운영 체제를 지원하는 광범위한 애플리케이션 및 인프라 호환성과 다양한 공급업체에서 검증된 솔루션 지원
- 엔터프라이즈 애플리케이션에 필요한 고성능, 고대역폭 스토리지 기반 동기식 복제 지원 (매우 강력한 장점)
- DR을 구현하기 위해 하이퍼바이저 마이그레이션 또는 운영 환경 변경이 필요하지 않다는 점은 운영 유지보수의 복잡도를 감소시키는 매우 강력한 장점. 특히 운영환경의 축소된 자원으로 구성된 완전히 미러링된 환경을 생성하여, 긴급 재해 복구 발생 시 RPO Zero를 지원
- 동일한 환경과 동일한 구성으로 이루어져 있기 때문에 운영환경과 DR 환경에 동시에 접근 가능한 대역에서 서버, 네트워킹 장비, 스토리지를 비롯하여 미들웨어, 어플리케이션까지 양쪽의 모든 기술 계층을 동시에 제어할 수 있음
이와 같은 장점을 제공하는 반면 다음과 같은 단점도 존재한다.
<단점>
- 인프라, 유지관리 인력 등 On-Premise를 운영하기 위한 대규모 선행 투자 및 망 분리 관리를 위한 또 다른 데이터 센터가 필요
- DR 센터의 데이터를 동기화하는데 필요한 운영 오버헤드 발생
- 재해 발생 시 DNS 라우팅 설정, L4 라우팅 설정 등은 수동 절체 과정을 거쳐야 함
DR 환경을 성공적으로 구축하였는가에 대한 부분은 크게 두가지 측면으로 평가할 수 있다. 그 첫번째는 얼마나 고가용성이 높고 성능을 최대한 확보한 환경을 빠르게 회복할 수 있는가이며, 두번째는 바로 데이터에 대한 정합성을 높이고 유실을 최소화 할 수 있는가이다. 바로 RTO / RPO에 대한 내용에서부터 접근해 볼 수 있을 것이다.
이 중 고가용성과 성능에 대한 부분은 솔루션 디펜드한 내용들이 많이 포함되어야 하므로, 본 포스팅에서는 제외하도록 하고, 데이터 유실을 최소화 하기 위한 데이터 복제 방식에 대해 알아보도록 하자. On-Premise 데이터 센터 간 복제에는 사용 가능한 많은 기술 옵션이 존재한다. 결국 DR 환경에 대한 데이터 복제 수준을 어떻게 가져갈 것인가가 핵심이며, 이는 데이터를 저장하는 저장소로 부터 출발할 수 있다.
<On Premise 데이터 복제 방안>
- 호스트 기반 복제 : 호스트 기반 복제는 개별 로컬 스토리지에 데이터를 적재하기 때문에, 별도 공유 볼륨에 대한 고려가 필요하지 않다. 호스트 기반 복제는 "단일" 하이퍼바이저 수준, 볼륨 수준 또는 파일 수준에서 발생한다. 이를 구현하기 위한 호스트 기반 복제 소프트웨어는 DR Fail-Over 및 Fail-Back 기능을 추가하여 보다 완전한 형태의 솔루션으로 성장하고 있다. 다만, 호스트 기반 복제의 경우 공유 볼륨이 필요하지 않은 단일 호스트 내 Object를 활용한다는 제약 조건이 존재하여 클라우드 환경에서 그 활용성은 매우 떨어진다.
- 애플리케이션 기반 확장 클러스터 : 애플리케이션 기반 확장 클러스터는 데이터 센터 장애를 극복하기 위해 두 데이터 센터에 걸쳐 애플리케이션 클러스터 기술을 구현한다. 애플리케이션 기반 클러스터는 솔루션에 따라 동기 및 비동기 장애 조치 기능을 모두 지원할 수 있으므로 Critical 시스템 복구에 적합하다. 그러나 이들은 특정 애플리케이션에만 적합한 솔루션이고, 개발/유지보수 비용이 적지않게 발생한다.
- 애플리케이션 기반 복제 : 기존 애플리케이션, 특히 데이터베이스는 항상 다른 데이터베이스로 복제 및 장애 조치하는 기술을 제공했다. 그러나 동기식 복제 기능이 부족하여 중요 시스템 복구에만 적용하는 것이 적합하다. 애플리케이션 기반 복제 솔루션은 복제가 애플리케이션을 인식하므로 스냅샷 및 기타 유사한 인스턴스를 스크립팅할 필요 없이 애플리케이션 상태 일관성이 유지된다는 장점이 있다.
- 스토리지 기반 복제 : 가장 많은 경우에서 선택되고 있는 Critical 시스템 복제에 적합한 스토리지 기반 복제이다. 이는 동기식 복제를 지원한다. 다만, 동기 복제는 자동화 구성이 어려워 관리 오버헤드를 증가 시킬 수 있다. 복제 중단 및 볼륨 re-마운트와 같은 작업이 필요에 따라 수동으로 실행해야 한다.
- 확장된 저장소 클러스터 : 확장된 스토리지 클러스터는 고급 스토리지 어레이 미러링 및 장애 조치 기능을 활용하여 2개의 물리적 데이터 센터에 분산된 단일 논리적 데이터 센터를 생성한다. 확장된 스토리지 클러스터는 호스트 중단 없이 다운타임 및 디스크 어레이 장애를 견뎌내고 데이터 센터 간 가상 머신의 라이브 마이그레이션 및 HA와 같은 가상화 기능과 함께 사용된다.
- 백업 기반 : 디스크 백업 또는 테이프로 DR을 수행하는 기존 백업 방식은 RTO/RPO가 시간 또는 일 단위로 측정되는 DR 시나리오에만 적합하다.
※ Case 2: On-Premise 데이터 센터 → Public Cloud DR
퍼블릭 클라우드는 탄력적인 컴퓨팅 및 스토리지를 갖춘 데이터 센터를 제공하기 때문에 DR 위치에 대한 새로운 옵션으로 떠오르고 있다. DR로서의 퍼블릭 클라우드는 매몰 비용을 줄이고, 특히 망 분리 원칙에 따른 두 번째 데이터 센터를 구축 및 유지 관리할 필요가 없다는 점에서 최근 많은 각광을 받고 있다.
On-Premise to Public Cloud의 경우 비용 측면에서 가장 큰 장점이 있다.
<장점>
-
하드웨어 및 데이터 센터가 유틸리티로 제공되기 때문에 초기 설비 투자가 필요하지 않고, 비용 역시 사용량 기반 차지한다.
-
보조 데이터 센터에 대한 하드웨어 또는 데이터 센터 유지 관리 비용이 없다.
-
복제, DR 오케스트레이션 및 하이퍼바이저 변환에 여러 옵션을 사용할 수 있다.
-
데이터 센터와 서비스는 CSP을 통해 즉시 사용할 수 있으므로 DR 프로젝트 실현 시간을 최소화할 수 있다. 또한 자체 DR용 데이터 센터를 구축할 필요가 없다.
최근 Naver Cloud에서는 해당 솔루션이 Managed Service로 추가되었는데, 이와 같이 솔루션의 제약 사항은 Public Cloud로의 전환에 걸림돌이 될 수 있다.
-
CSP에서 제공하는 OS는 대부분 Windows 또는 Linux에서 실행되는 가상화된 워크로드만 지원하기 때문에 대부분의 DR 시나리오에는 하이퍼바이저 마이그레이션이 필요하다. UNIX 또는 메인프레임은 지원하지 않는다.
-
CSP에 대한 네트워킹 및 파일 서비스(NAS)와 같은 인프라의 DR에는 더 많은 주의가 필요하다.
-
온-프레미스에서 CSP로 데이터를 복제하는데는 비동기식 복제 기술만 사용할 수 있으며, 이는 데이터 손실이 필요하지 않은 애플리케이션에 영향을 준다.
-
온-프레미스에서 CSP까지의 네트워크 대역폭이 제한될 수 있다.
- 장애 조치(failover) 후 퍼블릭 환경을 운영하기 위한 운영자가 필요하다. 이는 운영자가 관리해야 하는 플랫폼이 두배로 늘어 나기 때문에 운영조직의 부담으로 작용할 수 있다. (평시에는 운영 비용이 감소하지만, 실제 장애 조치 발생 시 운영할 수 있는 인력이 필수적으로 필요하다.)
CSP로의 데이터 복제 기술은 여러가지 방법으로 접근해 볼 수 있다. 다음은 여러 기술 셋에 대한 복제 방법들이다.
<Public Cloud 데이터 복제 방안>
- DR 복제 소프트웨어 : 기존 DR 및 데이터 복제 솔루션을 납품하는 업체에서 퍼블릭 클라우드 환경 상에서 호스트 또는 하이퍼바이저 기반 복제 기능을 제공한다.
- CSP가 제공하는 Managed Service를 활용한 DR 복제 : CSP는 클라우드에 DR을 제공하기 위해 기본 SaaS 솔루션을 제공한다.
- 하이퍼바이저에서 제공하는 하이브리드 클라우드 모델 : 하이퍼바이저 전환 및 운영 환경 변경 없이 온프레미스 환경을 CSP상에 확장하고 기존 온프레미스 DR 솔루션을 CSP로 복제 및 마이그레이션 할 수 있다.
- 하이브리드 클라우드 스토리지 파일 시스템 : 스토리지 공급업체는 스토리지 기반 복제를 활용하여 CSP에 DR을 제공함으로써 온프레미스 데이터 센터와 CSP 간의 하이브리드 아키텍처로 소프트웨어 정의 스토리지(SDS) 소프트웨어를 배포한다.
- CSP에 대한 백업 기반 DR : 기존 백업 소프트웨어 제공 업체는 온프레미스와 CSP 모두에 백업 소프트웨어를 배포하여 DR 서비스를 제공하기 위해 백업 이미지를 CSP에 복제한다.
Public Cloud DR vs On Premise DR 비교
DR 환경에 대한 Public vs On Premise를 비교해 보자. (장점 파란색, 단점 빨간색)
| Public Cloud DR | On Premise DR | |
| 안정성 (사례) | 적음 | 매우 많은 |
| 비용 | 사용량 기반 비용을 차지하며, 매몰비용이 낮음 | 별도 데이터 센터가 필요하며, 매몰비용이 매우 높음 |
| 데이터 복제 | 네트워크 대역폭에 대한 한계가 발생할 수 있음 | 고성능, 고대역폭 스토리지 기반 동기식 복제 지원 |
| 구축 효율성 | DR 데이터 센터는 구축할 필요가 없지만 솔루션 구축에 비용이 발생함 (대체 솔루션 등) | 손쉬운 구축 및 이전 가능 |
| 유지보수 | 운영 사업자 관점에서 관리해야 할 환경이 두배로 늘어나기 때문에 인력 관점의 비용 증가 | 운영 환경과 동일한 환경으로 운영관리 비용 감소 |
| RPO | 데이터 유실 발생 (최소화 방안 수립 필요) | RPO 제로 가능 |
| 통합관리 | 불가능 (클라우드 인프라 관리포털 별도 개발 가능) |
네트워크 연동이 가능할 경우 통합 대시보드 구축 가능 |
결론적으로 인프라에 대한 매몰 비용을 최소화 할 수 있다는 점에서 Public Cloud DR 환경이 각광받고 있지만, 데이터 유실이 발생할 수 있으며, 아키텍처에 대한 충분한 검토가 진행되어야 한다는 점을 충분히 고려하고 선택해야 한다.
결론
재해 발생 후 비즈니스 연속성 및 기술적 대응성을 유지하는 것은 비즈니스의 최우선 순위 중 하나여야 한다. 재해 복구 전략이 누락되거나 실패할 경우 단순 비용적인 손해 뿐만 아니라, 고객의 평판 및 점유율 하락등에 직면할 수도 있다.
이를 위해 DR 환경을 구성하는 것은 중요하고 상세한 전략을 통해 구축되어야 할 것이다.
※ 참조
- 최대 허용 중단 (MAO - Maximum Acceptable Outage) : 허용 가능한 최대 서비스 중단 시간
- 복구 지점 목표 (RPO - Recovery Point Objective) : 오류 또는 오류로 인해 데이터가 손실될 수 있는 최대 기간을 정의. 복구 지점은 재해 발생 후 견딜 수 있는 잠재적인 데이터 손실의 양을 나타냄.
- 복구 시간 목표 (RTO - Recovery Time Objective) : 재해 선언 후 비즈니스 또는 애플리케이션이 복구 절차를 시작하여 서비스를 사용할 수 있을 때까지의 시간.
|
순번
|
중요도
|
복구
시간 |
데이터
유실허용 |
상세 내용
|
|
0
|
중요한
IT 인프라 |
0-15분
|
0분
|
. 비즈니스 기능 이전에 복원할 기본 인프라 및 공통 서비스 - 사전 구축 및 기동 시간 소요 수준 - 환경 정보는 실시간 복제 |
|
1
|
제로다운
타임 |
0-15분
|
1 시간
|
. 지속적으로 사용할 수 있어야 하는 중요한 비즈니스 기능
- 이러한 애플리케이션은 장애에 대해 광범위하게 복원할 수 있도록 설계 |
|
2
|
미션
크리티컬 |
<1시간
|
8 시간
|
. 고객 대면 및 수익 창출 응용 프로그램과 같이 회사의 지속적인 운영에 가장 큰 영향을 미치는 비즈니스 기능
- 지속적으로 사용할 수 있도록 설계되지는 않았지만 신속하게 복구할 수 있어야 함 |
|
3
|
비즈니스
크리티컬 |
<24시간
|
24 시간
|
. 복구가 필요하지만 덜 중요한 고객 대면 또는 수익에 영향을 미치는 애플리케이션
|
|
4
|
중요
|
<1주
|
일주
|
. 중요한 비즈니스 프로세스를 지원하지만 즉시 복구하는 것이 중요하지 않은 애플리케이션
|
|
5
|
연기
|
>1주
|
마지막
백업 |
. 중요한 비즈니스 프로세스를 지원하지만 즉시 필요하지 않은 비즈니스 애플리케이션
|
- Total
- Today
- Yesterday
- MSA
- openstack token issue
- kubernetes
- JEUS7
- git
- API Gateway
- OpenStack
- apache
- SWA
- TA
- 오픈스택
- node.js
- 마이크로서비스 아키텍처
- aa
- webtob
- 쿠버네티스
- jeus
- Docker
- 마이크로서비스
- openstack tenant
- 아키텍처
- SA
- JBoss
- k8s
- Architecture
- aws
- Da
- nodejs
- JEUS6
- wildfly
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |