서버리스 컴퓨팅 표준 될까?··· ‘K네이티브’의 가치와 과제

InfoWorld
어떤 하나의 ‘관행’이 널리 전파되고, 수 많은 이질적인 방법들로 이를 다루는 경우가 많을 때 표준이 필요해진다. 오늘날 서버리스 컴퓨팅 시장에 적용되는 상황이다. 

PaaS(platform-as-a-service (PaaS)) 맥락에서 보면, 서버리스 컴퓨팅은 이벤트에 기반하고, 변동성이 존재하는 워크로드에 잘 맞는다. 온디맨드 방식이고, 축소 및 확장이 가능하며 효율적이고, 사용한만큼 돈을 내기 때문이다. 

개발자는 인프라를 구성할 필요 없어, 더 빨리 기능을 배포할 수 있다. 자동으로 크기가 조정되는 기능을 시작시키는 트리거를 정의할 수도 있다. 또 작업이 완료될 때 기능이 자동 종료되도록 만들 수 있다.

서버리스 컴퓨팅 모멘텀
최근 클라우드 네이티브 컴퓨팅 부문에서 서버리스 컴퓨팅과 관련한 큰 모멘텀이 형성되어 있다. 라이트스케일(RightScale)의 ‘2018년 클라우드 현황(State of the Cloud)’ 보고서에 설명되어 있듯, 이벤트가 동인이 되는 스테이트리스(stateless) 클라우드 애플리케이션이 마이크로서비스 모델을 급성장시키고 있다. 약 연간 75%의 증가 비율로 엔터프라이즈 도입이 늘어나는 중이다. 

그리고 가벼운 클라우드 기능을 대상으로 하는 서버리스 컴퓨팅의 장점과 이점은 수 많은 커머셜(상용), 오픈소스 서버리스 플랫폼을 등장시키고 있다.

많은 서버리스 환경이 퍼블릭 클라우드에서 네이티브(기본)로 지원되고 있다. AWS 람다, 애저 펑션(Azure Functions), 구글 펑션(Google Functions), IBM 클라우드 펑션(IBM Cloud Functions), 오라클 펑션(Oracle Functions)을 비롯해 서비스로서의 펑션(Function-as-a-Service) 상품에서의 증가에서 확인할 수 있듯, 서버리스 컴퓨팅은 이미 퍼블릭 클라우드 서비스에 크게 ‘통합’된 상태이다.

여기에 그치지 않는다. 프라이빗 클라우드 시장으로도 깊이 진입하기 시작했다. 지난 몇 년간, 온프레미스와 하이브리드 클라우드, 멀티클라우드 배포를 대상으로 한 다양한 대안적인 서버리스 플랫폼이 많이 등장했다. OpenWhisk, Fission, Gestalt, IronFunctions, Nuclio, Fn Project, Funktion, Fission, Kubeless, Funcatron, OpenFaaS, Webtask.io 등을 예로 들 수 있다.

그런데 이런 서버리스 플랫폼 확산으로 조기 도입자들에게 사일로 및 벤더 종속 문제가 나타났다. 현재 대부분의 서버리스 배포 도구는 AWS 람다 서비스를 중심으로 특정 사일로를 위한 기능 구현을 지원한다. 그렇지만 여러 주요 백엔드에 대한 통합을 지원하고, Node.je와 파이썬, 자바, 고 등 다양한 언어로 기능을 프래그래밍 할 수 있는 추상화 계층을 제공하는 서버리스 IDE가 증가하고 있는 추세이다. 해시코프(HashiCorp)의 테라폼(Terraform), 서버리스닷컴(Serverless.com)의 서버리스 프레임워크(Serverless Framework), 솔로닷아이오(Solo.io)의 글루(Gloo)를 예로 들 수 있다.

엔터프라이즈 애플리케이션 환경에서도 느리지만 확실하게 하이브리드 서버리스 멀티클라우드가 부상하고 있다

그러나 크로스 플랫폼(여러 플랫폼에 적용되는) 서버리스 표준에 대한 전망은 좋게 봐도 ‘흐릿한’ 정도다. 일관된 관행을 수립하고, 공급자와 사용자, 기타 이해당사자로 구성된 커뮤니티의 합의 프로세스로 관리되는 공식적이고, 문서화 되어있고, 개방적인 사양이 진짜 표준이다.

언젠가 서버리스 표준이 될 수 있는 K네이티브(Knative)
일부 업계 전문가들은 오픈소스인 K네이티브 프로젝트가 서버리스 표준화의 토대라고 주장한다. 물론 아직은 설익은 주장일 수 있다. 지난해, CNCF(Cloud Native Computing Foundation)의 후원 아래 공개된 K네이티브 프로젝트는 퍼블릭과 프라이빗, 하이브리드 등 모든 클라우드에 배포해 실행할 수 있는 콘테이너 기반의 서버리스 애플리케이션 구축을 단순화시키는 데 목적을 두고 있다. 

한편 별개의 프로젝트 리프(Project Riff)도 있다. 이는 K네이티브를 개발자 및 운영자 도구로 확장시킨다. 설치를 단순화시키고, 주요한 사용자 경험 요소를 추가할 수 있는 도구이다.

