SDDC 구성 요소 별로 간단히 살펴보는 SDDC의 필요성과 특징

규모가 작은 기업이 IT인프라를 활용하는 방법은 크게 3가지로 나눌 수 있습니다. 첫 번째는 'IDC의 서버 호스팅 서비스를 사용해 IT인프라 운영 위탁'이고요. 두 번째는 'IDC의 코로케이션 서비스 사용', 세 번째는 '클라우드 서비스 활용'이라고 할 수 있습니다. IDC의 서버 호스팅을 선택한 기업들은 IT운영 비용 절감이라는 장점은 누릴 수 있지만 IDC의 자원을 다른 기업들과 나눠서 사용해야 하기에 고성능이 필요한 애플리케이션에는 알맞은 방법이 아닙니다. 이를 극복할 수 있는 것이 코로케이션 서비스 사용이나, 애플리케이션 운영을 위한 모든 IT인프라를 직접 설정하고 관리해야 하는 부담에 더해, 내가 사용하는 IT인프라, 물리적인 하드웨어에 접근하는 것 역시 제한적이라는 단점이 있습니다.

그래서 규모가 작은 기업 입장에서 가장 훌륭한 대안으로 떠오른 것이 퍼블릭 클라우드 서비스를 활용하는 것입니다. 믿을만한 글로벌 대기업이 운영하는 데이터 센터에서 안정적으로 애플리케이션 운영을 위한 IT자원을 제공받을 수 있고, 요금만 지불하면 고성능 애플리케이션도 거뜬히 운영할 만큼의 고성능 자원을 활용할 수 있기 때문이죠. IT인프라 관리 노하우 부족은 클라우드 서비스 기업에서 제공하는 PaaS를 사용하면 상당부분 극복할 수 있고요. 하지만 데이터가 우리 회사가 아닌 외부의, 클라우드 서비스 기업의 데이터 센터에 저장된다는 점, 사용한 만큼 과금되는 클라우드 서비스 요금을 예측하는 것이 쉽지 않다는 점, 클라우드 서비스 기업의 운영 정책에 얽매일 수 있다는 점은 감안해야 합니다.

이러한 이유로 규모가 큰 기업은 과거부터 지금까지 쭉 데이터 센터를 직접 운영하는 쪽을 선택해 왔습니다. 이들은 오랫동안 IT인프라를 직접 운영해왔기에 관리 노하우도 충분히 쌓였고, 관리 인력 역시 풍부하게 보유하고 있습니다. 데이터는 우리 회사 데이터 센터에 저장되니 데이터 주권을 확실히 쥐고 있을 뿐만 아니라, 회사의 자율적인 운영 방침으로 IT인프라를 운영, 관리해 나갈 수 있죠. 운영하는 IT인프라 규모가 워낙 크기에 신규 인프라 도입 시 규모의 경제를 통해 보다 저렴하게 도입할 수 있고, 어떠한 상황이라도 IT인프라 운영 비용이 갑자기 증가하는 등의 위험을 감수할 필요가 없습니다.

<이미지 출처 : Information Age, Digital business transformation post Covid-19: the next wave>

그런데, 시대가 달라지고 있습니다. 문제는 비즈니스 환경이 너무 빠르게 변한다는 것입니다. 과거와 달리 지금은 클라우드의 유형때문에 애플리케이션 개발, 운영 환경이 매우 유연해졌고, 개발 및 배포 속도 역시 새로운 방법론들의 등장으로 매우 빨라졌습니다. 과거의 산물인 전통적인 데이터 센터 운영 방식으로는, 빠르게 변화하는 비즈니스 상황을 따라잡기 버거워 진 것입니다. 고객들의 요구사항은 점점 다양해지고 많아지는데, 물리적 하드웨어와 가상 머신 위에서 운영되는 모놀리식 아키텍처 기반의 애플리케이션은 변화의, 기능 추가 및 업데이트 속도가 매우 느리거든요.

즉, 서비스는 웹에서 모바일 앱으로 넘어가고, 운영 인프라는 가상 머신에서 컨테이너로 진화하고 있지만, 기존의 온프레미스 데이터 센터로는 이러한 변화를 따라잡기 어려운 시대가 된것입니다. 과거의 데이터 센터 운영 방식으로는 현재의 클라우드 환경에서 요구하는 민첩성, 그리고 유연성을 확보하는 것은 불가능에 가깝다고 할 수 있겠습니다.

