📌 Action Items
- 서버리스의 의미는 무엇인가요?
- 마이크로서비스와 서버리스는 어떤 관계가 있나요?
- 서버리스는 마이크로서비스의 어떠한 특징들을 반영하고 있나요?
- AWS가 제공하는 서버리스 서비스들엔 어떤 것들이 있나요?
- 마이크로서비스는 꼭 서버리스로 구현되어야 하나요?
- 서버리스의 특징 중 하나인 무상태성(Stateless)는 무엇을 의미하나요?
- 서버리스 컴퓨팅의 장단점은 무엇인가요?
📌 서버리스란?
- 제일 처음 서버리스라는 단어를 접하면 '서버가 없다'라고 인식할 수 있다. 하지만, 정확한 의미의 서버리스는 버 또는 클러스터 프로비저닝, 패치 적용, 운영 체제 유지 관리 및 용량 프로비저닝과 같은 인프라 관리 작업을 직접 하는것이 아닌, 클라우드 공급자가 대신 해주는 것을 의미한다.
- 서버가 없는것이 아니다.
- 서버리스를 사용하면 서버를 고려하지 않고 애플리케이션과 서비스를 구축하고 실행할 수 있다.
📌 마이크로서비스와 서버리스는 어떤 관계가 있는가?
-
마이크로서비스 아키텍처의 경우, 애플리케이션이 독립적인 구성 요소로 구축되어 각 애플리케이션 프로세스가 서비스로 실행된다. 이러한 서비스는 경량 API를 사용하여 잘 정의된 인터페이스를 통해 통신한다.
-
서비스는 비즈니스 기능을 위해 구축되며 서비스마다 한 가지 기능을 수행합니다.
-
서비스가 독립적으로 실행되기 때문에 애플리케이션의 특정 기능에 대한 수요를 충족하도록 각각의 서비스를 업데이트, 배포 및 확장할 수 있다.
마이크로서비스는 반드시 서버리스로 구축되는것은 아니다. 하지만 서버리스로 구축했을때, 마이크로서비스의 아래와 같은 이점을 극대화 할 수 있다.
- 민첩성
마이크로서비스는 해당 서비스를 소유한 독립적인 소규모 팀 조직을 육성하는 역할을 합니다. 팀은 충분한 이해를 바탕으로 하는 소규모 컨텍스트 내에서 활동하며 더 독립적이면서 신속하게 업무를 수행할 수 있습니다. 덕분에 개발 주기 시간이 단축됩니다. 그리고 조직의 집계 처리량 측면에서 큰 이점을 누리게 됩니다.
- 유연한 확장성
마이크로서비스의 경우 각 서비스가 지원하는 애플리케이션 기능의 수요를 충족하도록 해당 서비스를 독립적으로 확장할 수 있습니다. 따라서 팀은 필요한 인프라의 규모를 적절히 조절하고, 기능의 비용을 정확하게 측정하고, 서비스의 수요가 급증하는 경우에도 가용성을 유지할 수 있습니다.
📌 AWS가 제공하는 서버리스 서비스
AWS에서 제공하는 컴퓨팅 서버리스는 ECS와 람다로 예를 들 수 있다.
AWS ECS를 이용하면 Docker 컨테이너를 지원하는 확장성과 성능이 뛰어난 컨테이너 관리 서비스로서, 서비스를 사용하여 Amazon EC2 인스턴스의 관리형 클러스터에서 애플리케이션을 손쉽게 실행할 수 있다.
AWS 람다를 이용하면 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있습니다. 코드를 업로드하기만 하면, Lambda에서 높은 가용성으로 코드를 실행 및 확장하는 데 필요한 모든 것을 관리한다.
이외에도 어플리케이션 통합을 위한 SQS, SNS, API Gateway 등이 있으며, 데이터 스토어 기능을 위한 S3, DynamoDB, Aurora Serverless 등이 있다.
📌 서버리스 특징 중 무상태성(Stateless)이란?
서버리스의 무상태성 특징은 특히 FaaS(Function As a Service)에서 도드라진다.
서버리스는 기본적으로 현재 상태에 대한 데이터를 저장하지 않으므로, 이벤트에 대해 항상 동일한 기능(함수)을 수행한다.
이러한 특징 때문에, 인증이 필요한 기능과 같이 상태를 유지해야 하는(stateful) 서비스를 서버리스로 구현할때는 JWT와 같은 기능을 이용하여 이를 보완한다.
📌 서버리스 컴퓨팅의 장단점
장점
- 낮은 비용
기존 클라우드 제공 업체의 백엔드 서비스(서버 할당)는 사용자에게 사용하지 않은 공간이나 CPU 대기 시간에 대해 비용을 종종 청구하기 때문에 서버리스 컴퓨팅은 일반적으로 매우 비용 효과적입니다. - 간편한 확장성
서버리스 아키텍처를 사용하는 개발자는 코드 확장을 위한 정책을 걱정하지 않아도 됩니다. 서버리스 업체가 요청에 따라 확장을 모두 처리합니다. - 간단한 백엔드 코드
개발자는 FaaS를 사용하여 API 호출 같은 단일 목적을 독립적으로 실행하는 간단한 기능을 만들 수 있습니다. - 시간 단축
서버리스 아키텍처는 시장 진출 시간을 크게 줄일 수 있습니다. 복잡한 배포 프로세스를 이용하여 버그 수정과 새로운 기능을 배포하는 대신 개발자는 필요에 따라 코드를 추가하고 수정할 수 있습니다.
단점
-
콜드 스타트(Cold start)
서버리스 기능을 가상 프라이빗 클라우드에서 구동할 때 발생하는 문제로, 지연이 생기거나 기동 시간이 오래 걸릴 수 있다. 고등학교 때 타던 뷰익 자동차의 시동을 생각하면 비슷하다. 게다가 개발 언어에 따라 지연도 달라진다. 벤치마크를 해보면 흥미로운 결과를 얻을 수 있는데, 파이썬이 가장 빠르고 닷넷과 자바가 가장 느리다. 툴을 사용해 지연 시간을 분석해 워크로드에 미칠 영향을 파악할 수 있다. 서버리스에 인프라 모두를 걸었다면, 이들 툴을 살펴보기 바란다. -
거리 지연
서버리스 기능이 최종 사용자와 얼마나 멀리 떨어져 있느냐에 따라 다르다. 상식적인 사실이지만, 사용자 대부분은 미국에 있는 기업이 서버리스 기능을 아시아에서 구동하기도 한다. 여기서 문제는 대역폭이 아니다. 따라서 이들 기업은 유용성보다는 편의성을 찾는다. 그리고 아시아에 있는 관리자처럼 부정적인 영향을 전혀 고려하지 않는다. 데이터가 그 데이터를 사용하는 핵심 서버리스 기능과는 다른 리전에 있을 때도 거리 문제가 생긴다. 이런 좋지 않은 결정은 보통 퍼블릭 클라우드에 프로세스를 분산할 때 나온다. 파워포인트에서는 멋져 보이지만, 실용적이지는 않다. -
성능이 부족한 런타임 환경 구성
간과하기 쉬운 부분이다. 서버리스 시스템은 사전 정의된 일련의 메모리와 컴퓨트 구성이 있는데, 예를 들어 ‘메모리 구동 64MB~3008MB’ 같은 식이다. CPU는 사용되는 메모리의 양을 기반으로 상관관계 알고리즘을 이용해 할당된다. 보통 메모리 설정이 낮으면 저렴하지만, 서버리스 시스템이 메모리와 CPU 모두 적게 할당되기 때문에 성능상의 반대급부가 있기 마련이다.
레퍼런스 참조
