서버리스 컴퓨팅

**서버리스 컴퓨팅**(serverless computing)은 ISO/IEC 22123-2에 따르면 "고객이 애플리케이션 코드를 제공하거나 데이터를 제공하는 것 외에 하드웨어 또는 소프트웨어 리소스를 프로비저닝, 배포 및 관리할 필요 없이 다양한 클라우드 기능 유형을 사용할 수 있는 클라우드 서비스 범주이다. 서버리스 컴퓨팅은 가상화된 컴퓨팅의 한 형태를 나타낸다"라고 정의된다. 서버리스 컴퓨팅은 클라우드 제공업체, 서비스형 함수(FaaS), 관리형 서비스, 도구, 프레임워크, 엔지니어, 이해관계자 및 기타 상호 연결된 요소를 포함하는 광범위한 생태계이다.

## 개요
서버리스는 클라우드 서비스 제공업체가 개발자를 위해 코드를 실행하는 데 여전히 서버가 사용된다는 점에서 잘못된 명칭이다. 서버리스 컴퓨팅의 정의는 시간이 지남에 따라 진화해 왔으며, 다양한 해석을 낳았다. 벤 키호(Ben Kehoe)에 따르면, 서버리스는 엄격한 정의보다는 하나의 스펙트럼을 나타낸다. 강조점은 엄격한 정의나 특정 기술에서 서버리스 사고방식을 채택하는 것으로 옮겨가야 하며, 비즈니스 과제를 해결하기 위해 서버리스 솔루션을 활용하는 데 집중해야 한다.

서버리스 컴퓨팅은 복잡성을 제거하는 것이 아니라 그 중 상당 부분을 운영 팀에서 개발 팀으로 옮긴다. 그러나 운영 팀이 ID 및 액세스 관리(IAM), 네트워킹, 보안 정책, 비용 최적화와 같은 측면을 계속 관리하기 때문에 이러한 전환은 절대적이지 않다. 또한, 애플리케이션을 더 세밀한 구성 요소로 분해하면 관리 복잡성이 증가할 수 있지만, 세밀함과 관리 난이도 사이의 관계가 엄격하게 선형적인 것은 아니다. 추가된 관리 오버헤드보다 이점이 더 큰 최적의 모듈화 수준이 존재하는 경우가 많다.

얀 추이(Yan Cui)에 따르면, 서버리스는 고객 가치를 더 빠르게 전달하는 데 도움이 될 때만 채택해야 한다. 또한 채택하는 동안 조직은 작은 단계를 밟으며 과정에서 위험을 제거해야 한다.

## 과제
서버리스 애플리케이션은 분산 컴퓨팅의 오류에 취약하다. 또한 다음과 같은 오류가 발생하기 쉽다.

* 버전 관리가 간단하다
* 보상 트랜잭션은 항상 작동한다
* 관측 가능성은 선택 사항이다

### 모니터링 및 디버깅
서버리스 애플리케이션의 모니터링 및 디버깅은 분산되고 이벤트 중심적인 특성과 독점적인 환경으로 인해 독특한 어려움을 안겨줄 수 있다. 기존 도구는 서비스 간의 실행 흐름을 추적하는 데 한계가 있을 수 있다. 그러나 분산 추적 도구(예: AWS X-Ray, Datadog), 중앙 집중식 로깅, 클라우드 불가지론적(cloud-agnostic) 관측 플랫폼과 같은 현대적인 솔루션들이 이러한 과제를 완화하고 있다. OpenTelemetry, AI 기반 이상 탐지, 서버리스 전용 프레임워크와 같은 신기술은 가시성과 원인 분석을 더욱 개선하고 있다. 과제는 여전히 남아있지만, 모니터링 및 디버깅 도구의 발전으로 이러한 제한 사항들이 꾸준히 해결되고 있다.

### 보안
OWASP에 따르면 서버리스 애플리케이션은 전통적인 공격의 변형, 안전하지 않은 코드 및 일부 서버리스 전용 공격(지갑 거부 공격 등)에 취약하다. 따라서 위험 요소가 변화했으며 공격 방지를 위해서는 사고방식의 전환이 필요하다.

### 벤더 종속성
서버리스 컴퓨팅은 제3자 서비스로 제공된다. 서버리스 환경에서 실행되는 애플리케이션과 소프트웨어는 기본적으로 특정 클라우드 벤더에 종속(Lock-in)된다. 이러한 문제는 서버리스 컴퓨팅에서 더욱 심화되는데, 추상화 수준이 높아짐에 따라 퍼블릭 벤더는 고객이 기본 환경을 구성할 권한 없이 FaaS 플랫폼에 코드만 업로드할 수 있도록 허용하기 때문이다. 더 중요한 점은 서비스형 백엔드(BaaS)를 포함하는 복잡한 워크플로우를 고려할 때, BaaS 오퍼링은 일반적으로 동일한 제공업체의 FaaS 오퍼링만 기본적으로 트리거할 수 있다는 점이다. 이로 인해 서버리스 컴퓨팅에서의 워크로드 마이그레이션은 사실상 불가능해진다. 따라서 멀티 클라우드 관점에서 서버리스 워크플로우를 설계하고 배포하는 방법을 고려하는 것이 이를 완화할 수 있다.

