serveless 프레임워크는 2010년대부터 이야기되어온 개발 개념으로 현재에는 MS, AWS나 구글 등 굴지의 업체들이 앞다퉈 제공하고 있는 서비스입니다.
정보를 저장하고 업데이트하는 것이 필요한 서비스에서는 백앤드 서버가 필수적이었는데요.
서버리스는 기존의 서버 프로세스를 쓰는 것이 아니라, 써드파티 서비스(다른 회사 어플리케이션을 이용하는 것)를 이용해서 서버가 하던 역할을 대신하는 것입니다.
즉, 서버리스(serveless)라고 해서 서버가 없는 것이 아니라, 직접 백앤드 서버를 구축하는 것이 아니라 다른 회사의 서비스를 이용해서 서버 구현을 대신하여, 초기 비용과 인력 이슈등을 해결할 수 있는 개발 방법론을 이야기한다고 보면 됩니다.
대표적인 serverless 서비스
백앤드 개발은 알다시피 많은 지식과 또는 그러한 지식들을 나눠서 일을 할 수 있는 여러 사람이 일반적으로 필요합니다. (풀스택으로 혼자 하는 분이 있다면 정말 든든하겠죠?)
상대적으로 많은 클라이언트 개발자보다 부족한 서버 개발자로 인해 어려움이 있는 회사들이 많았으므로, 구글, AWS 및 MS 같은 회사들이 백앤드 서비스와 관련된 것들을 서비스로서 제공하기 시작하게 되었습니다.
현재 가장 대표적인 서버리스 백앤드 서비스로는 Baas와 Faas가 있습니다.
1. Baas (Backend as a service)
서비스로서 백앤드를 통합 제공하는 것을 Baas라고 합니다.
여러가지 Baas 서비스가 있겠지만, 대표적인 것은 바로 구글의 Firebase입니다.
모바일 게임을 만들때 FIrebase에서 제공하는 인증, 데이터베이스, 소셜 연동 등을 이용할 경우 서버 프로그래머가 없어도 클라이언트에서 바로 사용이 가능합니다.
이러한 Firebase 같은 Baas 시스템을 이용하므로서 얻을 수 있는 장점은 아래와 같습니다.
(1) 초기 비용 무료
(2) 백앤드 서비스에 필요한 기능을 일일이 만들 필요가 없고, 서버 프로그래머를 따로 고용할 필요가 적어져 시간 및 비용 절약
(3) 보안, 로드밸런서 등 관련해서 신경을 덜 써도 됨
비용과 업데이트 그리고 제한성
하지만 Bass 도 단점이 존재하지 않을 수 없습니다.
가장 큰 단점 중에 하나는 서비스가 성공을 할수록 더 비용이 커지는 구조입니다.
처음에는 무료로 시작했지만, 누구나 돈을 벌기를 원하는데 그러한 상황이 발생하면 비용이 증가하게 됩니다.
또한 클라이언트 단으로 모든 기능이 넘어와 있으므로, 기존에는 서버만 수정해도 되는 부분을 클라이언트 수정이 필요해지게 되고, 업데이트를 위해 다시 앱을 다운로드 받아야 하는 경우가 발생합니다.
앱을 업데이트 해야 할때마다 일정 비율의 이탈이 발생한다고 봤을때, 위험으로서 간주될 수 있습니다.
또 다른 Bass의 단점으로는 Baas에서 제공하는 방식 이외의 확장이나 변경은 복잡하거나 불가능할 수 있다는 것입니다.
즉 서비스에 백앤드를 맞추는 것이 아니라 백앤드에 서비스를 맞춰야 하는 것입니다.
2. Faas (Function as a service)
만약, 실시간으로 계속 업데이트가 일어나는 서비스가 아니라면, 이벤트마다 서비스를 호출하는 비용만 지불하는 것이 훨씬 더 효과적일 수 있습니다.
즉 서드파티에 서버에 호출하는 함수를 등록해 놓고, 해당 함수가 호출될때마다만 비용을 제출하는 것입니다.
이러한 서비스로 대표적인 것은 아마도 AWS의 Lambda, 구글의 Cloud Function 그리고 MS 애져의 Azure function이 입니다.
넷플릭스를 비롯한 굴지의 업체들도 이러한 Faas를 이용해서 서비스를 하고 있고, 가장 최근의 기술이며 앞으로 각광을 받을 가능성도 높습니다.
비용적인 측면에서도 좋지만, 유지 보수 관리 등에 대해서 크게 걱정할 필요가 없기 때문입니다.
단, 이러한 Faas도 마찬가지로 단점이 있습니다.
가장 큰 단점은 아직도 대부분의 업체와 개발자들인 전통적인 서버 방식 또는 Baas를 쓰고 있습니다.
그렇다보니 처음 Faas에 진입하는 사람이라면 레퍼런스를 구하기가 어렵다는 단점이 있습니다.
또한, baas는 하나만 쓰면 알아서 해줬는데 Faas는 저장 기능등을 서비스 제공 업체의 다른 서비스 또는 별도의 서드파티 서비스와 연결해서 사용해야 된다는 것입니다.
글 마무리
서버리스(serverless)에 대해서 조금 알아보았는데요.
위에 언급한대로 무조건 서버리스가 좋다라고 말할수는 없습니다.
프로젝트에 따라서 더 이득이 될 수 있는 것을 골라야하며, 무엇보다 중요한 것을 그러한 의사결정을 내려줄 수 있는 전문가가 있어야 실제 서비스까지 끌고가는데 위험이 덜 할 것입니다.
'프로그래밍' 카테고리의 다른 글
프론트 앤드 프레임워크 2020 TOP 5 (0) | 2021.03.10 |
---|---|
Brackets 을 대체할 코드 편집기 추천 5가지 (0) | 2021.03.09 |
블록체인 프로그래밍 입문자 추천 언어와 툴 4가지 (0) | 2021.03.07 |
ini 파일 유니티에서 읽고 쓰는 방법 (0) | 2021.03.06 |
유니티 윈도우 빌드 메뉴 프레임 없애는 방법 (0) | 2021.03.05 |