디지털 Transformation, 데이터센터 & Cloud, 베트남

Cloud Friendly, Cloud Native 등 친숙하지 않은 개념들을 많이 듣게 됩니다.

Cloud Native Application은 Cloud 환경에 최적화된 애플리케이션이라고 할 수 있는데 이것만 가지고는 어떤 의미인지 이해하기가 어렵습니다.

기업들이 Cloud를 도입하는 이유가 뭘까요? 새로운 기술, 즉 트렌드라서? 분명한 이점이 있기 때문일텐데요, 

가장 대표적으로 IT자원에 대한 자산투자를 하지 않고, 데이터센터 및 서버/운영체제/스토리지/네트웍 등의 자원에 대한 운영인력을 줄이고 컴퓨팅 자원은 필요할 때 즉각적으로 사용하고, 사용량만큼 비용을 지불할 수 있기 때문일 겁니다. Cloud도입 초기에는 인프라(데이터센터, 서버/스토리지/네트웍 등)를 빌려쓰는 IaaS로도 효과를 충분히 볼 수 있었지만, IaaS를 사용해보면 알겠지만 운영체제의 운영, 데이터베이스 운영, 네트웍 및 미들웨어 (Tomcat, Jeus 등) 운영 등 실제 애플리케이션 개발을 위한 플랫폼 운영 관련한 인력이 유지되어야 하고, 플랫폼 소프트웨어 설치/운영/모니터링 등의 업무도 그대로 남게 됨을 알 수 있습니다. 소프트웨어 개발자와 시스템 운영자는 여전히 넘을 수 없는 벽을 사이에 두고 일하게 되고, 개발자가 짠 애플리케이션은 하나의 거대한 단일 애플리케이션 (Monolithic)으로 구성되어 있어, 그중의 일부를 바꾸기 위해서는 전체 애플리케이션을 빌드하고 배포해야 하므로 배포는 자주해서는 안되는 금기시되는, 고객에게 필요한 기능도 쉽게 적용할 수 없는 상황에 처하게 됩니다. 

Cloud에 최적화된 애플리케이션은 바로 위에서 벌어지는 다양한 불합리함을 극복할 수 있게 해주는데, 가장 중요한 factor는 자동화라고 볼 수 있을 것 같습니다. 여기서, DevOps, Continuous Delivery, Micro-service, 그리고 Container 개념이 등장하게 됩니다. 

DevOps는 소프트웨어 개발자와 IT운영자간의 협업을 의미하는데, 소프트웨어 배포(Delivery)나 인프라의 변경 프로세스를 자동화하는 목적으로 합니다. 소프트웨어의 개발, 테스트와 배포를 보다 더 빠르고, 자주, 안정적으로 할 수 있는 하나의 문화라고 볼 수 있을 것 같습니다. 

Continuous Delivery는 단위 애플리케이션이 변경되어 배포되어야 할 때 시스템 정비시간을 기다릴 필요없이 배포할 수 있는 특징을 의미합니다. 배포작업은 모든 개발자 및 시스템 운영자가 부담스러워 하는 작업인데, 위험부담을 줄이고 고객의 피드백을 빠르게 적용하여 경쟁자를 압도할 수 있게 됩니다. 넷플릭스나 Amazon.com이 하루에도 수십/수백번의 배포를 할 수 있는 것도 바로 Continuous Delivery 정책을 사용하기 때문입니다. 

Microservice는 작은 서비스의 결합으로 하나의 애플리케이션을 구성하는 아키텍처 디자인 접근방식입니다. 각 서비스는 HTTP API를 통해 통신하고, 서비스별로 배포, 업그레이드, 스케일 out 및 구동될 수 있고 타 서비스와의 연결고리가 약하게 되어 있기 때문에 사용자에게 영향을 최소화 또는 없게 업데이트할 수 있습니다. 

Container는 하나의 운영체제 (물리적서버 or VM에 무관)에 서로 독립적인 파일시스템과 리소스를 갖고 있는 container로 나뉘어 동작합니다. Container의 생성 및 폐기가 가상머신에 비해 엄청 빠르게 이루어지고, 자원도 거의 사용하지 않아 고집적으로 사용할 수 있습니다. 

바로 이러한 DevOps, CD, MSA, Container 방식으로 개발된 Cloud Native Application의 구동을 가능하게 하려면 PaaS (Platform as a Service)가 필요하게 되는데, 가장 많이 사용하는 플랫폼이 바로 Cloud Foundry 입니다. 

모든 기술은 진화한다.

물리적인 서버, 가상화, 그리고 Infra Cloud (IaaS), 그리고 PaaS (Platform as a Service)로 진화하더니 이제는 Container로 ... 

오늘은 Container에 대한 이야기를 좀 해보려고 한다. 

가장 대표적인 회사가 Docker라고 생각할 것이고, Docker는 CaaS (Container as a Service)를 제공하는 회사이다. 

Container는 VM (Virtual Machine)과 달리, 운영체제를 전부 포함하고 있지 않고 소프트웨어가 동작하는데 꼭 필요한 코드, 런타임, 시스템도구, 시스템 라이브러리와 설정값을 갖고 있다. 리눅스와 윈도우 기반 앱으로 동작하고, 어떤 환경에 배포되더라도 항상 동일한 동작을 한다. Container는 주변 환경과 소프트웨어를 격리시켜주므로 개발, 스테이징 환경 등의 차이에 무관하게 동작한다. VM 대비로 훨씬 적은 자원/공간을 점유하고, 일반적으로 수십 메가바이트 규모이며 대부분 즉시 (초단위로) 구동된다. 

VM (Virtual Machine)은 물리적 하드웨어를 추상화한것으로 봐야하는데, 하이퍼바이저를 통해 하나의 하드웨어에 여러개의 VM을 구동하는 방식이다. 각 VM은 운영체제를 다 설치해야하고 여러개의 애플리케이션과 라이브러리 등을 설치해야 하기 때문에 수십 기가바이트 규모로, 부팅에 오랜 시간이 소요된다. 

일단 container를 사용하고자 마음 먹으면, container를 스케쥴링하고 관리하는 솔루션이 필요하게 된다. 바로 이 역할을 하는 것이 Orchestration 도구인데, 가장 일반적으로 많이 알려진 것이 Kubernetes와 Docker Swarm이다. 그 중에서 완성도가 높고 확장성이 있는 솔루션이 바로 Kubernetes이고, 오픈소스라는 것이 특징이다. (구글이 만들었다.)

개중에는 Docker와 Kubernetes를 비교하는 경우가 있는데, Docker는 orchestration만 제공하는 것이 아닌 훨씬 많은 것을 제공하므로 Docker Swarm과 대응하는 솔루션임을 꼭 기억하자. Docker Swarm은 아직은 좀 더 성숙할 시간이 필요하다고 생각한다. 

Kubernetes에 대해서는 조금씩 자세히 알아보도록 하겠다.