하지만, 아직 희망은 있습니다. 오랫동안 온프레미스 데이터 센터를 운영해 온 규모가 큰 기업, 그리고 반드시 직접 데이터 센터를 운영해야 하는 기업들도 앞서 언급한 '민첩성'과 '유연성'을 확보하여 빠르게 변화하는 시장의 흐름을 따라잡을 수 있는 방법이 있습니다. 그 방법은, 컴퓨팅, 네트워크, 스토리지로 나눠진 IT인프라를 개별적으로 따로 관리하는 것이 아닌, 이 요소를 모두 소프트웨어로 가상화시켜 자동화 기술을 활용해 효율적으로 운영하는 것입니다. 이렇게 운영되는 데이터 센터를 우리는 SDDC, Software Defined Data Center라고 부릅니다.

<이미지 출처 : PR Newwire, Software-Defined Data Center (SDDC) Market Size to grow by USD 84.59 Bn | 17,000+ Technavio Reports>

글로벌 시장조사기관 technavio에 따르면, 글로벌 SDDC 시장은 2022년에만 22.25%, 2026년까지 향후 5년동안 연평균 24.31%의 고성장을 할 것으로 예측되고 있습니다. 2026년에 이르면 시장 규모 역시 한화로 90조가 넘게 증가할 것으로 예상되는 등 SDDC에 대한 수요는 앞으로 지속적으로 증가할 것으로 보입니다. 클라우드 서비스를 사용하는 기업들도 계속 증가하고 있지만, 여전히 온프레미스에 머물러야 하는 기업들도 많고, 이들이 가야할 길은 결국 SDDC라는 것이 글로벌 시장조사기관의 전망이라고 봐도 될 것 같네요.

다행인것은, 국내에도 프라이빗 클라우드 구축을 위해 자사 데이터 센터를 SDDC로 전환하고, 빠르게 변화하는 비즈니스 환경에 잘 대응해 나가는 기업들이 늘어나고 있다는 것입니다. 하지만 SDDC에 대한 이해도가 부족해서, SDDC가 좋은지는 알겠는데 어떻게 구현해야 할 지 잘 몰라서, SDDC 전환 자체가 너무도 큰 부담이라 시도조차 하지 못하고 있는 기업들 역시 많은 것이 현실입니다.

그래서 이번 콘텐츠에서는, SDDC 구현을 주저하는 기업들의 고민은 무엇이며, 어떻게 해결할 수 있는지에 대해 다루려고 합니다. 국내에서 다수의 SDDC 프로젝트를 성공적으로 완수한 효성인포메이션시스템의 웨비나 내용을 정리하면서, 온프레미스 데이터 센터 운영 기업이 SDDC로 전환하면 어떤 장점을 누릴 수 있는지 자세히 알아보겠습니다. 주요 아젠다는 아래와 같습니다.

이 콘텐츠는 효성인포메이션시스템의 지원으로 제작되었습니다.

​

1. 기업들이 SDDC 전환을 주저하는 이유와 해결 방안

효성인포메이션시스템이 만난 다수의 기업 담당자 분들은 SDDC 전환을 위와 같은 이유로 주저하고 있었습니다. 데이터 센터 인프라를 다루는 벤더의 세미나 혹은 웨비나에서는 늘 SDDC가 데이터 센터의 미래라고 이야기 합니다. 하지만 그들이 이야기하는 내용이 조금씩 다르고, 어떻게 우리 회사 인프라에 접목시켜 어느 부분부터 전환해야 하는지, 전환은 어떻게 해야 하는지, 최근의 저렴해진 하드웨어 대비 도입 비용이 너무 비싼 것은 아닌지, SDDC로 전환하게 되면 인프라 운영은 누가 해야 하는지 등 다양한 고민들을 들을 수 있었다고 하는데요.

이러한 고민들은 충분히 납득할 만한 것들입니다. 하지만 이런 고민을 하고 있는 IT담당자 분들 역시 SDDC가 앞으로 우리가 가야 할 길이라는 것을 인지하고 있죠. 그래서 SDDC로 가긴 가야 하는데, 뭐부터 어떻게 전환해 나가야 하는지에 대해 정보가 부족한 것이 SDDC의 전환을 주저하는 가장 큰 이유이지 않나 싶습니다. 그래서 우선적으로 SDDC 전환 프로젝트를 어떤 관점으로 바라봐야 하는지부터 알아보겠습니다.

