서버리스 컴퓨팅 이해하기: 인프라 관리 단순화

인프라 관리는 현대 소프트웨어 개발 워크플로에 복잡성을 추가합니다. 서버를 가동 상태로 유지하고, 보안 업데이트를 처리하며, 리소스를 확장하는 것은 데브옵스 팀의 귀중한 시간을 소모합니다. 서버리스 컴퓨팅에서는 모든 인프라 운영이 서비스 공급업체에 의해 처리됩니다. 따라서 서버리스는 개발 팀이 인프라 관리에 너무 많은 시간을 쓰지 않고 코드 작성에 집중할 수 있게 합니다.

이 기사는 서버리스 컴퓨팅이 무엇인지, 다양한 클라우드 배포 모델과 어떻게 비교되는지 설명합니다. 또한 서버리스의 장단점을 탐구하고 일반적인 사용 사례에 대해 이야기합니다.

서버리스 컴퓨팅이란?

서버리스 컴퓨팅은 서버 프로비저닝과 인프라 관리 없이 클라우드에서 코드를 배포하고 실행하는 방법입니다. 이름에도 불구하고 서버리스는 여전히 코드 실행을 위해 클라우드 또는 물리 서버에 의존합니다. 그러나 개발자는 기본 인프라에 신경 쓰지 않습니다. 이는 서버리스 공급업체에 맡겨지며, 사용자 대신 필요한 컴퓨팅 리소스를 동적으로 할당하고 관리합니다.

개발자에게 이는 서버 관리, 유지보수, 리소스 확장, 용량 계획에 제로 시간을 쓴다는 의미입니다. 그들은 단순히 코드를 업로드하고, 공급업체가 다양한 이벤트나 요청에 기반하여 서버 사이드 로직을 실행하게 합니다. 친숙한 클라우드 청구 모델과 달리, 서버리스 서비스는 코드 실행 횟수나 특정 이벤트 트리거 시점에 따라 청구됩니다.

서버리스 컴퓨팅 작동 방식

서버리스 환경에서 코드는 이벤트에 의해 트리거되고 함수로 실행됩니다. 이것이 서버리스가 종종 "FaaS(Functions-as-a-Service)"와 연관되는 이유입니다. FaaS는 사용자의 개입 없이 코드 실행을 위한 서버 사이드 로직을 처리하는 이벤트 기반 클라우드 모델입니다. 이러한 이벤트는 단순 HTTP 요청, API 호출부터 데이터베이스 쿼리, 파일 업로드까지 무엇이든 될 수 있습니다.

함수는 스테이트리스 컨테이너에서 실행됩니다. 이는 함수를 실행하기 위한 컴퓨팅 리소스가 호출될 때만 프로비저닝됨을 의미합니다. 데이터는 RAM에 지속되거나 디스크에 기록되지 않습니다. 요청이 완료되면 앱 상태가 재설정되고 트랜잭션에 대한 메모리가 없습니다. 새로운 요청은 리소스를 처음부터 프로비저닝하도록 호출하고, 이전 호출에 대한 참조 없이 코드가 실행됩니다.

이 스테이트리스 상태를 수용하기 위해 애플리케이션은 스테이트리스 컨테이너에서 실행될 수 있는 함수로 아키텍처되어야 합니다. 이는 일반적으로 마이크로서비스를 통해 달성됩니다. 큰 모놀리식 앱은 더 작은 세그먼트로 분해되고 API를 통해 상호 연결됩니다. 모놀리식 앱도 단일 함수로 실행될 수 있지만, 이는 일반적인 관행이 아닙니다. 모든 요청마다 새 컴퓨팅 컨테이너가 프로비저닝된다는 점을 고려하면, 큰 함수는 실행 속도와 지속 시간에 부정적인 영향을 미칩니다.

FaaS 함수는 무한히 실행되지 않습니다. 호출된 후 일정 시간이 지나면 종료됩니다. 대부분의 경우 함수는 호출 후 약 5분 후 타임아웃됩니다. 이는 긴 실행 작업을 시작하는 앱이 종료 제한을 고려하여 재설계되어야 함을 의미합니다.

