Cloud Functions, 이래서 베타다

지난번 글( 서버리스 Cloud Functions 사용하기 ) 에서 Cloud Functions 의 전반적인 내용에 대해서 훑어보았다. 작은 모듈 단위의 프로그램을 서버 구동 없이( 엄밀하게는 사용자가 신경 쓸 필요 없는 / 신경 쓸 수 없는 ) 사용할 수 있는 서버리스의 장점에 대해서 이야기를 했었는데 이번에는 그 한계에 대해 잠시 살펴보고 비판해보도록 하자. 이렇게 비판하는 정보를 공유하는 이유는 한계를 모르는 상태로 Serverless 서비스를 운영하는 것은 매우 위험하다고 생각하고 있기 때문이다.

Google Cloud Functions 은 Serverless 의 역할을 충실히 수행하며 작은 모듈 단위를 클라우드 위에서 동작 시키는데, 타사의 FaaS 대비해서 무엇이 좀 많이 부족하다. 그렇기 때문에 아직 베타인걸까?

Node 만 지원

Google Cloud Platform 위에 많은 서비스들이 이미 노드 친화적이긴 하다지만 Cloud Functions 은 특히 그렇다. 노드밖에 지원하지 않는다. 아래는 AWS Lambda 에서 지원하는 풍성한 Runtime 들이다. (부럽)

반면 Cloud Functions 은 Runtime 선택은 커녕 노드 버전도 변경할 수 없다. 내부 구현이 어떻게 되어 있길래 그런지는 조금 더 살펴봐야겠지만 우선 이게 가장 큰 베타 딱지의 이유일 수 있겠다.

인라인 편집의 한계

소스코드를 Cloud Functions 에서 사용할 수 있는 방식은 아래 네 종류가 있다. 꽤 다양한 방식을 지원한다고 칭찬할 수 있겠다. 하지만 다음 단계에서 문제가 발생한다.

인라인 편집기를 사용해서 코드를 작성할 때는 소스 코드를 디렉터리 단위로 나눌 수가 없다. 애초에 그런 기능은 지원하지 않으며 우리가 화면에서 볼 수 있는 파일은 오직 index.js 와 같은 디렉터리(레벨)에 있는 파일들 뿐이다. 또한 이 화면에서 새로운 파일 생성은 불가능 하다. 아래 그림은 기본으로 생성되는 모듈인데 참고해보도록 하자. 

혹시 ZIP 업로드를 하면 여러개의 파일을 다룰 수 있지 않을까? 맞다. 여러 개의 파일로 소스코드를 관리하고 싶다면 ZIP 업로드를 이용하면 된다. 하지만 node 의 특성상 외부 모듈을 사용하기 위해서는 npm 으로 node_modules 를 설치해서 사용해야 하는데 이 경우에 문제가 또 발생한다. 바로 소스코드 상에 디렉터리가 포함되는 경우에는 인라인 편집이 더이상 제공되지 않는다는 치명적인 단점이 존재한다. 가능한건 오직 코드 미리보기 뿐. 코드를 편집하려고 할 때 아래처럼 인라인 편집기가 선택할 수 없도록 비활성화 된다.

AWS Lambda 의 경우에는 일정 크기 이상의 사이즈를 ZIP 으로 올렸을 경우에만 인라인 편집이 비활성화 되는데 그 한계가 대략 3 ~ 5 MB 정도 된다. 그 이하는 계속 인라인으로 편집할 수 있으며 파일 단위로 소스코드가 나뉘어져 있어도 콘솔에서 모두 편집이 가능하다. 이런 부분을 보면 Cloud Functions 의 부족함이 여실없이 드러난다.

번외로 여러개의 파일을 ZIP 으로 업로드 했을 때의 화면은 아래와 같다...

ZIP 으로 올릴 때 버킷을 경유한다

그냥 압축된 소스를 올리면 끝이길 기대하지만 버킷을 필수로 지정해서 내부적으로 경유할 수 있도록 해야 한다. 즉, 내가 올린 ZIP 소스가 바로 어떤 컨테이너 등으로 업로드 되는 것이 아니라 버킷에 먼저 올라가고, 버킷에 있는 내용을 내려받아 사용하게 되는 개념이 되겠다.

사실 이렇게 된 배경은 Cloud Storage의 ZIP 기능에서 언제든 올려놓은 ZIP 파일을 재사용 할 수 있도록 하기 위해서다. 하지만 사용자의 편의를 위해서라면 ZIP 업로드는 업로드만 할 수 있도록 두고, Storage 에 업로드 하는 메뉴는 별도로 제공을 하는 편이 낫지 않았을까?

성능 한계

어디에도 나와있지 않은 성능의 한계이다. 아래는 기본 조건(256MB)으로 생성한 Cloud Functions 를 동시에 50개 호출한 결과이다. 여기서 real 부분을 보면 응답 시간을 확인할 수 있는데, 이 수치는 평소 단일 콜에 대해서 1s 미만이던 부분이다. 하지만 아래서 알 수 있듯이 수초가량 걸리는 세션이 다수 보인다.

이게 무엇을 의미하냐하면 Serverless 라고는 하지만 실제 우리가 생성한 Cloud Functions 에 할당된 컨테이너가 존재하며 그 컨테이너가 수용할 수 있는 스펙의 한계가 존재한다는 것이다. 이 문제는 단순하게 메모리를 늘린다고 해결되는 부분이 아니라 어쩌면 Function 자체를 나누는게 나을지도 모른다 (내부적으로 별도의 Serverless 컨테이너를 운영할 수 있게 된다). 아니, 어쩌면 그정도 트래픽이나 스펙이 필요한 경우에는 인스턴스 등을 따로 운영하는게 답일지도. 아무튼 이 문제는 모든 클라우드 제공업체의 FaaS 가 안고 있는 문제지만 어디에서도 언급은 안된다. 필요한 트래픽 처리량이나 스펙에 따라 유연하게 Cloud Functions 을 운영하는 전략이 필요하겠다.

마무리

애초에 Cloud Functions 의 용도는 매우 작은 서비스를 처리하는 것이기 때문에 위에 내용들을 지원하지 않는지도 모른다. 또한 여러가지 방법을 이용해서 문제를 회피할 수도 있지만 굳이 사용자가 그런 수고를 겪어야 하는지 의문( Runtime 에 노드가 아닌 다른 언어 사용 등 ). 아무튼 베타 딱지를 떼고 더 나은 서비스로 거듭나기 위해서는 여러가지 개선되어야 할 부분이 많다. 

우선 현재의 한계와 불편함을 인지하고 필요에 따라 Cloud Functions 를 적절하게 운영하는 것이 현명한 사용자 되시겠다.