과거의 IT인프라 고도화 프로젝트는 도입하려는 하드웨어 관점으로 다뤄져 왔습니다. 전반적인 애플리케이션 성능 개선을 위해 노후화된 서버와 스토리지를 최신 제품으로 교체하려는 프로젝트가 생길 경우, IT인프라 팀의 주도 하에 적합한 하드웨어를 도입하고 구축합니다. 그리고 모든 세팅이 끝나면 그제서야 현업의 개발자 및 사용자들이 새롭게 교체된 하드웨어 자원을 자신들의 업무에 활용하는 식이었죠.

하지만 SDDC 환경에서는 이러한 IT인프라 고도화 프로젝트의 중심 축이 IT인프라에서 현업 쪽으로 이동했습니다. 현업에서 필요로 하는 업무가 무엇이냐에 따라 그에 알맞은 IT인프라를 구현하는 것인데요. 예를 들어, 과거의 모놀리식이 아닌 마이크로서비스 아키텍처 기반의 애플리케이션 개발을 위해서는 가상머신이 아닌 컨테이너와 쿠버네티스, 그리고 CI/CD와 같은 DevOps 환경에 구현되어야 합니다. 개발팀에서 요구하는 개발 환경이 먼저 구체화되면, 이를 구현하기 위해 필요한 하드웨어와 소프트웨어를 IT인프라팀에서 준비하는 것이라고 할 수 있습니다.

만약 데이터 분석팀에서 자사 데이터의 보다 깊이 있는 활용을 위해 AI/ML 분석 플랫폼 구축을 원한다면, IT인프라 팀에서는 이를 위해 일반 x86 서버가 아닌 GPU 서버와 고성능 스토리지, 그리고 AI/ML 분석을 위한 각종 소프트웨어를 준비해야 합니다. 이렇듯, 과거 오랫동안 사용되어 온 온프레미스 레거시 환경에서는 IT인프라 팀의 주도 하에 도입하려는 하드웨어와 소프트웨어가 결정되고 이를 현업에서 어떻게 활용할지를 고민했다면, 지금은 현업에서 필요로 하는 업무 환경을 먼저 정의하고, 이후에 그에 알맞은 하드웨어와 소프트웨어를 IT인프라 팀에서 구현하는 형태라고 보시면 되겠습니다.

따라서, SDDC 전환을 고민하는 기업의 담당자는 어떤 하드웨어와 소프트웨어, 플랫폼을 선택할 것인지를 고민하는 것이 아닌, 어떤 업무를 SDDC로 구현하고자 하는지를 먼저 검토해야 합니다. 즉, SDDC는 전통적인 IT인프라 관점 보다는 현업의 업무 관점으로 먼저 접근해야 한다는 것입니다.

SDDC는 위와 같이 4가지 요소로 구성됩니다. 왼쪽부터 SDC(Software Defined Computing), SDS(Software Defined Storage), SDN(Software Defined Network), 그리고 CMP(Cloud Management Platform)입니다. HCI(Hyper Converged Infrastructure)의 확산으로 많은 기업들이 SDC와 SDS를 경험하고 있습니다. SDN 역시 조금씩 도입하는 기업이 늘어나고 있고요. 하지만 SDC, SDS, SDN 모두 개별 인프라로써 접근하게 되면, 앞서 언급했던 과거의 전통적인 레거시 환경에서 IT인프라팀에서 주도했던 고도화 프로젝트와 별반 다를게 없습니다. SDC, SDS, SDN 각 요소 별로 별도로 관리를 해야 하기에, 최신 플랫폼을 적용했음에도 불구하고 업무는 예전과 크게 달라지지 않을 수 있거든요.

그래서 필요한 것이 가장 우측에 있는 CMP입니다. 만약 CMP가 없다면 SDC, SDS, SDN으로 하드웨어 인프라를 소프트웨어 기술을 활용해 자원 활용률을 향상시켰을 뿐, 즉 사용하는 하드웨어와 소프트웨어만 달라졌을 뿐이지 관리 방식은 예전 방식 그대로라고 할 수 있습니다. SDDC의 진정한 가치는 SDC, SDS, SDN을 통해 자원 활용률 향상과 유연성을 확보한 다음, 이를 중앙에서 하나의 플랫폼으로 운영, 관리할 수 있어야 빛을 발합니다.

