Active – Active 데이터센터로의 여정

1. 데이터센터 기반의 IT 서비스

우리는 수많은 데이터의 홍수 속에서 살고 있다. 무엇인가 정보가 필요하면 별다른 어려움 없이 바로 스마트폰으로 검색엔진을 통해 자료를 검색한다. 그러면 스마트폰의 웹브라우저는 특정한 주소의 서버로 접속한다. 이후 서버는 자신이 보유한 데이터를 기반으로, 특정한 데이터를 사용자에게 돌려준다. 이러한 일들을 모두가 아무런 어려움 없이 처리하고 있고 이제는 이러한 일들은 마치 물이나, 전기 같은 당연한 공공재 서비스처럼 여겨 지고 있다. 하지만, 이와 같은 서비스를 위해서는 다양한 IT 인프라의 조합이 뒷받침되어야 한다. 데이터를 처리하는 서버, 저장되는 스토리지, 경로를 제공하는 네트워크, 서비스를 위한 애플리케이션의 조합이 필수적이다. 이러한 인프라들은 일반적으로 데이터센터라는 특수한 장소에 위치하고 있다. 서버, 스토리지, 네트워크 등 IT 서비스 제공을 위해 필요한 자원들을 하나의 공간에 집합시켜 운영과 관리의 편리성을 극대화하는 것이다.

 

[그림1. 일반적인 데이터센터의 구성요소 ]

 

대부분의 멀티 데이터센터 구성 : Active-DR

이러한 데이터센터는 기업의 서비스를 위해 필수적인 존재로, 일반적으로 많은 기업환경에서 2개 또는 그 이상의 데이터센터를 통해 서비스가 제공되고 있다. 일반적인 2개 구성의 경우 하나의 데이터센터는 주요 서비스용(Active), 또 하나의 데이터센터는 DR(Disaster Recovery, 재해복구)용으로 운영하고 있다. 모든 서비스는 Active 데이터센터를 통해 제공되며, 재난이 발생하여 데이터센터 전체가 서비스를 제공할 수 없는 경우에 한해서 DR데이터센터를 통해 서비스를 제공한다. 일반적으로 서버와 네트워크 등 물리적인 장비는 미리 준비해 두고, 스토리지에 저장된 데이터를 DR 데이터센터에서 다양한 방법을 통해 동기화 한 후, 재난발생 시 DR데이터센터의 물리적 인프라에 복구를 통해 서비스를 다시 제공하고 있다. 즉, 하나의 데이터센터는 언제 발생할지 모르는 장애나 재난을 대비하여, 항상 준비된 상태로 운영중인 것이다. 물론 재난이 발생하지 않는 것이 대부분이지만, 기업 데이터 및 서비스의 민감성 때문에 혹시 모를 상황에 대한 대비도 필요한 것이다. 하지만, 기업 입장에서는 당장 사용하지 않는 DR 데이터센터의 자원들로 인해 인프라 자원에 대한 효율성이 떨어지며, 실제 서비스되지 않는 자원에 대한 낭비 및 투자에 대한 부담을 가져가는 것도 사실이다.

Active-DR 센터 : 재난 발생 시 빠른 대응을 위한 RTO, RPO가 중요

또한, 데이터센터의 DR 구조는 RTO(Recovery Time Objective)와 RPO(Recovery Point Objective)의 목표수치를 지정하고 있다. RTO는 얼마만큼 빠른 시간 내에 DR 데이터센터를 통해 Active센터처럼 동일한 수준의 서비스를 제공할지에 대한 시간 목표이며, RPO는 최근 언제까지의 데이터가 Active 데이터센터와 DR 데이터센터 간에 동기화를 가져갈 것인지에 대한 목표수치이다. 재해가 발생한 경우 복구에 대한 목표치를 정해두고, 해당 시간을 제공할 수 있는 인프라를 꾸미는 것이다. 물론 RTO, RPO가 현재상황에서 0이면 좋겠지만, 0에 가까워질수록 비용의 문제가 발생한다. 이 역시 기업으로는 부담으로 작용하고 있다.

