서버리스 아키텍처

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

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

서버리스 애플리케이션에서 개발자는 일반적으로 이벤트나 트리거에 반응하여 실행되는 독립된 함수 형태로 코드를 작성하며, 클라우드 제공업체는 실제 사용된 컴퓨팅 자원에 대해서만 비용을 청구합니다. 이러한 접근 방식은 애플리케이션 개발을 단순화하고, 운영 오버헤드를 줄이며, 빠른 확장성을 가능하게 하여 마이크로서비스와 이벤트 기반 애플리케이션에 이상적입니다.

이 페이지에서 다룹니다:

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

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

서버리스 아키텍처는 개발자로부터 서버 관리를 추상화하고, 기본 인프라를 처리하기 위해 클라우드 제공업체에 의존합니다. 일반적으로 작동하는 방식은 다음과 같습니다:

1. 함수 생성: 개발자들은 개별 함수 형태로 코드를 작성하며, 각 함수는 특정 작업이나 서비스를 수행하도록 설계됩니다. 서버리스 아키텍처는 때때로 Function-as-a-Service 또는 서비스형 함수.

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

3. 이벤트 트리거: 함수는 특정 이벤트나 트리거에 반응하여 실행되도록 구성됩니다. 이벤트에는 HTTP 요청(예: API Gateway), 데이터 변경(예: 데이터베이스 업데이트), 타이머, 파일 업로드 또는 기타 항목이 포함될 수 있습니다. 클라우드 제공자는 이벤트 소스를 관리하고 연결된 함수를 자동으로 호출합니다.

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

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

6. 청구: 요금은 함수의 실제 실행 시간과 사용된 리소스를 기반으로 청구됩니다. 실행 횟수와 실행 중에 할당된 CPU 및 메모리 같은 연산 리소스에 대해 비용이 부과됩니다.

7. 무국적상태 서버리스 함수는 일반적으로 상태가 없으며, 이는 호출 간에 정보를 유지하지 않는다는 것을 의미합니다. 필요한 상태나 데이터는 외부, 대개 데이터베이스나 스토리지 서비스에 저장되어야 합니다.

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

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

서버less 개발은 전통적인 개발의 대안이므로, 서버less 애플리케이션을 설계, 배포 및 관리하는 방법을 명확하게 이해하기 위해 다음 용어와 개념을 익혀야 합니다.

기원 서버리스 함수의 실행을 트리거하는 이벤트. 예시로는 HTTP 요청, 데이터베이스 업데이트 또는 예약된 타이머가 있습니다.

기간: 서버리스 함수가 실행되는 데 걸리는 시간으로, 실행 비용을 계산하는 요인이 됩니다.

콜드 스타트 클라우드 공급자가 리소스를 프로비저닝하고 런타임 환경을 설정하는 서버리스 함수의 초기 실행. 콜드 스타트는 웜 스타트에 비해 추가적인 지연 시간을 발생시킵니다.

웜 스타트 런타임 환경이 이미 준비되어 있을 때 서버리스 함수의 후속 실행으로, 콜드 스타트에 비해 더 빠른 응답 시간을 제공합니다.

동시성 제한: 서버리스 플랫폼에서 허용하는 동시 함수 실행의 최대 수입니다. 이 제한은 동시 요청이나 이벤트 처리 능력에 영향을 미칠 수 있습니다.

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

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

무국적상태 서버리스 함수는 일반적으로 상태가 없으며, 이는 호출 간에 데이터를 유지하지 않음을 의미합니다. 필요한 모든 상태는 데이터베이스나 스토리지 서비스에 외부에 저장되어야 합니다.

자원 할당 서버리스 함수의 CPU 또는 메모리와 같은 컴퓨팅 리소스 사양. 이러한 리소스는 개발자가 함수를 정의할 때 종종 선택합니다.

자동 확장: 클라우드 제공업체가 다양한 워크로드를 수용하고 최적의 성능을 보장하기 위해 서버리스 리소스를 자동으로 조정하는 것.

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

서버리스 아키텍처를 사용해야 하는 시기

서버리스 아키텍처는 다목적으로 활용할 수 있지만, 모든 사용 사례에 가장 좋은 선택은 아닙니다. 장기 실행 작업, 높은 연산 요구 사항 또는 지속적인 워크로드가 있는 애플리케이션은 전통적인 서버 기반 아키텍처의 이점을 더 많이 누리는 경우가 많습니다. 애플리케이션에 적합한 선택인지 결정할 때는 서버리스의 특정 요구 사항과 고유한 장점을 반드시 고려해야 합니다.

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

서버리스 아키텍처에 가장 일반적이고 적합한 사용 사례 중 일부는 다음과 같습니다:

웹 및 모바일 앱: 웹 및 모바일 앱 백엔드를 처리하고, 콘텐츠를 제공하며, 사용자 요청을 처리하고, 사용자 인증을 관리합니다.

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