따라서 SDDC 전환을 준비하고 있다면, HCI와 같은 최신 기술의 인프라에 더해 반드시 CMP와 같은 통합 관리 플랫폼을 고려하셔야 합니다. SDDC는 소프트웨어로 관리되는 데이터 센터입니다. 데이터 센터를 구성하는 다수의 요소를 하나의 통합 소프트웨어로 관리해야 비로소 SDDC가 구현됐다고 할 수 있겠습니다.

지금부터는, SDDC를 구성하는 4가지 요소인 SDC, SDS, SDN, CMP의 특징에 대해 살펴보겠습니다.

​

2. SDDC를 구성하는 4가지 요소(SDC, SDS, SDN, CMP)별 특징

 1) SDC(Software Defined Computing)

SDDC 구성 요소의 첫 번째는 SDC입니다. 과거 레거시 IT인프라 환경에서 운영되는 ERP, DB와 같은 애플리케이션은 한번 구축하면 고도화 프로젝트 전 까지는 큰 변경 없이 오랫동안 사용되어 왔습니다. 애플리케이션 개발팀 역시 기존에 잘 정의된 아키텍처에 따라 유지보수하고 운영해 나가면 별다른 문제는 발행하지 않았죠. 기존 애플리케이션을 활용한 새로운 업무가 생기더라도, 기존의 활용했던 운영 및 관리 정책들을 적용하는 것이 가능했습니다.

하지만 최근의 애플리케이션은 상황이 다릅니다. 다양한 현업 종사자들이 요구사항이 많아지고 있고, 이들의 니즈를 빠르게 충족시키지 못한다면 비즈니스에 지장이 생기게 됩니다. 그래서 IT인프라팀에서는 이들이 원하는 바를 발빠르게 구현해 주어야 하는데 기존의 애플리케이션 운영 환경으로는 이를 커버하기 버겁습니다.

과거 가상머신에서 운영되는 애플리케이션의 기능 추가 혹은 변경을 하려면 해당 가상 머신에서 운영되는 애플리케이션 전체를 건드려야 하기에 작업 속도가 매우 느립니다. 현업의 요구사항에 발빠르게 대처하기 어려운 한계가 있는데요. 이를 극복하기 위해 필요한 것이 컨테이너입니다. SDC 인프라 위에서 컨테이너 기반으로 운영되는 애플리케이션은 마이크로서비스 아키텍처로 개발됐기에 애플리케이션의 각 기능 별, 요소 별 추가 혹은 변경이 가능합니다. 즉, 현업의 요구사항에 발빠르게 대처할 수 있다는 것입니다. IT민첩성을 확보하기 위해, SDC와 컨테이너가 이제는 필수인 시대가 되었다고 할 수 있죠.

하지만 그렇다고 최근의 애플리케이션이 무조건 컨테이너에서만 운영되는 것은 아닙니다. 컨테이너에 적합한 애플리케이션이 있고, 여전히 가상머신에서 운영하는 것이 나은 애플리케이션도 있으니까요. 과거부터 오랫동안 잘 사용해왔던, 가상머신 기반의 애플리케이션을 단번에 컨테이너 기반으로 전환하기에는 감수해야 할 리스크가 큰 것 역시 사실이거든요. 그래서, 가상머신과 컨테이너 두 환경을 모두 아우를 수 있는 통합 관리 플랫폼이 필요합니다.

​

 2) SDS(Software Defined Storage)

스토리지는 IT인프라 중 수명이 가장 긴, 오랫동안 사용하는 하드웨어입니다. 그래서 운영 방식이 어찌보면 좀 고착화되어있다고 할 수 있을 것 같은데요. 그래서, 데이터가 증가하면 필연적으로 생기는 문제가 있는데요. 만약 OS와 애플리케이션의 용도에 맞게 스토리지에 저장 공간을 할당하고 오랫동안 잘 사용해 왔다고 해봅시다. 그런데, 애플리케이션에서 생성되는 데이터가 증가해 스토리지 용량이 부족해졌다면? 애플리케이션 영역을 위한 스토리지의 디스크를 증설하거나 스토리지 자체를 추가해야 합니다. 그런데 이 작업이 금방 되는것이 아니었기 때문에 현업에서 사용자가 급격하게 늘어나거나 사용자가 증가하면 IT인프라팀 입장에서는 대처하는 데에 상당한 시간이 필요했습니다.

