첫번째 글은 4차 산업 혁명의 시대를 맞아 IT 인프라스트럭처 혁신을 위한 요구사항과 혁신 방향을 살펴 보았다. 4차 산업혁명을 맞아 데이터의 비즈니스적 가치가 높아지고 있는 상황에서 변화된 IT 인프라스트럭처 요구 사항에 맞춘 인프라 및 서비스 환경, 클라우드 관리 방안을 고려해야 하며, 비즈니스에 최적화시킬 수 있는 온프레미스 시스템의 혁신적 개선과 이를 활용한 하이브리드 클라우드(Hybrid Cloud) 운영이 필요한 상황이다. 또한 IT 인프라스트럭처의 혁신 위해 관련 조직의 혁신 또한 필수적이다.

 

두번째 글에서는 이러한 혁신을 위해 갖추어야 할 클라우드 인프라스트럭처의 세부 요구 사항 및 구성 방안을 소개하고자 한다.

 

아직까지 우리는 “퍼블릭 클라우드는 저렴하다”는 이유로 빠르게 확산되고 있다는 인식이 강하다. 그런데 이전 글에서 살펴본 바와 같이 퍼블릭 클라우드 사용기업을 대상으로 진행한 설문조사에서는 좀 다른 결과가 나왔다. 실제로 퍼블릭 클라우드를 사용하는 이유가 무엇인지에 대한 사용자 응답은 퍼블릭 클라우드의 사용 이점이 빠른 엑세스와 용량 확대의 용이성, 고가용성, 신속한 타임투마켓, 비즈니스 연속성 등 비용이 아니라 기존 인프라스트럭처의 한계 때문이라는 점이었다. 시장과 산업의 빠른 변화에 맞춰 비즈니스 어플리케이션은 민첩하게 IT서비스를 제공되고 빠르게 확장되는 구조로 발전하고 있는데, 앞에서 살펴본 바와 같이 우리의 기존 인프라스트럭처는 아직 준비가 되어 있지 않은 것이다.

 

<클라우드 도입 이점 2017 vs. 2016, RightScale 2017 State of the Cloud Report>

 

 

퍼블릭과 프라이빗 클라우드를 모두 사용하는 ‘하이브리드 클라우드’ 도입 기업 증가

이처럼 기존 인프라의 한계로 인해 많은 기업에서 퍼블릭 클라우드 도입을 적극 검토하고 있다. 그런데 재미있는 것은 퍼블릭 클라우드로 넘어가는 기업이 많으면 많을수록 프라이빗 클라우드 시장이 같이 커지게 된다. 이유는 퍼블릭 클라우드로 넘어가는 기업은 퍼블릭의 안정성 및 확장성 그리고 편리성을 맛본 곳이다. 그러나 사용한 만큼 비용을 지불하는 퍼블릭 클라우드의 과금 체계 상 시스템이 커지면 커질 수록 비용은 기하급수적으로 증가하게 된다. 시스템에 따라 다소 차이가 있지만 고객들을 통해 얻은 내용에 의하면 전체 시스템을 대상으로 TCO를 계산하면 클라우드 도입 이후 3년 정도부터는 퍼블릭 클라우드 사용 비용이 내부 인프라만 사용했을 때보다 오히려 더 비싸진다.

 

이로 인해 시스템의 상당 수를 퍼블릭 클라우드에서 운영하는 기업에서는 사용 비용이 실제적인 문제로 제기되고 있다. 퍼블릭 클라우드를 전세계적으로 확대시키는데 큰 공헌을 한 글로벌 기업인 삼성전자, 애플, 드롭박스 등이 퍼블릭 클라우드를 떠나 자체 프라이빗 클라우드를 구축한다는 기사를 손쉽게 접할 수 있다. 비용 측면만이 아니라 워크로드(Workload) 별 적합한 클라우드 유형이 분명 존재하기 때문에 작은 단위의 IT 환경에서는 고민 없이 퍼블릭 클라우드를 사용하지만, 실제적으로는 퍼블릭 클라우드와 프라이빗 클라우드의 공존은 피할 수 없는 현실이다. 이에 퍼블릭 클라우드의 절대 강자인 AWS에서 프라이빗 클라우드와 연계할 수 있는 VMware on AWS 서비스 제공이나 구글 GCP에서 시스코와 연계하여 프라이빗 클라우드 환경에서 동작할 수 있도록 Kubernetes 서비스를 제공하고 있다. 얼마 전만 해도 AWS나 GCP는 프라이빗 클라우드라는 것은 없다고 했었다. 그러나 이들은 프라이빗 시장이 존재함을 인정하고 하이브리드 클라우드를 위한 서비스를 제공하고 있다.

 

