INTRO

DR은 여러가지 의미를 가질 수 있지만 일반적으로 비즈니스 및 IT 환경에서의 ‘DR’은 Disaster Recovery를 뜻합니다. 이는 기업이 자연 재해, 사이버 공격, 시스템 오류 등으로 데이터 손실, 서비스 중단 등의 상황을 마주했을 때 신속하게 시스템을 복구하고 운영을 정상적으로 재개하도록 하는 일련의 계획과 절차를 의미합니다.

최근 수년간 크고 작은 데이터센터 장애로 인해 DR의 중요성은 점점 더 증가하고 있습니다. DR 계획은 기업의 규모와 업종에 따라 다를 수 있으나 효과적인 DR 계획은 기업의 생존과도 직결될 수 있는 중요한 요구사항입니다. 기존에는 주로 On-Premise(기업이 자체적으로 IT 인프라를 소유, 관리 및 운영하는 것) 환경에서 전산실이나 데이터센터 등을 통한 물리적인 DR 망을 구성하는 것이 일반적이었습니다. 이런 방식은 재해복구 시스템을 사용하지 않거나 최소한의 가동만 하는 평시 상황에도 에너지 소모가 커서 높은 유지 비용이 든다는 특징이 있었습니다. 하지만 최근에는 AWS와 같이 마이그레이션을 포함한 Public Cloud의 활용도가 높아지면서 Cloud 기반의 DR 서비스에 대한 이해도와 인프라 안정성도 향상됐습니다. 그 덕분에 다양한 Use Case에서 이를 활용하는 사례가 점점 확대됐습니다. 더 나아가 3rd-Party 등 여러 IT 솔루션들의 Public Cloud 통합 아키텍처 구현 사례 역시 증가하고 있습니다.

이번 글에서는 전산실이나 데이터센터에 직접 DR 인프라를 구성해야 했던 기존 방식의 한계점에서 벗어나 AWS 솔루션을 활용해 어떤 이점을 얻을 수 있는지 살펴보겠습니다. 그 사례로 On-Premise의 인터넷 관문 서비스에 대한 DR을 AWS 서비스 및 MCNS(Multi-Cloud Networking Software, 멀티 클라우드 환경에서 네트워크 가시성과 통합 관리를 제공하는 솔루션) 솔루션으로 구성한 케이스를 소개해드리려 합니다.

1. 인터넷 관문 DR 아키텍처

1) 전체 구성

기업의 인터넷 관문은 기업 내부 네트워크와 외부 인터넷 간의 트래픽을 관리하고 제어하는 중요한 네트워크 구성 요소입니다. 인터넷 관문은 보안, 성능, 관리 측면에서 다양한 기능을 제공하며 주로 내부 네트워크와 외부 인터넷 간의 데이터 패킷(Packet, 컴퓨터 네트워크가 전달하는 데이터의 형식화된 블록)을 라우팅(네트워크에서 경로를 선택하는 프로세스)하고 내부 네트워크의 사설 IP 주소를 공인 IP 주소로 변환해 외부 인터넷과 통신할 수 있도록 합니다. 무엇보다 네트워크 트래픽을 필터링해 불법적인 접근을 차단하고 보안을 강화하는 방화벽 및 침입 탐지/방지 시스템(IPS(Intrusion Prevention System, 악성 트래픽을 식별하고 그러한 트래픽이 네트워크에 유입되는 것을 사전에 차단하는 시스템)/IDS(Intrusion Detection System, 네트워크를 모니터링하고 네트워크 관리자에게 잠재적 위협에 대한 경고를 보내는 시스템))이 주요 기능입니다.

이런 인터넷 관문은 주로 특정 데이터센터에 위치하고 있으며, 네트워크망을 통해 기업의 다양한 지역 사업장들이 해당 관문으로 인터넷 통신을 할 수 있도록 구성하고 있습니다. 구체적으로 관문이 위치한 데이터센터의 재해 상황을 가정하고, 평소 사업장에서 관문을 통해 통신하던 인터넷 트래픽을 DR 상황에 노출시켜 AWS에 위치한 관문 구성으로 통신하는 구성을 살펴보겠습니다.

[그림 1]에서 일반적인 평시 사용자의 인터넷 통신 흐름을 살펴보겠습니다. 먼저 On-Premise 사용자망을 통해 인터넷 관문이 있는 데이터센터(Data Center, DC)의 보안 장비 등을 거쳐 인터넷 통신을 할 수 있습니다. 이때 DR 전환 상황이 되면 사용자는 On-Premise 사용자망에 연결된 AWS DirectConnect(사무실과 같은 장소에서 AWS와 전용 네트워크 연결을 제공하는 전용선 서비스)를 통해 기존 관문 Zone이 아닌 AWS에 구성한 관문 Zone으로 통신하게 됩니다. 이때 사용자 트래픽에 대한 보안 확보를 위해 AWS 상에 별도로 구성한 보안 장비를 거쳐 인터넷으로 연결되게끔 구성했고, 일반적으로는 On-Premise 사용자망의 라우팅 전환을 통해 DR 시 전환될 수 있도록 사전 검토 및 설정이 진행됩니다.

