서버리스 아키텍처

서버리스 아키텍처란 무엇인가요?

서버리스 아키텍처는 개발자가 기존 서버를 관리하지 않고 애플리케이션을 빌드하고 실행하는 클라우드 컴퓨팅 모델입니다. 서버는 여전히 존재하지만 클라우드에 있으며 클라우드 제공업체가 인프라, 확장 및 리소스 할당을 자동으로 처리합니다.

서버리스 애플리케이션의 경우 개발자는 일반적으로 이벤트나 트리거에 따라 실행되는 격리된 함수로 코드를 작성하고 클라우드 제공업체는 실제 사용된 컴퓨팅 리소스에 대해서만 요금을 청구합니다. 이 접근 방식은 애플리케이션 개발을 간소화하고 운영 오버헤드를 줄이며 빠른 확장이 가능하므로 마이크로서비스 및 이벤트 중심 애플리케이션에 이상적입니다.

이 페이지에서 다룹니다:

• 서버리스 아키텍처의 작동 방식
• 서버리스 아키텍처의 주요 개념
• 서버리스 아키텍처를 사용해야 하는 경우
  
• 서버리스 아키텍처의 이점
  
• 서버리스 아키텍처의 한계
• 서버리스 컴퓨팅 도구
• 결론

서버리스 아키텍처의 작동 방식

서버리스 아키텍처는 서버 관리를 개발자로부터 분리하고 기본 인프라를 처리하기 위해 클라우드 제공업체에 의존합니다. 일반적으로 작동하는 방식은 다음과 같습니다:
1. 함수 생성: 개발자는 코드를 개별 함수로 작성하며, 각 함수는 특정 작업이나 서비스를 수행하도록 설계됩니다. 서버리스 아키텍처를 서비스형 기능(Function-as-a-Service) 또는 FaaS.

2. 기능 배포: 함수는 클라우드 서비스 제공업체가 제공하는 서버리스 플랫폼에 패키지화되어 배포됩니다. 가장 일반적인 서버리스 플랫폼은 AWS Lambda, Azure 함수 및 Google Cloud 함수입니다.

3. 이벤트 트리거: 함수는 특정 이벤트 또는 트리거에 대한 응답으로 실행되도록 구성됩니다. 이벤트에는 HTTP 요청(예: API 게이트웨이), 데이터 변경(예: 데이터베이스 업데이트), 타이머, 파일 업로드 등이 포함될 수 있습니다. 클라우드 제공업체는 이벤트 소스를 관리하고 관련 함수를 자동으로 호출합니다.

4. 자동 스케일링: 이벤트가 발생하면 서버리스 플랫폼은 워크로드를 수용하기 위해 기본 리소스를 자동으로 확장합니다. 기능에 요청이 갑자기 급증하는 경우 클라우드 공급자가 더 많은 리소스를 프로비저닝합니다.

5. 실행: 이벤트가 함수를 트리거하면 서버리스 플랫폼은 해당 함수에 대한 컨테이너 또는 런타임 환경을 초기화합니다. 함수 내의 코드가 실행되고 필요한 리소스나 데이터에 액세스할 수 있습니다. 함수가 작업을 완료한 후 컨테이너는 짧은 시간 동안 워밍업 상태를 유지하여 후속 요청을 더 빠르게 실행할 수 있습니다.

6. 청구: 청구는 함수에 사용된 실제 실행 시간과 리소스를 기준으로 합니다. 실행 건당, 그리고 실행 중에 할당된 CPU 및 메모리와 같은 컴퓨팅 리소스에 대한 요금이 청구됩니다.

7. 무국적자: 서버리스 함수는 일반적으로 상태 저장소가 없으므로 호출 간에 정보를 보관하지 않습니다. 필요한 상태나 데이터는 데이터베이스나 스토리지 서비스 등 외부에 저장해야 합니다.

8. 로그 및 모니터링: 서버리스 플랫폼은 일반적으로 기본 제공 로깅 및 모니터링 도구를 제공하여 개발자가 성능을 추적하고 해당 기능의 문제를 해결할 수 있도록 합니다.

서버리스 아키텍처의 주요 개념

서버리스 개발은 기존 개발의 대안이므로 서버리스 애플리케이션을 설계, 배포 및 관리하는 방법을 명확하게 이해하려면 다음 용어와 개념을 숙지해야 합니다:
호출: 서버리스 함수의 실행을 트리거하는 이벤트입니다. HTTP 요청, 데이터베이스 업데이트 또는 예약된 타이머 등이 그 예입니다.