<클라우드 활용 현황, RightScale 2018 State of the Cloud Report>

 

첫 번째 글에서 살펴본 바와 같이 IT 인프라스트럭처의 한계로 인해 퍼블릭 클라우드가 성장하였지만, 주요 자원들이 다시 온프레미스(On-Premise, 내부구축형) 시스템 환경으로 회귀하고 있다. 그렇기 때문에 온프레미스 환경은 퍼블릭 클라우드의 안정성, 확장성 그리고 편리성을 제공하면서, 비용 효율적인 구성으로 재탄생 해야 하는 숙제를 떠안게 되었다. 그러나 요즘 프라이빗 클라우드에 대한 인식이 좋지 않다. 특히 공공기관에서는 단순 서버가상화나 VDI 구축을 해놓고 “클라우드 도입”이라고 크게 선전을 했기 때문에, 조직 내부에서는 ‘클라우드를 도입해도 별거 없다’는 이야기가 나온 것이다. 클라우드는 그런 것이 아니다. 우리나라 공공 기관을 중심으로 엔터프라이즈에도 프라이빗 클라우드에 대한 잘못된 인식을 볼 수 있다.

 

프라이빗 클라우드 인프라스트럭처 구현 위해 SDDC (데이터센터 정의 소프트웨어) 도입 검토

이번 두 번째 글에서는 프라이빗 클라우드 인프라스트럭처 요소들에 대해 살펴보자.

 

프라이빗 클라우드 인프라스트럭처도 당연히 서버, 스토리지, 네트워크로 구분되는데, 프라이빗 클라우드 인프라스트럭처의 핵심은 이러한 서버, 스토리지, 네트워크 자원이 애플리케이션의 요구에 맞춰 즉시적으로 유연하고 안정적으로 구성되고, 통합된 하나로 관리되어야 한다. 이를 위해 서버, 스토리지, 네트워크 간 서로의 정보를 주고 받을 수 있어야 하며, 서버의 설정이 네트워크와 스토리지에 자동으로 인식될 수 있어야 한다.

 

예를 들면, 클라우드 환경에서는 가상머신(VM) 이동을 위해 네트워크와 스토리지의 구성 변경이 별도로 이루어져서는 안 된다. 솔루션 간 연동을 통해 서버의 이동을 자동 인지하고 네트워크와 스토리지 구성이 자동으로 변경되어야 한다. 장애도 마찬가지다. 네트워크의 특정 포트에서 장애가 발생하면, 클라우드 인프라스트럭처는 당연히 이 문제로 인해 서버와 스토리지에 어떤 영향이 미칠지 예측할 수 있어야 하며, 사전 정의한 정책에 따라 서비스의 연속성이 제공되어야 한다. 이 때, 가상화가 되었는지 아닌지는 중요한 요소가 아니다. 가상화가 되면 구현하고 운영하는 과정에서 확연히 유연한 것은 사실이지만, 가상화가 필수 요건은 아니다.

 

다만, 앞서 살펴본 것과 같이 새 술은 새 부대에 담겨야 한다. 전통적인 인프라스트럭처 일부를 수정하는 방식으로 개선하는 것은 궁극적으로 더 복잡하고, 더 많은 비용이 들게 된다. 최근에 프라이빗 클라우드 인프라스트럭처를 구현하는 기술 중 SDDC (Software Defined DataCenter) 방식이 압도적으로 검토되고 있다. SDN (Software Defined Networking), SDC (Software Defined Computing), SDS (Software Defined Storage) 개별 기술을 묶어 데이터센터에 최적화시키는 방식을 SDDC라고 부른다. VM웨어에서 이 용어를 먼저 사용하기 시작한 것으로 알려져 있지만, 현재는 보편적으로 사용되고 있다.

 