함수 실행을 위한 컨테이너 프로비저닝 및 초기화에도 시간이 걸립니다. 이는 일반적으로 밀리초 단위로 측정됩니다. 그러나 복잡한 함수는 초기화에 몇 초가 걸릴 수 있어 더 큰 지연을 유발합니다.

함수 초기화에는 웜 스타트(warm start)와 콜드 스타트(cold start) 두 가지 일반적인 방법이 있습니다. 웜 스타트는 이전 이벤트의 리소스를 재사용하는 반면, 콜드 스타트는 새 컨테이너를 배포합니다. 함수 초기화 및 실행 시간은 코드 양, 프로그래밍 언어, 스크립트가 사용하는 라이브러리 수 등 많은 요인에 따라 달라집니다. 지연 시간 측면에서 콜드 스타트는 함수 시작에 더 많은 시간이 걸립니다.

서버리스 컴퓨팅 vs BaaS, PaaS, IaaS 비교

모든 소프트웨어 트렌드와 마찬가지로 서버리스가 무엇이고 무엇이 아닌지를 설명하는 공식 정의는 없습니다. 그래서 서버리스 컴퓨팅은 종종 다른 클라우드 서비스 및 배포 모델과 혼동됩니다. 서버리스 컴퓨팅 개념은 두 가지 유사한 영역을 중심으로 합니다:

BaaS(Backend-as-a-Service) — BaaS는 개발자가 프론트엔드 인터페이스 작성에 집중하면서 모든 백엔드 작업을 서비스 공급업체에 오프로드할 수 있게 합니다. 이러한 백엔드 작업에는 보통 기성 사용자 인증, 스토리지, 데이터베이스 관리, 호스팅 서비스가 포함됩니다. 또한 개발자는 백엔드를 실행하는 서버를 관리할 필요가 없어 더 빠른 앱 배포가 가능합니다.

FaaS(Functions-as-a-Service) — 이 서버리스 클라우드 서비스 모델은 인프라 관리를 없애줍니다. 서비스 공급업체는 사용자의 코드를 실행하기 위해 온디맨드 컴퓨팅 리소스 배포를 담당합니다. 이는 이벤트나 요청이 트리거될 때마다 발생합니다. 서버리스 함수는 스테이트리스 컨테이너에서 실행되며, 이는 함수가 호출될 때만 컴퓨팅 리소스가 배포됨을 의미합니다.

주요 혼동 지점은 BaaS(Backend-as-a-Service)와 PaaS(Platform-as-a-Service) 사이입니다. 전자는 서버리스 컴퓨팅의 기술인 반면, 후자는 클라우드 배포 모델입니다. 둘이 기본 특성을 공유하지만, PaaS는 서버리스 요구사항과 일치하지 않습니다.

PaaS(Platform-as-a-Service) — PaaS에서는 사용자가 개발 워크로드에 필요한 하드웨어 및 소프트웨어 솔루션을 구독료로 서비스 공급업체로부터 임대합니다. 개발자가 인프라 관리 걱정 없이 코딩에 더 많은 시간을 할애할 수 있게 합니다. 반면 BaaS는 기성 사용자 인증, 관리형 데이터베이스, 이메일 알림 등 추가 기능을 제공합니다. BaaS는 또한 개발자가 프론트엔드 구축에만 집중하면서 다양한 백엔드 서비스를 온디맨드로 통합할 수 있게 합니다.

IaaS(Infrastructure-as-a-Service) — IaaS는 공급업체가 사용자를 대신하여 인프라를 호스팅하는 셀프 서비스 클라우드 솔루션을 가리킵니다. 소프트웨어 설치를 포함한 모든 서버 프로비저닝 및 관리 작업은 사용자가 처리합니다. 일부 IaaS 공급업체는 서버리스 솔루션도 제공하지만 분명히 다른 제품으로 제공합니다.

일반적인 서버리스 컴퓨팅 사용 사례

앞서 언급했듯이 서버리스는 모든 사람을 위한 것은 아닙니다. 하지만 귀하의 필요가 다음 사용 사례 중 일부와 일치한다면 서버리스의 이점을 누릴 수 있습니다.