하지만 SDS 환경에서는 다릅니다. SDS는 스토리지의 저장 공간을 하나의 공용풀로 엮어서 사용하는데요. 앞서 말씀드린 것처럼 스토리지의 저장공간을 OS영역, 애플리케이션 영역으로, 하드웨어 즉 디스크 레벨에서 정의하지 않고 전체 디스크를 하나의 소프트웨어 레벨에서 정의합니다. 그리고 OS 영역, 애플리케이션 데이터 영역으로 스토리지 사용자가 원하는 만큼 원하는 성능과 용량을 설정해서 사용할 수 있고요. VM단위로도 설정이 가능하며, 스토리지와 연결되어 있는 애플리케이션을 중단하지 않고 운영 중에 이런 설정을 적용할 수 있습니다.

즉, 기존의 전통적인 스토리지는 성능 또는 용량 필요성에 따라 운영 중인 볼륨의 레이드 레벨을 변경하기 위해서는 서비스를 중단하여야 했지만, SDS에서는 서비스 중단 없이, 다운타임 없이 운영 중인 스토리지 볼륨의 레이드 레벨 변경이 가능하다는 것입니다. SDS 덕분에 IT인프라팀은 현업의 요구사항에 발빠르게 대처할 수 있는 민첩성을 확보할 수 있습니다.

보다 자세한 SDS의 특징을 나타낸 장표입니다. 기존에는 물리적으로 하나의 외장 스토리지로 구성하였지만, SDS는 물리적으로 서로 다른 하드웨어에 장착되어 있는 디스크를 하나의 논리 볼륨으로 구성하고, 해당 저장공간을 VM마다 개별적으로 용도에 맞게 RAID 설정해서 사용할 수 있습니다. 따라서 업무의 성격에 따라 성능 또는 용량 중심의 스토리지 정책을 구성할 수 있으며, 나아가 VM의 Power-Off 없이 서비스 온라인 상에서 레이드 레벨 변경이 가능합니다.

하지만 역시 SDS도 만능은 아닙니다. SDC와 마찬가지로 전통적인 레거시 환경에서 오랫동안 사용해왔던 블록 스토리지와 파일 스토리지에 알맞은 애플리케이션도 있을 것이고, 이러한 환경에서 이미 운영되고 있는 애플리케이션도 있을테니까요. 따라서 현재 운영 중인 스토리지 아키텍처를 일괄 변경한다기 보다는 HCI를 통해 SDS를 기존 스토리지 환경에 추가함으로써, 자유로운 설정 변경이 필요한 영역은 SDS로, 그렇지 않은 영역은 레거시 스토리지로 커버함으로써 업무 관점에서 최적의 스토리지 아키텍처를 운영하는 것을 효성인포메이션시스템에서는 추천하고 있으며, 실제 다수의 고객사에서 현재 운영 중에 있습니다.

​

 3) SDN(Software Defined Network)

과거의 네트워크는 네트워크 계층별로 하드웨어가 분리되어 있었습니다. L2, L3, L4 계층마다 네트워크 스위치가 존재했고, 각 장비 별로 종단 횡단 네트워크 트래픽이 발생하기 때문에 네트워크 보안을 위해 관리해야 할 포인트가 많았죠. 네트워크 스위치 따로, 네트워크 보안 장비 따로, 방화벽 따로, 망연계 장비 따로 등등 네트워크 요소 모든 것들을 개별적으로 관리해야 했습니다. 게다가 장비가 많을 수록 복잡성도 함께 비례해서 증가했기 때문에 바쁜 네트워크 운영자 입장에서는 효율적인 운영 및 관리 환경을 구축하기에 쉽지 않았습니다.

이러한 네트워크의 운영 효율성 및 관리 편의성을 향상시키기 위하여 등장한 개념이 SDN입니다. SDN은 SDS와 마찬가지로 물리적인 네트워크 장비 위해 하이퍼바이저를 통해 가상의 네트워크 고속도로를 깔고, 하이퍼바이저에 통합된 SDN 컨트롤러가 종단 횡단 트래픽을 관리합니다. 이게 무슨 의미냐면, 기존 환경에서 종단 네트워크만 타면 되는 트래픽이 어쩔 수 없이 연계된 횡단 네트워크도 거쳐야 했습니다. 이로 인하여 Latency가 증가할뿐만 아니라 패킷 유실 혹은 탈취 등 보안 취약점도 발생하게 됐죠.

