4차 산업혁명 시대로 접어들면서 기업 비즈니스가 애플리케이션 위주로 재편되고 있는 상황이다. 그 영향력이 어느 정도냐 하면 핀테크 스타트업이 제공하는 모바일 송금 서비스로 인해 시중은행들이 혁신을 외치며 이를 따라가고 있을 정도다. 이제 점점 더 많은 기업들은 누구보다 더 빠르게 애플리케이션 서비스를 내놓으려 하고 있으며, 이를 뒷받침할 수 있는 인프라로 클라우드가 각광 받는 시대가 됐다.

그동안 기업이 새로운 서비스를 제공하려면 서버를 구입해 운영체제(OS)와 미들웨어 등을 설치하고 서비스 영역을 프로비저닝하는 과정을 거쳐야 했으며, 이는 족히 개월 단위로 이뤄졌다. 이러한 체제에서는 신속한 애플리케이션 개발과 배포는 사실상 꿈만 같은 이야기였다.

그러나 클라우드는 이처럼 복잡한 IT 인프라 활용 방안에 혁신을 가져왔다. 이제 개발자는 물리 서버 배송돼 서비스 영역을 할당받기까지 기다릴 필요가 없어졌으며, 심지어 서비스가 올라갈 서버를 구성할 필요조차 없는 지경에 이르렀다. 이는 마치 별도의 서버가 없는 것처럼 느껴져 ‘서버리스(Serverless)’로 불린다.

하지만 중요한 것은 용어를 떠나 서버리스와 같은 개발 환경의 등장으로 인해 개발자들은 본연의 업무에만 더욱 충실할 수 있으며, 더 빠른 개발과 배포가 가능해졌다는 점이다.

IT 인프라 관리 효율화
서버리스 컴퓨팅은 현존하는 개발 인프라의 최종 단계로 여겨진다. 그만큼 최신 기술이며, 아직까지 이에 대해 잘 모르는 이들도 많은 편이다. 그렇다고 해서 어느 날 갑자기 하늘에서 뚝하고 떨어진 개념은 아니며, 예로부터 지금까지 이어지고 있는 IT 인프라 혁신의 연장선상에 존재한다.

서버리스 컴퓨팅은 클라우드 서비스 사업자가 컴퓨터 자원 할당을 동적으로 관리하는 소프트웨어 아키텍처 모델의 한 종류다. 개발자가 서비스를 배포하기 위해 서버 자원을 고려할 필요가 없기 때문에 ‘서버리스’라 불릴 뿐이지, 실제 서버가 없다는 것을 의미하지는 않는다.

다시 말해 서비스를 배포하고자 의존해야 할 서버가 없으며, 필요에 따라 서버 풀(Pool) 어디에서든 구동하기에 유리한 쪽으로 호출하고 필요한 만큼 사용한 이후 다시 종료(Shut-down)시키는 구조다. 일부에서는 기능이 호출할 때만 동작한다 해서 펑션 서비스(FaaS: Function-as-a-Service)라 일컫기도 한다.

인프라 서비스(IaaS)나 플랫폼 서비스(PaaS) 등 흔히 알려진 클라우드 서비스를 이용할 때는 할당된 컴퓨팅 자원을 이용 기간 동안 계속 점유하게 되는 구조다. 이용자가 할당된 컴퓨팅 자원을 사용하든 사용하지 않든 해당 자원은 지속적으로 구동되고 있는 상태가 유지되며, 그 기간 동안 이용자는 비용을 지불하게 된다.

반면 서버리스는 컴퓨팅 자원을 할당하지 않고 있다가 사용 요청(Request)이 들어오면 해당 이벤트를 처리할 서비스가 실시간으로 구동되는 형태다. 상시 점유하는 컴퓨팅 자원이 없기 때문에 서비스 공급자도 자원 풀을 좀 더 효율적으로 이용 가능하고, 서비스 이용자 역시 필요한 만큼 이용하고, 그 시간 동안만 과금되기 때문에 비용 효율적으로 클라우드 이용이 가능하다.