API 구축

관리할 서버가 없으므로, 고도로 확장 가능하고 반응성이 뛰어난 API 구축은 서버리스의 더 인기 있는 사용 사례 중 하나입니다. 서버리스의 자동 확장 기능은 트래픽이 많을 때도 API가 항상 사용 가능하도록 보장합니다. 또한 API 호출이 없을 때 유휴 리소스에 대해 요금이 청구되지 않습니다.

웹사이트 및 애플리케이션

서버리스 플랫폼에 웹사이트와 웹 기반 앱을 배포하려면 사전 인프라 설정이 필요하지 않습니다. 이는 완전히 기능하는 웹 앱을 출시하는 데 걸리는 시간을 크게 단축합니다. 자동 확장 기능도 여기에서 중요한 역할을 합니다. 사용자는 수요 증가를 지원하기 위해 더 많은 서버를 프로비저닝하는 것에 대해 걱정할 필요가 없습니다. 결과적으로 100% 가동 시간을 유지하는 것이 훨씬 쉽습니다.

다국어 애플리케이션

서버리스를 사용하면 단일 앱을 다양한 언어로 작성할 수 있습니다. 서버리스는 개발자가 모놀리식 앱을 더 작은 부분으로 분해하고 마이크로서비스로 실행할 수 있게 합니다. 그런 다음 마이크로서비스들은 API를 통해 서로 통신합니다. 앱의 각 세그먼트는 다른 프로그래밍 언어로 작성될 수 있습니다.

CI/CD 파이프라인

자동화는 성공적인 개발, 테스트, 통합 파이프라인 실행의 핵심입니다. 서버리스는 개발자가 코드를 자동으로 테스트하고 버그를 더 빠르게 수정할 수 있게 합니다. 서버리스가 이벤트 기반이므로, 사용자는 수동 개입 없이 자동화된 테스트를 트리거하는 이벤트를 설정할 수 있습니다.

서버리스 컴퓨팅의 장점은 무엇인가?

전통적인 서버 중심 클라우드 컴퓨팅과 비교할 때, 서버리스 컴퓨팅은 인프라 운영을 추상화합니다. 모든 것이 즉시 작동하여 더 빠른 코드 릴리스와 더 낮은 가격대에서 자동화된 확장성을 보장합니다.

이것이 서버리스의 세 가지 가장 일반적인 이점입니다:

자동 확장(Auto-Scaling)

서버리스 공급업체는 수요에 따라 인프라 리소스를 확장합니다. 확장 작업은 개발자의 개입 없이 동적으로 자동으로 수행됩니다.

더 빠른 시장 출시(Faster Time to Market)

복잡한 서버 클러스터를 프로비저닝할 필요 없이 개발자는 더 높은 릴리스 속도 달성에 더 집중할 수 있습니다. 이는 코드를 프로덕션에 릴리스하거나 점진적 코드 변경을 구현하는 데 걸리는 시간을 단축하여 고객에게 앱을 더 빠르게 제공합니다.

최적화된 비용(Optimized Costs)

모든 것이 온디맨드로 프로비저닝되므로, 조직은 사용하지 않는 스토리지 공간, 컴퓨팅 시간, 네트워킹에 대해 결코 비용을 지불하지 않습니다. 서버리스 서비스 소비는 일반적으로 밀리초 단위로 측정되며 그에 따라 청구됩니다.

서버리스 컴퓨팅의 단점은 무엇인가?

모든 소프트웨어 솔루션과 마찬가지로 서버리스에도 몇 가지 단점이 있습니다. 하지만 구축하는 앱에 따라 이러한 서버리스 단점 중 일부는 그다지 신경 쓰이지 않을 수 있습니다.

지연 시간(Latency)

함수 실행 시 서버리스 공급업체는 모든 호출마다 필요한 리소스를 자동으로 배포합니다. 워크로드 크기에 따라 컨테이너는 일반적으로 밀리초 내에 프로비저닝되지만 몇 초가 걸릴 수도 있습니다. 지연 시간은 이전 실행의 인스턴스를 재사용하는 "웜 스타트"를 통해 줄일 수 있습니다.