새로운 멀티 데이터센터 환경의 출현 : Active-Active

이러한 문제점을 극복하고자, 최근에는 데이터센터 구조를 Active-DR의 구조에서 Active-Active 구조로 변경하는 데이터센터들이 늘어나고 있다. 실제 2개 이상의 데이터센터를 통해 사용자의 상황에 맞는 최적화된 서비스를 제공하는 것이다. 예를 들어, 서울에 위치한 사람은 서울에 데이터센터를 통해, 부산에 위치한 사람은 부산의 데이터센터를 통해 제공하는 것이다. 하지만, 두 데이터센터에서 제공하는 서비스는 동일한 레벨과 데이터를 기반으로 동작하며, 하나의 데이터센터가 문제가 생기더라도, 다른 데이터센터를 통해 연속적인 서비스를 제공한다. 모든 데이터센터에서 동일한 수준의 서비스를 제공하며, 동시에 2개의 데이터센터의 자원을 효율적으로 사용함으로써, 서비스를 분산 처리하는 형태로 제공하는 것이다. 이를 통해 기업에서는 자원의 활용도도 높이고, 비용도 절약하는 1석2조의 효과를 누릴 수 있다.

Active-Active : 재난과 상관없이 서비스의 연속성 보장에 집중

Active-Active 데이터센터는 앞서 살펴 보았던 재해복구(DR)의 개념이 아니라 재난회피(DA, Disaster Avoidance)의 개념으로 접근하는 것이 일반적이다. 재난이 발생하여 복구시간에 대한 목표와 절차대로 복구를 진행하는 재해복구의 개념이 아니라, 재난이 발생하더라도 서비스에 대한 단절을 막아, 정상적인 서비스를 지속적으로 제공하는 개념인 것이다. 즉, 2개의 데이터센터가 동기화되고, 평상시에도 동일한 서비스를 동시에 제공하며, 서로의 재난 발생에 대해 서로 상호보완해주는 데이터센터인 것이다.

 

[ 그림2. DR센터와 Active-Active 데이터센터의 비교 ]

 

2. Active-Active 데이터센터를 위한 준비

현재의 Active-DR 데이터센터 구조에서 Active-Active모드로 변경은 구성을 원한다고 하루아침에 뚝딱 만들어 질 수 있는 것이 아니다. 사용자 관점에서 어느 데이터센터라도 동시에 동일한 서비스를 제공할 수 있는 환경을 갖추고 있어야 한다. 여기서의 환경이란 데이터센터의 특정한 구성요소 하나의 노력으로 되는 것은 아니며, 인프라부터 애플리케이션까지 모든 구성요소에서 이를 위한 고려가 필요하다. 기본적으로 데이터센터 내부의 스토리지 및 데이터베이스(DB) 동기화는 필수이며, 트랜잭션이 잦아 데이터의 변경이 잦은 경우라면 거리 및 회선의 성능에 대한 제약도 발생할 수 있다. 또한 애플리케이션 입장에서도 성능이나 확장을 고려한 설계가 필요하며, 내부적으로 APP을 통한 서비스 호출시에도 특정 IP가 아닌 DNS 기반으로 구성하는 등 전체적인 구성의 변경이 필수적이다. 예를 들어, 페이스북 등 대형 서비스업체의 경우, 전세계에 위치하는 데이터센터 중 사용자가 위치 기반으로 접속되는 데이터센터에 먼저 데이터를 저장한 후 일정 시간이나 규칙에 따라 순차적 동기화를 통해 전세계에 위치한 데이터센터로 동기화를 진행한다. 항상 동시에 모든 데이터센터가 동일한 데이터를 가지고 있지는 못하지만, 최대한 빠른 시간안에 동기화할 수 있는 환경을 구축하여, 지역별로 시간 차이를 두고 운영하는 경우도 있다. 이렇듯 각 기업별로 자신들의 애플리케이션 특성에 맞는 인프라 환경을 구축하는 것이 중요하며, 이를 위해서는 애플리케이션부터 인프라까지 함께 고민과 변화가 필요하다.

 

