서버리스 컴퓨팅 표준 될까?··· ‘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