서버리스 컴퓨팅이란 무엇인가요?

애플리케이션을 빌드할 때 개발자는 일반적으로 처리 및 저장을 위한 리소스 정의, 패치 적용, 부하 분산 등과 같이 코드 배포를 위해 수행해야 하는 다양한 기타 서버 관리 작업을 수행합니다. 이러한 모든 추가 항목으로 인해 프로비저닝 시간이 길어지고 운영 오버헤드가 증가하여 결국 개발팀의 속도가 느려집니다. 

서버리스 컴퓨팅은 개발자에게 보이지 않는 '서버리스' 환경을 제공하므로 서버나 애플리케이션 실행에 필요한 모든 것에 대해 생각할 필요가 없습니다. 대신 서비스 제공업체는 유휴 용량에 대한 비용 청구 없이 코드를 실행하고 요구사항을 충족할 수 있는 리소스를 확보할 수 있도록 백그라운드에서 모든 작업을 수행합니다. 

서버리스는 집에 물을 공급하는 것과 같습니다. 직접 우물을 파고 수질을 테스트하고 집으로 물을 연결하는 데 필요한 모든 외부 배관을 설치하고 유지관리할 수 있습니다. 또는 도시의 주 상수도에 연결할 수 있습니다. 수도꼭지를 돌려 필요할 때 정확히 원하는 만큼 물을 얻을 수 있습니다. 그러면 시에서 정확한 물 사용량에 대해 매달 청구서를 발행해 줍니다. 

마찬가지로 클라우드 제공업체는 서버리스 앱을 실행하는 데 필요한 인프라 리소스와 런타임 환경을 자동으로 가동하고 실행이 완료되면 자동으로 0으로 다시 축소합니다. 일반적으로 실행 시간 동안 리소스를 기준으로 요금이 청구됩니다. 하지만 이는 서비스와 공급업체에 따라 달라질 수 있습니다. 

하지만 다른 유형의 클라우드 컴퓨팅은 사용한 만큼만 지불하는 방식으로 주문형 리소스를 제공하지 않나요? Infrastructure as a Service(IaaS) 및 Platform as a Service(PaaS)와 같은 클라우드 서비스 모델도 컴퓨팅 리소스에 대한 주문형 액세스를 제공하는 것은 사실입니다. 

하지만 할당된 클라우드 인프라는 사용하지 않더라도 활성 상태로 유지됩니다. 서버 용량을 확장하거나 사용자 수요에 따라 확장 또는 축소하도록 애플리케이션을 구성하는 것도 개발자의 책임입니다. 

반면 서버리스 아키텍처는 이벤트 기반입니다. 이 모델에서 제공업체는 이벤트가 코드 실행을 트리거하고 요청에 따라 즉시 자동으로 확장되는 경우에만 리소스를 제공합니다.

서버리스 클라우드 컴퓨팅에는 일반적으로 Function as a Service(FaaS)와 Backend as a Service(BaaS)라는 두 가지 유형의 서비스가 있습니다. 

• FaaS는 요청에 대한 응답으로 애플리케이션 로직을 실행하는 데 필요한 컴퓨팅 리소스를 제공합니다. 이러한 로직(또는 함수)는 클라우드 서비스 제공업체가 완전히 관리하는 컨테이너에서 실행됩니다. 서버리스 애플리케이션은 일반적으로 이벤트에 대한 응답으로 하나의 작업을 수행하는 단일 함수로 구분됩니다. 
• BaaS는 인증 서비스, 데이터베이스 관리, 클라우드 스토리지, 푸시 알림, 호스팅과 같은 웹 또는 모바일 애플리케이션의 전체 백엔드 기능을 서비스로 제공합니다. 또한 BaaS를 사용하면 서버, 컨테이너, 가상 머신을 관리할 필요가 없습니다. 

개발 단계에서 '서버리스'라는 용어는 일반적으로 FaaS 제품을 설명하는 데 사용됩니다. 하지만 FaaS는 기술적으로 서버리스 기술의 하위 집합입니다. 서버리스 컴퓨팅에는 최종 사용자로부터 서버 관리, 구성, 확장, 청구를 추상화하는 모든 유형의 서비스가 포함됩니다. 여기에는 데이터베이스, 스토리지, 이벤트 스트리밍, 메시징, API 게이트웨이가 포함될 수 있습니다. 

가장 일반적이고 새롭게 떠오르는 서버리스 컴퓨팅의 예는 다음과 같습니다.

• 사용 사례: 다양한 비즈니스 애플리케이션(예: CRM에서 마케팅 자동화) 간에 리드/고객을 원활하게 동기화
• 서버리스 솔루션: HTTP 트리거 Cloud Run 함수는 소스 시스템(예: Salesforce)에서 웹훅을 수신하고, 데이터를 변환하고, 대상 시스템의 API(예: HubSpot)를 호출합니다. 이때 사용자 인증 정보에 Secret Manager를 사용하는 경우가 많습니다.
• Google Cloud 서버리스 제품: Cloud Run Functions 및 Secret Manager

