1.클라우드 전환 개요 

엔터프라이즈 기업의 데이터센터가 변화하고 있습니다. 유닉스 기반의 경직된 시스템 환경에서 스케일 아웃을 통한 확장성 있는 인프라로의 변화를 위하여 많은 기업들이 소프트웨어 정의 데이터센터(SDDC:Software Defined Data Center)를 외치고 있는 실정입니다.

현재 데이터센터를 자체적으로 보유한 기업들 조차도 신규 서비스 기획 시 사업에 대한 불명확성, 시장 반응들을 살펴볼 수 있는 시스템을 만들기 위하여 하드웨어 박스를 구매하고, 상용 소프트웨어로 도배된 데이터센터 기반 시스템의 사용에 대해 의문을 가지고 있으며, 일부 서비스를 클라우드 서비스 혹은 하이브리드 방식의 클라우드로의 전환을 검토 또는 진행 중에 있습니다.

퍼블릭 클라우드 인프라 시장도 급속도로 팽창을 하고 있으며, 아래의 표에서도 나타나지만 IaaS, PaaS 시장은 계속 4대 업체로 통합되고 있다. 이들 대형업체는 신규 서비스를 지속적으로 내놓고 있으며, 자신들의 강점 분야를 내세워 데이터센터 고객의 자사 클라우드 유도와 하이브리드 운영 방안에 대한 레퍼런스를 지속적으로 내놓고 있는 상황입니다.

가트너에 의하면 아마존은 2019년 7월 기준으로 전세계 IaaS 시장의 50% 이상을 여전히 차지하고 있는 것으로 발표하고 있습니다.

참고URL:  https://www.zdnet.co.kr/view/?no=20190730175837(아마존 IaaS 시장 절반 이상 독식)

국내의 경우 가장 먼저 진출한 아마존 AWS가 시장에서 많이 적용되고 있으며, 스타트업들에게는 사실상의 표준(DeFacto Standard)으로 자리를 잡았습니다. 본 아티클에서는 엔터프라이즈 관점에서 데이터 센터을 어떻게 퍼블릭 클라우드로 전환하는지에 대해 살펴보려고 합니다.

전환의 이유는 무엇인가?

국내 대기업의 데이터센터는 그룹사의 IT를 담당하는 회사에서 관리를 주로 하고 있으며, 오픈스택 또는 가상화 기반 하의 클라우드라는 명칭으로 각 그룹 고객사에 서비스 제공하려 많은 노력들을 기울이고 있습니다. 내부의 IT 자원의 성능이 훨씬 더 압도적일 것이라 대부분 판단하지만 퍼블릭 클라우드 서비스 업체가 기반 물리 자원에 대한 액세스를 너무나 잘 관리하기 때문에 그 차이가 그렇게 극명하게 나지 않는 것이 일반적입니다.

또한 내부 ITSM시스템의 관제하에 들어가게 되므로 클라우드 컴퓨팅이 제공하는 가치의 많은 부분이 민첩성에서 나온다는 점에서 이를 포기하고 데이터 센터만을 고집하는 것도 좋은 결정은 아닐 것입니다. 이로 인해 퍼블릭 클라우드에 대한 도입 검토와 개념검증(PoC), 실제 전환이 활발하게 이루어지고 있는 실정입니다.

일반적으로 전환 후 록인(lock-in)에 대해서 우려를 하는 기업들도 있겠지만 그러한 록인은 데이터 센터가 훨씬 더 심하며, 기업은 다양한 서버와 운영체제, 애플리케이션, 어플라이언스를 선택하고 원하는 특정 결과를 얻기 위한 과정일 뿐입니다.

어떻게 전환할 것인가?

클라우드 전환에 있어 중요한 한 가지는 클라우드라는 트렌드에 대한 기업의 ‘적응력’과 ‘변화에 대한 의지’가 가장 클 것입니다.