하지만 SDN에서는 종단 네트워크를 타야 할 트래픽이라면 종단 네트워크만 타면 되고, 횡단 네트워크를 타야 하는 트래픽이라면 횡단 네트워크만 탈 수 있도록 적용할 수 있습니다. 덕분에 불필요한 트래픽이 발생하지 않아최소한의 Latency와 더불어 보안상의 위험도 감소하게 됩니다.

아직 SDN 환경이 구축되어 있지 않는 환경에서 비교적 손쉽게 구축하여 SDN의 장점을 경험할 수 있는 것 중 대표적인 것이 바로 가상화 기반 분산방화벽입니다. VDI환경에서 각 팀 별로 네트워크 망분리를 했을 경우, 원칙대로라면 분리된 각 망의 가장 앞단에 방화벽을 구성해야 합니다. 하지만 이렇게 되면 방화벽 장비가 그만큼 많이 필요해 관리 포인트도 늘어나고, 각 팀 마다 적용해야 하는 정책이 다를 경우 이를 각각 관리해야 하는 불편함도 따라옵니다.

하지만 SDN의 분산 방화벽 기능을 사용하면 위와 같이 각 팀 별로 테넌트를 설정해서 논리적인 방화벽을 구성해서 보안을 강화할 수 있고요. 게다가 팀 별 개별적인 정책을 사용하더라도 팀 그룹으로 정책을 묶어 통합적으로 관리할 수 있습니다. 

과거 일반적인 VDI 환경에서는 가장 앞단의 경계에 놓인 방화벽이 뚫리면 그 안쪽은 무주공산이었습니다. 만약 하나의 VM에 해커가 침입했을 경우 주위에 있는 VM 역시 해커의 공격에 노출되게 되는 것이라고 할 수 있죠. 게다가 해커가 경계 방화벽을 뚫고 기업의 VM들을 넘나들며 알 수 없는 트래픽을 발생시키더라도, 네트워크 관리자 입장에서는 이게 정상적인 트래픽인지 비정상적인 트래픽인지 파악하기도 쉽지 않았습니다. 하지만 SDN에서는 위와 같이 VM단위 별로 방화벽을 구성할 수 있습니다. 그래서 가장 앞단의 경계 방화벽이 뚫려 특정 VM에 해커가 침입했더라도 다른 VM을 공격할 수 없는 환경을 구현해 줍니다.

보안에 대한 이야기를 좀더 해볼까요? 과거의 네트워크 보안을 위해서는 네트워크 침입 탐지 및 방지를 위한 IDS, IPS 장비를 랙 안에 별도로 설치하고, 해당 장비를 네트워크 스위치와 연결해 네트워크 보안을 관리했어야 했습니다. 때문에 이러한 보안 장비가 있는 환경에서는 일반 트래픽도 보안 장비를 한번 거쳐가야 하는 불편함이 있죠. 반드시 통과해야 하는 코스가 늘어나게 되면, 트래픽 지연이 발생하는 것은 당연한 결과입니다.

반면 SDN 환경의 보안은 다릅니다. 앞서 말씀드린 물리적인 IDS/IPS가 가지고 있던 보안 기능들이 모두 SDN 컨트롤러에 통합되어 있고, 이 SDN 컨트롤러는 하이퍼바이저 안에 존재합니다. 그리고 다른 네트워크 스위치와 서버들은 이미 SDN으로 연결되어 있죠. 덕분에 별도의 장비로 트래픽을 한번 보낼 필요 없이 SDN 컨트롤러 차원에서 모든 트래픽을 점검하고 불필요한 트래픽을 감지해서 차단시킬 수 있습니다.

SDN은 논리 단위의 정책 적용을 통해 보다 촘촘한 보안 환경을 운영할 수 있도록 돕습니다. 과거의 일반적인 네트워크 환경에서는 트래픽이 VM에서 커널을 지나 IDS/IPS를 거쳐서 다시 VM으로 되돌아오는 구조였다면, SDN에서는 그럴 필요 없이 트래픽이 커널을 통과하지 않고 그 안에서만 이동합니다. 덕분에 트래픽 전송 속도 향상과 더불어 보안상으로 더욱 안전해 지는 효과를 누릴 수 있습니다.