• 사용 사례: 정기 보고서 생성 및 배포 자동화
• 서버리스 솔루션: Cloud Scheduler 작업이 Pub/Sub를 통해 매일 Cloud Run 함수를 트리거합니다. 이 함수는 데이터 웨어하우스(예: BigQuery)를 쿼리하고, 데이터를 처리하여 보고서로 만들고, 이메일 API를 통해 전송합니다.
• Google Cloud 서버리스 제품: Cloud Scheduler, Pub/Sub, Cloud Run Functions, BigQuery

• 사용 사례: 유휴 컴퓨팅 리소스를 자동으로 식별하고 관리하여 클라우드 비용 절감
• 서버리스 솔루션: 매일 밤 Cloud Scheduler 작업이 Pub/Sub를 통해 Cloud Run 함수를 트리거합니다. 이 함수는 Compute Engine API와 Cloud Monitoring을 사용하여 유휴 인스턴스를 식별하고 자동으로 중지하거나 삭제하며 Cloud Logging에 작업을 로깅합니다.
• Google Cloud 서버리스 제품: Cloud Scheduler, Pub/Sub, Cloud Run Functions, Cloud Monitoring, Cloud Logging

• 사용 사례: 즉각적인 인사이트와 작업을 위해 대량의 스트리밍 데이터(예: 사용자 활동)를 처리 및 보강
• 서버리스 솔루션: 사용자 클릭스트림 이벤트가 Pub/Sub로 스트리밍됩니다. Cloud Run 함수(또는 Cloud Run 서비스)가 이러한 이벤트를 사용하고 Firestore의 데이터로 보강한 다음 보강된 데이터를 다른 Pub/Sub 주제에 게시하여 BigQuery에서 실시간 분석을 수행하거나 맞춤형 추천을 제공합니다.
• Google Cloud 서버리스 제품: Pub/Sub, Cloud Run Functions, Cloud Run, Firestore, BigQuery

• 사용 사례: 코드 변경 시 마이크로서비스의 빌드, 테스트, 배포 자동화
• 서버리스 솔루션: Cloud Build 트리거가 Git 저장소(예: Cloud Source Repositories)를 모니터링합니다. 코드가 커밋되면 Cloud Build가 테스트를 실행하고, 컨테이너 이미지를 Artifact Registry에 빌드하고, 새 버전을 Cloud Run에 자동으로 배포합니다.
• Google Cloud 서버리스 제품: Cloud Build, Cloud Run, Artifact Registry, Cloud Source Repositories

• 사용 사례: 업로드 시 최적화된 이미지 변형(예: 썸네일, 다양한 형식)을 자동으로 생성
• 서버리스 솔루션: Cloud Storage 버킷에 새 이미지가 업로드되면 Cloud Run 함수가 활성화됩니다. 이 함수는 이미지를 처리(크기 조정, 형식 변환)하고, 새 버전을 Cloud Storage에 다시 저장하고, Firestore에서 메타데이터를 업데이트합니다.
• Google Cloud 서버리스 제품: Cloud Storage, Cloud Run Functions, Firestore

• 사용 사례: Llama 3.1, Gemma 2, Mistral 등의 LLM을 사용하여 실시간 AI 추론 수행
• 서버리스 솔루션: Cloud Run은 Gemini API, Vertex AI 엔드포인트 또는 GPU 지원 Cloud Run 서비스에서 호스팅되는 모델과 같은 AI 모델과 통합됩니다. 또한 확장 가능한 API 엔드포인트 역할을 하고 AI 에이전트를 호스팅할 수 있습니다.
• GCP 서버리스 제품: Cloud Run, Cloud Storage, Firestore

서버리스 컴퓨팅의 가장 큰 단점 중 하나는 비교적 새로운 기술이라는 것입니다. 따라서 모든 잠재적 사용 사례를 충족하기에 아직 적합하지 않습니다. 

서버리스 컴퓨팅이 계속 발전함에 따라 현재의 일부 약점은 시간이 지남에 따라 해결될 수 있다는 점도 분명합니다. 특히 서버리스의 오픈소스를 구현하고 클라우드 서비스의 개방성을 높여 다양한 플랫폼과 환경에서 솔루션을 이식할 수 있는 방법을 찾기 위해 많은 노력을 기울이고 있습니다. 

• 제한된 사용 사례 적합성: 서버리스 아키텍처는 장기 실행 프로세스 또는 매우 짧은 지연 시간 요구사항과 같은 특정 요구사항이 있는 애플리케이션에 항상 적합한 것은 아닙니다.
• 성능 제약: 서버리스 함수는 콜드 스타트(초기 실행 지연)가 발생할 수 있으며 실행 시간과 메모리에 제한이 있을 수 있습니다.
• 공급업체 종속: API 및 구성의 차이로 인해 클라우드 제공업체 간에 서버리스 애플리케이션을 마이그레이션하는 것이 복잡할 수 있습니다.
• 서버 가시성 감소: 개발자가 기본 인프라를 파악하기가 어려워 성능 문제를 해결하거나 리소스 사용률을 최적화하기가 힘듭니다.
• 느린 시작: 서버리스 함수는 때때로 함수 호출에 지연이 발생하는 '콜드 스타트'를 경험할 수 있으며, 이는 지연 시간에 영향을 미칠 수 있습니다.