사이드 프로젝트 기획하는 당신! 서버리스를 아시나요?
서버의 하드웨어와 소프트웨어, 서버리스의 장단점
서론:
동네 카페에서
서버리스 공부하기
어제, 나는 개발자 A씨와 동네 카페에서 놀다가 서버리스 아키텍처라는 개념을 이해하게 됐다...! 매번 기획 관점의 포스팅만 썼으니, 어제 새롭게 알게 된 개발 지식을 포스팅으로 옮겨 보면 좋겠다는 생각에 브런치에 접속하게 됐다.
"서버리스 아키텍처? 그거 백엔드 개발자들이 공부하는 거 아닌가? 기획자가 그걸 왜 알아야 하지?"라는 생각이 드는 건 자연스러운 일인 것 같다. 나도 개발자 A씨와 사적으로 친하지 않았더라면 평생 들여다볼 일이 없는 분야가 바로 백엔드이지 않을까 싶다.
내가 어제 개발자 A씨로부터 서버리스 아키텍처에 대한 가르침을 받았던 이유는 개발자 A씨의 사이드 프로젝트에 대해 수다를 떨었기 때문이다. 그리고 개발자 A씨가 요즘 진행하는 작업에 대해 이야기해주다가 '서버리스'라는 단어가 툭 튀어나왔다. 그리고 그렇게 n시간 동안 서버의 역사부터 최근의 동향까지 쭉 훑게 되었다(ㅋㅋ). 애써 익힌 지식을 흘려보내기가 아까워서 포스팅으로 내가 이해한 바를 어설프게나마 요약해보려고 한다.
1. 서버의 하드웨어와 소프트웨어
우리 집 거실에
서버 컴퓨터가 없는 이유
출처=https://www.flickr.com/photos/89228431@N06/11285592553한때는 거실에 서버가 있었던 적도 있다. 말그대로 클라이언트의 응답에 요청해서 정보를 제공하는, 즉 서버 역할을 하는 컴퓨터의 하드웨어를 직접 관리해야 했다는 뜻이다. 이처럼 데이터센터나 서버실에 서버를 두고 직접 관리하는 방식을 온프레미스(On-premise)라고 부른다.
당대 개발자들은 자신이 배포한 애플리케이션의 서버가 24시간 원활하게 돌아갈 수 있도록 데이터 센터를 지극정성으로 돌보아야 했다. 전기 공급, 온습도 조절, 공기 청정까지. 웹사이트 트래픽이 과하게 증가하면 직접 서버 메모리를 사와서 하드웨어에 꽂아야 했다(...).
그리고 2006년, 아마존의 EC2가 등장했다. EC2를 사용하면 대기업 아마존에서 안정적으로 관리하는 최신 서버를 빌려 쓸 수 있다. 돈을 지불하기만 하면 아마존에서 대신 관리해주는 내 몫의 서버 컴퓨터가 생기는 셈이다. 덕분에 개발자들은 더 이상 집 거실에 서버 컴퓨터를 놓고 전전긍긍할 필요가 없어진 것이다. 하드웨어로서의 서버는 이렇게 자유를 얻었다. 클라우드 컴퓨팅의 시대가 도래한 것이다.
하드웨어는 자유를 찾았지만,
소프트웨어는?
그러나 아직 해결해야 할 문제가 하나 더 남아 있었다. 바로 소프트웨어로서의 서버에 대한 것이었다. 소프트웨어를 주기적으로 업데이트할 수 있는 인력이 있는 애플리케이션이라면 문제가 없겠지만, 그렇지 않은 애플리케이션은 최신 경향을 쫓아가기가 어렵다. 업데이트도 해줘야 하고, 보안도 신경 써야 하고, 데이터 백업도 해야 하는 등, 서버의 하드웨어 만큼이나 서버의 소프트웨어도 관리해야 할 지점이 성가실 만큼 많은 것이었다.
2. 사이드프로젝트와 서버리스
이때, 서버리스 아키텍처가 등장해서 또 한 번 문제를 해결했다. 서버리스(Serverless)는 '-less'라는 접미사 때문에 서버가 없다는 의미로 비춰질 수 있지만, 사실은 내가 직접 관리하지 않아도 되는 백엔드를 의미한다. 한마디로 '서버의 존재'에 대해서 신경쓰지 않아도 된다는 뜻이다. 대표적인 서비스로는 AWS Lambda, Azure Functions, Google Cloud Functions 등이 있다. 이들을 이용하면 서버의 사양과 갯수, 네트워크의 종류 등을 신경 꺼도 알아서 관리해준다.
불과 2주 전, 헤로쿠가 깜짝 유료화를 선언했다(...)이쯤에서 다시 서론에 등장했던 개발자 A씨의 이야기로 돌아가보자. 개발자 A씨는 1인 사이드 프로젝트를 개발 중이다. 개발자 A씨는 이 서비스의 클라우드 컴퓨팅 플랫폼으로써 헤로쿠를 선택했다. 그러나 순조롭게 개발을 하던 중, 헤로쿠가 위 사진처럼 돌연 유료화를 선언했다. 자세한 내용은 밝힐 수 없지만, 사이드 프로젝트의 특성상 개발자 A씨는 무료 서비스를 찾아야 했다. 그래서 개발자 A씨는 고민 끝에 '무료에 가까운' 서버리스 서비스, AWS Lambda로 갈아타기로 했다.
출처=https://www.instana.com/blog/observability-best-practices-for-aws-lambda-functions/서버리스의 장단점
출처=클라우드 패러다임의 전환: 서버리스 컴퓨팅이 AWS Lambda와 같은 서버리스 서비스, 즉 Faas(Function as a Service)를 자세히 설명하자면 다음과 같다. 백엔드를 여러 개의 함수로 쪼개서 아마존, 구글과 같은 거대 기업이 대신 관리해주는 서버에 등록하면, 이 함수들이 실행되는 횟수와 시간 만큼 비용을 지불하는 방식이다.
서버리스가 아닌 방식, 대표적으로 헤로쿠와 같은 PaaS(Platform as a Service)와의 가장 큰 차이점은 PaaS의 경우에는 서버가 24시간 돌아가고 있다는 것이다. 실제로 헤로쿠는 리퀘스트가 올 때까지 계속 켜진 상태에서 대기한다.
반면, AWS Lambda는 평상시에는 절전 모드에 들어가 있다가, 리퀘스트가 도착하면 해당 작업을 수행하고 다시 절전 모드로 돌아간다. 또한, 리퀘스트의 빈도를 구분하여 자주 쓰이는 리퀘스트의 경우에는 절전 모드로 돌리지 않고 항상 깨어 있도록 유지시킨다.
출처=클라우드 패러다임의 전환: 서버리스 컴퓨팅서버리스가 아닌 경우에는 전체 애플리케이션을 배포해야 하므로 유저가 적든 많든, 사이드 프로젝트든 기업의 프로젝트든 같은 돈을 내야 했다. 그러나 FaaS의 경우에는 함수 단위로 쪼개어서 배포가 가능하다. 이와 같은 이유로 서버리스는 매우 저렴하고, 프로토타이핑이나 사이드 프로젝트를 진행하는 개발자들에게 적합하다.
물론 이러한 서버리스에도 단점은 있다. 모든 코드를 함수로 쪼개는 작업이 필요하고, 이 작업으로 인해 쉽게 서비스를 옮길 수가 없다. 서버 제공자에 대한 의존도가 높다는 뜻이기도 하다. 또, 절전 모드를 켜고 끄는 과정에서 요청과 응답 사이에 딜레이가 생긴다. 따라서 초단타매매, 실시간 멀티플레이 등 아주 미세한 차이가 중요한 애플리케이션에서는 서버리스를 활용하기 어렵다.
ⓒJuly그러나 개발자 A씨의 사이드 프로젝트는 이러한 단점의 영향을 받지 않는다. 오히려,
예측 가능한 소수의 이용자
비교적 적은 리퀘스트
서버 비용 절감의 필요성
1인 프로젝트
이와 같은 특징에 최적화된 서비스인 것이다. 한창 작업하던 서버를 다시 함수 단위로 쪼개는 작업을 새롭게 해야 했지만, 결과적으로는 그 덕분에 사이드 프로젝트에 가장 걸맞은 백엔드를 만나게 된 거라고 볼 수 있다. 적은 돈을 지불하는 것만으로도 소프트웨어로서의 서버에 대한 관리와 설정을 전적으로 AWS Lambda에 맡겨 코드 작업에만 집중할 수 있게 됐다.
이러한 일련의 지식이 한 번에 이해되지는 않아서, 몇 번이나 되묻고, 또 관련 자료를 찾아보기도 했다. 특히 유튜버 노마드코더에서 업로드한 위 영상이 서버리스를 이해하는 데 많은 도움이 되었다. 짧은 포스팅이지만 개발자와의 대화를 통해서 새로운 지식을 배웠던 좋은 경험을 기록했다는 데 의의를 두려고 한다!ㅋㅋ
참고자료
