세번째 글에서 다루려는 내용은 하이브리드 클라우드이다. 하이브리드 클라우드는 클라우드 영역에서 여전히 논쟁이 많고, 벤더나 사업자마다 정의가 조금씩 다르다. 퍼블릭 클라우드 입장에서 보면, 부정하고 싶지만 부정할 수 없는 영역이고, 프라이빗 클라우드 입장에서는…

1. 데이터센터와 서버

요즘 우리는 인터넷과 떨어져 살아가기 힘든 시대에 살고 있다. 무엇이든 필요한 것이 있으면 바로 스마트폰으로 필요한 정보를 검색한다. 그럼 이러한 정보는 어디서 오는 것일까? 대부분의 정보는 데이터센터라는 곳에 위치하고 있고, 사용자는 그 데이터를 가공하여 보기 편하게 제공해주는 서버를 통해 서비스로 전달받는다. 서버라는 것은 우리가 사용하는 컴퓨터와 기본적인 구조는 동일하나, 서비스 연속성을 보장하기 위해 구성요소의 이중화를 기반으로 안정성이 강화된 형태의 컴퓨터이다. 각 서버들은 용도에 따라 데이터를 저장하는 용도로 사용되기도 하고, 데이터를 가공하는 용도로 사용되기도 한다. 결과적으로 서버는 데이터를 사용자에게 정보로 전달하는 중간 가교 역할을 하며, 이러한 서버들의 집합이 데이터센터이다.

 

서버의 진화

다시 말해, 사용자가 필요한 정보는 각 데이터센터에서 서버라고 불리우는 컴퓨팅 자원에서 연산 된 결과를 사용자에게 돌려주는 방식으로 제공된다. 이 과정에서 컴퓨팅 자원은 무엇인가 프로그래밍 된 애플리케이션에 따라 초기 데이터를 기반으로 다양한 결과를 사용자에게 돌려준다. 과거 이러한 컴퓨팅 연산은 메인프레임이라는 아주 커다란 장비에서 이루어졌다. 하지만, 특정 제조사나 솔루션의 종속성이 심하고, 공간 및 비용의 이슈를 가지고 있었다. 점차 작은 사이즈의 컴퓨팅 시스템에 대한 필요성이 점점 더 커졌고, UNIX 서버로의 다운사이징이 이루어 졌다. 이후 대부분의 서비스는 UNIX로 이루어졌지만, 시간이 지나면서 여전히 특정 제조사나 솔루션의 종속성은 그대로 가지고 있었다. 그러는 동안 X86 프로세스의 비약적인 발전을 기반으로 서버 가상화가 대세를 이루게 되었고, 결국은 서버 가상화 기반의 가상서버를 기반으로 서비스가 이루어 졌다. 현재 신규 구축되는 대부분의 서비스는 가상서버를 기반으로 이루어지고 있으며, 최근에는 가상서버보다 더 작은 단위로 가상서버 위에서 완벽한 고립(Isolation)을 통해 다양한 애플리케이션을 수용할 수 있는 컨테이너 기반의 서비스가 출현하였다. 물론 가상서버와 컨테이너를 단순한 가상화(virtualization) 여부만을 가지고 서로 비교하기는 어려울 수도 있으나, 앞으로의 서비스 및 개발의 형태가 컨테이너 기반으로 넘어갈 것이라는 방향성에는 대부분 동의한다. 최근에는 더 나아가, 서버리스라 불리는 클라우드 기반의 서비스 제공도 이미 사용되고 있는 상황이다. 서비스의 단위가 작아질수록, 기업의 개발방법론을 비롯한 다양한 변화가 필요하기 때문에, 하루아침에 모든 변화가 일어나지는 않는다. 하지만, 과거부터 현재까지의 서버의 역사를 본다면 점점 더 작은 단위로 쪼개지고 있음을 볼 수 있다. 물론 HPC등 특정한 용도에서는 여전히 더 큰 단위의 컴퓨팅 서비스가 필요하다. 하지만, 대부분의 일반 사용자를 위한 데이터센터에서는 점점 더 작은 단위로 서비스 단위가 줄어들고 있음이 분명하다.

 