쿠팡(쿠팡, IT인프라 전체를 AWS클라우드로 이전했다, 기사: https://byline.network/2017/08/10-6/ )과 같이 모든 인프라를 퍼블릭 클라우드로 전환하는 경우도 있겠지만, 대부분은 기존에 운영되던 시스템과 고객의 정보(규제를 포함하는)로 인하여 100% 이전을 못하는 경우가 대다수이다. 이로 인해 단계적인 클라우드 전환을 고려하게 되는데, 아래와 같이 데이터 센터와 퍼블릭 클라우드를 연결하여 상호 통신을 할 수 있도록 서비스를 구성하게 됩니다.

<그림. 데이터센터와 퍼블릭 클라우드>

퍼블릭 클라우드로 전환할 수 있는 단계는 여러가지가 있을 수 있지만 우선 크게 3단계에 대한 전환 절차를 고려할 수 있습니다.

첫번째 단계로 대상 시스템 선정 및 기술입니다. 기존의 내부 시스템에 대한 조사를 통해 퍼블릭 클라우드의 유연성(오토스케일링 같은)을 통해 그 효과를 즉시 확인할 수 있는 시스템들이 그 대상이 될 수 있습니다. 이러한 시스템에 대한 AS-IS 현황 분석을 통해 클라우드 전환 시 TO-BE 아키텍처를 그릴 수 있습니다. 이 때 중요한 것은 전체 업무 대상 시스템이 아니며, 현재 가장 손쉽게 올릴 수 있는 WEB-WAS-DB 아키텍처를 가진 트래픽의 양 변화가 큰 업무들이 대상이 될 수 있습니다.

그 업무 시스템에서 사용하는 기술들이 클라우드로 전환됐을 때, 그대로 옮겨갈 것인지 AWS와 같은 클라우드의 네이티브 서비스(예: ELB, RDS, DynamoDB)를 활용할 것인지도 중요한 결정 사항이 될 것입니다.

두번째 단계로는 시스템 전환입니다. 대부분의 큰 기업에서는 내부의 데이터센터와 클라우드를 연결하는 것을 기본 전제로 하고 있다. 이 때 서비스를 어떻게 구성할지에 대한 부분의 검토를 하게 되는데, 보통 퍼블릭 클라우드에서는 아래의 방식의 서비스들을 제공하고 있습니다.

<그림. 기업의 퍼블릭 클라우드 연결 방식>

기업 내의 데이터 센터와의 연결 시 전용선(비용 상승) 방식과 VPN을 통한 퍼블릭 클라우드 네트워크 연결을 고려할 수 있으며, 비용과 안정성 측면에서 장단점이 존재하므로 전환 시 의사결정이 필요한 부분 중 하나이다.

이후 클라우드 시스템 내의 목표 시스템 설계, 기술 아키텍처를 정의하고 기존의 베어메탈 방식에서 활용되던 개념을 스케일-아웃형 시스템으로 전환 설계 후 전환 작업을 진행한다. 전환 단계 상에서 성능, 안정성, 확장성 테스트를 통해 해당 시스템이 처리할 수 있는 능력을 정확하게 파악하고 이를 기준으로 향후 신규 온디맨드 시스템들이 필요한 경우 지표로 삼을 수 있어야 한다.

전환의 방식은 크게 아래와 가지를 들 수 있다.

• Life-and-Shift 방식: 기존 시스템의 기능, 소프트웨어 등을 변경하지 않고 그대로 클라우드 이전
• Cloud-Native 방식: 퍼블릭 클라우드에서 운영할 수 있도록 초기 또는 전환 시점부터 클라우드가 제공하는 서비스 활용에 중점을 두어 이전
• 오픈소스 전환 방식: 클라우드의 이점인 확장성과 비용 효율성을 최대한 살릴 수 있도록 대응 오픈소스로 변경하여 이전(멀티 클라우드 대응, 록인 방지)

전환에 대한 목표와 시스템 소프트웨어의 변경에 대한 예시는 다음의 그림과 같습니다.

<그림. 클라우드 목표모델 레이어 및 시스템 소프트웨어 변화>

마지막 단계로 운영 서비스로의 이행입니다. 전환 이후 전체 시스템에 대한 기능, 성능에 대한 상세 모니터링을 진행하고 필요 시 인스턴스 개수 조절, 사이즈 조정 등을 통해 비용최적화를 위한 작업을 진행합니다.

이 때의 운영은 DevOps를 기반으로 한 운영 서비스를 전제로 하고 DevOps로의 전환 (클라우드와 DevOps 툴을 통해 개발자 중심의 자동화 환경 구축 -> 지속적인 배포(CD, Continuous Delivery) 가 가능하게 함으로써 효율성을 확보하고 개발자의 생산성과 비즈니스 민첩성 향상을 위한 기초를 만들 수 있도록 해야 합니다.

기업이 가진 시스템에 대한 클라우드 전환은 빅뱅이 되어서는 안됩니다. 현재는 차세대 개념의 빅뱅형이 아닌 점진형 방식의 전환을 통해 리스크를 최소화할 수 있는 전략을 구상해야 한다. 전환 이후에도 트렌드로 자리잡아가고 있는 마이크로서비스 아키텍처, 컨테이너로의 확장과 자동화를 염두에 둔 전환이 필요한 시점이며, 이를 위한 조직/운영의 관점도 달라져야 할 것입니다.

2. 클라우드 기반의 컨테이너 서비스를 활용한 PaaS 

컨테이너 서비스가 대세다. 컨테이너는 리소스 격리 프로세스에서 애플리케이션과 종속 항목을 실행하게 해주는 운영 시스템 가상화 방법입니다. 컨테이너를 사용하면 애플리케이션의 코드, 구성 및 의존성에 대한 사용이 단순한 빌딩 블록 형태로 바로 패키징할 수 있으며 빌딩 블록은 환경 일관성, 운영 효율성, 개발자 생산성, 버전 제어를 제공합니다. 이를 통해 애플리케이션이 보다 빠르고 안정적으로 배포와 운영이 될 수 있는 환경이 만들어질 수 있는 장점이 있습니다.

현재 프라이빗/퍼블릭 클라우드 기반의 인프라를 구축하거나 이미 사용하고 있는 엔터프라이즈에서는 DevOps, 시스템 간의 오케스트레이션을 위하여 적극적으로 컨테이너 서비스에 대한 조사와 도입 검토를 진행하고 있는 상황입니다. 이러한 맥락과 함께 컨테이너 서비스 시장은 현재 엄청난 팽창을 하고 있으며 클라우드와 연계된 기술 영역에서 매년 40%이상의 높은 성장률을 통해 2020년까지 27억 달러 수준으로 커질 것으로 전망하고 있습니다.

그림. 애플리케이션 컨테이너 서비스 시장 전망, 2017. 451 Research’s

출처: https://451research.com/images/Marketing/press_releases/Application-container-market-will-reach-2-7bn-in-2020_final_graphic.pdf

현재 아마존, IBM, 마이크로소프트의 퍼블릭 클라우드에서도 이러한 컨테이너 서비스를 통한 애플리케이션 빌딩 블록을 만들 수 있는 서비스를 이미 내놓고 있는 상태이며, PaaS(Platform as a Service) 환경을 구축하는 부분에 대해 적극적으로 고객을 유도하고 있는 상황입니다.

현재 컨테이너 서비스들은 대부분 리눅스 환경에서 작동되고 Linux 컨테이너를 활용하여 개발 팀과 운영 팀 간의 충돌을 줄일 수 있다. 또한, Linux 컨테이너는  오픈소스 기술을 기반으로 하기 때문에 사용 즉시 최신 기술을 활용하여 회사 내부 인프라 및 애플리케이션에 대한 발전을 시킬 수 있는 특징을 가지고 있습니다.   CRI-O,  Kubernetes 및  Docker 등의 컨테이너 기술은 애플리케이션 개발 및 배포를 간소화하고 가속화하는 데 큰 도움이 됩니다.

퍼블릭 클라우드의 컨테이너 서비스

퍼블릭 클라우드들은 컨테이너를 위한 다양한 서비스를 제공하여 고객들을 자사의 클라우드 서비스로 유도하기 위해 많은 노력을 기울이고 있습니다.

IBM 클라우드에서는 Blumix Container Service를 통해 컨테이너 서비스를 제공하고 있으며, 하위의 인프라 기반은 Kubernetes와 Docker 기반으로 스케줄링, 자체 복구, 스케일-아웃 기능을 제공하고 IBM의 인프라에서는 마스터 노드를 관리하며, 사용자들은 자신들의 서비스에 대한 작업 노드를 정의하는 구조로 되어 있습니다.

특징적인 부분은 CLI 기반으로 클러스터 배치 등을 관리하고 강점으로 내세우는 왓슨(Watson)을 활용하여 스토리지, 분석, 액세스 제어 등에 대한 서비스를 통합할 수 있는 기능을 제공하고 있습니다.

아마존은 ECS(Amazon EC2 Container Service) 서비스를 통해 Docker 컨테이너를 제공하고 있으며, EKS(Elastic Kubernetes Service)의 자체 클러스터 관리 인프라를 구축하여 고객에게 제공하고 있습니다. SDK를 통한 API 호출을 통해 클러스터 상태관리, 보안, 엘라스틱 로드밸런싱, EBS 등에 대한 리소스 연계와 확장을 제공하고 있는 특징이 있으며, EC2 서비스 내에 포함되어 컨테이너 서비스에 대한 별도 비용이 필요없다는 특징이 있습니다.

마이크로소프트는 애저 컨테이너 서비스를 활용하여 아마치 메소스, Docker 등을 함께 사용할 수 있는 서비스를 제공하고 있으며, 2015년에 서비스를 출시했습니다. 다른 퍼블릭 클라우드와는 다르게 Docker를 위한 비주얼 스튜디오(Visual Studio Tools for Docker)를 통해 컨테이너 환경 하에서 윈도우용 .NET 이나 리눅스용 코어 응용 프로그램을 빌드하여 배포할 수 있는 기능을 제공하고 있습니다. 또한 비주얼 스튜디오 팀 서비스를 통해 애자일 및 DevOps를 위한 워크플로우에 컨테이너를 통합할 수 있는 기능을 제공하고 있습니다.

Docker를 통한 기술/프로세스 표준화

프라이빗과 퍼블릭 클라우드의 방향성은 IaaS 기반에서 컨테이너 서비스를 통한 플랫폼 유연성을 극대화하는 방법으로도 진화하고 있습니다. Docker는 별도의 게스트 OS를 설치하지 않고 커널 레벨에서 격리된 가상의 공간을 제공한다. 이의 장점은 호스트 운영체제와의 속도 차이가 거의 없고 가상머신보다 경량화된 상태에서 관리를 할 수 있습니다.

그림. 클라우드, 컨테이너, 마이크로서비스, DevOps 구조, DZone

출처: https://dzone.com/articles/markus-eisele-answers-questions-about-java-ee-and

현재 많은 기업들이 자사의 서비스 기반을 마이크로 아키텍처 서비스로 만들고자 하면서 컨테이너 서비스를 활용하고 이에 대한 내부 기술 표준화를 위한 시도를 많이 하고 있다. 또한 개발/배포/운영 프로세스에 대한 부분을 컨테이너 서비스를 통해 일원화하기 위한 노력도 병행하고 있습니다. MSA(Micro Service Architecture)를 컨테이너 기반으로 구성하는데 있어 프로세스화 되어야 하는 부분은 DevOps 영역입니다.

컨테이너는 이러한 DevOps 영역에 대한 부분을 통합할 수 있도록 하는 좋은 방법 중의 하나입니다. 컨테이너는 개발과 운영이라는 두 팀간의 장벽을 허무는 DevOps의 가교 역할을 하게 되며, 두 팀이 함께 협업하여 개발자 생산성과 운영의 안정성이라는 두 마리 토끼를 잡게 해줍니다.

그러한 관점에서 인프라, 컨테이너, 미들웨어 컴포넌트를 컨테이너화함으로써 클라우드 네이티브 형태의 애플리케이션을 만들 수 있습니다. 또한 기업이 가진 업무 시스템을 최적화하는 방법으로 컨테이너화된 다양한 오픈소스 기술을 활용하여 비즈니스적인 목표를 달성할 수도 있다. 이를 도식화한 간략한 그림은 아래와 같습니다.

그림. 클라우드 네이티브 영역 지도( https://github.com/cncf/landscape 의 도식도를 축약한 것임)

그림에서 보는 것처럼 컨테이너 서비스는 그 기반이 퍼블릭과 프라이빗과 상관없이 작동시키며 프로비저닝 자동화, 프로세스 개선, DevOps를 활용할 수 있는 기반을 마련해줍니다. 또한 조직이 소프트웨어 개발과 인프라 관리 프로세스의 자동화 및 간소화를 통해 더 빠르게 혁신할 수 있도록 지원하며, 이를 통한 비즈니스 이익이 극대화될 수 있도록 도와줍니다.

컨테이너, PaaS, DevOps는 상호 연결된 밀접한 단어이다. 아직 IaaS를 기반으로 한 클라우드(퍼블릭/클라우드)에 대한 경험이 없는 상태라 하더라도 기획을 해볼 수 있는 중요한 아이템이 바로 컨테이너 기반 PaaS 영역이다. 인프라 자동화, DevOps, MSA 등의 단어를 의식하고 있다면 클라우드 기반의 컨테이너 서비스 대한 적극적 검토를 해보아야 하며, 향후 펼쳐지게 될 IT 시스템의 변화에 대한 준비를 해야 할 것입니다.