그리고 SDN은 논리적 단위로 정책을 생성하여 그룹 별로 적용할 수 있다고 말씀드렸는데요. 가령, DMZ존의 경우 SSL/TLS 1.2 이상의 트래픽만 통과시킬 수 있고, DMZ존 아래에 있는 서비스 영역과 DMZ존과의 통신은 애플리케이션에 접근하는 사용자 ID별로 구분해서 접근을 허용할 지 말지를 결정할 수 있습니다. 그리고 서비스 영역과 개발 영역은 아예 통신할 수 없도록 구성할 수도 있습니다.

​

 4) CMP(Cloud Management Platform)

SDDC를 구성하는 4가지 요소 중 마지막은 CMP입니다. 지금까지 말씀드린 SDC, SDS, SDN을 각각 따로 관리한다면 앞서 언급했던 것처럼 IT인프라 관리 방식은 종전과 다를바 없게 됩니다. 그저 새로운 기술을 사용하는 것 뿐이죠. 때문에 이러한 3가지 SDDC 구성 요소를 통합 관리할 수 있는 플랫폼, CMP가 필요합니다.

위 장표에 나타난 모니터링, 자동화 및 셀프 서비스, 비용 산정 및 분석, 감사, 이벤트 알람 등은 기존의 IT인프라 환경에서도 수행하던 업무들입니다. 만약 CMP가 없다면, SDC, SDS, SDN 각각 개별적으로 이러한 업무들을 각기 다른 요소 별 소프트웨어를 통해 수행해야 하는 불편함이 생깁니다. 하지만 CMP가 있으면 모든 요소 별로 이러한 업무를 통합해서 관리할 수 있게 되죠. 그것도 하나의, 단일 소프트웨어에서 할 수 있습니다. SDDC로 전환해서 관리 편의성과 운영 효율성 향상을 누리기 위한 키는 결국 CMP가 쥐고 있다고 보셔도 무방합니다.

효성인포메이션시스템이 제공하는 CMP 관리자 화면입니다. 보시면 카탈로그 항목이라고 되어 있고 다양한 서비스 카탈로그가 존재하는 것을 볼 수 있는데요. 과거 일반적인 IT인프라 환경에서 특정 서비스를 구현하기 위해서는 해당 서비스에 필요한 하드웨어를 준비하고 VM을 올리고 OS 설치하고 네트워크 구성 설정하고 보안 정책 적용한 다음 서비스를 올려야 했습니다. 즉, 서비스 하나 올릴 때 마다 반복적으로 수행해야 하는 작업들이 상당히 많았죠.

하지만 CMP에서는 관리자가 이러한 서비스들을 사전에 위와 같이 템플릿 형태로 정의할 수 있습니다. 이미 서비스에 알맞은 인프라 환경을 세팅하고 OS 설치와 네트워크 구성 설정 및 보안 정책까지 끝마친 서비스를 카탈로그에 올려두면 됩니다. 현업에서 필요로 하는 서비스를 미리 만들어 둘 수도 있고, 사용자에게 요청을 받아 만들 수도 있습니다. 이렇게 되면 관리자 입장에서는 같은 유형의 서비스를 만들기 위해 필수적으로 거쳐야 하는 반복 작업들을 하지 않아도 되는 장점이 생깁니다.

이렇게 관리자가 만든 서비스를 사용자는 CMP 카탈로그 화면에서 보고 얼마나 사용할 지를 결정해 관리자에게 사용 요청하면 됩니다. 그럼 관리자는 해당 요청을 받아 검토 후 승인 혹은 거절하면 되고요. 이러한 서비스 카탈로그 화면은 당연히 CMP에 접근하는 사용자 별로 다르게 나타납니다. 내가 현재 사용하고 있는 항목이 무엇인지 나타나며, 사용자의 직무 혹은 소속된 팀에 따라 어떤 서비스를 신청할 수 있는지를 관리자가 정책으로 관리할 수 있다고 보시면 됩니다.

​

3. 효성인포메이션시스템의 SDDC 구현 역량

지금까지 말씀드린 SDDC 구성 요소 별 특징은 다소 원론적인 이야기입니다. 어느 SDDC 벤더라도 비슷하게 설명할 수 있다는 것인데요. 그렇다면 효성인포메이션시스템은 이러한 SDDC 데이터 센터를 잘 구축할 수 있는 충분한 역량을 가지고 있을까요? 그 내용은 위와 같은 구축 사례로 입증할 수 있습니다.