## 고성능 컴퓨팅
서버리스 컴퓨팅은 최대 메모리, CPU 및 실행 시간 제한을 포함하여 클라우드 제공업체가 부과하는 리소스 제한으로 인해 일부 고성능 컴퓨팅(HPC) 워크로드에는 이상적이지 않을 수 있다. 지속적이거나 예측 가능한 리소스 사용이 필요한 워크로드의 경우, 일괄 프로비저닝된 서버가 서버리스 플랫폼 특유의 종량제 모델보다 비용 효율적일 수 있다. 그러나 서버리스 컴퓨팅은 확장성과 탄력성을 활용하여 특히 고도로 병렬화 가능하고 이벤트 중심적인 특정 HPC 워크로드를 지원할 수 있는 능력이 점점 더 커지고 있다. HPC를 위한 서버리스 컴퓨팅의 적합성은 클라우드 기술의 발전과 함께 계속 진화하고 있다.

## 안티패턴
'모래알(grain of sand)' 안티패턴은 시스템 내에서 과도하게 작은 구성 요소(예: 함수)를 생성하는 것을 말하며, 종종 복잡성 증가, 운영 오버헤드 및 성능 비효율성을 초래한다. '람다 핀볼(Lambda pinball)'은 관련 안티패턴으로, 서버리스 아키텍처에서 함수(예: AWS Lambda, Azure functions)가 파편화된 체인으로 서로를 과도하게 호출할 때 발생할 수 있으며, 이는 지연 시간, 디버깅 및 테스트의 어려움, 관측 가능성 저하로 이어진다. 이러한 안티패턴은 분산된 모놀리스(distributed monolith) 형성와 연관이 있다.

이러한 안티패턴은 공용(public) 인터페이스와 공개(published) 인터페이스를 구분하는 명확한 도메인 경계를 적용함으로써 해결되는 경우가 많다. 공용 인터페이스는 메서드, 클래스, API 엔드포인트 또는 트리거와 같이 기술적으로 접근 가능한 인터페이스이지만 공식적인 안정성 보장이 제공되지 않는다. 반면, 공개 인터페이스는 공식적인 버전 관리, 철저한 문서화, 정의된 폐기(deprecation) 정책 및 하위 호환성 지원을 포함하는 명시적인 안정성 계약을 수반한다. 공개 인터페이스는 또한 여러 버전을 동시에 유지하고 중대한 변경 사항이 도입될 때 공식적인 폐기 프로세스를 준수해야 할 수도 있다.

파편화된 함수 호출 체인은 서버리스 구성 요소(함수)가 복잡한 패턴으로 다른 리소스와 상호 작용하는 시스템에서 자주 관찰되며, 이는 때때로 스파게티 아키텍처나 분산 모놀리스로 설명된다. 반면, 명확한 경계를 보여주는 시스템은 일반적으로 서버리스 구성 요소를 응집력 있는 그룹으로 조직하며, 내부 공용 인터페이스는 구성 요소 간 통신을 관리하고 공개 인터페이스는 그룹 경계를 넘나드는 통신을 정의한다. 이러한 구분은 안정성 보장 및 유지 관리 약속의 차이를 강조하여 종속성 복잡성을 줄이는 데 기여한다.

또한, 과도한 서버리스 함수 체이닝과 관련된 패턴은 개별 함수 대신 네이티브 서비스 통합을 강조하는 아키텍처 전략(함수 없는 사고방식, functionless mindset)을 통해 해결되기도 한다. 그러나 이 접근 방식은 학습 곡선이 더 가파르고, 통합 제한 사항이 동일한 클라우드 벤더 생태계 내에서도 다를 수 있다는 점이 지적된다.

서버리스 데이터베이스에 대한 리포팅은 리포팅 서비스를 위해 데이터를 가져오는 과정에서 바운디드 컨텍스트를 깨뜨리거나 데이터의 적시성을 떨어뜨리거나 혹은 둘 다를 초래할 수 있기 때문에 어려움이 있다. 이는 데이터를 데이터베이스에서 직접 가져오든, HTTP를 통해 가져오든, 배치로 수집하든 상관없이 적용된다. 마크 리처즈(Mark Richards)는 이를 '리치 인 리포팅(reach-in reporting)' 안티패턴이라고 부른다. 이 접근 방식의 가능한 대안은 리포팅 서비스가 데이터를 가져오는(pull) 대신 데이터베이스가 필요한 데이터를 리포팅 서비스로 비동기식으로 밀어넣는(push) 것이다. 이 방법은 서비스와 리포팅 서비스 간의 별도 계약이 필요하고 구현이 복잡할 수 있지만, 높은 데이터 적시성을 유지하면서 바운디드 컨텍스트를 보존하는 데 도움이 된다.

## 원칙
DevSecOps 관행을 채택하면 서버리스 기술의 사용과 보안을 개선하는 데 도움이 될 수 있다.

서버리스 애플리케이션에서는 인프라와 비즈니스 로직 사이의 구분이 모호한 경우가 많으며, 애플리케이션은 일반적으로 여러 서비스에 분산되어 있다. 테스트의 효과를 극대화하기 위해 서버리스 애플리케이션에서는 통합 테스트가 강조된다. 또한, 디버깅과 구현을 용이하게 하기 위해 바운디드 컨텍스트 내에서는 오케스트레이션이 사용되고, 서로 다른 바운디드 컨텍스트 간에는 서비스 안무(choreography)가 사용된다.

단명하는(ephemeral) 리소스는 높은 응집도를 유지하기 위해 일반적으로 함께 보관된다. 그러나 AWS RDS 클러스터나 랜딩 존과 같이 가동 시간이 긴 공유 리소스는 별도의 리포지토리, 배포 파이프라인 및 스택에서 관리되는 경우가 많다.

## 같이 보기
* 클라우드 컴퓨팅
* 서비스형 함수

## 각주

## 추가 문헌
* 
* 
* 


분류:클라우드 컴퓨팅