상업적인 추진력을 얻으면, K네이티브는 언젠가 여러 언어를 지원, 단 한 번만 개발하면 어느 장소에서나 실행시킬 수 있는 방식으로 서버리스 기능을 프로그래밍할 수 있게 만들 잠재력을 가진다. 
 
ⓒ Image Credit : Getty Images Bank



그러나 그런 날은 아직 멀었다. CNCF 아래 추진되는 많은 프로젝트들처럼, 진짜 표준화와 광범위한 도입이라는 결실을 맺기까지 해결해야 할 일들이 많다. CNCF는 K네이티브를 후원하기 전에, 이미 CloudEvents 사양을 규정한 전력이 있다. 이는 멀티클라우드 서버리스 애플리케이션 이동성과 재사용을 보장하는 이벤트 트리거 표준 세트이지만 충분한 추진력을 얻지 못했던 바 있다.

현재 버전 0.2인 K네이티브는 구글이 IBM 산하 레드햇 사업 부문, 피보탈, SAP와 협력해 개발했다. 현재 K네이티브에 미흡한 부분 중 하나는 아직까지는 온프레이스, 하이브리드, 멀티클라우드 배포에 맞춰진 다양한 서버리스 환경은 물론이고 AWS 람다 같은 인기 퍼블릭 서버리스 플랫폼의 기능을 흡수하지 못한다는 것이다.

K네이티브를 지원하는 벤더들
그러나 K네이티브의 주요 개발사들은 각자 보유 솔루션 포트폴리오에 K네이티브를 통합한다는 ‘중대’ 발표를 했다.

- 구글은 2018년 7월부로 구글 쿠버네티스 엔진(GKE)에서 서버리스 애드온으로 K네이티브를 지원하기 시작했다. 개발자들은 K네이티브를 활용, 클라우드 공급자 간 마이그레이션이 용이한 콘테이너 기반의 서버리스 애플리케이션을 빌드, 제공, 관리할 수 있다.


- IBM의 경우, 엔터프라이즈 고객들이 IBM 클라우드 쿠버네티스 서비스에 K네이티브를 설치해 활용할 수 있도록 지원한다. 또한 IBM 산하 레드햇 사업 부문은 오픈시프트 쿠버네티스 플랫폼에 K네이티브에 대한 지원을 추가했다. 고객들이 서버리스 애플리케이션을 빌드해 실행하고, Istio와 Kiali 프로젝트에 기반을 둔 이 회사의 오픈시프트 서버 메시(OpenShift Server Mesh)와 통합해 활용하도록 지원하기 위해서이다.

- 피보탈은 최근 쿠버네티스 기반의 멀티클라우드 서버리스 플랫폼인 PFS(Pivotal Function Service)의 알파 버전을 발표했다. K네이티브를 멀티클라우드 패키징한 것이며, 어떤 쿠버네티스 환경에도 설치할 수 있다. 여기에는 안전하게 기능을 패키징하고, 투명한 롤백을 지원하기 위해 기능 인스턴스의 이전 버전을 유지하고, 느슨하게 연결된 환경과 스트리밍 환경, 기타 분산형 환경 전반에 걸쳐 방해 없이 기능 리소스 스케일링 및 성능 최적화를 자동화해 제공하는 ‘빌드 팩(Build Packs)’이 포함되어 있다.

- SAP의 경우 SAP 클라우드 플랫폼에서 K네이티브를 사용할 수 있다. 또 엔터프라이즈 소프트웨어 확장용으로 프로젝트 키마(Project Kyma)의 일부로 지원한다. 이 프로젝트는 어떤 하나의 API 구현 애플리케이션을 연결, 맞춤화, 확장할 수 있는 애자일, 오픈 소스 도구에 대한 개발자의 니즈를 충족시킨다. 또 레가시 엔터프라이즈 소프트웨어와 다양한 공급자의 클라우드 서비스 간 경계를 흐리게 만드는 일관된 서비스 소비 계층을 제공한다. 표준 쿠버네티스 서비스 카탈로그에 K네이티브를 사용하며, 오픈 서비스 브로커 표준을 사용해 확장을 할 수 있다.

이 밖에도 업계에 K네이티브를 지원하는 또 다른 움직임이 있다. 예를 들어, 기트랩과 트리거메시( TriggerMesh)는 최근 기업이 K네이티브를 사용, 기트랩 UI에서 직접 서버리스 기능과 애플리케이션을 배포해 어떤 클라우드, 온프레미스 인프라에서도 서버리스 워크로드를 실행시킬 수 있는 기트랩 서버리스(GitLab Serverless)를 발표했다.

K네이티브 도입을 늦출 수 있는 요인
K네이티브에 많은 ‘후원자’가 있고 시장에 추진력이 일부 형성되어 있기는 하지만, 서버리스 공급자와 개발자, 사용자 사이에 도입되는 속도를 늦출 수 있는 부정적인 트렌드도 일부 존재한다.