컨테이너 관리 필요성 증대
서버리스 컴퓨팅을 논하며 마이크로서비스 아키텍처(MSA: Microservice Architecture)를 빼놓을 수는 없다. 어느 덧 현대적인 클라우드 네이티브 애플리케이션 개발에 필요한 요소로 자리 잡은 MSA야 말로 펑션 서비스인 서버리스 컴퓨팅을 활용하기에 최적의 조건을 갖추고 있다.

컨테이너(Container) 기술과 데브옵스(DevOps) 개념의 등장으로 MSA가 점차 보편화되고 있는 추세지만, 아직도 많은 기업 애플리케이션이 전통적인 모놀리식 형태로 남아있는 실정이다. 이들을 한꺼번에 클라우드 네이티브 애플리케이션으로 바꾸기는 어렵지만, API를 활용해 MSA와 같은 효과를 내는 경우는 늘어나고 있다.

이처럼 기능(함수) 레벨의 애플리케이션화가 진행되면서 과거 미들웨어와 데이터베이스(DB)가 통신하던 것처럼 상호 통신의 필요성도 증대하고 있으며, 이러한 기능들을 구동시키는 컨테이너들을 관리하는 개념도 함께 중요시되고 있다.

최근 클라우드 분야에서 쿠버네티스(Kubernetes)가 화두로 떠오른 이유 역시 컨테이너 관리 자동화를 지원하기 때문이다. 구글이 자사 클라우드 컨테이너 관리를 위해 개발했던 쿠버네티스는 이제 AWS, MS 애저(Azure), IBM 등 퍼블릭 클라우드 서비스 외에도 VM웨어, 피보탈, 레드햇 등 다양한 클라우드 기업들이 지원을 선언하면서 사실상 컨테이너 관리를 위한 표준으로 자리 잡았다.

특히 클라우드 서비스가 멀티·하이브리드 클라우드 형태로 확대되면서 다른 클라우드 환경으로 옮겨가더라도 쿠버네티스를 활용하면 클라우드 종류에 관계없이 통일화된 컨테이너 관리가 가능해짐에 따라 앞으로도 쿠버네티스는 그 영향력이 더욱 확대될 것으로 전망된다.

이용자 개입 없이 스토리지 관리
서버리스의 특성이 좀 더 빠른 개발과 서비스, 그리고 비용 효율적인 클라우드 서비스 이용에 있는 만큼, 이를 극대화하려면 사람의 개입 없는 완전 자동화 환경을 필요로 한다. 이제 컨테이터 오케스트레이션을 위해 쿠버네티스가 활용되면서 서버단 이외에 스토리지단에서의 자동화를 이뤄내는 역할을 하고 있다.

그동안 스토리지단에서는 할당받은 볼륨이 필요 없어졌을 때 해제하는 과정이 수작업으로 이뤄져야 했기에 상당히 복잡했다. 그러나 컨테이너 기술이 등장한 이후 컨테이너가 볼륨을 필요로 할 때 바로 할당받고, 또 지울 수 있는 기법들이 제공되기 시작했다.

초 단위로 서비스가 생성 및 소멸되는 서버리스 컴퓨팅과 컨테이너 환경에서는 수십에서 많게는 1만 개 이상에 이르는 동적 볼륨 생성 및 삭제를 지원할 수 있도록 동적 볼륨 할당을 지원하는 스토리지 환경이 필요하다. 컨테이너 기반 애플리케이션은 CPU 및 메모리 이외에도 로그 기록 및 데이터를 필요로 하기 때문에, 기존에는 특정 서버에 물리적으로 스토리지 공간을 미리 할당하는 정적(static) 방식을 사용했다. 이러한 방법은 서버의 자원이 대부분 상시 가동될 때는 큰 문제가 되지 않으나, 서비스가 초 단위로 변화하는 컨테이너 환경에는 적합하지 않기 때문에 동적 볼륨 할당이 요구된다.

