서버리스와 마이크로서비스를 파헤쳐보자.

서버리스 의미

서버리스는 서버가 없다는 뜻이 아닌, 개발자가 서버를 관리할 필요없이 Application을 빌드하고 실행할 수 있도록 하는 Cloud native 개발 모델이다. 서버가 존재하지만, 직접적인 관리가 필요하지 않기 때문에 추상화되었다고도 볼 수 있다. 

마이크로서비스와 서버리스의 관계

AWS의 Fargate를 사용한 서버리스 마이크로서비스

마이크로서비스는 독립적인 작은 서비스 단위로 배포와 업데이트가 가능하며, API 게이트웨이가 사용자 또는 마이크로 서비스간 API 통신을 지원하는 것이 특징이다.

서버리스는 별도의 서버 구축필요 없이 어플리케이션 개발과 배포를 지원하는 클라우드 컴퓨팅 서비스다. 서버리스는 마이크로서비스 구조의 개발을 위해서 아주 적합한 형태의 컴퓨팅 서비스다.

여러 Function을 구성하고 이들을 독립적인 API로 구성해서 배포하면 마이크로서비스 형태의 어플리케이션이 될 수 있다.

서버리스는 마이크로서비스의 어떠한 특징들이 있을까

마이크로 서비스의 특징은 Resilience, Selective scalability, Easier to add or update features, Flexibility for delelopers가 있다. (https://www.cloudflare.com/ko-kr/learning/serverless/glossary/serverless-microservice/)

• Resilience(복원력): 응용 프로그램이 분할되어 있기 때문에, 다른 프로그램의 영향을 받지않는다.
• Selective scalability(선택적 확장성): 사용량이 많은 마이크로 서비스만 부분적으로 확장이 가능하다.
• Easier to add or update features(손쉬운 기능 추가 및 업데이트): 전체 어플리케이션을 업데이트하지 않고 선택된 기능만 롤아웃하거나 업데이트가 가능하다.
• Flexibility for developers(개발자를 위한 유연성): 마이크로서비스는 여러 언어로 작성될 수 있으며 각각 고유 라이브러리가 있다.

서버리스 또한 마이크로 서비스와 비슷한 특징을 지니고 있다. (https://www.ingeno.ca/blog/the-characteristics-of-serverless-architecture, www.megazone.com/techblog_20200612_best-practices-for-organizing-larger-serverless-applications/)

• It is Inherently Distributed(분산되어 있다) : 분산은 프로젝트를 하위 서비스로 분할하고 다른 컴퓨터와 서버에 할당하는 것을 말한다. 서버리스 컴퓨팅은 상태 비저장이기 때문에 모든 데이터는 BaaS에 보관되어야 하므로, 아키텍처는 본질적으로 분산되어 있다.
  
  서버리스 아키텍처는 클라우드 데이터 센터의 일부 지역에서 장애가 발생해도 작동 중인 다른 가용 영역을 사용할 수 있다.
  
  
• It Has Elasticity(유연하다) : 서버리스는 높은 탄력성, 유연성을 가지고 있어 확장성 면에서 아주 유리하다. 개발자가 리소스를 수동으로 확장해야하는 레거시 서버와 달리, 이 과정을 자동으로 수행할 수 있다. 또한, 특정 시나리오에서 사용한 만큼만 비용을 청구하여 운영 비용도 크게 줄일 수 있다.
  
  
• 3rd Party Dependencies(종속적이지 않다): 대부분의 프로젝트는 사용하는 언어나 프레임워크에 빌드되지 않은 라이브러리에 의존한다. 그러나 Serverless는 더 적은 코드와 패키지의 종속성으로 구성되기 때문에 테스트가 쉬워지고 코드 라이브러리 유지 관리의 필요성이 줄어든다.

AWS가 제공하는 서버리스 서비스

https://www.youtube.com/serverlessland

• AWS Lambda : 서버를 프로비저닝하거나 관리하지 않아도 코드를 실행할 수 있는 이벤트 기반 컴퓨팅 서비스
• AWS Fargate : ECS와 EKS가 연동되는 서버리스 컴퓨팅 엔진(Container)
• Amazon EventBridge : AWS와 기존 시스템에서 이벤트 기반 application을 대규모로 구축할 때 사용하는 서버리스 이벤트 버스
• AWS Step Functions : 여러 AWS 서비스를 쉽게 비즈니스 어플리케이션으로 배열할 수 있게 해주는 시각적 워크플로우 오케스트레이터
• Amazon S3 : 모든 데이터를 저장하고 보호할 수 있도록 설계된 객체 스토리지 서비스
• Amazon DynamoDB : 10밀리초미만의 성능을 제공하는 key-value 문서 DB 서비스

기타 서버리스 제품은 다음 링크에서도 확인할 수 있다(https://aws.amazon.com/ko/serverless/)

마이크로서비스는 서버리스가 굳이 필요한가

모놀리식 아키텍처가 서버 가상화 수준에 적합했다면, MSA는 컨테이너 오케스트레이션에 적합하며 서버리스 아키텍처의 경우 컨테이너 오케스트레이션 수준보다 더 작은 단위의 함수 관리에 적합하다.

클라우드 컴퓨팅의 발전은 IaaS에서 PaaS로 그리고 서버리스로 흘러간다. 애플리케이션 발전 패러다임은 하나의 거대한 덩어리, 모놀리식(Monolithic)에서 잘게 쪼개지는 형태인 마이크로서비스 아키텍처(MSA)로 간다. 여기서 서버리스가 중심으로 자리를 잡고 있다.

서버리스는 애플리케이션을 구동할 때 기본적으로 클라우드 위에서 구동되므로 유연하게 규모를 조정할 수 있다. 클라우드 컴퓨팅의 일종인 서버리스는 애플리케이션을 자동으로 확장할 수도 있고, 개별 서버 단위가 아닌 사용 단위(처리량, 메모리)를 설정/해제해 용량을 조정할 수 있다.

서버리스는 가용성 또한 자동화를 기반으로 애플리케이션을 실행하는 서비스에서 기본적으로 제공된다. 그렇기에 개발자들은 더더욱 애플리케이션 개발과 운영에만 몰두할 수 있다.

+ 서버리스 사용이 부적절한 경우

- 코드가 직접 클라우드에서 실행되는 환경이라 호환성이 떨어질 가능성이 높은 경우
- 장시간 지속적으로 실행돼야하는 어플리케이션 (서버리스 컴퓨팅은 빨리 실행될 수 있는 작은 단위 작업에 적합)

https://www.comworld.co.kr/news/articleView.html?idxno=49816 

[커버스토리] 모놀리식에서 MSA로…다음은 ‘서버리스’다 - 컴퓨터월드

서버리스의 무상태성(Stateless)

스테이트리스 프로세스 또는 애플리케이션은 격리된 것으로 간주됩니다. 과거 트랜잭션에 대한 정보 또는 참조가 저장되지 않기 때문입니다. 각 트랜잭션은 모두 처음부터 시작됩니다. 스테이트리스 애플리케이션은 하나의 서비스 또는 기능을 제공하며, 콘텐츠 전달 네트워크(CDN), 웹, 프린트 서버를 사용해 이러한 단기 요청을 처리합니다. 

이러한 스테이트리스 트랜잭션의 가장 일반적인 예시는 검색창에 질문을 입력하고 엔터키를 누르는 형식으로 진행되는 온라인 검색입니다. 트랜잭션이 우발적으로 중단되거나 종료되면 새롭게 시작하면 됩니다. 스테이트리스 트랜잭션은 단일 요청에 대해 하나의 응답이 나오므로, 자동판매기와 비슷합니다. 

https://www.redhat.com/ko/topics/cloud-native-apps/stateful-vs-stateless

스테이트풀(Stateful)과 스테이트리스(Stateless) 차이 및 비교

서버리스 컴퓨팅의 장단점

[장점]

• 서버리스 컴퓨팅은 개발자 생산성을 높이고 운영 비용을 줄일 수 있다. 서버 프로비저닝 및 관리와 같은 일상 업무의 부담을 줄여, 개발자가 애플리케이션에 더 많은 시간을 할애할 수 있다. 
• 서버리스는 개발자가 프로비저닝하기 위한 작업에 필요한 인프라를 명시적으로 설명할 필요를 줄여줌으로써 DevOps 도입을 지원한다.  
• 제3사 BaaS 오퍼링의 모든 구성 요소를 통합해 애플리케이션 개발을 더욱 간소화할 수도 있다.
• 서버리스 모델에서 운영 비용이 낮출 수 있다. 항상 자체 서버를 실행하고 관리하는 대신 필요한 만큼 클라우드 기반 컴퓨팅 시간에 대해 비용을 지불하기 때문이다.

[단점]

• 자체 서버를 실행하지 않거나 자체 서버측 로직을 제어하지 않다.
• 클라우드 제공업체는 자사 구성 요소가 상호작용하는 방법을 엄격히 제한할 수 있어, 사용자 시스템의 유연성과 커스터마이징 수준에 영향을 주게 된다. BaaS 환경의 경우 개발자는 코드 제어 권한이 없는 서비스에 의존해야 할 수 있다.
• IT 스택의 이러한 측면에 대한 제어 권한을 이전하면 벤더 종속성 문제도 발생할 수 있다. 제공업체를 변경하면 새로운 벤더 사양에 맞추기 위해 시스템을 업그레이드하는 비용이 발생할 수도 있다.

https://www.redhat.com/ko/topics/cloud-native-apps/what-is-serverless