하지만 실제 DR 상황을 발생시키는 것은 거의 불가능하기 때문에 구성에 대한 검토(TEST) 시에는 라우팅을 조정해 일부 사용자 또는 사업장에만 적용되는 형태로 설정해 진행하게 됩니다. 상세 내용은 On-Premise 네트워크 구성이나 설정에 대한 지식이 필요하기 때문에 본 글에서는 전체 아키텍처와 DR 인프라에 대한 AWS 구성 요소만 다루도록 하겠습니다.

2) 세부 구성

1. AWS에 구성 가능한 MCNS 솔루션 적용

• MCNS란?

AWS와 같은 Public Cloud 환경에서 VPC~VPC(Virtual Private Cloud, 클라우드 환경에서 논리적으로 독립된 고객 전용 사설 네트워크 공간을 제공하는 서비스), VPC~On-Premise 간의 네트워크를 구성하고 Public Cloud 내 네트워크 가시성을 확보할 수 있는 솔루션입니다. Public Cloud 사업자들의 API와 연계된 자원의 자동화 구현부터 End-to-End 라우팅 관리 및 네트워크 보안 구성, 경로(Traffic) 가시성까지 확보할 수 있는 솔루션입니다.

이번 글에선 MCMS 솔루션 중 하나인 AVIATRIX를 활용한 DR 아키텍처를 살펴보습니다. 본 솔루션은 DR 아키텍처뿐만 아니라 AWS 서비스와 함께 다양한 형태의 아키텍처에서 활용할 수 있는 솔루션 중 하나로 참고하시기를 추천합니다.

• AVIATRIX 솔루션의 Gateway를 AWS VPC 내에 구성하기

AWS VPC 내에 AVIATRIX 솔루션의 Gateway를 구성합니다. 해당 Gateway는 DirectConnect 및 방화벽 등을 연결해 통신하며, On-Premise 망으로 라우팅을 전파하기 위한 코어 라우터 역할을 수행합니다. 솔루션 특성상 AWS Account와 연동해서 자동으로 이중화(프로비저닝, IT 인프라를 생성하고 설정하는 프로세스) 및 다른 자원과 연결이 가능합니다. 특히 원하는 대역 라우팅을 On-Premise 망으로 전파할 수 있는 기능이 있어 이번 DR 구성에서 중요한 요소라고 할 수 있습니다.

2. 기존 On-Premise 망 통신을 위한 AWS 서비스 설정

• AWS DirectConnect 연결하기

AWS N/W와 기존 On-Premise N/W 간 통신을 위한 DirectConnect 연결을 진행합니다. 이는 기존 사용자가 DR 상황 발행 시 On-Premise에 연결된 DirectConnect로 AWS의 DR 인프라와 통신할 수 있는 경로를 만드는 것입니다. On-Premise 망에서는 DR 상황 발행 시 기존 망 설정에 따라 자동 또는 수동으로 라우팅 전환이 가능하도록 연결 설정을 사전에 검토합니다.

DR 상황이 발생하기 전에는 해당 DirectConnect 연결을 통한 사용자 트래픽이 발생하지 않기 때문에 평소에는 최소한의 Bandwidth(대역폭, 특정한 기능을 수행할 수 있는 주파수의 범위)를 유지할 수 있습니다. 즉, DR 상황에서만 증속을 고려하면 되는 것입니다. 게다가 평소 서비스용으로 사용하지 않는 회선이기 때문에 이중화를 고려하지 않는 등, DR 요구 조건에 따라 다양한 형태로 구성과 설정이 가능합니다.

• AWS VPC 내부 자원 구성 및 AVIATRIX 솔루션의 Gateway와 연결하기

이미 구성되어 있는 AVIATRIX 솔루션의 Gateway의 관문 보안을 위해서는 VPC 내에 필요한 AWS 자원 연결 설정을 진행해야 합니다. 그 예로 보안 장비 및 인터넷 통신을 위해 생성되는 IGW, Subnet Route Table 등이 있습니다. 이번 글에서는 보안 장비, 그 중에서도 방화벽 정도만 구성되는 아키텍처로 설명했지만 실제 DR 요구사항에 따라 다양한 형태의 장비나 서비스, 솔루션에 대한 구성도 가능할 것입니다.