앞서 살펴본 IT 인프라스트럭처 구성 영역에 해당하는 SDDC는 크게 인프라스트럭처 영역, 인프라 관리 영역, 자동화 및 인프라 운영 영역 등 3가지로 구분된다. SDDC는 하드웨어의 비중을 매우 낮게 본다는 선입견이 있는데, 절대 그렇지 않다. 오히려 질 좋은 하드웨어에 대한 고민이 많이 묻어 있다. 고속도로가 아무리 잘 설계되어 있어도 기반이 부실하면, 금방 쓸모 없게 된다. 이를 위해 인프라스트럭처 영역은 대부분 하드웨어와 관련된 설계에 집중하고 있다. SDDC의 핵심은 각 영역의 표준화 구성을 통해 질 좋은 하드웨어 간 경쟁이 이루어지게 함으로써 하드웨어 종속성 제거 및 좋은 가격을 확보하는 것에 있다. 이를 위해서 인프라스트럭처 영역의 각 하드웨어는 인프라 관리 영역의 제어 계층 솔루션과 상호 호환성을 갖추어야 한다.

 

 

조금이라도 SDDC 환경을 경험해본 사람은 충분히 공감할 것이다. 요구 스펙만 맞춰서 도입한 하드웨어들이 SDDC 소프트웨어들과 펌웨어 등에 호환 이슈가 발생해서 성능은 성능대로 안되고, 예측 불가능한 장애는 장애대로 생기는 경우가 많다. 이런 이슈를 조금이라도 줄이기 위해서는 반드시 제어 계층의 각 관리 소프트웨어와 해당 하드웨어 간에는 상호 호환성 검증이 되어 있어야 한다. 혹자들은 이를 두고 국산 제품이 못 들어오게 하려는 것이라는 비판도 하는데, 그것과는 전혀 무관하다. 안전한 고속도로를 위해서는 안정성이 확보되어야 한다.

 

또한 제어 계층 내 각 관리 소프트웨어 간에도 (가급적) 서로 연동된 솔루션을 선택할 필요가 있다. 특정 스위치의 포트 장애가 서비스에 어떤 영향을 미치는지 관리 소프트웨어 간 정보 공유를 통해 장애 예측 또는 장애 처리를 빠르게 할 수 있어야 한다.

 

 

그러나, 만약 제어 계층의 관리 소프트웨어 간 연동이 어렵다면, 필요한 정보들은 클라우드 운영 포털을 통해서 취합되고 관리되어야 한다. 서버 가상화 기능을 예로 들면, 서비스의 안정적인 성능을 보장하기 위해서는 VM의 우선 순위에 맞춰 호스트에 VM들이 골고루 자동 분포되어야 한다. 서버 관리 소프트웨어와 네트워크 관리 소프트웨어가 연동되어 있다면, 앞에서 논의한 바와 같이 VM을 이동시킬 때 네트워크 솔루션에서는 즉시적으로 인지하고 해당 스위치 포트에 VM의 네트워크를 자동으로 할당한다. 그런데, 클라우드 환경에서 꼭 필요한 이런 리소스 분배 기능을 지원하지 못하는 하이퍼바이저도 있다.

 

그리고, 이 하이퍼바이저가 네트워크 관리 소프트웨어와도 연동되어 있지 않다면 해결 방법은 클라우드 운영 포탈에서 워크플로우를 통해 해당 기능을 구현하는 것이다. 간단히 설명하면, 운영 포털에서 하이퍼바이저별 / VM별 리소스 사용 현황을 체크하고, 임계치 이상인 경우 해당 VM을 여유 자원이 있는 호스트로 이동시키도록 하고, 해당 호스트에 연결되어 있는 스위치 포트의 구성이 자동으로 변경되도록 하는 것이다. 이 모든 기능을 운영 포털에서 구현할 수 있어야 한다. “소프트웨어 정의(Software Defined)”라고 하는 이유가 이런 것 때문이다. 비즈니스 애플리케이션이 요구하는 기능을 정의하고, 이 기능을 기반으로 도입한 인프라환경에서 손쉽게 제공할 수 있는 기능을 선별하고, 그렇지 않은 것을 소프트웨어를 통해 구현하는 것이 SDDC의 핵심이다. 그렇기 때문에 소프트웨어 정의(Software Defined)로 가면 가격이 저렴해진다고 잘못된 인식은 절대적으로 잘못된 것이다. 그건 애플리케이션이 요구하는 기능마다 천차만별이 된다. 지금까지 살펴본 바와 같이 SDDC 클라우드 인프라스트럭처는 비용 때문이 아니라 클라우드 환경에 최적화된 인프라를 제공하기 위한 것임을 기억해야 한다.

 

