[Cloud] 9주차. 서버리스(Serverless) 서비스의 이해

⭐ 서버리스(Serverless)

서버리스(Serverless)는 말 그대로 서버가 전혀 없다는 의미가 아니라, 서버의 구축과 관리 부담을 클라우드 제공업체가 대신 맡아주는 클라우드 컴퓨팅 방식이다. 개발자는 서버 운영 환경을 직접 관리하기보다, 애플리케이션의 핵심 기능을 구현하는 데 집중할 수 있다.

 

서버리스 환경에서는 개발자가 코드를 함수 단위로 작성해 클라우드 플랫폼에 배포한다. 이후 HTTP 요청, 데이터베이스 변경, 파일 업로드와 같은 특정 이벤트가 발생하면 해당 함수가 자동으로 실행된다. 함수 실행이 끝나면 사용된 리소스는 자동으로 해제되며, 비용은 실제로 실행된 시간과 사용량을 기준으로 청구된다.

 

즉, 서버리스는 인프라 관리의 복잡성을 줄이고, 필요한 순간에만 코드를 실행할 수 있도록 해주는 효율적인 개발 방식이라고 할 수 있다.

 

서버리스 아키텍처의 주요 구성 요소

• 함수 (Functions): 서버리스 아키텍처의 핵심으로, 특정 작업을 수행하는 작은 코드 단위
• 이벤트 소스 (Event Sources): 함수를 실행시키는 트리거. HTTP 요청, 데이터베이스 변경, 파일 업로드 등이 해당됨
• 서비스형 백엔드 (BaaS): API를 통해 접근할 수 있는 데이터베이스, 인증, 파일 스토리지 등의 백엔드 기능
• API 게이트웨이: 클라이언트 요청을 적절한 서버리스 함수로 연결하고 관리하는 역할

 

장점

• 비용 효율성: 함수가 실행된 시간과 사용한 컴퓨팅 자원에 따라 비용이 청구되므로, 유휴 상태의 낭비가 없음
• 자동 스케일링: 트래픽이 늘어나면 자동으로 확장되고, 줄어들면 자동으로 축소됨
• 유지보수 간소화: 서버 관리 부담이 없어 개발자가 비즈니스 로직에만 집중 가능
• 빠른 개발 및 배포: 인프라 설정 없이 바로 코드 작성과 배포가 가능

 

단점

• 콜드 스타트: 함수가 처음 실행되거나 오랜만에 실행될 경우, 실행 환경을 새로 준비하느라 응답이 느려지는 현상이 발생할 수 있음
  • 반대로 실행 환경이 이미 준비된 상태를 Warm Start라고 하며, 이 경우엔 빠르게 실행됨
• 벤더 종속성: 특정 클라우드 제공업체의 서비스에 의존하게 될 수 있음
• 장기 실행 작업에 부적합: 대부분의 플랫폼은 함수 실행 시간에 제한을 두고 있어 오래 걸리는 작업에는 맞지 않음
• 디버깅과 모니터링의 어려움: 분산 환경 특성상 문제 추적이 복잡할 수 있음

 

활용 사례

• 이벤트 기반 처리: 비동기 작업 처리나 실시간 데이터 스트림 처리에 적합
• 마이크로서비스: 작고 독립적인 단위로 나뉜 서비스 개발에 유용
• 변동성 높은 워크로드: 트래픽 변동이 큰 애플리케이션에 효과적
• 빠른 프로토타이핑: 새로운 아이디어를 빠르게 구현하고 테스트하는 데 적합

 

⭐ 서버리스 서비스 제공업체

클라우드 3대 벤더인 Azure, AWS, GCP 모두 서버리스 서비스를 제공하고 있다.

 

1. Azure Functions
   • Microsoft Azure의 서버리스 컴퓨팅 서비스
   • Azure 생태계(Cosmos DB, Service Bus 등)와 긴밀하게 통합되어 있어 작업 자동화나 마이크로서비스 구축에 적합
2. AWS Lambda
   • Amazon Web Services의 서버리스 플랫폼
   • 다양한 트리거에 응답하여 코드를 실행할 수 있으며, S3, DynamoDB 등 다른 AWS 서비스와 연동이 용이
