클라우드의 시대, 컨테이너 오케스트레이션 툴이 반드시 필요한 이유

클라우드 네이티브 애플리케이션 전략

기업이 환경 변화에 보다 민첩하게 대응하고 리스크를 최소화하며 기회를 최대한 활용하기 위해서는 애플리케이션과 플랫폼을 구현하고 운영하기 위한 IT 요소들에 많은 변화가 필요합니다.

개발방법론, 아키텍처, 조직, 프로세스, 인프라, 개발언어 등이 이에 해당되는데, 디지털 트랜스포메이션에 필요한 이 많은 요소를 기업에서 한꺼번에 도입하고 내재화 하는 것은 정말 어려운 일입니다. 그래서 일부 영역부터, On-premises 에서 클라우드로 단계적인 마이그레이션을 하는 전략이 필요할 수 있습니다.

궁극적으로 모든 시스템 요소를 클라우드 기반으로 변경하고, 클라우드 컴퓨팅의 장점을 충분히 활용하기 위해서는 클라우드 네이티브 컨셉을 적극적으로 수용하면서 혁신의 속도를 높여가야 합니다.  기업은 클라우드 네이티브를 통해 보다 민첩한 비즈니스 활동을 전개할 수 있는 IT 시스템을 갖출 수 있기 때문입니다.

그렇다면 우리가 디지털트랜스포메이션을 이야기 할 때 빼놓지 않고 언급하는 ‘클라우드 네이티브’란 과연 무엇을 의미하는 것일까요? 

클라우드 네이티브는 클라우드의 규모와 성능에 최적화 되어있는 애플리케이션을 개발하기 위한 접근 방식과 기술을 의미합니다. 클라우드 네이티브 애플리케이션은 프라이빗, 퍼블릭 및 하이브리드 클라우드 환경 전체에, 지속적인 개발과 자동화된 운영 환경 제공을 위해 설계된 애플리케이션입니다. 클라우드가 제공하는 민첩성, 가용성, 확장성의 장점을 애플리케이션/서비스의 개발, 운영, 관리에 적용하여 기존 환경을 최적화할 수 있습니다. 

클라우드 네이티브 애플리케이션 개발을 위해 필요한 여러 가지 핵심 기술 가운데, 공통적으로 언급되는 기술은 MSA, CI/CD, DevOps 그리고 Container입니다.

MSA (Micro Service Architecture) 는 기존에 하나로 되어 있던 애플리케이션을 실행이 가능한 업무 단위인 마이크로서비스 블록으로 나누어 상호 통신을 통해 연계하여 애플리케이션을 구성하는 소프트웨어 아키텍처입니다. 고객의 요구와 기술적 환경 변화에 빠르게 대응할 수 있는 유연한 시스템을 개발 운영할 수 있습니다. 

CI/CD는 지속적인 통합, 서비스 제공, 배포를 의미하는 것으로 애플리케이션 라이프사이클 전체에 걸쳐 지속적인 자동화와 시각화, 프로세스 단순화가 핵심입니다. 

DevOps는 소프트웨어 시스템을 빠르게, 고품질로 개발 및 운영하기 위한 조직 문화이자 접근 방식으로 각 조직들이 공동의 목표를 설정하고, 이를 위한 여러 자동화 도구 및 시각화 툴 등을 활용해 빠른 개발과 운영이 가능합니다.

마지막은 Container입니다.  컨테이너는 인프라의 일관성을 유지하며, 안전한 배포 및 운영을 가능하게 해주는 기술로 애플리케이션 실행에 필요한 라이브러리, 바이너리, 구성 파일을 하나의 객체로 패키징하는 표준화된 방식을 제공합니다. 호스트 환경과 관계없이 애플리케이션 실행이 보장되므로, 최소한의 조건만 유지된다면 컨테이너는 어떤 환경에서도 실행될 수 있는 독립성이 보장됩니다.

왜 컨테이너인가?

2020년 현재 컨테이너는 가장 ‘핫’한 IT 기술 가운데 하나입니다. 컨테이너 기술에는 여러가지가 있지만 가장 많이 사용되고 있는 것은 ‘도커’입니다. 도커는 애플리케이션 실행에 필요한 환경을 하나의 이미지로 모으고, 그 이미지를 사용하여 다양한 환경에서 애플리케이션 실행 환경을 구축, 운영하기 위한 소프트웨어 입니다. 

온프레미스, 프라이빗/퍼블릭 클라우드, 하이브리드 클라우드, 멀티 클라우드 등 인프라가 복잡해져감에 따라 도커 컨테이너는 점점 더, 중요한 기술이 되어 가고 있습니다. 클라우드가 더욱 발전한다면 그것은 도커 컨테이너 덕분에, 가능할 것이라는 얘기가 나오고 있을 정도입니다. 