SDDC의 각 구성요소인 SDC(서버), SDS(스토리지), SDN(네트워크)를 유기적으로 묶어 운영 관리하는 것은 결국 운영 포털을 통해서다. 그런데 포털이라고 하면 많은 사람들은 단순 사용자 포털로 인식하는 경향이 강하다. 이유는 퍼블릭 클라우드의 영향 때문인데, 퍼블릭 클라우드에서는 기업들이 운영자 포털을 볼 일이 없다. 그러다 보니 퍼블릭 클라우드를 구성하는 곳에서도 운영자 포털을 간과하고 사용자 포털만 고민을 하는 경향이 강하다. 그런데, 막상 퍼블릭 클라우드에서는 인프라스트럭처의 안정적이며 효율적인 운영을 위해 엄청난 노력을 기울이고 있다.

 

이전에도 퍼블릭 클라우드 인프라스트럭처 컨설팅을 한 적이 있지만, 최근에 또 다른 좋은 기회를 얻어 기존 퍼블릭 클라우드 사업자의 인프라스트럭처 확장을 위한 디자인 작업에 참여한 적이 있다. 여러 나라의 전문가들도 함께 참석하였는데, 결국은 퍼블릭 클라우드에서도 가장 필요한 기술은 서버, 스토리지, 네트워크를 개별 요소가 아닌 논리적 하나처럼 어떻게 관리할 것인가이다. 인프라스트럭처를 플러그앤플레이(Plug & Play) 방식으로 필요할 때마다 손쉽게 확장하고 장애가 나면 단순 교체하는 방식으로 운영 고민을 많이 하고 있다. 즉, 인프라스트럭처를 모듈화해서 레고 스타일 빌딩 블록(Lego Style Building Block)으로 구성해서 안정성 및 효율성을 강화시키는 것이다. 이렇게 고속도로가 안전해야 그 위에 정책들을 잘 설계할 수 있는데, 프라이빗 클라우드에서도 동일하게 이런 안정성과 효율성을 확보하지 못하면 퍼블릭 클라우드와 같은 클라우드 서비스를 기대하기 매우 어렵다.

 

이미 많은 곳에서 증명되었듯 결국은 퍼블릭 클라우드나 프라이빗 클라우드 인프라스트럭처는 SDDC 기반으로 하는 것이 가장 검증된 방식이다. 클라우드 운영 포털을 통해 서버, 스토리지, 네트워크를 논리적 하나처럼 관리하고, 제어 계층의 관리 솔루션은 하드웨어의 종속성 없이 동일하게 기능을 제공할 수 있는 기반을 제공하며, 인프라스트럭처는 하드웨어 단계에서의 안정성 및 성능을 제공하도록 구성하는 것이다. 결국은 각 영역의 역할을 구분하고 상호 연동을 통한 표준화 방식이 핵심이 된다.

 

클라우드 인프라 관리를 위해 서버, 스토리지, 네트워크 전반에 대한 이해 갖출 때