3. Google Cloud Functions
   • Google Cloud Platform의 서버리스 솔루션
   • Cloud Storage, Pub/Sub 등과 연동하여 특정 이벤트에 반응하는 함수를 실행할 수 있음

 

 

⭐ Azure Functions

주요 특징

• 서버리스 아키텍처: 서버 인프라를 직접 관리하지 않고 코드 실행에만 집중 가능
• 이벤트 기반 실행: HTTP 요청, 타이머, 메시지 큐, 파일 변경 등 다양한 이벤트를 트리거로 함수를 실행
• 다양한 언어 지원: C#, JavaScript, Python, Java, PowerShell 등 여러 언어로 함수 작성 가능
• 자동 확장성: 요청 수에 따라 자동으로 확장되어 대규모 작업도 처리 가능
• Azure 서비스 통합: Storage, Cosmos DB, Service Bus 등 다양한 Azure 서비스와 쉽게 연결 가능

코드는 Azure Portal에서 직접 작성하거나, VS Code에서 작성 후 업로드하는 방식으로 배포할 수 있다.

 

주요 호스팅 옵션

1. 사용 계획 (Consumption Plan)

• 함수 실행 횟수, 실행 시간, 사용한 컴퓨팅 리소스에 따라 비용 발생
• 자동 확장 지원하는 기본 서버리스 호스팅
• * Cold Start 발생 가능

2. 프리미엄 계획 (Premium Plan)

• 사전 준비된 인스턴스를 통해 Cold Start를 줄이거나 방지 가능
• 강력한 리소스와 가상 네트워크 지원 제공

3. 전용 계획 (App Service Plan)

• App Service 리소스를 공유하거나 항상 활성 상태로 실행 가능
• * 정해진 용량의 리소스를 사용하므로 함수가 실행되지 않아도 비용 발생

4. Flex 사용량 계획 (Flex Consumption Plan)

• 사전 인스턴스 프로비전과 빠른 확장을 지원하며 비용 효율적

 

SLA (Service Level Agreement)

서비스 제공자와 고객 간에 서비스의 품질, 가용성, 책임 등을 명시한 계약.
가동 시간, 응답 시간, 문제 발생 시 대응 방법, 보상 조건 등이 포함.
서비스의 기대치를 명확히 정의해 신뢰를 형성하고 책임 소재를 분명히 하기 위해 사용.

 

Azure Functions는 99.95%의 SLA를 보장한다.

 

⭐ Azure Functions Trigger와 Binding

Trigger (트리거)

함수의 실행을 시작시키는 이벤트다. 각 함수에는 하나의 트리거만 존재할 수 있으며, 주요 트리거 유형은 다음과 같다.

• 스토리지: Blob Storage, Cosmos DB 등 저장소나 데이터베이스에서 데이터가 생성·변경되는 이벤트 감지
• 이벤트: Event Grid, Event Hubs 등에서 발생하는 이벤트 처리
• HTTP: 웹 요청이나 웹훅(Webhook)을 통해 함수 실행
• 큐: Queue Storage나 Service Bus 큐에 쌓인 메시지 처리
• 타이머: 지정된 시간 또는 일정한 시간 간격에 따라 함수를 주기적으로 실행

 

Binding (바인딩)

함수에 외부 리소스 또는 서비스를 연결하는 방식이다. 트리거와 달리 여러 개의 바인딩을 가질 수 있으며, 방향에 따라 두 가지로 나뉜다.

• 입력 바인딩 (Input Binding): 외부 서비스의 데이터를 함수 안으로 가져와 함수에서 사용할 수 있도록 연결하는 방식
  • ex. Azure SQL 입력 바인딩 → SQL DB에서 데이터를 조회하여 함수의 입력 매개변수로 전달
• 출력 바인딩 (Output Binding): 함수가 처리한 결과를 외부 서비스로 내보내거나 저장하도록 연결하는 방식
  • ex. Azure SQL 출력 바인딩 → 함수 실행 결과를 Azure SQL Database에 저장