도커 컨테이너가 클라우드 네이티브의 핵심 기술로 떠오르고 있는 가장 큰 이유는 애플리케이션의 독립성과 이식성 그리고 확장성 때문입니다. 도커 컨테이너는 하나의 애플리케이션을 패키징한 형태로, 불필요한 프로세스는 존재하지 않으며, 오직 애플리케이션을 실행하기 위한 라이브러리, 바이너리, 구성 파일을 함께 패키지로 묶어 놓은 것입니다. 애플리케이션을 실행하지만 개별 애플리케이션에 필요한 환경은 완전히 독립되어 있습니다. 애플리케이션을 배포하면 운영 환경과 관계없이 애플리케이션 실행이 보장되므로, 최소한의 조건만 유지된다면 컨테이너는 어디서든 옮겨가면서 실행될 수 있습니다. 

컨테이너는 오케스트레이션 툴이 필요하다

컨테이너는 원래 프로세스나 애플리케이션을 기반 시스템으로부터 격리하기 위해 만들어졌기 때문에, 개별 컨테이너를 생성하고 배치하는 것은 쉬운 일입니다.

하지만 컨테이너의 수가 많아지게 되면 관리와 운영에 어려움이 따르게 됩니다.

각각 독립적으로 배치된 컨테이너를 연결하고 관리하고 확장하면서 이 요소들 전체가 하나로 실행되도록 할 수 있어야 합니다. 이렇게 다수의 컨테이너 실행을 관리하고 조율하는 것을 컨테이너 오케스트레이션이라고 부릅니다.

오케스트레이션 엔진을 통해 컨테이너의 생성과 소멸, 자동 배치 및 복제, 장애 복구, 스케줄링, 로드 밸런싱, 클러스터링 등 컨테이너로 애플리케이션을 구성하는 모든 과정을 관리할 수 있습니다.

단순한 컨테이너 앱은 일반적으로 오케스트레이션이 필요 없습니다. 하지만 앱의 기능과 사용자 수가 그 이상이라면 오케스트레이션 툴 없이 직접 해결하기는 매우 어려워집니다. 다수의 컨테이너가 관련되는 앱이라면 오케스트레이션 툴을 사용하는 것이 좋습니다.

조건이 바뀔 때 마다, 코딩으로 대응하지 않고 원하는 상태로 인프라를 구축할 수 있으며 워크로드와 컨테이너 균형을 위해 원하는 시스템 상태를 바꿀 수도 있습니다. CI/CD를 적용하여 운영관리를 하고 싶을 때 오케스트레이션 툴을 사용하면 여러 번 새로운 버전을 배포하더라도 pod를 점진적으로 새로운 것으로 업데이트하여 서비스 중단 없는 롤링 업데이트를 할 수 있습니다.

많이 사용되는 컨테이너 오케스트레이션 툴에는 쿠버네티스, Docker Swarm, Mesos 등이 있으며, 이 가운데 구글의 프로젝트를 기반으로 하는 쿠버네티스가 가장 많이 주목받고 있는 오픈소스 플랫폼입니다. 

쿠버네티스는 플랫폼에 종속되지 않기 때문에 퍼블릭 또는 프라이빗 클라우드 구축 환경이나 베어 메탈에서도 배포가 가능합니다. 특히, 하이브리드 및 멀티 클라우드를 혼용하여 사용하는 환경에서도 동일하게 적용할 수 있기 때문에 최근의 클라우드 구축 환경에서 많은 각광을 받고 있습니다.

또한, 2016년 클라우드 네이티브 컴퓨팅 파운데이션 산하의 인큐베이팅 프로젝트는 쿠버네티스를 포함 4개의 프로젝트가 전부 였지만, 2020년 현재 쿠퍼네티스를 포함해 9개의 프로젝트가 완료되었고, 17개의 인큐베이팅 프로젝트가 진행중입니다.

클라우드 네이티브 컴퓨팅 파운데이션 (CNCF)에서 발표한 2019 서베이 결과에 의하면, 조사 대상 기업의 78%가 쿠버네티스로 컨테이너 인프라를 관리하고 있다고 대답했습니다. 2018년에 58%였는데 1년 사이 20%가 증가한 것입니다.

클라우드 벤더인 아마존, 애저, 구글 모두 컨테이너 관리 환경을 쿠버네티스를 지원하는 정책으로 선회하였으며, IBM이나 시스코와 같은 온프레미스(on-premise) 솔루션 업체들도 경쟁적으로 쿠버네티스를 지원하고 있습니다.

도커 컨테이너 기술에 대한 종속을 피하려는 시도는 보이지만, 쿠버네티스 오케스트레이션이 적용되지 않은 플랫폼은 찾아보기 힘들 정도로 널리 퍼지고 있는 상황입니다.