위치 및 하드웨어에 종속되지 않는 가상화 기반의 인프라 구성 필요

대부분의 Active-Active 데이터센터를 구성하는 인프라 요소는 가상화를 기반으로 구성하는 것이 일반적이다. 가상화 기반 위에 서비스 애플리케이션을 구성함으로써, 위치에 대한 종속성을 추상화하고, 이동에 대한 제약을 제거하여, 위치에 상관없는 서비스의 연속성을 보장하고자 하는 것이다. 인프라의 입장에서 서버의 이동성에 대한 준비는 하이퍼바이저 기반의 서버 가상화가 대부분의 데이터센터 환경에서 구성되어 있기 때문에 어느 정도 준비되어 있는 것으로 볼 수 있다. 하지만, 애플리케이션이 동작하는 서버의 서비스 연속성을 보장하기 위해, 위치에 상관없는 인프라 서비스가 제공되어야 한다. 2개의 데이터센터 모두 동일한 네트워크를 가지고, 동일한 스토리지를 공유하며, 동일한 서비스를 제공하는 것이 최고의 방법이다. 하지만, 각 사이트별로 상황과 구성의 한계로 모든 데이터센터의 인프라 구성요소를 동기화하여 확장하는 것은 매우 제약적인 환경에서만 구성 가능한 옵션이다. 예를 들어, 직접 보유한 매우 가까운 거리에 존재하는 두개의 데이터센터에서는 구축이 가능하겠지만, 서울과 대전같이 매우 멀리 떨어져 있는 경우에는 현실적으로 어려움이 있다. 따라서 Active-Active 데이터센터는 Metro 이상의 거리에서는 구현이 어려운 경우가 발생할 수 있기 때문에, 모든 데이터의 실시간 동기화가 아닌 등급에 따른 동기화 및 상호 DR을 처리할 수 있는 인프라의 구성으로의 변경이 필요하다. 100% 동기화 기반의 Active-Active 데이터센터는 기술적보다는 환경적 어려움에 대한 영향이 크기 때문에, 원거리의 2개 이상의 데이터센터에서 상호 DR 서비스를 제공하며, 자원의 활용도를 높이는 경우에도 Active-Active 데이터센터로 인정되는 추세이다.

서버의 준비는 완료, 그러나 네트워크와 스토리지는 많은 고민이 필요

앞서 언급했듯이, 서버 가상화를 제외한 네트워크, 스토리지의 가상화는 개념은 보편적이 되었지만, 아직 많은 곳에서 도입되지 못한 경우가 많아 이에 대한 준비 역시 부족한 상황이다.

스토리지는 동기화와 복제 방식이 중요

스토리지의 경우 데이터 유실을 막기 위해 한쪽의 데이터센터가 변경될 경우, 다른 사이트에도 변경이 필수적이다. 하지만, 상대방 데이터센터까지 모두 write된 것을 확인한 후 응답을 줄 경우, 서비스에 지연을 불러와 사용자 불편을 가져올 수 있다. 따라서, 스토리지의 동기화와 복제 방식에 대한 고민이 함께 필요하다. 각 사이트별로 별도의 저장소를 가져가게 되는데, 이들 간의 동기화가 가장 큰 숙제 중 하나인 것이다. 또한, 복제 시간 외에도 장애 발생시 대처 방법에 대한 방법론 역시 스토리지 솔루션별로 차이가 있음으로 애플리케이션 특성에 맞는 솔루션 선택이 필요하다.

네트워크는 SDN을 통한 개별 경로 및 정책 제어

