서버리스아키텍처

덤프버전 : r20200302

분류

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


서버인데 서버가 없다고?


1. 배경[편집]

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

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

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

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


2. 개요[편집]

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

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

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

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

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

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

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

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

  • 함수 서비스 : 프론트엔드 서버의 서버리스 버전이다.
  • 메모리 캐시 서비스 : 메모리 데이터 그리드의 서버리스 버전이다.
  • 데이터베이스 서비스 : 데이터베이스 샤드 클러스터의 서버리스 버전이다.

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

3. 장점[편집]

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

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

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

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

그러면서도 싸다. 사용자당 일분에 십여번 정도의 리퀘스트를 보내는 경우 일반적인 클라우드서버(IaaS)보다 적은 비용이 든다.

4. 단점[편집]

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

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

대용량 사용자 처리에는 적합하나, 1밀리초의 응답 시간도 이슈가 되는 분야(초단타매매, 온라인 게임의 실시간 멀티플레이)에서는 처리 속도가 못 쫓아간다.

5. 응용사례[편집]

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

서버리스아키텍처는 게임서버의 아웃게임(out-game; 로그인,매치메이킹,아이템결제,플레이어정보관리 등을 담당하는 부분. 아래 인게임 부분을 제외한 나머지 모두)의 서버 역할로 활용되기도 한다.

인게임(in-game; 게임 시작 버튼 누르고 게임아웃 나오기 전까지의 구간)에서는 실시간 멀티플레이가 빡시게 일어난다. 약간의 랙도 쉽게 받아들여지지 않는 상황이다. 단점에서 상술했듯이, 서버리스아키텍처는 인게임에 부적합하다.

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

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

  • Amazon : AWS Lambda
  • Microsoft : Azure Functions
  • Google : Google Cloud Functions

7. 관련 용어[편집]

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

8. 여담[편집]

아마존에서 처음으로 서버리스아키텍처와 AWS Lambda를 출시했을 때 "이제는 서버가 필요없다!"를 외치며 오함마로 서버 기기를 관중 앞에서 부수는 퍼포먼스를 벌였다고.
[1] 혹은 그런 경험이 태부족 하니까.


관련 문서