참고로 AWS 상의 방화벽 장비 프로비저닝 및 Gateway 연결은 AVIATRIX 솔루션을 통해 보다 수월하게 구성 가능합니다. 물론 계속 변경될 수 있는 기존 On-Premise 환경의 방화벽 장비 정책 등을 DR 용도의 방화벽과 어떻게 맞출지, 또는 DR 상황에서도 별도 정책을 적용할지 등 여러 방면의 검토가 반드시 사전에 필요합니다.

2. 적용 효과

1) 비용 절감

기존 On-Premise에 DR 인프라를 구성하기 위해서는 네트워크 장비나 서버 등 장비 H/W(HardWare)뿐만 아니라 이를 수용하는 데이터센터의 RACK 공간, 전원, 케이블 등이 필요해 초기 투자 비용이 발생할 수밖에 없었습니다. AWS는 방대한 클라우드 서비스에 대해 사용량에 따른 요금 접근 방식을 제공합니다. AWS에서는 장기 계약이나 복잡한 라이선스 없이 필요한 개별 서비스에 대해 사용한 만큼의 비용을 지불하면 되고, 사용을 중단하더라도 추가 비용이나 종료 비용을 지불하지 않아도 됩니다.

2) 구축 일정/인력 단축

기존 On-Premise에 DR 인프라를 구성하려면 네트워크 장비나 서버 등 H/W 뿐만 아니라 이를 수용할 데이터센터의 랙 공간, 전원, 케이블 등 물리적인 인프라를 모두 마련해야 합니다. 따라서 공간 확보부터 장비 발주, 설계 및 구축까지 많은 시간이 소요될 뿐만 아니라, 구축을 위해 필요한 인원도 규모에 따라 다수가 필요할 수 있습니다.

하지만 AWS와 같은 Public Cloud 사업자의 서비스를 활용해 DR 인프라를 구성할 경우, 물리적인 인프라 구성이 불필요하거나 최소화되기 때문에 구축 일정이 단축됩니다. 또한, 구성 변경이 필요한 경우에도 수월하게 작업할 수 있습니다. 필요한 인력 역시 최소화할 수 있어 효율적인 구축이 가능합니다.

3) 지역적 한계 극복

AWS는 전세계 다수 지역에 글로벌 Region(AWS 서비스가 제공되는 서버의 물리적인 국가/도시 단위의 위치)을 보유하고 있습니다. 이는 DR 구성에 대한 지역적 제약이 없는 것과 마찬가지입니다. 메인 인프라와 DR을 구축하고 싶은 지역이 국내인지 국외인지와 관계없이 인프라를 구성할 수 있습니다. 일반적으로 DR을 국외에 구성할 경우, 필요에 따라 국내 엔지니어가 해외로 출장을 가야 하는 등의 상황이 발생해 해외 인프라 구성과 함께 비용, 일정, 인력이 국내보다 훨씬 많이 소요될 수 있습니다. 하지만 AWS와 같은 Public Cloud 사업자의 서비스를 활용하면 이러한 지역적 한계를 극복할 수 있고, 효율적인 운영 관리로 인해 기업은 많은 이점을 얻을 수 있습니다.

OUTRO

On-Premise 환경의 DR은 On-Premise에, Cloud 환경의 DR은 Cloud에 구성해 운용하는 것이 일반적입니다. 하지만 이번 글에서는 실제 Public Cloud 서비스 및 인프라의 진화에 따라 상호간 DR 구성을 통해 재해의 영향을 줄이면서 서비스와 인프라의 형태에 따른 이점을 극대화할 수 있는 아키텍처를 살펴보았습니다.

이번에 소개해 드린 아키텍처는 인터넷 통신과 관련한 일부 서비스 flow에 대한 DR이 고려된 아키텍처입니다. 하지만 AWS 서비스에 대한 이해와 활용도가 증가함에 따라 다양한 서비스에 대해 이와 같은 형태로 DR을 구현할 수 있을 것으로 보입니다. 이는 사용자의 활용 여부에 따라 점점 더 물리적인 데이터센터나 지역의 한계를 벗어난 서비스 연속성 확보가 가능한 형태로의 기업 서비스 확장으로 이해할 수 있습니다. 단, 다른 DR 구성과 마찬가지로 RTO(Recovery Time Objective, 예상 복구 목표 시간)를 실시간으로 짧게 구현하기는 쉽지 않을 수 있습니다. 따라서 다른 DR 계획 수립과 마찬가지로 복구 우선순위와 단계에 따른 시나리오 검토 및 정기적인 DR 훈련을 통해 빠른 대응을 준비해야 합니다. 이러한 준비가 비즈니스 연속성을 위한 올바른 전략과 연결됩니다.

[참고문헌] https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/how-it-works.html