클라우드 전문정보
| 제목 | 데이터센터의 퍼블릭 클라우드 전환 | ||
|---|---|---|---|
| 등록일 | 2017-09-25 | 조회수 | 4494 |
최지웅 오픈소스컨설팅 이사
엔터프라이즈 기업의 데이터센터가 변화하고 있다. 유닉스 기반의 경직된 시스템 환경에서 스케일 아웃을 통한 확장성 있는 인프라로의 변화를 위하여 많은 기업들이 소프트웨어 정의 데이터센터(SDDC:Software Defined Data Center)를 외치고 있다.
현재 데이터센터를 자체적으로 보유한 기업들 조차도 신규 서비스 기획 시 사업에 대한 불명확성, 시장 반응들을 살펴볼 수 있는 시스템을 만들기 위하여 하드웨어 박스를 구매하고, 상용 소프트웨어로 도배된 데이터센터 기반 시스템의 사용에 대해 의문을 가지고 있으며, 일부 서비스를 클라우드 서비스 혹은 하이브리드 방식의 클라우드로의 전환을 검토 또는 진행 중에 있다.
퍼블릭 클라우드 인프라 시장은 급속도로 팽창하고 있으며, 아래의 표에서도 나타나지만 IaaS, PaaS 시장은 4대 업체가 주도하고 있다. 이들 대형업체는 신규 서비스를 지속적으로 내놓고 있으며, 자신들의 강점 분야를 내세워 데이터센터 고객을 자사 클라우드로 유도하고 하이브리드 운영 방안에 대한 레퍼런스를 지속적으로 내놓고 있는 상황이다.
시너지 리서치 그룹(Synergy Research Group)의 2017년 2분기 데이터에 따르면, AWS는 클라우드 인프라 시장의 34%를 차지했으며, 그 뒤를 마이크로소프트(11%), IBM(8%), 구글(5%)이 쫓고 있다.
[표1] Cloud Infrastructure Services - Q2 2017 Market Share & Revenue Growth
출처 : Synergy Research Group, 2017. 7
국내의 경우 가장 먼저 진출한 아마존 AWS가 시장에서 많이 적용되고 있으며, 스타트업들에게는 사실상의 표준(DeFacto Standard)으로 자리를 잡았다. 본 아티클에서는 엔터프라이즈 관점에서 데이터센터을 어떻게 퍼블릭 클라우드로 전환하는지에 대해 살펴볼 것이다.
전환의 이유는 무엇인가?
국내 대기업의 데이터센터는 그룹사의 IT를 담당하는 회사에서 주로 관리하고 있으며, 오픈스택 또는 가상화 기반 하의 클라우드라는 명칭으로 각 그룹 고객사에 서비스를 제공하기 위해 많은 노력을 기울이고 있다. 내부 IT 자원의 성능이 훨씬 압도적일 것이라 대부분 판단하지만 퍼블릭 클라우드 서비스 업체가 기반 물리 자원에 대한 액세스를 훌륭하게 관리하기 때문에 그 차이가 그렇게 극명하게 나지 않는 것이 일반적이다.
또한 내부 ITSM시스템의 관제 하에 들어가게 되므로 클라우드 컴퓨팅이 제공하는 가치의 많은 부분이 민첩성에서 나온다는 점에서 이를 포기하고 데이터 센터만을 고집하는 것도 좋은 결정은 아닐 것이다. 이로 인해 퍼블릭 클라우드에 대한 도입 검토와 개념검증(PoC), 실제 전환이 활발하게 이루어지고 있다.
일반적으로 전환 후 록인(lock-in)에 대해서 우려를 하는 기업들도 있겠지만 그러한 록인은 데이터센터의 경우가 훨씬 더 심하며, 록인 현상은 기업이 다양한 서버와 운영체제, 애플리케이션, 어플라이언스를 선택하고 원하는 특정 결과를 얻기 위해 거치는 과정일 뿐이다.
어떻게 전환할 것인가?
클라우드 전환에 있어 중요한 한 가지는 클라우드라는 트렌드에 대한 기업의 ‘적응력’과 ‘변화에 대한 의지’이다.
쿠팡1과 같이 모든 인프라를 퍼블릭 클라우드로 전환하는 경우도 있겠지만, 대부분의 경우 기존에 운영되던 시스템과 고객의 정보(규제를 포함하는)로 인하여 100% 이전하는 것은 불가능하다. 따라서 많은 기업은 단계적인 클라우드 전환을 고려하며, 아래와 같이 데이터센터와 퍼블릭 클라우드를 연결하여 상호 통신을 할 수 있는 서비스를 구성하게 된다.
[그림1] 데이터센터와 퍼블릭 클라우드
퍼블릭 클라우드로 전환하는 단계는 여러가지가 있을 수 있지만 우선 크게 3단계에 대한 전환 절차를 고려해보겠다.
첫번째 단계는 대상 시스템 선정 및 기술이다. 기존 내부 시스템에 대한 조사를 통해 퍼블릭 클라우드의 유연성(오토스케일링 같은)으로 그 효과를 즉시 확인할 수 있는 시스템이 그 대상이 될 수 있다. 이러한 시스템에 대한 AS-IS 현황 분석을 통해 클라우드 전환 시 TO-BE 아키텍처를 그릴 수 있다. 이 때 중요한 부분은 전체 업무 대상 시스템이 아니고, 현재 가장 손쉽게 올릴 수 있는 WEB-WAS-DB 아키텍처를 가진 트래픽의 양 변화가 큰 업무이다.
그 업무 시스템에서 사용하는 기술들이 클라우드로 전환됐을 때, 그대로 옮겨갈 것인지 AWS와 같은 클라우드의 네이티브 서비스(예: ELB, RDS, DynamoDB)를 활용할 것인지도 중요한 결정 사항이 될 것이다.
두번째 단계는 시스템 전환이다. 대부분의 큰 기업에서는 내부의 데이터센터와 클라우드를 연결하는 것을 기본 전제로 하고 있다. 이 때 서비스를 어떻게 구성할지에 대한 부분의 검토를 하게 되는데, 보통 퍼블릭 클라우드에서는 아래의 방식의 서비스들을 제공하고 있다.
[그림2] 기업의 퍼블릭 클라우드 연결 방식
기업 내의 데이터센터와 연결 시 전용선(비용 상승) 방식과 VPN을 통한 퍼블릭 클라우드 네트워크 연결을 고려할 수 있으며, 비용과 안정성 측면에서 장단점이 존재함으로 전환 시 의사결정이 필요한 부분 중 하나이다.
이후 클라우드 시스템 내의 목표 시스템 설계 및 기술 아키텍처를 정의하고 기존의 베어메탈 방식에서 활용되던 개념을 스케일-아웃형 시스템으로 전환 설계 후 전환 작업을 진행한다. 전환 단계에서 성능, 안정성, 확장성 테스트를 통해 해당 시스템이 처리할 수 있는 능력을 정확하게 파악해야 향후 신규 온디맨드 시스템이 필요한 경우 이를 지표로 삼을 수 있다.
전환은 크게 아래와 같은 방식으로 가능하다.
- Life-and-Shift 방식: 기존 시스템의 기능, 소프트웨어 등을 변경하지 않고 그대로 클라우드 이전
- Cloud-Native 방식: 퍼블릭 클라우드에서 운영할 수 있도록 초기 또는 전환 시점부터 클라우드가 제공하는 서비스 활용에 중점을 두어 이전
- 오픈소스 전환 방식: 클라우드의 이점인 확장성과 비용 효율성을 최대한 살릴 수 있도록 대응 오픈소스로 변경하여 이전(멀티 클라우드 대응, 록인 방지)
전환에 대한 목표와 시스템 소프트웨어의 변경에 대한 예시는 다음의 그림과 같다.
[그림3] 클라우드 목표모델 레이어 및 시스템 소프트웨어 변화
마지막 단계는 운영 서비스로의 이행이다. 전환 이후 전체 시스템에 대한 기능, 성능에 대한 상세 모니터링을 진행하고 필요 시 인스턴스 개수 조절, 사이즈 조정 등을 통해 비용최적화를 위한 작업을 진행한다.
이 때의 운영은 DevOps를 기반으로 한 운영 서비스를 전제로 하고 DevOps로의 전환(클라우드와 DevOps 툴을 통해 개발자 중심의 자동화 환경 구축 -> 지속적인 배포(CD, Continuous Delivery)이 가능하도록 함으로써 효율성을 확보하고 개발자의 생산성과 비즈니스 민첩성 향상을 위한 기초를 다질 수 있도록 진행해야 한다.
기업이 가진 시스템에 대한 클라우드 전환은 빅뱅이 되어서는 안된다. 현재는 차세대 개념의 빅뱅형이 아닌 점진형 방식의 전환을 통해 리스크를 최소화할 수 있는 전략을 구상해야 한다. 전환 이후에도 트렌드로 자리잡아가고 있는 마이크로서비스 아키텍처, 컨테이너로의 확장과 자동화를 염두에 두어야 하며, 이를 위한 조직/운영의 관점도 달라져야 할 것이다.
다음 회에서는 클라우드 하에서 컨테이너 서비스를 활용한 아키텍처 기술표준화, DevOps, 오픈소스에 대해 다뤄볼 예정이다.
- "쿠팡, IT인프라 전체를 AWS 클라우드로 이전했다", BYLINE NETWORK, 2017.8.10 ↩︎