사물인터넷 센서 데이터로 이벤트를 트리거하는 IoT 디바이스의 데이터 처리 및 분석을 효율적으로 관리합니다.

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

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

파일 및 데이터 저장 작업: 클라우드 스토리지 서비스와 연동하여 파일 업로드, 다운로드 및 데이터 처리를 관리합니다.

사용자 인증 및 권한 부여: 사용자 인증 및 권한 부여를 위한 신원 및 접근 관리(IAM) 서비스는 서버리스 함수에 적합합니다.

알림 서비스: 특정 이벤트나 트리거가 발생했을 때 이메일, SMS 또는 푸시 알림과 같은 알림을 전송합니다.

챗봇과 가상 어시스턴트: 기능이 자연어 요청을 처리하고 응답을 생성하는 대화형 인터페이스를 구축합니다.

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

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

마이크로서비스: 더 큰 애플리케이션 내에서 개별 마이크로서비스를 생성하고 관리하여, 간편한 확장과 독립적인 배포가 가능하도록 합니다.

보안 및 규정 준수 서비스: 침입 탐지, 모니터링, 규정 준수 감사와 같은 보안 관련 기능을 구현합니다.

서버리스 대 컨테이너

언뜻 보면 서버리스 아키텍처는 컨테이너 아키텍처나 마이크로서비스 아키텍처와 각각 일정한 유사점을 가지고 있어, 때때로 이들과 혼동되기도 합니다. 사실 서버리스는 이 둘과는 상당히 구별되는 개념이며, 이 글에서는 그 차이점이 무엇인지 설명해 드리겠습니다.

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

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

요약하자면, 서버리스 컴퓨팅은 서버 관리 작업을 추상화하여 이벤트 기반의 단기 작업에 이상적인 반면, 컨테이너는 서버 환경에 대한 제어력을 더 많이 제공하므로 장시간 실행되는 프로세스나 일관된 워크로드에 더 적합합니다. 어느 쪽을 선택할지는 애플리케이션의 구체적인 요구 사항과 기반 인프라에 대한 제어 수준에 따라 달라집니다. 경우에 따라 단일 애플리케이션 내에서도 구성 요소별로 두 기술을 조합하여 사용하기도 합니다.

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

마이크로서비스 마이크로서비스는 애플리케이션을 API를 통해 통신하며 복잡하고 모듈화된 기능을 제공하기 위해 협력하는, 독립적으로 배포 가능한 소규모 서비스들의 집합으로 구성하는 소프트웨어 아키텍처 패턴입니다. 마이크로서비스와 서버리스 아키텍처 간의 혼동은 두 개념 모두 모듈성과 확장성을 중시한다는 점에서 종종 발생합니다. 두 개념의 경계를 더욱 모호하게 만드는 점은, 서버리스 함수가 더 큰 규모의 마이크로서비스 기반 애플리케이션 내에서 마이크로서비스 역할을 수행하며, 두 기술이 종종 함께 사용된다는 사실입니다.

서버리스와 마이크로서비스는 유사점이 있지만, 다음과 같은 측면에서 서로를 구별 짓는 고유한 특징을 가지고 있습니다:

인프라 관리

• 마이크로서비스 – 개발자는 서버 및 컨테이너 오케스트레이션에 대한 제어권을 유지합니다.
• 서버리스 – 서버 관리 작업은 완전히 추상화되어 있으므로, 개발자는 기본 인프라를 직접 다룰 필요가 없습니다.

실행 모델

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

비용 모델

• 마이크로서비스 – 서버 리소스를 프로비저닝하고 유지 관리해야 합니다. 이로 인해 사용량이 적은 기간에도 지속적인 비용이 발생할 수 있습니다.
• 서버리스 – 실제 함수 실행을 기준으로 한 종량제 모델을 따릅니다. 이는 간헐적으로 발생하는 워크로드의 경우 비용 효율성이 더 높을 수 있습니다.

모듈성

• 마이크로서비스 – 애플리케이션은 작고 독립적인 서비스들로 나누어져 있습니다.
• 서버리스 – 개발자는 개별 기능 단위로 코드를 작성합니다.

확장성

• 마이크로서비스 – 각 서비스의 독립적인 확장을 허용합니다.
• 서버리스 – 개별 함수를 자동으로 확장합니다.

서버리스 아키텍처의 이점

서버리스 아키텍처는 다양한 애플리케이션과 사용 사례에 매력적인 선택지가 되도록 하는 광범위한 이점을 제공합니다. 가장 강력한 장점은 다음과 같습니다:

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

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

운영 오버헤드 감소 서버리스는 서버 관리 작업을 추상화하여 개발자가 인프라 유지보수보다는 코드에 집중할 수 있도록 해줍니다. 이는 데브옵스(DevOps) 노력의 필요성을 줄이고 배포와 확장을 단순화합니다.

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