컨테이너가 웹 서버 또는 임시 저장 데이터를 필요로 하는 스테이트리스(stateless) 워크로드에서 DB 서버와 같은 스테이트풀(Stateful) 워크로드까지 확장되면서, 서비스의 지속성을 보장하는 영구 볼륨(Persistent Volume)의 중요성이 높아지고 있다. 영구 볼륨은 컨테이너의 종료 후에도 컨테이너의 최신 상태 정보 및 DB를 보존해 컨테이너 재가동 시 이러한 데이터를 다시 사용할 수 있도록 한다.

기존의 영구 볼륨은 네트워크 기반의 파일 시스템상에 보관됐으나, 이러한 방식은 고성능 IO를 요구하는 DB 서버 등의 워크로드에는 적합하지 않다. 대신 FC/iSCSI 기반의 고성능 외장 스토리지 볼륨을 동적으로 할당함으로써 컨테이너 구동을 지원해 고성능 워크로드 요구사항을 충족시킬 수 있다.

스토리지 업계에서는 쿠버네티스 플러그인을 제공함으로써 스토리지 데이터 풀을 쿠버네티스에서 직접 다룰 수 있도록 돕는다. 이전까지는 스토리지 관리자가 볼륨을 생성하고 할당해줘야 이용이 가능했지만, 플러그인을 통해 쿠버네티스 관리자가 직접 볼륨을 할당받고 컨테이너를 기동시킬 수 있게 됐다.

아울러 백업도 스토리지 관리자 없이 컨테이너 관리자 레벨에서 가능하도록 지원한다. 특수한 경우 볼륨을 할당받은 이후 스냅샷을 찍어 백업하는 것까지 프로그램화해서 애플리케이션단에서 관리하는 것도 가능하다.

컨테이너화의 또 다른 장점으로는 다른 노드로 손쉽게 페일오버(Failover)도 가능하다는 것이다. 이전에는 미리 동일한 환경을 구성해야 할 필요가 있었지만, 쿠버네티스 클러스터 환경에서는 컨테이너 이미지 배포를 중앙해서 제어하기 때문에 이동이 한층 쉬워졌기 때문이다.

이러한 특성으로 인해 기존 IT 환경을 베어메탈이 아닌 컨테이너로 마이그레이션하려는 검토와 시도들이 이어지고 있다. 가장 큰 장점은 OS 호환성을 신경쓰지 않고 운영이 가능하다는 점이며, 많은 클라우드 사업자들이 쿠버네티스를 지원하는 만큼 호환성도 좋아 이용이 편리하다.

“서버리스, 자원 효율·비용 과금면에서 유리” 서버리스는 자원 효율성과 비용 과금 측면에서 굉장히 뛰어난 방식이다. 가령 웹 애플리케이션 서버(WAS) 활용사례를 보면 WAS는 필요한 메모리 자원을 1GB든 2GB든 띄워놓으며, 이는 그만큼 클라우드 서비스 기저에 있는 실제 메모리를 잠식하게 된다. 이럴 경우 실제 CPU 사용은 일어나지 않더라도 메모리를 잠식하며 메모리 부족 현상도 발생할 수 있기 때문에 추가적으로 인프라를 구입하고 풀(Pool)을 늘려야 한다. 그러나 서버리스는 서비스 호출이 들어올 때만 동작하고 끝나면 종료되는 형태인 만큼 클라우드 서비스 공급자 입장에서는 자원 풀을 구성해 놓고 필요한 순간마다 효율적으로 활용할 수 있으며, 이용자 입장에서도 본인이 이용한 시간만큼 초나 분 단위로 과금되기 때문에 훨씬 경제적인 활용이 가능하다. 이제 기업에서도 인프라를 풀 형태로 구성하고 필요한 시점에 띄워 쓰는, 가벼우면서도 빠르게 동작하는 형태를 선호하기 때문에 MSA와 서버리스 아키텍처를 활용하고 있는 기업들이 늘어나고 있는 추세다.