CS | Serverless

happy tiger·2023년 2월 16일

CS

목록 보기

9/10

1. Serverless 는 무엇인가

1-1. Server 가 less 하다..?

Serverless 는 Server 와 less 의 합성어이다.
그래서 많은 사람들이 서버(Server)가 없다(less) 라고 잘못 해석한다. 하지만 서버가 없다는 것은 말이 되지 않는다. 어딘가에 로직 코드가 저장되어있어야 하지 않겠는가.
그렇다면 Serverless는 왜 Serverless 일까? Serverless는 백엔드 개발자가 직접 서버(Server)를 관리하지 않는다(less) 는 의미로 만들어진 합성어이다.

Serverless : 클라우드 상에 있는 서버에서 소스코드를 동작하게 하는 개발 모델
더이상 개발자가 서버를 직접 구축하고 관리할 필요 x
서버는 여전히 존재하지만 클라우드측에서 알아서 관리해줌

1-2. Traditional Way

예전에 직접 서버를 사야하던 시절엔 어떻게 서버를 운영했을까?

거실에 위와 같은 서버를 놓고 전원을 연결해서 사용했다. 즉, 서버의 하드웨어와 소프트웨어 둘 다 관리했다는 뜻이다.
정전이 되거나 서버의 전원을 뽑으면 서버연결이 끊기기 때문에 신경써줘야 했다. 또한 트래픽이 증가하면 서버의 메모리가 충분하지 않아 서버가 다운되기 쉽다. 이럴 때면 상점으로 뛰어가서 메모리를 사와 서버에 꼽아주어야 했다.
이 모든 것을 수동으로 직접 해주어야 했었다.

문제점

트래픽 관리
소프트웨어 관리(유지보수)
서버가 잘 동작하는지 모니터링하는 시스템 마련
사용자 수에 따른 업 / 다운 스케일링
24시간 운영

1-3. Serverless Way

아마존의 EC2가 등장
→ 거실에 서버 설치하는 대신 아마존에 돈을 내면 아마존이 사용하는 최신식 서버를 빌려서 사용할 수 있다.덕분에 정전이나 서버다운을 걱정할 필요 없다. 돈만 더 내면 아마존이 스토리지를 한방에 팍팍 늘려줄테니 말이다.
이제 우리는 구글 아마존 등의 서버를 돈을 내고 빌리면 되고 그 큰 회사들이 서버 하드웨어 부분을 책임지고 관리해준다. 하지만 아직 서버의 소프트웨어는 관리를 직접해줘야 한다.
업데이트, 보안, 데이터 백업 등 소프트웨어 관리 할 것이 많은데, 바로 이 때 소프트웨어 관리까지 해주는 서버리스가 등장한다.

서버리스에선 개발자가 직접 서버를 만들지 않고 어플리케이션 소스코드에만 집중해서 개발한다. 그대신 호스팅 플랫폼에서 서버의 설정과 하드웨어 부분을 관리해준다.

Serverless Computing = FaaS = Function as a Server

Serverless에서는 백엔드를 작은 함수단으로 쪼개서 클라우드 호스팅(e.g. AWS lambda)에 올림

request가 들어오면 AWS가 함수를 깨워 요청을 수행
request가 없으면 함수는 잠 (request: GET /products)

서버리스가 아닌 경우, 서버는 24시간 작동한다. 즉, 언제나 요청에 응답할 준비를 하고 있다는 것이다.
서버리스의 경우, 개발자가 업로드한 함수는 기본적으로 잠을 자고 있다. 그러나 리퀘스트가 오는 순간 AWS는 함수를 깨울 것이고 함수는 요청한 작업을 수행하고 다시 함수는 잠든다. 함수가 24시간 동안 깨어서 대기를 하지 않아도 된다는 것이 바로 서버리스의 혁명이다.

2. 장점

빠르게 제품 출시 가능
Traditional Way의 문제점이었던 트래픽 관리, 유지 보수, 서버 모니터링, 스케일링을 호스팅 플랫폼이 도와주므로, 빠르게 제품출시가 가능하다.
돈 절약 가능
이전의 경우 유저 0명이든 100명이든 같은 돈을 내야 한다.
하지만 Serverless 에서는 수행한 함수 만큼만 돈을 내면 된다. request가 와서 함수가 뭔가를 수행하면 그때 돈을 내는 것이다.

3. 단점

cold start → 서버가 응답하는데 시간이 걸림

request가 와서 함수를 깨우는데 아무래도 시간이 걸린다. ms 단위로 긴 시간은 아니겠지만, 원래의 서버는 항시 대기하고 있으니 보통 서버보다 시간이 더 걸리게 된다. 그러니 그 시간차도 허용되지 않는 경우는 서버리스는 좋은 선택이 아니다.
서버 제공자에 너무 의지하게 됨. 즉, 서버에 대한 통제를 잃음
백엔드를 aws에 배포했다면 aws와 결혼한셈이다. 그래서 aws와 싸운다면 단순하게 함수를 빼서 다른 Serverless 클라우드로 이사갈 수 없다. 즉, 한 서버리스에서 다른 서버리스로 이동하는 것은 쉽지 않다는 것이다. aws에서 서버만 빌렸다가 구글 클라우드로 이사가는 건 쉽다. 하지만 Serverless 클라우드는 클라우드마다 동작하는 방법이 가지각색이기 때문에, 이동이 쉽지 않은 것이다.
구조를 변경해줘야함
서버리스로 작업하면 어플리케이션의 구조자체가 바뀌게 된다.
리소스의 한계 (메모리 한계)

AWS lambda 함수로 등록할 수 있는 메모리 사이즈는 정해져 있다.
또한, 15분 이상이 걸리면 timeout이 발생한다. 고로 너무 무거운 함수를 돌리기에 적당하지 않다.
상태가 없는 독립적 새별적인 함수로 만들어야함.
특정 이벤트가 발생하면 수행되기 때문에, 함수 내부에서 전역 데이터를 참조하거나 상태를 가지거나 할 수 없다.다만 함수 내부에서 다른 데베에 접근해서 읽고 쓰는것은 괜찮다.
기존에 RESTful API로 만들었다면 상태가 없는 함수로 만들었으니 크게 상관쓰지 않아도 된다. ( 무슨 내용인지 아직 모르겠다..! 나중에 다시 돌아오기 )