실행 시간(Execution Duration)

서버리스 함수의 실행 시간은 제한되며 일정 기간 후 중단됩니다. 이는 일반적으로 호출 후 5분 정도지만 공급업체마다 다릅니다. 실행 제한은 긴 프로세스를 시작하는 앱에 주요 단점입니다. 이 문제는 코드를 더 작은 청크로 분할하여 마이크로서비스로 실행함으로써 완화할 수 있습니다.

벤더 락인(Vendor Lock-In)

공급업체는 보통 독점 기술을 사용하여 서버리스 서비스를 가능하게 합니다. 이는 워크로드를 다른 플랫폼으로 마이그레이션하려는 사용자에게 문제를 일으킬 수 있습니다. 다른 공급업체로 이동할 때 코드와 앱 아키텍처 변경은 불가피합니다.

보안(Security)

사용자는 코드를 실행하는 인스턴스 구성에 대한 통제력이 거의 없습니다. 이는 사용자로부터 숨겨져 있으며 서비스 공급업체의 영역에 속합니다. 따라서 보안 운영도 공급업체의 손에 달려 있습니다. 공격이 발생하면 사용자는 무력하며, 피해 완화와 시스템 복구를 전적으로 공급업체에 의존합니다. 서버리스 환경에서 여러 진입점을 가진 애플리케이션은 공격 표면 증가로 인해 취약점에 더 취약합니다.

서버리스 컴퓨팅의 미래는?

서버리스 컴퓨팅은 여전히 비교적 새로운 기술입니다. 그 미래는 위에 나열된 단점들, 특히 콜드 스타트 해결 능력에 달려 있습니다. 공급업체는 유휴 상태였던 함수를 실행하는 데 걸리는 시간을 단축해야 합니다. 이 문제 해결은 지연 시간을 줄이고 원활한 사용자 경험을 보장할 것입니다.

서버리스는 현재 함수 실행을 위해 스테이트리스 컨테이너에 의존합니다. 서버리스의 미래는 스테이트풀 앱이 서버리스의 이점을 활용할 수 있게 하는 방향으로 나아가고 있습니다. 이는 개발자가 백엔드 데이터 관리 걱정 없이 스테이트풀 앱을 구축할 수 있게 할 것입니다.

데브옵스 측면에서 서버리스는 NoOps 확장으로 이어질 것입니다. 이 트렌드는 서버리스 공급업체가 고객을 대신하여 모든 인프라 운영을 처리하게 할 것입니다. 그런 환경에서는 기업이 내부 운영 팀을 가질 필요가 없습니다.

향후 몇 년간 Kubernetes가 서버리스의 기반이 될 것으로 예상됩니다. 네트워킹 지원, 민첩한 자동 확장, 멀티 클라우드 배포로 Kubernetes 이식성은 서버리스 컴퓨팅을 여러 면에서 향상시킵니다. 서비스 공급업체가 때때로 앱 행동을 제한하기 때문에 서버리스에서 특정 클래스의 앱 실행은 비현실적입니다. Kubernetes를 통해 개발자는 이러한 제한을 극복하고 특정 요구에 기반한 서버리스 플랫폼을 구축할 수 있습니다.

결론

이름이 서버의 부재를 암시하지만, 서버리스 컴퓨팅은 여전히 클라우드 또는 물리 서버에 의존합니다. 인프라 운영을 제거하여 개발자가 앱 작성과 배포에 집중할 수 있게 하는 컴퓨팅 모델입니다. 서버리스 모델은 BaaS(Backend-as-a-Service)와 FaaS(Functions-as-a-Service) 두 가지 핵심 영역을 중심으로 합니다.

전자는 사용자에게 기성 백엔드 아키텍처를 제공하고, 후자는 스테이트리스 컨테이너에서 앱 실행을 가능하게 합니다. 이 컨테이너는 이벤트나 트리거에 기반하여 자동으로 프로비저닝됩니다. 따라서 서버리스는 현재 모든 개발 문제의 만능 해결책은 아닙니다. 주로 마이크로서비스 기반 아키텍처를 사용하는 비모놀리식 앱을 대상으로 합니다.