- 클라우드 공급자들은 각자 사유 서버리스 플랫폼을 발전시키고 있다. 자신의 퍼블릭 클라우드를 더 많이 사용하도록 만들고 이질적인 (K네이티브와 다른 인터페이스를 매개체로 하는)서버리스에 대한 니즈를 줄이기 위해, 유수 퍼블릭 클라우드 공급업체는 각자 서비스로서의 펑션(Function-as-a-Service) 플랫폼을 발전시키는 투자를 계속할 것이다. 각각 서버리스 프로그래밍 언어를 계속 발전시켜, 이것이 자신의 클라우드 IaaS 및 PaaS 포트폴리오의 서버리스 인터페이스로 탑재시키는 것이다. 

예를 들어, AWS는 최근 서버리스 클라우드에 안전한 멀티테넌트 콘테이너와 AWS 람다 기능을 구현해 관리할 수 있는 가벼운 오픈소스 가상머신 모니터인 파이어크래커(Firecracker)를 발표했다.

- 여러 개발 도구들이 ‘사일로화(단절)’된 서버리스 플랫폼을 연결하는 대안적인 추상화를 제공한다. 백엔드 서버리스 코드는 꽤 끈질기다. 앞으로도 계속 메시징과 데이터베이스 같은 클라우드 특정 서비스에 효율적으로 액세스할 수 있도록 작성이 될 것이다. 이미 Fn Project, Funktion, Fission, Kubeless, Virtual Kubelets, Funcatron, OpenFaaS 같은 몇몇 오픈소스 프로젝트들이 ‘사일로화’된 클러스터 전반에 걸쳐 기능을 효과적으로 사용할 수 있게 도와주는 쿠버네티스, Docker, 기타 콘테이너 스케줄러 기반의 서버리스 추상화를 제공하고 있다. 

이런 추상화는 엔터프라이즈 IT 담당자들이 자신의 엔터프라이즈 멀티클라우드 환경에서 출현하는 이질적인 서버리스 백엔드들에 대해 콘테이너화한 기능을 포팅하는 작업을 줄여준다. 필자는 이런 것들과 다른 API를 사용, 이질적인 백엔드 서버리스 환경에서 실행되는 마이크로서비스를 사용할 수 있게 해주는 추상화를 추가시키는 클라우드 네이티브 개발 도구가 증가할 것으로 예상한다. 이것이 K네이티브 같은 개방형(오픈) 표준의 크로스 서버리스 API에 대한 수요를 대체할 수도 있다.

- 서버리스의 취약점 때문에 현재 표준 프레임워크의 범위를 넘는 추상화가 필요하다. 서버리스 컴퓨팅은 개발자들이 “눈에서 멀어지면 마음에서도 멀어진다’는 마음가짐을 갖게 만드는 경향이 있다. 물리적 보안과 네트워크 보안을 클라우드 서비스 공급자가 책임질 것이라고 생각하게 만든다는 의미이다. 

그러나 최근 조사에서 드러났듯, 이는 위험한 태도이다. 최근 1,000개의 서버리스 애플리케이션을 감사한 결과에 따르면, 심각한 애플리케이션 취약점이 있는 애플리케이션 비율이 20%에 달했다. 잘못된 개발 관행, 서버리스 보안에 대한 교육 미흡, 안전하지 않은 샘플 코드, API 키, 크리덴션을 실제 프로젝트에 사용한 것이 이를 초래하는 주요 원인들이다. 하이브리드 배포가 증가하면서 이러한 취약점도 계속 심각해질 것이다. 

이를 방지하려면 클라우드 네이티브 도구가 서버리스 개발 추상화에 안전한 ‘관행’을 적용시켜야 한다. K네이티브나 다른 업계 표준 멀티클라우드 추상화에 기능 코드에 포함된 취약점을 없앨 강력한 보안 체계가 포함되기 전에는, 서버리 앱 개발자들은 자신이 선호하는 클라우드 네이티브 AIP에 사유 보안 도구를 탑재하는 방법 밖에 없다.

보안 만이 아니다. 하이브리드 서버리스를 시장에서 실현시키기 위해, 멀티클라우드 추상화에 통합시켜야 할 기능들이 다양하다. 크로스 클라우드 기능 병렬 처리, 로드 밸런싱, 이벤트 연결, 데이터 액세스 추상화, 오케스트레이션, 텔레매트리, 성능 추적, 사용량 모니터링, 이상 동작 감지, 로그 분석, 인터랙티브 진단, 인시던트 기반 얼럿, 디버깅 등에 대한 표준 API가 여기에 포함된다.

이런 혼란스러운 상황에서 개발자들에게 필요한 ‘결론’은 무엇일까? 서버리스, 콘테이너화, 가상화, 기타 코드를 가능한 단순하게 효율적으로 빌드 및 배포할 수 있도록 도움을 주는 클라우드 네이티브 도구를 선택해야 한다는 것이다. 사용하는 도구에 기능 코드를 한 번 작성한 후 이를 모든 서버리스 백엔드로 이동시킬 수 있는 표준 API가 포함되어 있는 것이 이상적일 것이다. ciokr@idg.co.kr

* James Kobielus는 실리콘앵글 위키본의 수석 애널리스트다. ciokr@idg.co.kr