[1] 서버리스에 대한 아주 간략한 개요

Background

기업의 기술적인 발전은 우위를 점하는 데 큰 역할을 하게 된 시대이다. 이런 양상에서 클라우드 서비스가 수요가 높아진 데에는 다음과 같은 이유들이 있다. 

이전엔 모든 기업이 각자의 전산 팀을 구성하여 서버와 서비스를 관리하였다. 각 기업의 소프트웨어 혹은 기술들이 조직에 구내 되어있는 컴퓨터에 설치 및 실행되었고, 이러한 방식을 On-premises 라고 한다. On-premises 환경에서 고민해야 할 것들은 수도 없이 많을 것이다. 예를 들면 다음과 같은 것들이 있다. 

 

- 네트워크 안정성 및 보안

- 현재 비즈니스에 대한 서버의 사양 분석

- 배포, 패치, 백업에 대한 계획 수립

- 서비스의 발전에 따른 프로비저닝

- 운영체제 선택, 하드웨어 선택, 하드웨어 장애 분석 전략 수립

- 정전 등의 위기 상황을 대비한 UPS 적용 등등.. 

 

아무래도 개발을 하는 입장에서, 하드웨어와 운영체제 및 보안 영역까지 신경을 쓰게 되면 프로덕션에 집중하기 힘들게 될 것이다. 이와 같은 고민들을 덜어주고 IT 자원을 관리하고 구성해주는 IaaS (Infrastructure as a Service) 서비스가 등장하였다. Iaas는 서버 자원, IP, Network, Storage, 전력 등등의 인프라를 가상의 환경에서 쉽게 이용할 수 있게 서비스 형태로 제공한다. 덕분에 소기업의 입장에서 서버 관리 인력을 절감하고 쉽게 인프라를 구축할 수 있게 되었다. 

 

그러나, Iaas 만으로는 서버 중단 방지 등의 시스템 관리 및 모니터링, 서버 스케일링 및 보안 등의 책임이 남아있어, 이 부분을 충족하기 위해 Paas (Platform as a service) 가 등장하였다. Paas 에서는 사용자 증가에 대한 서버 스케일링 및 프로비저닝, DB 관리, Business Intelligence 제공 등 빌드 테스트 배포 관리 업데이트의 완전한 웹 어플리케이션의 수명 주기를 지원한다. 결국 개발자들이 서버, 스토리지, 백업 프로비저닝 등 어플리케이션에 구축할 수 있는 즉시 사용 가능한 요소들을 프레임워크의 형태로 제공을 하는 것이다. 

 

여기에서 한단계 나아가, '서버리스'가 등장한다. 서버리스는 이벤트 기반, trigger 방식으로 코드가 실행될 때만 사용료를 지불한다. 인프라 자원의 프로비저닝 및 관리 개념이 사라지고, 모든 규모의 개발 과정에서 필요에 따라 동적으로 기능을 수행하며, 일시적으로 리소스를 활용하여 작업을 수행한다. Faas는 서버리스 아키텍쳐를 통한 서버리스 컴퓨팅 개념으로, 개별 기능-함수-비즈니스 로직- 단위로 배포가 가능하다. 

 

클라우드의 기능별 구분 (출처 : GTPlus 문서[1])

 

What is Serverless Computing

 

서버리스 컴퓨팅은 '개발자'가 서버에 대한 걱정 없이 어플리케이션을 개발하게 해주는 획기적인 기술이다. 

three-tier architecture에서 Client Side Code는 Static Deploy를 제공하는 버킷 서비스로 (Storage as a service)

domain logic은 Function으로 (Function as a Service)

Data Storage tier는 BaaS로 구성될 수 있다. 

이런 서버리스 아키텍쳐에서 대부분의 어플리케이션은 ephemeral stateless container에서 동작한다. ephemeral stateless container는 상태를 저장하지 않고 금세 종료되는 컨테이너로, 특정 이벤트를 수행한 후 바로 종료된다. 이러한 종류의 클라우드 컴퓨팅은 FaaS로 불린다. 

FaaS는 provisioning 혹은 managing 없이 코드를 동작시키며, 어떤 백엔드 코드든 업로드만 하면 Auto Scale, High availability, API와 같이 동작해야한다. 

 

Bare Metal에서 Serverless 까지의 발전단계 (출처 : 논문[2])

 

Pros 

- Scalability -> Provisioning Risk를 없애고 자동적으로 Shrink, Scale 된다

- Low cost -> 사용자는 idle time 에 대해서는 지불하지 않고, set up cost가 없다.

- No Infrastructure maintenance -> 인프라 구축을 직접 하지 않아도 된다

- Easy deployment -> 일반적인 서비스가 CLI및 GUI를 통해 제공되어, 1분 내외로 배포가 가능하다. 

- No Infrastructure security required -> 모든 인프라가 클라우드에서 제공되므로 보안에 신경쓰지 않아도 된다

- run close to the end user -> Lambda@edge와 같은 서비스를 통해 latency를 줄일 수 있다. (원리 알아봐야)

- Faster time to market -> 다른 클라우드 서비스와 융화가 잘 되어, 빠른 시간내로 서비스를 만들 수 있다. 

 

Cons

- Latency -> 초기 실행의 경우 Cold-Start 문제가 있다. 

- Debugging and monitoring -> stateless 하므로 디버깅 자체가 어려울 수 있다. 

- New Technology -> large scale enterprise application에 대한 검증 사례가 아직 없다.

- Security -> 접근성이 좋은 만큼, 해킹에 대한 우려도 만만치 않다. 모니터링 자체도 어렵다. 

 

Reference 

[1] - http://cloud.gtplus.co.kr/wp-content/uploads/IDG_Whitepaper_ServerlessWhitepaper.pdf

[2] - https://www.researchgate.net/publication/331729868_Serverless_Architectures_Review_Future_Trend_and_the_Solutions_to_Open_Problemshttps://www.researchgate.net/publication/331729868_Serverless_Architectures_Review_Future_Trend_and_the_Solutions_to_Open_Problems