클라우드와 모바일 환경이 확산되면서 빠른 서비스를 제공할 수 있는 능력이 기업의 경쟁력이 됐다. 고객은 오랜 시간 기다려주지 않으며, 원하는 서비스를 제공받지 못할 경우 미련 없이 떠나버린다. 단순히 인프라만 갖췄다고 서비스가 제공되지는 않는다. 애플리케이션이 개발되고 동작해야 서비스 제공이 가능하다. 이에 클라우드에서 신속한 서비스 개발과 배포를 지원하는 서비스형 플랫폼(PaaS: Platform-as-a-Service)의 역할이 점차 중요해지고 있다. <편집자>

기술의 발전은 고객이 원하는 경험을 바꿔놓았다. 좀 더 빠르고 안정적인 서비스를 기대하게 됐으며, 이는 기업들로 하여금 비즈니스 방식을 바꾸도록 만들고 있다. 그러나 기업이 기존 체제에 최적화돼 있는 IT를 바꾸는 것이 쉽지 않다. 그렇다고 처음부터 모든 IT를 재설계할 수 있는 것도 아니다.

클라우드는 이런 기업들에게 디지털 트랜스포메이션을 위한 좋은 대안이다. 일부 부서 또는 일부 서비스 영역에만 도입할 수 있으며, 직접 인프라를 보유하지 않고 필요에 따라 사용한 만큼만 비용을 지불하면 되기 때문에 총소유비용(TCO) 절감 효과도 얻을 수 있다.

그러나 클라우드의 진정한 강점은 민첩성과 유연성에 있다. 레거시 데이터센터는 사업에 따라 또는 트렌드에 따라 신속한 체제 전환이 어렵지만, 클라우드에서는 원하는 IT자원을 원하는 시간에 손쉽게 이용할 수 있기 때문이다. 뿐만 아니라 개발한 애플리케이션을 쉽고 빠르게 배포해줄 수 있도록 지원한다.

애플리케이션 중심 개발환경 마련

고객이 원하는 서비스를 적기에 제공하는 것이 기업들의 최우선 목표가 되면서 기업 비즈니스 역시 서비스 중심으로 변하고 있다. 기업이 개발하고 배포하는 애플리케이션이 곧 서비스이며, 인프라만 갖췄다고 해서 서비스가 제공되는 것은 아니다. 애플리케이션이 동작하면서 서비스를 제공할 수 있는 플랫폼이 필요하다.

조립PC를 구매했다고 바로 온라인 게임을 할 수는 없는 것과 마찬가지다. 운영체제(OS)를 설치하고, 온라인 게임 프로그램을 설치해야 비로소 온라인 게임을 즐길 수 있다. 그렇기에 클라우드 도입 초기에는 클라우드 환경을 구성하기 위한 인프라 영역(IaaS)이 강조됐지만, 이제는 클라우드에서 애플리케이션이 동작할 수 있도록 해주는 플랫폼 영역(PaaS)이 강조되고 있다.

IaaS가 인프라를 쉽고 빠르게 생성하는데 초점이 맞춰져 있다면, PaaS는 실제 서비스를 올려야 하는 미들웨어나 데이터베이스 등을 서비스 형태로 제공함으로써 기업들이 애플리케이션에만 집중할 수 있도록 하는 환경을 제공한다. 특히 도커(Docker)와 같은 컨테이너 기술을 이용할 수 있게 되면서 PaaS의 영향력은 더욱 커지고 있다.

컨테이너 기술은 애플리케이션 실행에 필요한 파일과 라이브러리를 패키지화하는 것으로, 필요할 때마다 이를 실행시켜 동일한 환경을 이용할 수 있도록 구성해준다. 하드웨어 기반의 가상화가 가상머신(VM)을 이용해 게스트(Guest) OS를 설치하고 구동해야 했던 것과 달리 컨테이너는 호스트(Host) OS를 그대로 이용하면서 애플리케이션과 라이브러리만 가상화하기 때문에 VM 대비 가벼운 것이 특징이다.

이로 인해 하이퍼바이저나 게스트 OS로 인한 오버헤드(Overhead)가 없으며, 컨테이너가 구동되면 그 안에 담긴 애플리케이션이 바로 시작되기 때문에 빠른 서비스 제공이 가능하다. 또한 인스턴스 증가 시 추가적인 설정을 필요로 하지 않는다는 것도 강점이다.

도커 이전에도 다양한 컨테이너 기술들이 존재했지만, 컨테이너를 생성하고 관리하는 방식이 어려웠다. 그러나 도커는 그 방법이 매우 단순했으며, 오픈소스 프로젝트로 진행됐기에 많은 참가자들의 도움으로 빠르게 안정됨으로써 사실상 컨테이너 기술의 표준으로 자리 잡고 있다.

자동화 통한 속도 향상

도커와 같은 컨테이너 기술은 필요한 애플리케이션과 라이브러리를 컨테이너에 담아 쉽게 이동시키고 어디서든지 간단하게 실행할 수 있는 도구와 환경을 제공했다. 그러나 기업에서 단순히 하나의 컨테이너만 활용하는 것은 아니며, 엔터프라이즈급의 규모일 경우 여러 대의 호스트에서 수많은 컨테이너들이 이용된다. 엔드 유저에게 서비스가 이뤄지려면 이들이 서로 호출되고 엮이는 과정이 필요하지만, 수가 많으면 많을수록 사람이 이를 관리하는 것은 불가능해진다.

