[CCCR 프로젝트] 서버리스 아키텍처 분석

드디어 학원에서 프로젝트가 시작되었다!
우리 팀이 하게 될 프로젝트는 서버리스 아키텍처를 이용한 애플리케이션 구축이다. 이 프로젝트를 통해 서버리스라는 용어를 처음 접하게 된 만큼 본격적인 프로젝트가 시작되기 전 서버리스에 대해 조사하고 분석한 내용을 포스팅해보려 한다.

1. 클라우드 패러다임의 전환 - 서버리스 컴퓨팅

1) 서버리스의 탄생

코카콜라가 아마존 웹 서비스(AWS) EC2(Elastic Compute Cloud) 인스턴스에서 운영 중이던 자판기 관리 시스템을 AWS Lambda로 이전하여 관리비용을 년 1만 3,000달러에서 4,500달러로 65%나 절감했다고 한다. Lambda는 서버리스 개념이 최초로 적용된 서비스로 2014년 11월 AWS가 발표했다.

2) 서버리스의 개념

서버리스는 언뜻 단어로만 보면 'Server + Less'로 '서버가 필요 없다'는 뜻으로 생각될 수 있다. 하지만 실제 의미는 클라우드 서비스 공급자가 서버를 관리, 실행하며, 요청이나 특정 이벤트가 있을 때 클라우드의 서버를 이용하여 서비스 할 어플리케이션을 동작시키는 것이다. 이를 통해 사용자(개발자)는 서버 관리에서 완전히 자유로워지며 실제 구현해야 할 기능에 더 집중할 수 있게 된다.

서버리스는 보통 '서버리스 컴퓨팅' 또는 '서버리스 아키텍처'로 불린다. 서버리스 개념은 어플리케이션 관점에서 BaaS(Backend as a Service)와 FaaS(Function as a Service)로 나누어 살펴보면 이해가 더 쉽다.

• BaaS

  어플리케이션 개발 시 요구되는 복잡한 백엔드 기능들을 사용자가 직접 개발하지 않고 클라우드 공급자가 제공하는 서비스를 이용해 쉽고 안정적으로 구현 (ex. 클라우드 인증 서비스인 Auth0)

• FaaS

  • 사용자가 쓸 기능을 함수 단위로 나누어 구현하고 이를 서비스하는 형태
  • 사용자가 원하는 기능을 미리 작성해놓고 특정 이벤트(예를 들어 HTTP Request, API 호출, 특정 조건 등)에 의해 실행
  • 서버는 계속 대기하면서 이벤트를 기다리지 않고 이벤트가 발생할 때마다 실행, 비용은 서버가 실행된 횟수와 시간(밀리세컨드. 1,000분의 1초)에 따라 산정됨
    (ex. FaaS를 구현한 대표적인 서비스: AWS의 Lambda, 마이크로소프트의 Azure Functions, 구글의 Google Cloud Function)

3) 서버리스의 장점 및 단점

• 장점

  1. 요청에 따라 호출되어 처리되기 때문에 유휴 자원이 발생하지 않아 운영 비용이 절감된다는 효과가 있다. 코카콜라의 비용 절감 사례가 그 예이다.
  2. 기존 클라우드 서비스보다 더 유연한 확장성을 제공한다.
     FaaS의 경우 일반적인 클라우드 서비스와 같이 특정 조건(예를 들어 CPU, RAM 임계치 도달과 같은)에 따라 확장되는 방식이 아닌, 호출될 때마다 새로운 인스턴스가 기동되어 동작하기 때문에 특정 조건을 설정하지 않아도 급격한 트래픽 변화에 유연한 대응이 가능하다.
  3. 기능이 함수 단위로 개발되기 때문에 서비스를 빠르고 간단하게 출시할 수 있다.
     
     

• 단점

  1. 빠른 응답이 필요한 제품의 경우 서버리스로의 전환은 부적합할 수 있다. 이는 실행되는 함수가 호출되기 위해 컨테이너가 실행되는 대기 시간(콜드스타트, Cold-Start)이 존재하기 때문인데 서버가 항시 기동되고 있지 않은 서버리스의 특징에 기인한다.

  2. 무상태(Stateless)적인 기능으로 구현되어야 한다. 하나의 작은 기능으로 나뉘어진 함수들은 요청마다 새로 기동되어 호출되기 때문에 전후 상태를 공유할 수 없다. 또한 변수와 데이터의 공유가 불가능하며, 데이터를 로컬 스토리지에서 읽고 쓸 수 없습니다. (이는 서버리스 벤더에 따라 추가 서비스를 통해 극복이 가능하지만, AWS S3, Azure Storage등 일반적인 서버리스는 불가능하다.)

참고 사이트 - 서버리스 컴퓨팅

2. AWS 서버리스 아키텍처 분석

1) 서버리스 웹 애플리케이션 아키텍처

(1) Amazon Route 53
사용자가 웹서비스를 이용하고자 DNS 요청을 하게 된다. 그러면 고가용성을 제공하는 DNS인 Amazon Route 53으로 전달된다. 이처럼 Amazon Route 53은 신뢰할 수 있는 DNS 시스템을 제공한다. 네트워크 트래픽은 AWS에서 돌아가는 인프라 안으로 라우트된다.

(2) Amazon S3
정적 컨텐츠는 Amazon CloudFront(edge locations의 전역 네트워크)에서 전달된다. 사용자의 요청은 자동으로 가장 가까운 edge location으로 라우팅된다.

