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

서버리스란

서버리스(serverless)란 개발자가 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델이다.

서버리스 모델에도 서버가 존재하긴 하지만, 애플리케이션 개발에서와 달리 추상화되어 있다. 클라우드 제공업체가 서버 인프라에 대한 프로비저닝, 유지 관리, 스케일링 등의 일상적인 작업을 처리하며, 개발자는 배포를 위해 코드를 컨테이너에 패키징하기만 하면 된다.

서버리스 애플리케이션은 배포되고 나면 필요에 따라 자동으로 스케일 업되거나 스케일 다운된다. 퍼블릭 클라우드 제공업체의 서버리스 오퍼링은 일반적으로 이벤트 기반 실행 모델을 통해 온디맨드로 미터링된다. 그러므로 서버리스 기능이 유휴 상태일 때는 아무런 비용도 들지 않는다.

 

서버리스 컴퓨팅 서비스

서버리스 컴퓨팅 서비스는 일반적으로 서비스로서의 백엔드(Backend-as-a-Service, BaaS)와 서비스로서의 기능(Function-as-a-Service, FaaS)이라는 두 그룹으로 나뉜다. 

BaaS는 개발자가 다양한 제3사 서비스와 애플리케이션에 액세스할 수 있게 해주는데 예를 들어, 클라우드 제공업체는 인증 서비스와 추가 암호화, 클라우드 액세스 가능한 데이터베이스 및 상세한 데이터 사용량을 제공할 수 있다. BaaS를 활용하는 경우 서버리스 기능은 일반적으로 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API)를 통해 호출된다.

개발자가 서버리스를 언급하는 경우에는 FaaS 모델을 가리키는 경우가 더욱 일반적이다. FaaS의 경우 개발자는 사용자 정의 서버 측 로직을 작성할 수 있지만, 이러한 로직은 클라우드 서비스 제공업체가 전체를 관리하는 컨테이너에서 구동된다. 

주요 퍼블릭 클라우드 공급업체에서는 하나 이상의 FaaS 오퍼링을 제공한다. 여기에는 Amazon Web Services의 AWS Lambda, Microsoft Azure의 Azure Functions, Google Cloud의 여러 오퍼링, IBM Cloud의 IBM Cloud Functions 등이 포함된다. 

 

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

마이크로 서비스의 장점으로는 

• 복원력: 애플리케이션이 분할되어 있기 때문에 애플리케이션 중단 또는 충돌의 한 부분이 애플리케이션의 나머지 부분에 반드시 영향을 미치지는 않는다.
• 선택적 확장성: 전체 애플리케이션을 확장하는 대신 사용량이 많은 마이크로서비스만 확장 가능
• 더 쉬운 기능 추가 또는 업데이트: 전체 애플리케이션 스택을 업데이트하는 대신 한 번에 하나씩 기능을 롤아웃하거나 업데이트할 수 있다.
• 개발자를 위한 유연성: 마이크로서비스는 서로 다른 언어로 작성될 수 있으며 각각 고유한 라이브러리가 있다.

서버리스의 장점

• 낮은 비용 - 기존 클라우드 제공 업체의 백엔드 서비스(서버 할당)는 사용자에게 사용하지 않은 공간이나 CPU 대기 시간에 대해 비용을 종종 청구하기 때문에 서버리스 컴퓨팅은 일반적으로 매우 비용 효과적이다.
• 간편한 확장성 - 서버리스 아키텍처를 사용하는 개발자는 코드 확장을 위한 정책을 걱정하지 않아도 됩니다. 서버리스 업체가 요청에 따라 확장을 모두 처리한다.
• 간단한 백엔드 코드 - 개발자는 FaaS를 사용하여 API 호출 같은 단일 목적을 독립적으로 실행하는 간단한 기능을 만들 수 있다.
• 시간 단축 - 서버리스 아키텍처는 시장 진출 시간을 크게 줄일 수 있다. 복잡한 배포 프로세스를 이용하여 버그 수정과 새로운 기능을 배포하는 대신 개발자는 필요에 따라 코드를 추가하고 수정할 수 있다.

서버리스의 단점

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

둘을 비교만 해봐도 공통점이 존재하는데 간편하고 선택적으로 확장 할 수있으며 코드를 추가하고 업데이트를하는 배포 방식에서도 시간이 단축되게한다 또한 언어에 종속 받지않게 개발이 용이한 장점들이 있다

 

마이크로 서비스와 서버리스 기능의 차이점은 무엇인가?

MSA로 개발을 해도 결국에 도메인 종류별로 나눠놨기 때문에 그래도 적은단위의 관리가 아니다 하지만 서버리스는 그보다 작은 함수단위로 관리하게된다 이말은 즉 중요한 로직이아니며 계속 불려지는 함수가 아닌 것들을 서버리스로 대체하는게 옳다고 생각이든다 그렇기 때문에 서버리스를 고민할때는 가볍고 어느 서비스와도 유연하게 사용할 수있는지 고민해봐야하며 개발자가 애플리케이션을 분할한 방법에 따라 마이크로서비스는 기능과 같을 수도 있고(하나의 작업만 수행함을 의미) 여러 기능으로 구성될 수도 있다.

 

서버리스의 무상태성

하지만 서버리스가 언제 어디에나 좋은 것은 아니다. 실제로 오랜 시간 억지로 적용하면 시험 운영보다 더 많은 오류가 발생하는 것으로 보인다. 서버리스는 특히 스테이트풀(Stateful) 애플리케이션에는 최악의 아이디어이다.

스테이트리스(Stateless) 애플리케이션은 모든 트랜잭션을 처음부터 완료된 것처럼 수행한다. 현재의 트랜잭션에 사용하는 이전에 저장된 정보 같은 것은 없다. 반대로 스테이트풀 애플리케이션은 한 세션의 동작으로부터 클라이언트 데이터를 저장해 다른 세션에 사용한다. 이렇게 저장된 데이터를 흔히 애플리케이션의 상태, 즉 스테이트(State)라고 부른다.

스테이트풀 애플리케이션이 서버리스에 맞지 않는 이유는 분명하다. 서버리스 애플리케이션은 여러 서비스, 즉 기능으로 구성되어 있는데, 이들 기능은 짧게 실행되고 스테이트가 없다. 전통적인 의미의 트랜잭션에 이를 적용하면, 서버리스 애플리케이션은 실행된 이후에는 아무 것도 유지하지 않는 것이다.

서버리스 시스템은 애플리케이션 개발과 배치에 이런 방식으로 접근한다. 특정 기능을 실행하는 데 필요한 자원만을 할당해 처리한 다음에는 자원을 다시 공유 풀에 반환한다.

서버리스 시스템과 서버리스 개발자 모두에게 상태를 유지하는 것은 너무나 복잡한 일이다. 이런 식으로 애플리케이션은 실행 서비스로 깔끔하게 나뉘어 있으며, 서로 간에 독립적이고 느슨하게 연결되어 있다.

참고자료

https://www.cloudflare.com/ko-kr/learning/serverless/why-use-serverless/

https://www.itworld.co.kr/news/124572

IDG 블로그 | 서버리스가 전혀 맞지 않는 애플리케이션

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

서버리스란?