기간: 서버리스 함수가 실행되는 데 걸리는 시간으로, 실행 비용을 계산할 때 고려하는 요소입니다.

콜드 스타트: 클라우드 제공업체가 리소스를 프로비저닝하고 런타임 환경을 설정하는 서버리스 기능의 초기 실행입니다. 콜드 스타트는 웜 스타트에 비해 지연 시간이 추가로 발생합니다.

따뜻한 시작: 런타임 환경이 이미 준비된 상태에서 서버리스 함수를 실행하면 콜드 스타트에 비해 응답 시간이 빨라집니다.

동시 접속자 수 제한: 서버리스 플랫폼에서 허용되는 최대 동시 함수 실행 횟수입니다. 이 제한은 동시 요청 또는 이벤트를 처리하는 기능에 영향을 미칠 수 있습니다.

시간 초과: 서버리스 함수의 실행에 허용되는 최대 기간입니다. 함수가 이 제한을 초과하면 강제로 종료되며 결과가 반환되지 않을 수 있습니다.

이벤트 소스: 서버리스 함수를 트리거하는 이벤트의 출처입니다. 이벤트 소스의 예로는 Amazon S3 버킷, API 게이트웨이, 메시지 대기열, 데이터베이스 업데이트 등이 있습니다.

무국적자: 서버리스 함수는 일반적으로 상태 저장소가 없으므로 호출 간에 데이터를 유지하지 않습니다. 필요한 상태는 데이터베이스나 스토리지 서비스에 외부에 저장해야 합니다.

리소스 할당: 서버리스 함수에 대한 CPU 또는 메모리와 같은 컴퓨팅 리소스의 사양입니다. 이러한 리소스는 개발자가 함수를 정의할 때 선택하는 경우가 많습니다.

자동 스케일링: 클라우드 공급자가 서버리스 리소스를 자동으로 조정하여 다양한 워크로드를 수용하고 최적의 성능을 보장합니다.

서버리스 데이터베이스: 서버리스 데이터베이스는 탄력적으로 확장할 수 있는 데이터베이스로, 운영되는 인프라를 노출하지 않습니다. 카우치베이스 카펠라™ DBaaS 는 완전히 관리되는 서버리스 데이터베이스의 예입니다.

서버리스 아키텍처를 사용해야 하는 경우

서버리스 아키텍처는 다목적이지만 모든 사용 사례에 적합한 것은 아니며, 장기 실행 작업, 높은 연산 요구 사항 또는 일관된 워크로드가 있는 애플리케이션은 기존 서버 기반 아키텍처의 이점이 더 많은 경우가 많습니다. 서버리스가 애플리케이션에 적합한 선택인지 결정할 때는 구체적인 요구 사항과 서버리스의 고유한 강점을 고려해야 합니다.

서버리스 아키텍처 사용 사례

서버리스 아키텍처의 가장 일반적이고 가장 적합한 사용 사례는 다음과 같습니다:
웹 및 모바일 앱: 웹 및 모바일 앱 백엔드 처리, 콘텐츠 제공, 사용자 요청 처리, 사용자 인증 관리.

API: RESTful 및 GraphQL API를 자동 확장하고 다른 서비스와 쉽게 통합하세요.

IoT: 센서 데이터로 이벤트를 트리거하는 IoT 디바이스의 데이터 처리 및 분석을 효율적으로 관리하세요.

실시간 데이터 처리: 클릭스트림 분석, 로그 처리, 이벤트 중심 분석과 같은 실시간 데이터 스트림을 처리합니다.

일괄 처리: 데이터 ETL(추출, 변환, 로드), 보고서 생성, 데이터 정리와 같은 주기적 또는 온디맨드 배치 작업을 실행하세요.

파일 및 데이터 저장 작업: 클라우드 스토리지 서비스와 상호 작용하여 파일 업로드, 다운로드, 데이터 조작을 관리하세요.

사용자 인증 및 권한 부여: 사용자 인증 및 권한 부여를 위한 ID 및 액세스 관리(IAM) 서비스는 서버리스 기능에 적합합니다.

알림 서비스: 특정 이벤트 또는 트리거에 대한 응답으로 이메일, SMS 또는 푸시 알림과 같은 알림 및 경고를 전송합니다.

챗봇 및 가상 비서: 함수가 자연어 요청을 처리하고 응답을 생성하는 대화형 인터페이스를 구축하세요.

데이터 및 이미지 처리: 최소한의 사용자 상호작용이 필요한 이미지 크기 조정, 형식 변환, 데이터 변환과 같은 작업을 수행합니다.

