What is Serverless Architecture
Serverless Overview
서버리스 아키텍처는 서드파티의 BaaS 서비스를 통합하거나 FaaS 플랫폼의 매니지드 임시 컨테이너에서 실행되는 사용자 지정 코드를 포함하는 애플리케이션 설계다. 이런 아키텍처는 이런 아이디어와 SPA와 같은 아이디어를 결합해 사용함으로써 기존의 상시 가동 서버 구성요소에 대한 필요성을 상당 부분 제거한다. 서버리스 아키텍처는 운영 비용, 복잡성, 엔지니어링 리드 타임을 크게 줄일 수 있는 이점이 있지만, 프로바이더 디팬던시, 미성숙한 지원 등에 대한 단점이 있다.
What is Serverless
서버리스에 대한 명확한 정의는 없지만, 대부분의 서버리스는 다음 두 가지 영역을 포괄한다.
- 서버리스는 서버 측 로직과 상태를 관리하기 위해 서드파티 클라우드 호스팅 애플리케이션과 서비스를 상당 부분 또는 완전히 통합하는 애플리케이션을 설명하는데 처음 사용되었다. 예를들어 cloud-accessible databases와 같은 Firebase나 Parse, authentication services인 Auth0, AWS congnito와 같은 BaaS가 그 예다.
- 서버리스의 서버 측 로직은 여전히 애플리케이션 개발자가 작성하지만, 기존 아키텍처와 달리 이벤트에 의해 트리거링 되고 임시적이며, 서드파티 프로바이더가 완전히 관리하는 stateless 컴퓨팅 컨테이너에서 실행되는 애플리케이션을 의미하기도 한다. AWS Lambda와 같은 FaaS가 그 예다.
기존 모놀리식 애플리케이션에서는 모든 흐름, 제어, 보안이 중앙 서버 애플리케이션에 의해 관리되었다. 서버리스에서는 이런 문제에 대한 중앙 조정자가 존재하지 않기 때문에 orchestration방식보다 choreography식의 형태를 선호하며, 각 구성 요소가 보다 아키텍처를 고려한 역할을 수행하는 마이크로서비스 접근 방식에서 흔히 볼 수 있는 아이디어로 구성된다.
이런 접근 방식에는 많은 이점이 있다. 이렇게 구축된 시스템은 전체적으로는 물론 구성 요소의 독립적인 업데이트를 통해 더 유연하고 변경하기 쉬운 경우가 많으며, 우려 사항을 더 잘 분담할 수있고, 비용적 측면에서 상당한 이점이 있다. 반면, 이런 설계는 더 나은 분산 모니터링을 요구하게 되고 기본 플랫폼의 보안 기능에 더 크게 의존된다는 단점이 생긴다.
Dive into FaaS
Basic of functions
기본적으로 FaaS는 자체 서버 시스템이나 수명이 긴 자체 서버 애플리케이션을 관리하지 않고 백엔드 코드를 실행하는 것이다. Long lived server application이 사용하는 컨테이너나 PaaS와 같은 최신 아키텍처와 비교해 핵심적인 차이점이다. FaaS는 long lived server application을 프로비저닝 하거나, 항상 실행시키지 않아도 되는 서버로 변화시킨다.
FaaS 서비스는 특정 프레임워크나 라이브러리에 대한 코딩이 필요하지 않다. 거의 대부분의 경우 일반적으로 언어에서 제공하는 환경측면의 애플리케이션과 동일하다. 하지만 FaaS 함수는 상태 및 실행 기간과 관련해 상당한 아키텍처적 제한이 있다.
또한 직접 실행하는 서버 애플리케이션이 없기 때문에 배포는 기존 시스템과 매우 다르다. FaaS 환경에서 함수에 대한 코드를 업로드하면 프로바이더가 리소스 프로비저닝, VM 인스턴스화, 프로세스 관리 등에 필요한 모든 작업을 수행한다. 수평 확장은 완전히 자동적이고 탄력적으로 프로바이더가 관리한다. 시스템에서 수백개의 요청을 병렬로 처리해야할 때에도 추가 구성 없이 프로바이더가 처리한다. 함수를 실행하는 컴퓨팅 컨테이너는 일시적인 것으로 FaaS 프로바이더가 런타임의 필요성에 따라 생성 및 소멸시킨다. 가장 중요한 점은 FaaS를 사용하면 프로바이더가 모든 리소스 프로비저닝과 할당을 처리하므로 사용자가 클러스터나 VM을 관리할 필요가 전혀 없다는 점이다.
FaaS의 함수는 일반적으로 프로바이더가 정의한 이벤트 유형에 따라 처리된다. AWS의 경우 S3 업데이트, 스케쥴링, 메세지 버스에 추가된 메세지, HTTP에 의해 트리거링된다.
State
FaaS 함수는 로컬 머신의 상태, 즉 메모리 변수에 저장하는 데이터나 로컬 디스크에 쓰여지는 데이터와 관련해 큰 제약을 가지고 있다. 여러 번 호출해도 해당 상태가 유지된다는 보장은 없다. 따라서 FaaS 함수는 stateless로 여겨지기 때문에 state oriented 함수들은 이런 상태들을 데이터베이스, 애플리케이션간 캐시, 오브젝트 스토리지 등으로 외부화 해야한다.
Execution duration
FaaS 함수는 일반적으로 각 호출이 실행될 수 있는 시간 제한이 설정되어 있다. 따라서 장기 작업은 재설계 없이 FaaS로 마이그레이션하기엔 쉽지 않다.
Cold start
FaaS 플랫폼이 각 이벤트 전에 함수 인스턴스를 초기화하는 데는 약간의 시간이 걸린다. 이 시작 지연 시간은 여러 요인에 따라 다르다. AWS 람다에는 함수 인스턴스와 호스트 컨테이너를 재사용하는 warm start, 새 컨테이너 인스턴스를 생성하고 함수 호스트 프로세스를 시작하는 등의 cold start를 제공한다. 시작 지연 시간이 우려되는 것은 cold start 영역이다.
Lambda의 경우 함수 초기화 단계에는 함수 코드 다운로드, 런타임 및 외부 종속성 시작, 함수 초기화 코드 실행 등이 포함된다. 하지만 snapstart와 같이 메모리 / 디스크 상태에 대한 스냅샷을 만들고, 암호화하여 캐싱하면 함수에 대한 시작 성능을 향상시킬 수 있다.
NoOps
NoOps의 의미가 운영이 필요 없다는 뜻은 아니다. 이는 부분적으로 No sysadmin의 형태를 가지고 있다. Ops는 서버 관리 그 이상을 의미한다. 최소한 Ops에는 모니터링, 배포, 보안, 네트워킹, 지원, 프로덕션 디버깅, 확장의 역할을 가지고 있다. 이런 부분들은 서버리스에도 공통적으로 관리해야하는 부분이며 이를 해결하기 위한 새로운 전략이 필요하다. 아직 서버리스는 이런 부분에서 기존 시스템에 비해 덜 성숙하기 때문에 어떤 부분에서는 운영이 더 어렵게 느껴질 수 있다.
Benefits
Reduce operation cost
- 프로바이더가 인프라를 관리하기 떄문에 인프라에 투자하는 비용이 절감된다.
- BaaS를 사용하는 경우 개발 비용도 절감할 수 있다.
- FaaS는 사용한 컴퓨팅 비용에 대해서만 요금을 청구하기 때문에 트래픽 규모와 형태에 따라 큰 이점이 될 수 있다.
Global distribution architecture
- Lambda@Edge와 같은 서비스를 사용하는 경우 한 번의 업로드로 전 세계 100개 이상의 리전에 함수를 배포할 수 있다. 이는 전 세계에 분산된 형태로 기능을 제공할 수 있다는 의미다.
Drawbacks
Vendor problems
- 서버리스의 벤더 종속 문제는 다른 벤더로 옮겨가기 어렵게 되는 문제는 야기한다.
- 시스템 일부에 대한 제어권을 프로바이더에 넘기는 셈이기 때문에 이런 통제력에 대한 상실은 시스템 다운 타임 증가, 비용 변경, 강제 API 업그레이드 등으로 나타날 수 있다.
Server optimization
BaaS는 클라이언트 성능에 맞게 서버 설계를 최적화할 수 없다. 이런 단점을 완화하는 방법은 FaaS나 다른 lightweight server-side pattern을 채택해 특정 로직을 서버로 이동시키는 방법이 있다.
Stateless한 FaaS의 특성 때문에 함수가 충분히 자주 사용되는 경우가 아니라면 인메모리 캐시를 사용하는 등의 최적화는 매우 어렵다.
Execution
- 앞서 서버리스는 실행 시간 제약이 있다고 설명했다. 서버리스는 특정 시간 이상 함수가 실행되면 중단시켜 버리며, 이는 장기 실행 작업에 적합하지 않다는 의미다.
Discovery
- Discovery는 마이크로서비스 아키텍처에서 자주 논의되는 주제로, 서버리스에서는 디스커버리에 대한 논의가 거의 없다. 이는 본질적으로 서버리스가 이벤트 기반의 동작이기 때문이다.
Monitoring and observability
- 컨테이너의 임시적이고 관리적인 특성으로 인해 모니터링은 FaaS에서 매우 까다로운 영역이다. 사용자가 할 수 있는 일은 벤더가 제공하는 능력에 따라 달라진다.