네트워크의 경우에는 두가지 경우로 나누어 고려해볼 필요가 있다. 외부에서 2개의 데이터센터로 접근하는 경로와 내부에서 외부로 서비스를 제공하는 경우이다. 외부에서 2개의 데이터센터로 접근하는 경우에 대해서는 일반적으로GSLB(Global Server Load Balancing)를 통해 서비스의 DNS를 기반으로 접속자수, 지연, 위치 등을 고려하여 최적화된 데이터센터로 경로를 안내하는 것이 일반적이다. 이를 통해, 외부의 사용자는 위치에 상관없이 최적의 서비스 접근을 보장받을 수 있다. 하지만, 문제는 내부에서 외부로 나갈 때이다. 내부에서 외부로 나가는 경우 요청이 들어온 데이터센터 내부에서 모두 처리되는 것이 최적이나, 상황에 따라 두개의 데이터센터에 동일한 서비스가 모두 존재함으로, Web은 1번 센터에 APP은 2번 센터에 존재하는 경우가 발생할 수도 있다. 이 경우 1번 센터에서 2번 센터로 요청이 가게 되고, 다시 2번 센터에서 1번 센터를 통해 사용자 응답이 진행되게 되어 트래픽의 우회가 발생하게 된다. 이러한 경우를 트롬본(Trumbone) 네트워크라고 부르며, 효율적이지 않은 방법이기 때문에 권장하지 않는다. 또한, 각 데이터센터에 동일한 네트워크 및 게이트웨이가 존재하게 될 텐데, 서비스 입장에서는 어떤 데이터센터의 게이트웨이가 자신이 바라보는 게이트웨이인지 알기 어렵기 때문에, 네트워크 입장에서 해당 트래픽에 대한 제어가 필요하다. 이를 위해서는 SDN(Software-Defined Networking)의 도움을 받는 것이 일반적이다.

데이터센터간 연결 방법 역시 함께 고려해야

또한, 스토리지 및 가상서버의 이동성을 보장하기 위해서는 데이터센터 간 연결(DCI, DataCenter Interconnect)에 대한 고민도 필요하다. 내부적인 스토리지, 서버의 모든 트래픽이 데이터센터 간에 서로 오갈 수 있는 환경 구성이 필요한데 기존의 전용선을 이용하는 방식과 외부의 회선을 터널링 프로토콜을 통해 확장하는 두가지 방식이 주로 사용된다. 전용선을 이용할 경우 거리에 대한 비용이 문제가 될 수 있으나, 가장 안정적이고, 성능을 보장해 줄 수 있는 방법이며, 터널링 방식을 이용할 경우 비용은 상대적으로 저렴하겠지만, 실시간 동기화 등 성능 이슈가 발생할 수 있는 문제점이 있다. 각 기업별로 애플리케이션의 특징을 고려하여 올바른 연결 방법에 대한 고민도 필요하다.

 

3. Active-Active 데이터센터를 위한 추가 고려사항

Active-Active 데이터센터 도입을 위해서는 인프라 구성 뿐만 아니라, 추가적으로 고려해야 할 사항들이 있다.

통합 관리 플랫폼을 통한 멀티 데이터센터 통합 관리

현재의 Active-DR 데이터센터에서 가지고 있는 문제점 중 하나는 분산화 된 개별관리이다. 네트워크 담당자는 해당하는 네트워크에 대해서만 알고 있으며, 관리는 개별적인 접속을 통해 장비 별 관리를 수행한다. 서버의 경우 하이퍼바이저별 통합 관리가 이루어지지만, 가상화 부분만 관리될 뿐, 물리적인 부분은 역시 별도로 관리한다. 이러한 영역별 관리 기반에서 장애에 대한 복구 시간이 오래 걸리며, 전체적인 아키텍처를 알고 있는 몇 명의 엔지니어에 대한 의존성이 매우 높다. 이는 Active-Active 데이터센터에서도 동일하게 발생할 수 있다. 단지 현재의 운영 방식을 그대로 고수하며 단순 신기술 또는 확장의 개념으로만 Active-Active 데이터센터를 구성한다면, 문제 발생시 더욱 많은 어려움에 봉착하게 된다. 따라서, 이제는 Active-DR, Active-Active 데이터센터 모두 통합된 인프라 위에서 통합 인프라 운영자에 의한 관리가 필요하다. 특히, Active-Active 데이터센터의 경우, 다수의 데이터센터가 하나의 데이터 센터로 묶였기 때문에, 단순 한 영역만 가지고 전체를 처리할 수 없다. 서버, 스토리지, 네트워크 등 데이터센터 인프라에 대해 개별적으로 몇 명의 특별한 엔지니어에 의존하는 관리 체계는 더 이상 유효하지 않은 것이다. 따라서, Active-Active 데이터의 특성을 살려 통합된 환경으로 관리할 수 있는 인프라 통합 관리 솔루션의 도입은 필수적이다. 하나의 관리도구를 통해 전체 데이터센터를 관리하며, 가상화 및 물리적 환경까지 통합 관리할 수 있는 환경 구축이 필요한 것이다. 통합 관리 솔루션은 기존 관리환경을 고려하여 API 기반의 연동을 제공함은 물론이고, 추가적인 기술 및 솔루션 확장에 대해서도 대응할 수 있는 확장성도 가지고 있어야 한다.

 


