Serverless Computing는 언제 써야 할까?

서버 개발자라면은 한번쯤은 들어.. 아니 한번쯤은 써봤을 것이다.

 

---

serverless computing

---

 

 

만약 들어본적이 없다면 google cloud functions, aws lamda는 들어봤을 것이다. 대표적인 serverless computing service이다. 오늘 필자는 serverless computing service를 언제 써야만 하는지 장점이 무엇인지 또는 단점은 무엇인지에 대해서 생각을 풀어보고자 한다.

 

 

serverless computing의 장점은 무엇일까?

 

생산성

인프라 없이 사용할수 있다는 아주 큰 장점이 있다. 초기 빠른개발과 코드에만 집중할수 있는 환경인 것이다. 배포 환경도 자동화가 잘되어 있으며, 코드를 쓰고 명령어 몇줄만 치면 자동으로 무중단 배포를 지원한다. 뿐만 아니라, auto scale 기능이 있어 특정 instance에 부하가 걸리면 자동으로 instance를 확장해준다. 만약 우리가 직접 compute을 돌린다고 가정해 보자. 물론 요즘 cloud service에서 많은 자동화 편의성을 제공하고 있지만, 초기 설정 하고 셋팅하는데만 족히 몇시간은 걸릴수 있다. serverless compute는 위와 같은 셋팅이 거의 필요 없고 그냥 코드 작성해서 배포해주기만 하면 된다. 너무 간단하지 않은가?

 

가격

저렴하다.물론 일반 compute를 빌려쓰는것도 설정을 잘하면 저렴하게 쓸수 있다. 하지만 큰 compute power가 필요하지 않는 api서버를 만들고 싶다면 대여하는 것보다 저렴할것이다. 왜? instance를 사용시간만 사용하고, 딱 사용된 compute 비용만 지불하기 때문이다.

 

그렇다면 serverless computing은 장점만 있는 것일까?

 

NO

 

다음과 같은 단점이 존재한다.

 

이식성

google cloud functions를 위해 짠코드는 google cloud functions에서만 돌릴수 있다. lamda를 위해서 짠 코드는 lamda에서만 돌릴수 있다. 만약 google cloud 가 마비되었다고 가정해보자? 그럼 빨리 aws로 스위칭 할수 있어야 할것 아닌가?(물론 스타트업 같은 작은 서비스에서 이런 디테일은 챙기기 어렵다.) 물론 언어가 같다는 가정하에 layer로 감싸 이식성을 만들수 있다.(약간의 노가다를 동반하여) 하지만 이건 우리가 말하는 편한 이식성은 절대 아니다.

 

디버깅 환경

디버깅이 불편하다. 로컬 환경에서 다양하게 제공되는 디버깅 툴을 사용할수가 없다. break point를 걸수도 없고, 단지 로컬 실행을 해가면 print 문 또는 로그를 찍어가면 디버깅 해야만 한다. 개발자에게 디버깅 툴은 정말 중요하다. 거짓좀 보태서 개발자는 디버깅 시간이 70% 라고도 말한다. 그런데 이런 구시대적인 디버깅 방법을 사용해야만 하는것인가?

 

커스터마이즈

위에 생산성 부분에서 설명했듯이 auto scale, 배포 등 많은 자동화를 제공한다. 그뜻은 역으로 커스터마이즈를 할수 없다는 뚯이기도 하다. 예를 들어, auto scale의 속도 라던지, 임계값은 설정할수 없다. 그리고 큰 compute power가 필요한 서비스를 만들때는 serverless compute로 벅찰수도 있다. 또한 배포 test를 위해 일부 instance에만 신규 기능을 배포하는 등의 a/b 테스트도 불가능하다. 만약 a/b test 및 신규 기능 일부 배포 기능을 넣고 싶다면 serverless compute 사용을 다시 한번 생각해봐야만 한다.

 

cold start

위에 설명했듯이 serverless compute는 instance를 자동 확장해준다. 하지만 instance를 확장할때, instacne를 확장하기 위한 시간이 필요한데 이걸 cold start 라고 한다. 이게 무슨문제냐고? 이시간의 부담을 서비스 사용자가 해야 되니깐 문제다. api를 만들었다고 가정했을때, cold start에 해당하는 api call의 return 시간은 길면 10~20초까지 걸릴수 있다.

물론 lazy initialization 등 여러가지 방법을 사용해서 cold start를 줄일수 있다. 하지만 서비스가 커지면서 어쩔수 없이 cold start 시간이 길어질수 밖에 없다. 물론 microservice architecture로 개발한다면 cold start는 거의 없을수 있다.

 

serverless compute는 언제 써야 할까?

 

자 이제 결론이다.

필자의 생각은 다음과 같다.

가격을 저렴하게, 인프라 없이, 코드로만 빠르게, 큰 compute power가 필요없는, 초기 개발하고 싶다면 serverless computing를 사용 할것이다. 초기 개발을 할때 너무나도 좋다. 하지만 물론 일정 시간이 지나면 compute instance로 올려야 하기 때문에 layer를 분리해야만 한다.

 

하지만 위와같은 장점에도 불구하고, 아직까지 serverless compute는 갈길이 멀다. 이식성의 부재와 불편한 디버깅 환경은 너무 치명적이다. 요즘 kubernetes같은 컨테이너 오케스트레이션 환경도 요즘 너무 잘되어 있고, 클라우드 서비스들도 많은 자동화 편의성와 문서를 제공하고 있다. 물론 너무 인원이 부족하고 해야할일이 많다면 serverless compute는 찰떡이다. 하지만 아직까지는 부족한점이 많은건 사실이다.(필자는 시간이 너무 없거나, 또는 간단한 서비스를 만들고 싶을때 serverless compute를 사용할것 같다.)

 

그래도 필자는 언젠가는 serverless compute의 이식성이 더 좋아질날이 올것이라 믿는다. 더 나은 디버깅 환경을 제공해 줄것이라 믿는다. 그날을 기약하며 글을 마치고자 한다.