예를 들어 여러 호스트에 올라가 있는 컨테이너들이 서비스를 원활히 제공하려면 사용자 리퀘스트가 잘 전달될 수 있도록 로드밸런싱 하는 과정이 필요하다. 관리할 호스트와 컨테이너 수가 적을 때는 문제되지 않겠지만, 많을 경우에는 관리자가 일일이 대응해주기 어렵다.

이 같은 문제를 해결하기 위해 등장한 것이 쿠버네티스(Kubernetes)다. 쿠버네티스는 구글이 도커 컨테이너를 관리하기 위해 개발했으며, 오픈소스 프로젝트를 통해 공개했다. 쿠버네티스는 멀티 호스트 상의 멀티 컨테이너를 조직화하고 연결하기 위한 스케줄링, 셀프 힐링, 오토 스케일링, 서비스 디스커버리, 로드밸런싱 등의 역할을 자동으로 처리해줌으로써 빠른 애플리케이션 서비스가 이뤄질 수 있도록 돕는다.

현재 쿠버네티스는 컨테이너 오케스트레이션을 위한 사실상의 표준으로 자리 잡았으며, 구글과 경쟁관계에 있는 곳을 포함해 많은 클라우드 서비스에서 쿠버네티스를 지원하고 있다.

마이크로서비스 아키텍처, 애플리케이션 개발 방향 제시

클라우드 시대의 성공적인 디지털 비즈니스는 현대적인 애플리케이션을 기반으로 한다. 이들의 민첩성과 확장성은 경쟁 우위와 긍정적 고객 경험으로 이어진다. 이처럼 클라우드 환경에서 구동되도록 설계된 ‘클라우드 네이티브’ 애플리케이션은 과거 레거시 인프라에서 구동되던 ‘모놀리식(Monolithic)’ 애플리케이션과 차이가 있다.

모놀리식은 애플리케이션은 일체형 구조다. 각 기능들은 하나의 애플리케이션에 고정돼 있기 때문에 상대적으로 무겁다. 특정 기능에 장애가 발생했을 경우에도 애플리케이션 서비스 전체를 중단하고 수정하거나 업데이트가 이뤄져야 한다.

반면 클라우드 네이티브 애플리케이션은 독립된 기능들이 유기적으로 느슨하게 결합된 구조다. 각 기능들이 블록처럼 모듈화돼 있어 자유로운 결합과 분리가 가능하며, 기능들의 결합만으로도 새로운 애플리케이션을 만들어낼 수 있다. 또한 문제가 발생했을 경우에도 전체 서비스를 유지하면서도 해당 기능만 수정하거나 교체가 가능하다.

클라우드 네이티브 애플리케이션 개발에는 마이크로서비스 아키텍처가 사용된다. 애플리케이션을 기능별로 잘게 나눠 개발하는 방식으로, 개발된 서비스들은 독립적으로 배포되고 운영될 수 있다. 컨테이너처럼 가벼운 구조에서 이용하기에 좋으며, 소프트웨어의 개발과 배포가 수시로 일어나는 환경에 적합하다. 점차 개별 서비스의 기능이 부각될수록 마이크로서비스 아키텍처 기반의 개발 방식이 점차 확대될 것으로 보인다.

서버리스 컴퓨팅, PaaS 역할 극대화

기업들이 애플리케이션에만 집중할 수 있도록 해주는 역할을 위한 서버리스 컴퓨팅도 점차 늘어날 전망이다. 서버리스 컴퓨팅을 풀이하면 말 그대로 서버가 없는 컴퓨터 환경을 의미하지만, 실제로 그렇다는 것은 아니다. 애플리케이션을 구동해 서비스를 제공하기 위해 필요한 환경에 대해 생각할 필요가 없다는 것을 의미한다.

애플리케이션 실행을 위해서는 필요한 컴퓨팅 환경이 있다. 코어, 메모리 등 인프라 자원이 할당돼야 하며, 이를 구동하기 위한 미들웨어 등의 소프트웨어도 필요하다. 애플리케이션이 실행되려면 서비스 제공 전에 이들을 준비해놔야 한다.

서버리스 컴퓨팅은 개발자가 이러한 과정을 미리 준비하지 않아도 되도록 한 환경으로, 애플리케이션 실행에 필요한 컴퓨팅 자원을 스스로 할당하고 처리함으로써 운영 자원의 효율성을 높인다. 이를 사전에 정의해둘 경우 플랫폼은 정해진 시간에 이를 실행한다. 이 역시 클라우드 플랫폼이 제공하는 자동화 기능이며, 함수적으로 구현되기에 함수 서비스(Function-as-a-Service)로 불리기도 한다.

서버리스 컴퓨팅은 지난 2014년 아마존웹서비스(AWS)가 람다(Lambda) 서비스를 출시한 이후 마이크로소프트(MS)에서도 서비리스 컴퓨팅 서비스가 등장하는 등 점차 시장이 확대되고 있는 추세다. 아직은 초기 단계에 불과하지만, 오픈소스 프로젝트인 ‘오픈위스크(OpenWhisk)’를 비롯해 서버리스 컴퓨팅에 대한 연구가 활발히 진행되고 있다.