[ 그림3. 클라우드 인프라 통합 운영 플랫폼 아키텍처 ]

 

경험이 없다면, 전문 엔지니어 및 컨설팅을 통한 전환 가속화

또한, 2개의 데이터센터에 구성된 다양한 솔루션이 하나의 유기적인 데이터센터를 구성하여 운영되기 위해서는 특정 영역의 특정 제조사 솔루션을 통해서만 해결되지 않는다는 점을 기억해야 한다. 다양한 솔루션이 어우러져 운영되어야 하며, 이는 각 기업의 애플리케이션 환경과도 조화를 이루어야 한다. 아무리 좋고 강력한 솔루션이라 할지라도, 기업 애플리케이션의 특징에 부합하지 못한다면 제외되어야 한다. 즉, 고객 환경에 따라 각 사이트별로 다양한 인프라의 조합을 가지고 있으며, 그 위에 다양한 서비스별 특징을 가지고 있어, 단 하나의 모델을 기반으로, 모든 환경을 여기에 맞추어 구성하는 것은 해결책이 아니며, Active-Active 데이터센터의 구성을 모두에게 동일한 구성으로 제시하는 것 역시 옳지 않다. 기본적인 Active-Active 구성을 위한 기업의 환경 분석을 바탕으로, 최적화된 구성을 하기 위한 방안을 도출하는 것이 필수적이다. 다양한 조합의 사전 테스트가 필요하며, 테스트별로 솔루션의 특징이 아닌 기업환경에 맞는 테스트를 진행해야 한다. 당연히 사전에 Active-Active데이터센터의 경험과 고민을 가지고 있는 전문 컨설팅 엔지니어의 도움을 받는 것도 큰 도움이 될 수 있다. 기존의 환경에 대한 정확한 분석 및 현황에 맞는 올바른 솔루션의 조합을 통해, 실제 환경에서 검증하고, 또 검증하며 각 사이트에 맞는 방법을 찾아야 한다. 이를 위한 수많은 테스트가 필요함은 당연하며, 시간 단축 및 노하우 공유를 위해 전문가의 도움 역시 당연히 필요하다.

위와 같이 다수의 데이터센터를 논리적으로 하나처럼 운영하기 위해서는 수 많은 고려사항이 필요하다. 따라서, 기존 Active-DR 데이터센터 환경에서 하루아침에 Active-Active 데이터센터로 변경될 수 없으며, 특정 영역의 특정 제조사 솔루션만으로도 해결이 어렵다. 하지만, 앞으로 대부분의 데이터센터가 Active-Active 모델로 진화할 것이라는 예측에는 모두들 동의할 것이다. 이를 위해 애플리케이션부터 인프라까지 모든 영역에 대한 고민이 필요하며, 이를 위해 다양한 솔루션의 최적의 조합을 찾는 것이 필요하다. 한번에 모든 것을 가질 수 없듯이 지금부터 도입되는 솔루션부터 차근차근 Active-Active 데이터센터를 통한 데이터센터 구성을 위해 고민해보자.