본문 바로가기

TECH ZOOM

서버리스 컴퓨팅, 컨테이너 그리고 스토리지



위키피디아에 따르면 “서버리스 컴퓨팅(Serverless Computing)은 클라우드 컴퓨팅 실행 모델의 하나로, 클라우드 제공자가 동적으로 자원을 할당하고 관리하며, 가격은 미리 구매한 용적 단위가 아닌 애플리케이션이 실제로 소비한 자원 양을 기준으로 책정한다”고 한다.

서버리스 컴퓨팅이라고 하지만 여전히 물리적인 서버를 필요로 한다. 다만, 용량 증설 및 구동할 서버 위치 등 서버 관리에 관한 모든 내용이 개발자 혹은 운영자에게 철저히 가려져 있어서 애플리케이션 기능에 대해서만 신경 쓰면 되는 클라우드 서비스의 일종이다.

서버리스 컴퓨팅의 대표적인 사례는 2014년에 소개된 아마존 AWS Lambda 서비스를 들 수 있다. 사용자는 서버 관리에 대해 신경 쓸 필요 없이 애플리케이션 코드( C#, java, Node.js, Python등)를 업로드해 실행시키면, 각 애플리케이션이 실행한 실제 시간에 대해 100ms 단위로 쪼개 과금하기 때문에 기존의 월 단위 과금 대비 비용을 최적화할 수 있다.


서버리스 컴퓨팅의 핵심 기술, 컨테이너

서버리스 컴퓨팅은 애플리케이션을 제외한 모든 요소를 클라우드 제공자가 서비스 형태로 제공하는데 ‘Function-as-a-Service’ 라고 표현하기도 한다. (그림 1)에서 보는 바와 같이 애플리케이션을 제외하고 물리적 인프라, 가상 머신, 컨테이너 그리고 통합적으로 관리하는 영역을 클라우드 제공자가 서비스하며, 사용자는 애플리케이션만 관리한다.


(그림1) IaaS(서비스형 인프라) vs. 서버리스 컴퓨팅 서비스 영역 비교



이 중 컨테이너는 가상머신에 비해 훨씬 가벼운 가상화 기술로, 애플리케이션 실행을 위한 모든 연관 요소(관련 라이브러리, 구성 파일 등)를 하나의 패키지로 구성해 구동하는 기술이다. 예를 들어 다른 버전의 OS 혹은 서버로 이동할 경우, 호환에 중요한 라이브러리가 같이 구성되어 있기 때문에 코드를 변경하지 않고도 다른 컴퓨팅 환경으로 손쉽게 이동할 수 있다.

가상머신에 비해 용량이 적기 때문에 개발자는 컨테이너를 생성하고 배포하는 시간을 단축시킬 수 있으며, 재기동 또한 빠르다. 이 때문에 사용하지 않을 때에는 컨테이너 인스턴스를 Power-off 하여 서버 사용을 최적화할 수 있다. 서버리스 컴퓨팅은 일반적으로 이런 컨테이너 기술을 기반으로 한다.


스토리지 볼륨의 동적 할당 필요한 컨테이너 기술

그렇다면 서버리스 컴퓨팅과 컨테이너 환경 그리고 스토리지는 무슨 관계가 있을까. 컨테이너는 초 단위의 서비스 생성과 소멸 과정을 겪는 서버리스 컴퓨팅의 핵심 기술이다. 컨테이너로 번들된 애플리케이션은 CPU와 메모리만 사용하는 것이 아니다. 때로는 로그 기록과 데이터를 저장할 수 있는 물리적 저장소를 필요로 한다. 기존의 전통적인 방식에서는 이런 공간을 사전에 정의해 놓기 때문에, 어느 특정 서버에 물리적으로 스토리지 공간을 미리 할당하는 정적인(Static) 방식을 사용한다. 이는 서버의 자원이 대부분 24x365 유지되기 때문에 큰 문제가 되지 않기도 했다.

그러나 서비스(혹은 컨테이너)의 생성과 소멸이 초 단위로 이뤄지는 컨테이너 환경에서는 컨테이너가 사용하는 볼륨의 개수가 적게는 수십에서 많게는 만 개 이상 실시간으로 생성될 수 있다. 이런 볼륨 생성 및 삭제 작업이 동적으로 일어나기 때문에 기존의 정적인 볼륨 할당 작업은 적합하지 않다. 따라서 동적으로 볼륨을 할당할 수 있는 스토리지 환경이 필요하다.

또 한 가지는 Persistent Volume 이슈이다. 지금까지 컨테이너는 주로 웹서버와 임시 보관성 데이터를 저장하는 스테이트리스(Stateless; 상태 정보를 보관하지 않는) 워크로드에서 운영되었기 때문에 컨테이너를 삭제할 때 기존 데이터를 유지하지 않아도 되었다. 하지만 최근 컨테이너 적용 영역이 DB 서버와 같은 스테이풀(Stateful)한 워크로드로까지 확장되면서, 컨테이너가 Power-Off 상태에서도 최신 상태 정보와 DB를 그대로 보존하고 있다가 필요할 때 재가동해 서비스를 지속해주는 Persistent Volume 지원이 필요해졌다. 초기에 Persistent Volume은 네트워크 상에 공유 파일시스템에 파일 형태로 보관되었으나, 이러한 방식은 고성능의 I/O를 요구하는 DB 서버 등에는 적합하지 않다. 따라서 FC/iSCSI 기반의 고성능 외장 스토리지 볼륨 (LUN 혹은 LDEV)을 동적으로 할당하는 방식을 사용하게 된다.


최적의 컨테이너 환경을 지원하는 HSPC

히타치 밴타라의 HSPC(Hitachi Storage Plug-in for Containers)는 쿠버네티스, 도커 스웜(Docker Swarm)과 같은 컨테이너 오케스트레이션 도구와 연동해 Persistent Volume의 동적 생성을 지원한다. HSPC를 설치하고 간단한 환경 설정만 완료하면, 컨테이너 오케스트레이션 도구 상에서 스토리지 볼륨을 동적으로 자동화해 관리할 수 있다.

HSPC와 2018년 상반기 출시한 차세대 하이브리드 클라우드 스토리지 VSP G시리즈와 올플래시 클라우드 스토리지 VSP F 시리즈를 통해, 컨테이너용 볼륨을 동적으로 최소 1만 6,000개에서 최대 6만 4,000개까지 생성할 수 있어서 서버리스 컴퓨팅의 기반이 되는 컨테이너의 확장성을 보장한다.

또한, 성능 모니터링, 원격 장애 처리 지원 등 검증된 고급 스토리지 관리 기능을 그대로 사용할 수 있기 때문에 컨테이너로 인프라 환경 전환 시 100% 데이터 가용 서비스를 제공할 수 있으며, 이는 업계 유일한 방법이다. 이를 통해 고객은 클라우드 환경으로 전환 시 리스크를 최소화하고 목표하는 클라우드/서버리스 컴퓨팅 환경을 구현하는 일에 집중할 수 있게 된다.