그러나, 이렇게 구성한다는 것이 말이 쉽지 결코 손쉽게 할 수 있는 영역은 아니다. 지금까지 업무 포털이 없었던 것은 아니다. 이런 시도가 분명히 존재했지만, 거의 실패하였다. 이유는 하나의 포털을 통해 서버, 스토리지, 네트워크를 구성할 수 있는 창을 모아 두었을 뿐이지 실제 내부 구성은 별도의 솔루션과 마찬가지인 것처럼 서버는 서버대로, 네트워크는 네트워크대로, 스토리지는 스토리지대로 별도로 하고, 이벤트 발생 또는 업데이트 시 상호 정보 확인이 안된다. 그렇기 때문에, 스토리지에서 장애가 나서 로그가 올라오면, 로그가 올라왔구나 정도로 인식하지 그것이 무엇을 의미하는지 모르고 넘어가는 경우가 많다. 대부분 단순 SI 사업에 의해서 장비의 API만 맞춰서 구현하였기 때문에 발생하는 이슈다. 이는 개발 능력에 영향을 받는 것이 아니라 인프라스트럭처를 얼마나 잘 아는지가 핵심이 된다. 지금까지 사일로 형태의 각 영역 전문가들은 많았다. 그러나 클라우드 시대에는 서버, 스토리지, 네트워크 전반을 걸쳐 이해하는 전문가가 필요하다.

 

이런 전문가를 만드는데, 얼마나 시간이 걸릴까? 우리 직원들 경험으로 보면, 각 영역의 전문가가 인프라 전반에 걸쳐 이해를 하는데 보통 3년은 걸리는 것 같다. 적어도 2년에서 3년은 아무리 돈을 많이 투여한다고 해도 클라우드 환경에 맞는 인프라 전문가가 되기 위해서는 단축시킬 수 없는 절대적인 시간으로 보인다. 더욱이 기존 일은 기존 일대로 하면서 클라우드 인프라 전문가가 된다는 것은 불가능하다.

 

고객 맞춤형 하이브리드 클라우드 인프라 운영 시뮬레이션 지원

나임네트웍스는 클라우드 인프라스트럭처 전문 기업이다. 단순히 클라우드 소프트웨어를 잘 설치하고 전문지식이 높은 기업을 의미하지 않는다. 우리는 우리 스스로를 “Trusted Advisor”로 인식한다. 그러기 위해서는 부단히 노력해야 하는데, 나임네트웍스가 클라우드 인프라스트럭처 기술에 자신하는 이유는 우리가 보유한 클라우드 인프라 Test Lab 환경 때문이다. 8개의 Rack에 50대 이상의 고사양 서버와 40대 이상의 스위치 그리고 다양한 타입의 스토리지가 1년 365일 24시간 각종 클라우드 테스트를 위해 쉼 없이 돌고 있다. 이 안에는 Private Cloud를 위한 각종 소프트웨어들과 SDN, SDS, SDC가 구성되어 있고, 각 Public Cloud와 연동하여 Hybrid Cloud 시대를 준비하고 있다.

 

특히, 요즘 한참 주가를 달리고 있는 Container 기술들도 3rd party 솔루션 및 Public Cloud와 연동되어 쉼 없이 테스트 중에 있다. 클라우드 시대에 준비된 Trusted Advisor가 되기 위한 과감한 투자와 준비이다. 이러한 과정을 통해 얻은 노하우를 기반으로 단순 서버가상화나 VDI가 아닌 진정한 의미의 클라우드 인프라스트럭처에 대한 소개 및 라이브 데모를 9월에 고객대상으로 오픈한다. 단순 벤더의 솔루션 경험이 아닌 클라우드 인프라스트럭처에 대한 실제적인 경험을 할 수 있는 좋은 시간일 것이다. 나임의 데모 세션에 참석하는 고객들은 SDDC환경에서의 데이터센터 운영, 멀티 데이터센터의 효율적 운영, 하이브리드 클라우드 운영에 대한 시연을 선택적으로 볼 수 있으며, 나임이 자체 개발한 클라우드 인프라 통합운영 솔루션인 ‘탱고(TANGO)’ 시연도 확인 할 수 있다. 참석 고객에게는 1:1 라이브 데모 세션을 제공하여 고객들의 운영환경에 맞는 인프라 설계 및 운영 방안을 제안 해 주고 있다. 관심이 있는 고객들은 contacts@naimnetworks.com 으로 메일을 보내면 참석 가능 일정을 확인할 수 있다.

관련기사 : [데이터넷 – 테크가이드] http://www.datanet.co.kr/news/articleView.html?idxno=127096