서버리스 아키텍처

덤프버전 :

분류


Serverless architecture

1. 배경
2. 개요
3. 장점
4. 단점
5. 사례
6. 서버리스 아키텍처 제공업체
7. 관련 용어
8. 여담



1. 배경[편집]

서버를 구성하는 것은 서버 하드웨어만 있는 것이 아니다. 다음과 같은 것들이 모두 있어야 서버로서의 역할을 한다.

  • 인터넷 망
  • 서버 하드웨어
  • 서버 운영체제
  • 서버 미들웨어
  • 서버 애플리케이션

클라우드 서버를 구축하는 경우 위에 중 인터넷 망, 서버 하드웨어, 서버 운영체제 부분까지는 구축하는 노력을 안 해도 된다. 클라우드 서버가 인기가 있는 이유이기도 하다.

그러나 사람들은 서버 미들웨어와 서버 애플리케이션도 노력을 안 하게 만드는 방법을 연구했고, 그 결과 서버리스 아키텍처가 등장하게 되었다.


2. 개요[편집]

서버를 구축할 때 어려움은 크게 다음과 같다.

  • 대용량 서비스에서의 서버 안정성
  • 해킹으로부터의 방어
  • 관리
  • 서버 애플리케이션 유지보수의 신속성

대용량 서비스에서의 서버 안정성을 위한 대표적인 방법은 서버 하드웨어의 수를 늘리는 것이다. 클라우드 서버를 쓰면 몇 분만에 서버 하드웨어(가상머신이지만...)를 쉽게 늘릴 수 있다.

하지만 서버 하드웨어만 늘린다고 쉽게 대용량 서비스에 대응하는 것이 아니다. 대용량 분산 서버 설계와 구현 능력이 필요하다. 서버 하드웨어를 늘리더라도 서버 미들웨어와 서버 애플리케이션이 마치 한 대의 거대한 수퍼컴퓨터처럼 작동하게 만들 수 있어야 한다.

이는 쉽지 않다. 실력도 실력이지만 오랜 서비스 장애 삽질 경험을 필요로 한다. 그러나 세월이 지나며 많은 경험이 쌓이다 보니, 다음과 같은 분산 서버 설계 패턴이 도출되었다.

  • 백엔드 서버: 비지니스 로직을 담당하는 서버들의 군집체
  • 메모리 데이터 그리드: 메모리 저장소 역할을 담당하는 서버들의 그물망 군집체
  • 데이터베이스 샤드 클러스터: 거대한 데이터를 나눠 가지는 서버들의 군집체

이러한 패턴을 미리 설계해서 구현 해놓고, 서버 프로그래머들은 이 위에다가 "자기가 필요한 비지니스로직을 만들어 넣게 해주기만 하면" 되게 만들어 놓았으니...이를 서버리스 아키텍처라고 칭한다.

서버리스 아키텍처는 다음과 같이 구성된다.

  • 백엔드 서버 => 함수 서비스
  • 메모리 데이터 그리드 => 메모리 캐시 서비스
  • 데이터베이스 샤드 클러스터 => 데이터베이스 서비스

서버 프로그래머는 함수 서비스에다가 함수를 구현해 놓고, 필요한 만큼의 메모리 캐시 서비스를 예약하고, 데이터베이스 서비스에 들어갈 데이터 구조를 정의하면 끝.

따라서 서버리스 아키텍처는 그 명칭과 달리 서버가 전혀 없는 아키텍처가 아니다. 그 뒷단에는 여전히 실제 서버들이 구성 되어 돌아가고 있으며 단지 서버를 구성하는데 필요한 부분들을 서비스화 하고 단순화시켜 직접 서버를 구축함으로써 발생하는 애로사항 등을 줄이고자 하는 것이다.

3. 장점[편집]

대용량 서버를 쉽게 만들 수 있다. 대용량 서버 설계와 구축, 설치에만도, 초심자는 몇 달의 연구가 필요하고, 게다가 그 연구결과도 신뢰할 수 없다. 경험이 없으니까. 그리고 그런 경험이 태부족 하니까. 그렇지만 서버리스 아키텍처에서는 비즈니스 로직을 구성하는 함수 코드만 작성하면 된다. 그러면 알아서 서버리스 아키텍처 안에서 필요한 만큼 서버 하드웨어가 늘었다 줄었다 한다. 해커 보안 방어라든지 성능 튜닝 등 서버 관리 전문가들의 노력이 없어도 된다. 서버리스 아키텍처를 제공하는 사업자가 그건 다 알아서 해주니까.

따라서 개발 기간이 엄청 단축된다. 개발 기간이 바로 돈으로 직결되는 소프트웨어 서비스 개발 사업에서는 매우 중요한 부분이다. 시간이 돈이니까.