예약된 작업: 데이터 백업, 보고서 생성, 데이터베이스 유지 관리와 같은 정기적인 작업을 자동화하세요.

마이크로서비스: 대규모 애플리케이션 내에서 개별 마이크로서비스를 생성하고 관리하여 손쉽게 확장하고 독립적으로 배포할 수 있습니다.

보안 및 규정 준수 서비스: 침입 탐지, 모니터링, 규정 준수 감사 등 보안 관련 기능을 구현하세요.

서버리스와 컨테이너

언뜻 보기에 서버리스 아키텍처는 컨테이너 아키텍처 또는 마이크로서비스 아키텍처와 특정 유사점을 공유하기 때문에 혼동되기도 합니다. 사실 서버리스는 이 두 가지 아키텍처와는 상당히 다르며, 그 차이점을 설명해 드리겠습니다.

무엇 컨테이너 와 서버리스의 공통점은 둘 다 개발자가 호스트 환경을 추상화하여 애플리케이션 코드를 배포할 수 있다는 점입니다. 그러나 서버리스는 서버 관리를 완전히 추상화하는 반면, 컨테이너는 개발자가 인프라를 더 잘 제어하여 자체 서버 환경을 관리할 수 있다는 점이 주요 차이점 중 하나입니다.

가벼운 가상화 형태인 컨테이너는 애플리케이션과 애플리케이션의 종속성을 공유 운영 체제에서 독립적인 인스턴스로 실행되는 격리된 일관된 환경에서 패키징합니다. 컨테이너는 개발에서 프로덕션에 이르기까지 다양한 환경에서 애플리케이션이 일관되게 작동하도록 보장하는 방법을 제공하며, 소프트웨어를 패키징하고 배포하는 표준화된 방법을 제공합니다. 컨테이너는 일반적으로 장기 실행되며 단일 컨테이너 내에 여러 프로세스를 포함할 수 있습니다.

간단히 말해, 서버리스 컴퓨팅은 서버 관리를 추상화하여 이벤트 중심의 단기간 작업에 이상적인 반면, 컨테이너는 서버 환경을 더 잘 제어할 수 있으며 장기 실행 프로세스 및 일관된 워크로드에 더 적합합니다. 애플리케이션의 특정 요구 사항과 기본 인프라에 대한 제어 수준에 따라 둘 중 하나를 선택해야 합니다. 경우에 따라서는 단일 애플리케이션 내에서 서로 다른 구성 요소에 대해 두 기술을 조합하여 사용하기도 합니다.

서버리스 대 마이크로서비스

마이크로서비스 는 API를 통해 통신하고 함께 작동하여 복잡한 모듈식 기능을 제공하는 독립적으로 배포 가능한 소규모 서비스 모음으로 애플리케이션을 구성하는 소프트웨어 아키텍처 패턴입니다. 마이크로서비스와 서버리스 아키텍처는 모듈성과 확장성을 공통적으로 강조하기 때문에 종종 혼동되는 경우가 있습니다. 또한 서버리스 기능이 더 큰 마이크로서비스 기반 애플리케이션 내에서 마이크로서비스의 역할을 하는 등 함께 사용되는 경우가 많기 때문에 그 경계가 더욱 모호해집니다.

서버리스와 마이크로서비스는 유사점에도 불구하고 다음과 같은 영역에서 고유한 특성을 가지고 있어 차별화됩니다:

인프라 관리

• 마이크로 서비스 - 개발자는 서버 및 컨테이너 오케스트레이션을 계속 제어할 수 있습니다.
• 서버리스 - 서버 관리가 완전히 추상화되어 개발자는 기본 인프라를 다루지 않습니다.

실행 모델

• 마이크로 서비스 - 전용 서버 인스턴스에서 지속적으로 실행됩니다.
• 서버리스 - 함수는 이벤트나 트리거에 대한 응답으로 실행됩니다. 이러한 차이로 인해 서버리스 애플리케이션에서 콜드 스타트가 발생할 수 있으므로 응답 시간에 차이가 발생할 수 있습니다.

비용 모델

• 마이크로 서비스 - 서버 리소스를 프로비저닝하고 유지 관리해야 합니다. 이로 인해 사용량이 적은 기간에도 지속적인 비용이 발생할 수 있습니다.
• 서버리스 - 는 실제 기능 실행에 기반한 종량제 모델을 따릅니다. 이는 산발적인 워크로드에 더 비용 효율적일 수 있습니다.

모듈화

• 마이크로 서비스 - 애플리케이션은 작은 독립 서비스로 나뉩니다.
• 서버리스 - 개발자는 개별 기능 단위로 코드를 작성합니다.