Amazone S3는 정적 리소스와 컨텐츠를 담는 곳이다. 정적 리소스와 컨텐츠는 내구성이 뛰어난 스토리지 인프라인 Amazon Simple Storage Service(S3)에 저장된다. S3는 HTML, CSS, Javascript 파일과 같은 웹사이트의 정적 콘텐츠를 제공한다.

(3) Amazon Cognito
Amazon Cognito를 통해서 클라이언트는 Amazon API Gateway를 호출하기 위한 임시 자격 증명을 얻을 수 있다. 이 기능을 통해서 클라이언트는 서비스에 접근하기 위한 자격 증명을 얻을 수 있다.
Cognito는 AWS STS(AWS Security Token Service)로부터 자격 증명을 검색하여 사용자에게 다시 전달한다.

(4) Amazon API Gateway
Amazon Cognito를 통해 얻은 임시 자격 증명을 사용하여 API 요청이 서명되고, 또 그 요청은 Amazon API Gateway 서비스로 보내진다. API 요청은 API 게이트웨이를 통해 백엔드 서비스 로직으로 전달된다.

(5) AWS Lambda
AWS 람다는 웹 어플리케이션을 위한 백엔드 비즈니스 로직을 제공한다. 서버를 실행할 필요 없이 코드를 AWS에 업로드하면 API를 통해 요청이 들어왔을 때 해당 코드가 실행된다.

(6) AWS DynamoDB
완전한 관리형 데이터베이스 솔루션으로서, Amazon DynamoDB는 웹 애플리케이션의 데이터 계층으로서 빠르고 일관된 성능을 제공한다. 이 DynamoDB를 통해 동적인 컨텐츠를 클라이언트에게 제공할 수 있다.

2) 서버리스 모바일 백엔드 아키텍처

(1) Amazon Cognito
모바일 사용자는 모바일 기기 간 모바일 아이덴티티 관리와 데이터 동기화를 제공하는 Amazon Cognito로부터 아이덴티티를 검색한다. 모바일 사용자가 ID를 받으면 다른 AWS 서비스에 대한 액세스 권한이 부여된다.

(2) Amazon S3
사용자가 생성한 미디어 파일은 가용성과 내구성이 뛰어난 스토리지 서비스인 Amazon S3(Amazon Simple Storage Service)에 저장된다.

(3) Amazon CloudFront
모바일 사용자는 아마존 S3에 저장되어 있는 업로드된 디지털 자산에 짧은 대기 시간, 컨텐츠 전달 네트워크인 Amazon CloudFront를 통해 접속할 수 있다.

(4) Amazon API Gateway
모바일 사용자가 Amazon API Gateway에 애플리케이션 로직과 동적 데이터에 접근하기 위한 요청을 보낸다. API Gateway는 모바일 애플리케이션이 AWS 람다에서 실행되는 코드에서 기능에 액세스하기 위한 진입점 역할을 한다

(5) AWS Lambda Function
모바일 애플리케이션은 모바일 사용자가 생성하는 다양한 사용을 지원하기 위해 확장성이 뛰어난 백엔드 인프라를 필요로 한다. AWS 람다는 요청에 따라 코드를 실행하고 기본 리소스를 자동으로 관리 및 확장한다. 람다 함수 1은 사용자가 Amazon DynamoDB에서 비정형 데이터를 저장하고 검색할 수 있는 동기식 엔드포인트를 제공한다.

(6) Amazon DynamoDB
람다 함수 2는 Amazon DynamoDB 스트림을 사용하여 사용자가 변경한 내용을 검색하고 검색 가능한 문서를 만든 후 Amazon CloudSearch에 삽입한다.

(7) Amazon CloudSearch
람다 기능 3은 사용자가 CloudSearch에서 데이터를 검색할 수 있는 동기식 인터페이스를 제공한다. CloudSearch는 모바일 백엔드에 대한 검색 솔루션을 관리하고 확장한다.

(8) Amazon SNS
람다 함수 4는 모바일 사용자가 모바일 애플리케이션 내에서 서로 통신할 수 있도록 비동기식 엔드포인트를 제공한다. 기능은 각 통신요청을 포맷하고 특정 사용자에게 Amazon SNS로 푸시 알림을 보낸다.

참고 사이트 - 서버리스 Serverless 아키텍처 파헤치기

3. 서버리스 아키텍처 조사 후 느낀 점

서버리스 아키텍처를 조사하면서 서버리스의 개념, 장단점 그리고 웹과 모바일에 적용한 서버리스 아키텍처에 대해 알아볼 수 있었다.
처음에는 서버리스라는 용어도 생소하고 또 서버리스 아키텍처를 이용해 프로젝트를 어떻게 구현하면 좋을지 막막하다는 생각이 들었는데, 이번에 다양한 블로그들을 참고해서 조사를 하고 나니 우리 팀이 진행할 프로젝트를 어떻게 구현해나가야 할지 조금은 가닥이 잡히는 느낌이었다.
이번 프로젝트가 나에게는 첫번째 프로젝트인 만큼 앞으로 어려운 점들도 또 배워야할 것들도 많이 있을 것이라 생각한다. 그 때마다 조원들과 함께 서로 도와가며 프로젝트를 잘 진행할 수 있었으면 좋겠다🙂