장표에 나타난 기업의 경우 다수의 스타트업들에게 개발 지원 플랫폼 및 VDI 기반 스마트 오피스 플랫폼, 빅데이터 분석 플랫폼을 위한 SDDC 기반 프라이빗 클라우드를 구현하고자 했습니다. 이를 위해 효성인포메이션시스템이 위와 같은 전체 업무 설계도를 그렸고, 이를 위해 필요한 IT인프라에 더해 각 업무 영역 별로 어떻게 구현해야 하는지에 대한 컨설팅과 실제 구축을 완료했고요. 구축 이후 원활한 SDDC 운영을 위한 유지보수 및 기술지원까지 제공하고 있습니다.

좀 더 구체적으로 살펴보면, 위와 같이 스타트업을 위한 IaaS 플랫폼은 SDC/SDS/SDN + CMP로 구성했고, 애플리케이션 운영 인프라 기반은 VM입니다. PaaS 플랫폼은 여기에 컨테이너를 더한 환경이라고 보시면 되고요. 스마트 오피스 플랫폼은 VDI로 구성한 것이며 빅데이터 분석 플랫폼은 대량의 데이터를 빠르게 분석할 수 있는 GPU 서버를 추가한 구성이라고 보시면 됩니다. 그리고 이렇게 구분된 4가지 영역 외의 것들은 효성인포메이션시스템의 오랜 전문 분야인 블록 / 파일 / 오브젝트 스토리지 솔루션으로 커버하고 있습니다.

앞서 보여드린 사례 외에도 효성인포메이션시스템은 다수의 SDDC 구축 사례를 보유하고 있습니다. 하지만 단순히 구축사례가 많다고 해서 SDDC 구현 역량이 훌륭하다고 보기는 어렵습니다. 관계된 여러 벤더, 업체의 도움을 받아 고객의 SDDC를 구축하고 빠지는 케이스도 분명 있을 테니까요.

그러나 효성인포메이션시스템은 온프레미스에서 SDDC로의 전환을 고려하고 있는 기업들의 고민이 무엇인지, 무엇때문에 SDDC 도입을 주저하는지 잘 알고 있습니다. 이를 바탕으로 자문 / 컨설팅과 SDDC 계획 및 설계, 그리고 구축과 수행까지 SDDC를 위한 End-to-End 서비스를 제공하는 기업입니다. 다수의 국내 SDDC 전환 프로젝트를 성공적으로 완수한 사례에 더해 지금까지 그들의 SDDC를 기술지원하고 있는 점이, 효성인포메이션시스템의 SDDC 구축 역량이 충분하다는 것을 입증하고 있는 것이 아닌가 싶습니다.

그리고 이번 콘텐츠에서 소개해 드리지는 못했지만, 지난 7월에 있었던 쉐어드IT 클라우드 인프라 컨퍼런스에 참여한 효성인포메이션시스템은 자체적인 DX센터를 통해 기업이 자사의 데이터 센터를 실제 SDDC로 전환하기 전에 테스트해볼 수 있는 환경을 갖추고 있습니다. 고객의 IT관리자가 DX센터에서 미리 구현된 SDDC 환경을 직접 체험해 봄으로써, 자사의 IT인프라 운영 환경 대비 무엇이 좋아졌고, 앞으로 SDDC로 전환하게 되면 무엇이 더 필요할 지 파악할 수 있습니다. 그리고 실제 SDDC로 전환이 완료되면, DX센터에서 CMP 기반의 SDDC 운영 교육도 받으실 수 있고요.

지금까지 말씀드린 SDDC 내용은 위 웨비나의 내용을 정리한 것입니다. 효성인포메이션시스템의 김기수 컨설턴트가 직접 자세히 전달하는 전체 발표 내용이 궁금하신 분들은 위 영상을 참고해 주시기 바라고요. 자사의 온프레미스 데이터 센터를 SDDC로 전환하기 위해 준비 중이신 분들 혹은 SDDC 전환을 고민 중이신 분들은 아래의 링크를 통해 효성인포메이션시스템 전문가의 도움을 받아보시기 바랍니다.

• ●효성인포메이션시스템 전문가에게 문의하기

이 콘텐츠가 SDDC 도입을 주저하시는 분들, SDDC란 무엇이고 어떻게 접근해야 하는지에 대한 정보가 부족했던 분들께 조금이나마 도움이 되었기를 바랍니다. 끝!