확장성

• 마이크로 서비스 - 각 서비스를 독립적으로 확장할 수 있습니다.
• 서버리스 - 개별 기능을 자동으로 확장합니다.

서버리스 아키텍처의 이점

서버리스 아키텍처는 많은 애플리케이션과 사용 사례에 매력적인 선택이 될 수 있는 다양한 이점을 제공합니다. 가장 매력적인 장점은 다음과 같습니다:

자동 스케일링: 서버리스 아키텍처 플랫폼은 들어오는 워크로드에 따라 리소스를 자동으로 확장하거나 축소합니다. 따라서 애플리케이션이 다양한 수준의 트래픽을 처리할 수 있어 수동 개입 없이도 높은 가용성과 성능을 제공할 수 있습니다.

비용 효율성: 서버리스를 사용하면 함수 실행 중에 실제로 사용된 컴퓨팅 리소스에 대해서만 비용을 지불합니다. 유휴 시간과 관련된 비용이 발생하지 않으므로 특히 예측할 수 없거나 산발적인 트래픽이 발생하는 워크로드에 비용 효율적입니다.

운영 오버헤드 감소: 서버리스는 서버 관리 작업을 추상화하여 개발자가 인프라 유지 관리가 아닌 코드에 집중할 수 있도록 합니다. 따라서 DevOps 작업의 필요성이 줄어들고 배포 및 확장이 간소화됩니다.

더 빠른 개발: 서버리스는 서버와 인프라를 관리할 필요가 없으므로 개발 프로세스를 가속화합니다. 개발자는 코드를 빠르게 반복하고 배포할 수 있으므로 애플리케이션의 출시 기간을 단축할 수 있습니다.

복원력: 서버리스 함수는 일반적으로 상태가 저장되지 않으므로 데이터 지속성을 위해 외부 스토리지 서비스나 데이터베이스에 의존하는 설계를 촉진합니다. 이는 보다 탄력적이고 내결함성 있는 애플리케이션으로 이어질 수 있습니다.

로깅 및 모니터링 기능이 내장되어 있습니다: 서버리스 플랫폼은 종종 모니터링 및 로깅을 위한 기본 제공 도구를 제공하여 개발자가 성능을 추적하고 문제를 해결하며 애플리케이션 동작에 대한 인사이트를 얻을 수 있도록 지원합니다.

공급업체 종속성 감소: 많은 기능이 비교적 공급업체에 구애받지 않도록 설계되어 마이그레이션하거나 다른 클라우드 제공업체의 서비스를 통합하기가 더 쉽습니다. 다음 섹션에서 서버리스 제한 사항에 대해 살펴보겠지만 항상 그런 것은 아닙니다.

고가용성: 서버리스 플랫폼은 이중화 및 장애 조치 메커니즘이 내장되어 있어 고가용성을 제공하도록 설계되었습니다. 따라서 장애가 발생하더라도 애플리케이션에 대한 액세스 및 응답성을 유지할 수 있습니다.

에너지 및 리소스 효율성: 서버리스 플랫폼의 자동 확장 및 리소스 관리는 에너지 효율과 리소스 활용도를 개선하여 환경에 미치는 영향을 줄일 수 있습니다.

서버리스 아키텍처의 한계

서버리스 아키텍처는 많은 장점을 제공하지만 한계도 있습니다. 서버리스의 특정 특성은 장점 또는 과제로 나타날 수 있습니다. 특정 애플리케이션에 대해 서버리스를 평가할 때는 다음과 관련된 요구 사항이나 제약 조건을 고려하세요:
콜드 스타트: 서버리스 함수는 클라우드 제공업체가 새로운 실행 환경을 초기화해야 하므로 함수를 처음 호출할 때 지연이 발생할 수 있습니다. 이러한 지연 시간은 일관되게 빠른 응답 시간이 필요한 애플리케이션의 경우 문제가 될 수 있습니다.

리소스 제약: 서버리스 플랫폼은 메모리 및 실행 시간 제한과 같은 리소스 제약을 부과합니다. 이러한 제약은 컴퓨팅 집약적인 작업이나 장기 실행 프로세스가 필요한 애플리케이션에 제한이 될 수 있습니다.

무국적자: 서버리스 함수는 일반적으로 상태 저장소가 없으므로 호출 간에 데이터를 보존하지 않습니다. 이는 복원력을 향상시키는 데 도움이 될 수 있지만(위에서 설명한 대로), 데이터 지속성을 위해 외부 데이터베이스나 스토리지 서비스를 사용하면 일부 애플리케이션에 복잡성을 더할 수 있습니다.