회복력 서버리스 함수는 일반적으로 상태가 없으며, 데이터 지속성을 위해 외부 스토리지 서비스나 데이터베이스에 의존하는 설계를 장려합니다. 이는 더 탄력적이고 결함 허용력이 뛰어난 애플리케이션으로 이어질 수 있습니다.

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

공급업체 종속성 감소: 많은 함수는 특정 벤더에 비교적 종속되지 않도록 설계할 수 있으며, 이를 통해 함수를 쉽게 마이그레이션하거나 서로 다른 클라우드 제공업체의 서비스를 더 쉽게 통합할 수 있습니다. 서버리스의 한계에 관한 다음 섹션에서 살펴보겠지만, 항상 그런 것은 아닙니다.

고가용성: 서버리스 플랫폼은 내장된 이중화 및 페일오버 메커니즘을 통해 고가용성을 제공하도록 설계되었습니다. 이는 장애가 발생한 상황에서도 애플리케이션이 계속해서 액세스 가능하고 응답성을 유지할 수 있도록 보장하는 데 도움이 됩니다.

에너지 및 자원 효율성: 서버리스 플랫폼의 자동 확장 및 자원 관리 기능은 에너지 효율성과 자원 활용도를 향상시켜 환경적 영향을 줄일 수 있습니다.

서버리스 아키텍처의 한계

서버리스 아키텍처는 많은 이점을 제공하지만 한계도 존재합니다. 서버리스의 특정 특성은 장점이나 과제로 나타날 수 있습니다. 특정 애플리케이션에 대해 서버리스를 평가할 때는 다음 사항과 관련된 요구 사항이나 제약 조건을 고려하십시오.

콜드 스타트: 서버리스 함수는 클라우드 제공업체가 새로운 실행 환경을 초기화해야 하기 때문에 처음 호출될 때 지연이 발생할 수 있습니다. 이러한 지연 시간은 일관되게 빠른 응답 시간이 필요한 애플리케이션에 문제가 될 수 있습니다.

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

무국적상태 서버리스 함수는 일반적으로 상태가 없으며, 이는 호출 간에 데이터를 유지하지 않는다는 것을 의미합니다. 이는 (위에서 설명한 것처럼) 복원력을 향상시키는 데 도움이 될 수 있지만, 데이터 지속성을 위해 외부 데이터베이스나 스토리지 서비스를 사용하는 것은 일부 애플리케이션에 복잡성을 더할 수 있습니다.

공급업체 종속: 많은 함수를 특정 벤더에 종속되지 않도록 설계할 수 있지만, 애플리케이션에 특정 플랫폼에 종속된 설정과 통합이 포함되어 있어 다른 클라우드 제공업체로 이전하기 어려운 경우가 있을 수 있습니다.

복잡한 디버깅: 서버리스 아키텍처에서는 함수의 분산된 특성과 직접적인 서버 접근의 부재로 인해 문제 식별 및 해결이 어려워질 수 있으므로, 서버리스 애플리케이션의 디버깅과 문제 해결이 더 까다로울 수 있습니다.

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

서버리스 컴퓨팅 도구

개발자가 선호하는 프로그래밍 언어와 클라우드 서비스 제공업체를 사용하여 서버리스 애플리케이션을 구축, 배포 및 관리할 수 있게 해주는 수많은 서버리스 컴퓨팅 플랫폼과 도구가 있습니다. 다음은 가장 인기 있는 몇 가지 플랫폼과 도구입니다:

플랫폼

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

마이크로소프트의 에저 펑션스 Azure 클라우드 생태계 내의 서버리스 제품입니다. 여러 언어를 지원하고 Azure 서비스와의 통합을 제공하여 Windows 기반 애플리케이션을 위한 강력한 선택지입니다.

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

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

알리바바 클라우드 펑션 컴퓨트 개발자가 알리바바 클라우드 생태계 내에서 애플리케이션을 구축하고 여러 언어를 사용하여 다른 알리바바 클라우드 서비스와 통합할 수 있도록 합니다.

도구

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

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

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

결론

서버리스 아키텍처는 개발자가 서버 관리가 아닌 코드 작성에 집중할 수 있도록 해주기 때문에 웹 및 모바일 애플리케이션, IoT, 실시간 데이터 처리 및 기타 일반적인 사용 사례에서 인기가 있습니다. 관리 책임은 AWS Lambda, Azure Functions, Google Cloud Functions와 같은 클라우드 제공업체에 위임되어 기본 인프라를 처리하고 워크로드 변화에 맞춰 리소스를 자동으로 확장할 수 있습니다. 하지만 서버리스가 모든 사용 사례에 이상적인 것은 아니며, 특정 워크로드나 장기 실행 작업은 전통적인 서버 기반 방식이 더 적합할 수 있습니다.

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

클라우드 컴퓨팅을 활용한 서버리스 아키텍처
카우치베이스 2023 예측 – 엣지 컴퓨팅, 서버리스 등
아카펠라 앱 서비스(BaaS)
방문하기 개념 허브 데이터베이스와 관련된 다른 주제들에 대해 배우기 위해서.