[그림 1. 컴퓨팅 서비스 제공 방법의 진화]

 

변화하는 서버, 뒤 따라가는 네트워크

서비스는 점점 더 작은 서버 리소스를 기반으로 서비스되고 있다. 가상화 된 컴퓨팅 리소스는 이제 물리적인 기반을 떠나 어디로나 이동할 수 있는 환경이 되었다. 서버스용 컴퓨팅의 단위가 줄어들었지만, 네트워크는 아직도 변화의 시작단계에 있다. 과거 동축케이블부터 시작되어, 10G, 100G까지 더 빠른 네트워크를 사용하고 있는 현재이지만, 네트워크의 속도만 빨라 졌을 뿐, 기본적인 물리적 기반의 아키텍처는 그대로 유지하고 있다. 자유롭게 이동할 수 있는 서비스와는 달리 물리적인 한계속에 갇혀 있는 상황이다. 물론, 서비스 제공을 위해 무조건적인 가용성을 보장하기 위해 수십년 동안 전해 내려온 현재의 아키텍처는 매우 견고하고 다양한 기술의 조화로 이루어져 있다. 하지만, 이러한 구성은 모든 방식이 개별 장비의 설정으로 이루어져 있어 가상화 된 서비스의 이동이나, 신규 서비스의 런칭, 기존 구성의 변경 등에서 다시 사람의 손을 기다린다. 기존 서비스의 사용자 폭증으로 인해 갑자기 서버의 수를 늘리는 경우, 빠른 대응이 제일 중요하다. 하지만, 기본적인 구성이 모두 장비 기반으로 구성되다 보니, 골든타임을 놓치는 경우가 종종 발생한다. 서비스의 변화에 능동적으로 대응할 수 있는 네트워크가 필요한 시점이다.

 

2. 새로운 네트워크 세상 – 소프트웨어 정의 네트워킹(SDN)

최근 많은 데이터센터에서 물리적 기반의 네트워크 아키텍처를 벗어나, 효율적인 네트워크를 만들기 위해 다양한 시도들이 진행되고 있다. 데이터센터 네트워크를 바꾸는 여러가지 기술 중 현재까지 가장 앞서 있고, 데이터센터의 미래로 인정받는 기술이 바로 소프트웨어 정의 네트워킹(SDN, Software-Defined Networking)이다. 데이터센터에서 제일 중요한 서비스의 연속성을 유지시키기 위해, 서버는 다양한 방식으로 변화하고 있다. 이러한 서버의 변화에 효율적인 대응을 위한 것이 바로 SDN이다. 이를 통해 물리적 네트워크의 한계를 뛰어넘으며, 소프트웨어의 정책으로 네트워크를 제어한다. 물리적 구성을 통한 네트워크 개별 설정이 아니라, 네트워크의 관리 및 설정 기능을 컨트롤러라고 불리는 통합 관리 서버를 통해 통합 제어하는 것이다. 컨트롤러에서는 자동화된 애플리케이션을 기반으로 네트워크를 제어하여, 사용자의 대응보다 빠른 자동화된 대응이 가능하다. SDN을 통해 물리적 구성이 아닌 논리적 구성을 기반으로 네트워크가 구성되며, 서비스별로 가상의 네트워크를 가지게 된다. 물리적 위치에 상관없이 네트워크 서비스를 제공할 수 있는 것이다. 다수의 데이터센터를 가지고 있는 경우에는, 각 데이터센터에서 동일한 네트워크를 가지고 서비스의 연속성을 이어갈 수 있다. 또한, 최신의 데이터센터에서는 일반 데이터 트래픽뿐만 아니라, 스토리지 트래픽도 네트워크를 타는 경우가 많다. 이러한 경우에도 데이터 트래픽의 장애가 스토리지 트래픽에 영향을 주지 않도록 정책적으로 제어할 수 있다. 물리적 네트워크 구성에서는 별도의 네트워크를 구성했던 것을 통합하여 표준화된 네트워크 아키텍처 기반으로 운영할 수 있는 것이다.

 