공급업체 종속: 많은 기능이 비교적 공급업체에 구애받지 않도록 설계될 수 있지만, 애플리케이션에 일부 플랫폼별 구성 및 통합이 있어 다른 클라우드 공급업체로 이동하기 어려울 수 있습니다.

복잡한 디버깅: 서버리스 아키텍처에서는 기능의 분산된 특성과 서버에 직접 액세스할 수 없기 때문에 서버리스 애플리케이션의 디버깅 및 문제 해결이 더 까다로울 수 있으며, 문제를 식별하고 해결하기가 어려울 수 있습니다.

제한된 로컬 테스트: 로컬 테스트는 클라우드의 실행 환경을 완전히 복제하지 못할 수 있기 때문에 서버리스 함수를 로컬에서 개발하고 테스트하는 것은 어려울 수 있습니다. 개발자는 철저한 테스트를 위해 서버리스 플랫폼에 함수를 배포해야 하는 경우가 많습니다.

서버리스 컴퓨팅 도구

개발자가 선호하는 코딩 언어와 클라우드 서비스 제공업체를 사용하여 서버리스 애플리케이션을 빌드, 배포 및 관리할 수 있는 수많은 서버리스 컴퓨팅 플랫폼과 도구가 있습니다. 가장 인기 있는 몇 가지를 소개합니다:

플랫폼

아마존의 AWS 람다 는 다양한 프로그래밍 언어를 지원하며 다른 AWS 서비스와 원활하게 통합됩니다. 또한 AWS는 RESTful API를 생성하고 Lambda 함수를 트리거하기 위한 API 게이트웨이를 제공합니다.

Microsoft의 Azure 기능 는 Azure 클라우드 에코시스템 내의 서버리스 제품입니다. 여러 언어를 지원하고 Azure 서비스와의 통합을 제공하므로 Windows 기반 애플리케이션을 위한 강력한 선택이 될 수 있습니다.

Google의 클라우드 기능 는 여러 프로그래밍 언어를 지원하며 다른 Google Cloud 서비스와 잘 통합되므로 Google Cloud 에코시스템 내에서 애플리케이션을 구축하는 데 적합합니다.

IBM 클라우드 기능 는 Apache OpenWhisk 프레임워크를 기반으로 하며 다양한 언어를 사용하여 IBM Cloud 서비스와 통합할 수 있습니다.

Alibaba 클라우드 함수 컴퓨팅 를 통해 개발자는 여러 언어를 사용하여 Alibaba Cloud 에코시스템에서 애플리케이션을 빌드하고 다른 Alibaba Cloud 서비스와 통합할 수 있습니다.

도구

Netlify 는 정적 웹사이트 호스팅에 가장 잘 알려진 플랫폼이지만 백엔드 서비스, API 및 워크플로우를 구축하기 위한 서버리스 기능도 제공합니다.

OpenFaaS 는 컨테이너 기반 함수를 위한 오픈 소스 서버리스 프레임워크입니다. 이를 통해 Docker 컨테이너를 사용하여 서버리스 함수를 빌드하고 실행할 수 있습니다.

Fission 는 여러 언어를 지원하며 Kubernetes 클러스터에 쉽게 배포할 수 있도록 설계된 또 다른 오픈 소스 Kubernetes 네이티브 서버리스 프레임워크입니다.

결론

서버리스 아키텍처는 개발자가 서버 관리 대신 코드 작성에 집중할 수 있기 때문에 웹 및 모바일 애플리케이션, IoT, 실시간 데이터 처리 및 기타 일반적인 사용 사례에 널리 사용됩니다. 관리 책임은 AWS Lambda, Azure Functions 또는 Google Cloud Functions와 같은 클라우드 제공업체에 오프로드되므로 기본 인프라를 처리하고 워크로드 변화에 따라 리소스를 자동으로 확장할 수 있습니다. 그러나 서버리스가 모든 사용 사례에 이상적인 것은 아니며, 특정 워크로드나 장기 실행 작업은 기존 서버 기반 접근 방식이 더 적합할 수 있습니다.

서버리스 아키텍처 및 관련 기술에 대해 자세히 알아보려면 다음 리소스를 확인하세요:

클라우드 컴퓨팅을 사용한 서버리스 아키텍처
Couchbase 2023년 예측 - 엣지 컴퓨팅, 서버리스 등
아카펠라 앱 서비스(BaaS)
방문하기 개념 허브 를 클릭하여 데이터베이스와 관련된 다른 주제에 대해 알아보세요.