컨테이너를 쉽고 편리하게 관리하는 방법

쿠버네티스 기반 애플리케이션은 사용하기 편하지만, 쿠버네티스 자체는 사용하기 쉽지 않다는 문제가 있습니다. 많은 기업들이 어렵고 복잡한 쿠버네티스를 쉽게 사용하고 싶어 하지만 대부분의 기업들에게 쿠버네티스는 여전히 ‘흑마술’에 가깝습니다. 일반적으로 엔지니어들이 쿠버네티스를 이해하려면 배워야 하는 ‘추상화’가 너무 많기 때문입니다. 

그럼에도 불구하고 쿠버네티스가 컨테이너 오케스트레이션의 대세로 자리잡은 이유는 무엇일까요?

서비스를 운영하는데 컨테이너를 하나만 사용한다면 쿠버네티스는 필요 없습니다. 하지만 운영환경에서는 다양한 종류의 컨테이너가 알맞은 워크로드에 맞게 여러 호스트에 배치되어야 합니다. 

일반적인 n-tier 아키텍처 환경에서는 워크로드를 효율적으로 분산 배치하기 어려울 수 있습니다. 컨테이너를 알맞은 위치에 배포하고, 확장하며, 업데이트, 모니터링 할 수 있는 컨테이너 오케스트레이션 툴이 없다면 복잡한 운영 환경의 워크로드를 충족하기 위한 클러스터 환경을 구축할 수 없습니다.

하지만 쿠버네티스를 기반으로 개발자가 작업을 하게 되면 어떤 클라우드를 사용하던 상관없이 모든 조직에 서비스를 전달할 수 있게 됩니다. 즉 쿠버네티스는 서로 다른 클라우드 간의 이식성을 보장함으로써 종속 현상을 방지할 수 있는 최적의 수단입니다.

이런 이유로 많은 기업들이 어렵고 복잡한 쿠버네티스를 쉽게 사용하고 싶어합니다. 이를 위해 컨테이너 통합 관리 솔루션들이 하나 둘씩 등장해 기업들이 쿠버네티스를 단순화하여 사용할 수 있도록 하는데 도움을 주고 있습니다. 

컨테이너를 쉽게 사용할 수 있도록 만들기 위해서는 배포, 관리, 모니터링 등 몇 가지 추가적인 요소들이 꼭 필요합니다.

첫째 쿠버네티스는 개발자가 빌드한 애플리케이션을 신속하게 다양한 방식으로 배포 및 업데이트 할 수 있습니다. 또한 배포된 애플리케이션에 문제가 있다면 배포 전으로 쉽게 롤백하는 기능을 지원합니다.

둘째 쿠버네티스는 컨테이너와 관련된 많은 부분을 자동화 하여 관리의 편의성을 제공하고 있습니다.  컨테이너화된 애플리케이션의 서비스 리소스 요구사항 또는 기타 제약 조건에 따른 자동 배치, 자원 사용률에 따른 컨테이너의 자동 확장, 여러 컨테이너를 묶어 단일 DNS 이름을 통한 로드밸런싱, 고가용성을 보장하는 점진적 배치 등이 이에 해당합니다.

셋째 쿠버네티스는 클러스터, 노드, 서비스, 파드, 앱 등에 대해 자체적인 모니터링 컴포넌트를 제공하고 있습니다. 시스템 관리자는 운영하고 있는 시스템의 모니터링을 통해 안정적인 운영과 서비스 장애를 미연에 방지할 수 있습니다.

쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고 확장 가능한 오픈소스 플랫폼입니다. 하지만, 오픈소스이기 때문에 안정적인 기술지원을 받기 힘듭니다.

만약 쿠버네티스를 이용하여 중요한 서비스를 운영하는 기업에서 장애가 발생한다면 신속한 기술지원을 받지 못해 장애 상태가 지속됨으로써 매우 어려운 상황에 놓일 수 있습니다. 이럴 때 쿠버네티스를 쉽게 운영 및 관리할 수 있는 솔루션이 있다면 쉽고 간단하게 장애 이슈를 해결할 수 있습니다.

아코디언은 쿠버네티스를 쉽고 편리하게 운영하기 위한 솔루션으로, 쿠버네티스를 통해 컨테이너를 쉽고 빠르게 배포하고 관리 운영하여 모니터링 할 수 있는 최적화된 환경을 제공합니다.

특히 템플릿을 통하여 손쉽게 앱을 등록하고 관리하면서 CI/CD를 적용하여 빌드 및 배포를 관리할 수 있도록 해줍니다. 또한 쿠버네티스의 기본 오브젝트뿐 아니라, 웹 어플리케이션에 특화된 모니터링 기능도 제공하여 장애 분석을 신속하게 할 수 있습니다.