[그림2. SDN의 표준 아키텍처]

 

3. SDN으로의 여정

SDN 도입은 단순 도입이 아니라, 데이터센터 아키텍처의 변화를 가져온다. 이를 위해서 다양한 방법의 변화가 가능하나, 일반적으로 다음의 절차에 따른 변화를 준비하는 것이 좋다. 먼저, 실제 데이터센터 네트워크의 주요문제점 및 원인을 파악하여, 정확한 현황을 파악하는 것이 좋다. 이를 바탕으로 필요한 기능에 대한 요구사항 명세서를 작성할 수 있다. 그 다음 요구사항 명세서를 기반으로SDN 도입을 위한 방향성을 수립하여, 목적에 맞는 도입 유형을 선택하고, 전체 네트워크 영역 중 정확한 적용 범위 및 도입 유형을 확정한다. 이후 대상 서비스 및 SDN 적용 방법에 대해 고민하여, 실제 서비스에 최소한의 영향으로 전환하는 것이 중요하다. 여기까지 왔으면 기존 운영방법 대신 새로운 운영방법 및 내부 프로세스의 재정립이 필요하다. 단지 솔루션의 변화가 아니라, 데이터센터 네트워크 방법의 변경이기 때문에, 기존과는 다른 조직 및 역할분담이 도움이 된다.
하지만, 안타깝게도 데이터센터의 최신 트렌드로만 SDN을 접근하는 경우가 많다. 비용 절감의 효과를 볼 수 있다는 달콤한 말에 따라 SDN을 도입하고자 하는 경우가 종종 있다. 하지만, SDN이 기존의 네트워크 환경을 100% 대체할 수 있는 수단으로, 그냥 교체만 하면 모든 것이 바로 될 수 있다는 생각은 버려야 한다. SDN은 특정 활용도나 목적에 따라 사용되어야 하며, 기존 네트워크도 당연히 남아있어 서로 간의 연동도 하나의 고려사항으로 두어야 한다. 또한, 기존 하드웨어 장비 제조사 기반의 엔지니어나 운영자들에게 SDN 뿐만 아니라, 서버 가상화를 비롯한 데이터센터 전체 숲을 볼 수 있는 능력을 사전에 길러주어야 한다. 이를 위한 기존 네트워크 관련 인원의 재교육은 필수적이다.

만약 내부적으로 충분히 준비되어 있지 않다고 판단되지만, SDN을 통한 다양한 효과를 얻고 싶거나, 앞으로 가야할 길에 대해 충분한 확신이 생기는 경우, 주저하지 말고 SDN 전문 업체의 컨설팅을 받는 것이 좋다. 기존 Legacy 기반의 네트워크 업체는 전체 데이터센터의 숲과 가상화에 대한 이해가 일반적으로 높지 않기 때문에, 가상 환경과 클라우드 데이터센터에 최적화된 SDN에 대한 경험을 가지고, 실제 구축 및 운영 서비스를 제공할 수 있는 전문가와 함께 하는 것이 중요하다. 데이터센터 전체 아키텍처가 고려되고, 서버/스토리지/네트워크 환경의 통합을 통한 최적화된 SDN의 구축은 비용절감을 넘어서 자동화를 통한 클라우드 서비스의 운영 최적화를 선물로 가져다줄 것이다. 앞으로 다가올 클라우드 세상을 SDN과 함께 맞이해보자.

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 데이터센터를 통한 데이터센터 구성을 위해 고민해보자.

첫번째 글은 4차 산업 혁명의 시대를 맞아 IT 인프라스트럭처 혁신을 위한 요구사항과 혁신 방향을 살펴 보았다. 4차 산업혁명을 맞아 데이터의 비즈니스적 가치가 높아지고 있는 상황에서…

4차 산업 혁명의 바람이 거세게 몰아치고 있다. 우리가 지금까지 살아온 방식인 아날로그 세계에 인공지능, 사물 인터넷, 클라우드, 암호화폐 등으로 대변되는 디지털 쓰나미가 뒤덮어…