안정성이 높다. 오랜 경험을 가진 선배들의 경험을 서버리스 아키텍처라는 물건 위에 다 만들어 놓았다. 서버 프로그래머는 그 위에 숟가락만 얹으면 된다. 필요한 함수 코드만 만들어 놓으면 되며, 서버 프로그래머가 무한루프같은 이상한 삽질만 하지 않으면 잘 돌아간다. 접속자가 폭주를 해도 빵빵하게 잘 돌아간다. 그 대가로 서버리스 아키텍처 제공업체에게 사용료도 빵빵하게 나간다

서버리스 아키텍처에서는 서버 개발자가 만든 모든 소스코드가 확보된다. 개발자들이 어떤 미들웨어나 프레임워크를 구매해서 쓰는 경우 그것의 소스코드가 없어서 뭔가 찜찜할 수 있다. 버그가 만약 프레임워크 안에서 나게 되면 소스코드가 없어서 원인을 찾는데 어려움이 있을 수 있다. 서버리스 아키텍처에서는 모든 비즈니스 로직을 프로그래머가 직접 만들어 넣을 수 있다. 서버리스 아키텍처에서는 전반적인 서버 소스 프로그램이 크게 단순화된다. 따라서 유지보수가 쉽다. BaaS나 PaaS에서는 얻을 수 없는 큰 장점이다.

그러면서도 싸다. 사용자당 일분에 십여번 정도의 리퀘스트를 보내는 경우 일반적인 클라우드서버(IaaS)보다 적은 비용이 든다. 이는 서버리스 아키텍처의 서비스 특징에서 비롯되는데, 평소에 잠자고 있는(슬립) 상태로 대기하고 있다가 요청이 들어올 때만 깨어나서 응답을 하는 형태로 서비스가 돌아가며, 이후 일정 시간 동안 추가적인 요청이 없으면 다시 슬립 상태로 돌아가게 된다. 따라서 실제로 처리가 이뤄진 시간만큼만 요금이 부과되기 때문에 요금이 매우 저렴한 것이다.

4. 단점[편집]

락인(lock-in) 문제가 있다. 특정 서버리스 아키텍처 제공업체의 것을 쓸 경우 다른 제공업체로 전환하기가 까다롭다. 이를 완화하기 위해서 특정 서버리스 아키텍처에 종속되지 않는 표준이 필요한 실정이다. 오픈위스크나 서버리스프레임워크 같은 것들이 이 문제를 해결하기 위한 노력의 일환이다.

행여나 서버리스 아키텍처 인프라 자체에 문제가 생길 경우 컨트롤할 수 없다. 서버리스 아키텍처 제공업체에게 신고하고 문의하고 기다리는 수밖에 없다.

앞서 장점에서 언급한 서버가 슬립에서 깨어나 처리를 하고 실제로 처리가 이뤄진 시간 만큼만 요금이 부과되기에 요금이 매우 저렴하지만, 이러한 서비스 과정에서 요청에서 응답까지 걸리는 시간이 상당하기 때문에 1밀리초의 응답 시간 지연조차도 문제가 되는 분야(초단타매매, 온라인 게임의 실시간 멀티플레이)에서는 서버리스 아키텍처를 개선해야 한다.

5. 사례[편집]

넷플릭스가 서버리스 아키텍처를 쓰고 있다. (링크)

서버리스 아키텍처는 게임 서버의 아웃게임(out-game; 로그인, 매치메이킹, 아이템결제, 플레이어정보 관리 등을 담당하는 부분. 아래 인게임 부분을 제외한 나머지 모두)의 서버 역할로 활용되기도 한다. 인게임(in-game; 게임 시작 버튼 누르고 게임아웃 나오기 전까지의 구간)에서는 실시간 멀티플레이가 빡시게 일어난다. 약간의 랙도 쉽게 받아들여지지 않는 상황이다. 단점에서 상술했듯이, 서버리스 아키텍처는 인게임에 부적합하다.

6. 서버리스 아키텍처 제공업체[편집]

대표적인 서버리스 아키텍처 제공업체는 다음과 같다.

7. 관련 용어[편집]

FaaS(Function as a Service)나 마이크로 서비스 아키텍처(Micro Service Architecture; MSA)와도 맞물려서 표현된다. 정확히는 "Faas(함수) + SaaS(메모리,데이터베이스) = 서버리스 아키텍처"다.

8. 여담[편집]

아마존에서 처음으로 서버리스 아키텍처와 AWS Lambda를 출시했을 때 "이제 서버는 필요없다!"를 외치며 오함마로 서버 기기를 관중 앞에서 부수는 퍼포먼스를 벌였다고.
[각주]
파일:크리에이티브 커먼즈 라이선스__CC.png 이 문서의 내용 중 전체 또는 일부는 2023-12-03 02:08:01에 나무위키 서버리스 아키텍처 문서에서 가져왔습니다.

관련 문서