가상 머신(VM), 컨테이너, 퍼블릭 클라우드 등의 혁신으로 여러 면에서 애플리케이션 개발 과정이 개선되었지만, 여전히 개발자가 기술 자체보다는 몇 가지 구성, 유지 관리, 최적화에 대하여 결정을 해야 합니다.
이러한 책임이 개발자에게 더 많이 부여될수록 제품 및 내부 애플리케이션을 빌드하는 데 필요한 시간이 줄어듭니다.안타깝게도 널리 채택된 많은 기술 때문에 개발자들은 성능 최적화, 애플리케이션 확장, 보안 패치, 부하 분산 등의 작업을 수행해야만 합니다.이러한 책임에 따라 예산을 고갈시키거나 취약성 및 가동 중지 시간을 유발할 수 있는 차선의 선택이나 실수를 할 위험이 초래됩니다.
이러한 비효율성은 심각한 결과를 초래합니다.놀랍게도 개발자가 코딩이 아닌 작업에 소비하는 시간 때문에 조직에서 들여야 하는 비용은 연간 850억 달러 이상입니다.
따라서 애플리케이션 개발에서 복잡성을 제거하면 개발자 경험이 개선되는 동시에 조직에서도 상당한 비용을 절감할 수 있습니다.
서버리스 기술은 이러한 문제를 해결하도록 설계되었으며, 특히 개발자의 부담을 줄여 애플리케이션 개발이 개선되었습니다.그러나 모든 서버리스 플랫폼이 동일하게 생성되는 것은 아닙니다.서버리스 플랫폼은 초기에 반복되면서 컨테이너, 지역, 퍼블릭 클라우드 등의 구축 기술과 관련하여 많은 구성, 확장성, 성능 문제가 이어졌습니다.
따라서 오늘날 우리가 알고 있는 "서버리스"는 종종 오래된 모델 위에 구축한 불완전한 결과입니다.
첨단 서버리스 플랫폼 은 몇 가지 중요한 아키텍처 개선을 통해 이러한 문제를 극복하면서 발전했습니다.이러한 개선 사항으로 개발 프로세스에서 시간 소모적인 결정이 제거되므로 팀에서는 훌륭한 제품과 애플리케이션을 구축하는 데 더 많은 시간을 할애할 수 있습니다.
서버리스 이전에는 VM 과 컨테이너가 있었습니다.VM은 다른 컴퓨터의 운영 체제 내에 존재하는 소프트웨어 기반 컴퓨터이며, 컨테이너는 애플리케이션을 실행하는 데 필요한 모든 요소를 보유하는 표준 소프트웨어 단위입니다.
이 두 기술 덕분에 개발자가 하드웨어 관리보다는 애플리케이션에 더 집중할 수 있게 됩니다. 그러나 VM과 컨테이너는 여전히 개발자에게 관리 및 구성 업무를 부여하여 전체 개발 프로세스가 느려집니다.
정도는 차이가 나지만, VM과 컨테이너 때문에 개발자와 파트너 IT 및 보안 팀에서는 다음과 같은 작업을 수행해야 합니다.
보안 패치 및 ID 및 액세스 관리(IAM) 권한 관리
부하 분산 및 네트워킹 구성
가용성 보장 및 이중화 통합
쿠버네티스 와 같은 컨테이너 오케스트레이션 시스템은 규모 및 중복성 관리를 포함하여 컨테이너와 관련된 많은 구성 요구 사항을 완화합니다.그러나 고객 대면 문제보다 내부 개발 문제 해결에 중점을 두는 개발자 운영(DevOps) 팀은 이를 효과적으로 관리하기 위해 쿠버네티스 전문 지식이 필요합니다 .쿠버네티스와 적절하게 교육받은 팀이 없을 경우 컨테이너의 제약이 여전히 적용됩니다.
VM과 컨테이너는 더 큰 구성의 일부일 뿐입니다. 이 모든 기술은 자체적인 한계가 있는 퍼블릭 클라우드에서 사용할 수 있습니다.
퍼블릭 클라우드는 개발의 다양한 측면을 단순화하는 데는 도움이 되지만, 지역 선택, 보안 관리, 네트워킹 솔루션 설계, 가용성 보장 등의 구성 계층이 고객 조직의 몫으로 남습니다. 또한 퍼블릭 클라우드는 데이터베이스, 메시지 대기열, 스토리지 등 여러 서비스를 수동으로 결합해야 합니다. 이러한 서비스를 수동으로 구성하고 연결하려면 시간이 많이 걸리므로 전체 배포 시간이 늘어납니다.
서버리스 개발은 VM, 컨테이너, 퍼블릭 클라우드와 관련된 문제를 극복하도록 설계되었습니다. 그러나 초기 서버리스 방법은 부분적으로만 성공을 거두었습니다.
1세대 서버리스 개발의 주요 문제는 다음과 같습니다.
대기 시간 및 확장성. 이러한 서버리스 플랫폼 중 다수는 오버헤드 비용을 줄이기 위해 중앙 집중식 데이터 센터에 의존하는 퍼블릭 클라우드에서 작동합니다.이 모델에서는 고객이 리소스가 물리적으로 배치될 배포 지역을 선택해야 합니다.데이터를 중앙 집중화하면 코드가 최종 사용자와 멀리 떨어져 실행되므로 대기 시간이 발생합니다.또한 여러 지역에 걸쳐 확장하고 배포할 수 있지만, 구성이 복잡합니다.
콜드 스타트 및 CPU 제한. 컨테이너에 구축된 서버리스 플랫폼에서는 콜드 스타트 및 중앙 처리 장치(CPU) 제한으로 어려움을 겪습니다.콜드 스타트는 서버리스 기능이 처음 실행될 때 발생하는 로드 지연입니다.콜드 스타트는 컨테이너를 예열하는 데 몇 초가 걸릴 수 있으므로 발생합니다.반면에 CPU 제한은 플랫폼이 서버리스 인스턴스의 지정된 제한에 도달하고 요청이 지연될 때 발생합니다.
열악한 개발자 경험. 개발자는 오케스트레이션 템플릿 설정, 애플리케이션 크기 조정, 메모리 계층 결정 등 시간 소모적인 작업을 관리해야 하는 경우가 많습니다.이러한 작업에 따라 비용이 많이 드는 실수의 가능성이 생기고 개발자가 코딩에 소비하는 시간을 줄어들므로 시간이 지남에 따라 조직에서 들여야 하는 비용이 커집니다.
제한된 관찰 가능성. 많은 서버리스 개발 플랫폼은 적절한 관찰 가능성이 제공되지 않으므로 모니터링하기가 어렵습니다.관찰 가능성은 조직이 성능 메트릭, 이벤트 로그 등을 통해 분산 시스템에서 발생하는 상황을 이해할 수 있는 정도를 말합니다.적절한 관찰 기능이 없으면 조직에서는 서버리스 애플리케이션 내에서 발생하는 문제를 효율적으로 진단하고 해결할 수 없습니다.
상태 비저장 특성은 애플리케이션 기능을 제한합니다. 1세대 서버리스 플랫폼은 사실상 상태 비저장입니다.상태 비저장 특성의 경우에는 확장이 쉬워지지만, 대화형 채팅, 비디오 게임, 공동 작업 편집 도구 등 여러 클라이언트 간의 강력한 일관성 또는 실시간 조정이 필요한 애플리케이션을 빌드하기가 어려워질 수 있습니다.
비용. 많은 클라우드 서버리스 플랫폼에는 API Gateway 수수료 또는 컨테이너를 따뜻하게 유지하기 위한 요금과 같은 추가 비용이 숨겨져 있는 경우가 많습니다.결과적으로 이러한 1세대 플랫폼으로 애플리케이션을 구축하는 것은 특히 대규모로 비용이 많이 들 수 있습니다.
서버리스 이동의 목적은 항상 애플리케이션 개발 프로세스를 더 쉽게 만드는 것이었지만, 중앙 집중식 퍼블릭 클라우드에서 실행되는 서버리스 플랫폼은 그 약속에 완전히 부응하지 못합니다.
차세대 서버리스 개발 플랫폼은 이전 제품의 많은 단점을 극복하면서 발전했습니다. 컨테이너 및 퍼블릭 클라우드와 같은 레거시 인프라에 의존하지 않으므로 이러한 솔루션은 몇 가지 사항이 개선되었으며 개발자가 더 많은 시간을 쓸 수 있게 되었습니다.
개선된 사항은 다음과 같습니다.
네트워크 에지에서 실행됨. 가장 진보된 서버리스 플랫폼은 많은 데이터 센터의 분산 네트워크를 의미하는 '에지'에서 실행됩니다.네트워크가 클수록 성능 및 확장성 문제를 더 잘 해결할 수 있습니다.이는 에지 네트워크에서 컴퓨팅이 최종 사용자와 가장 가까운 상호 접속 위치에서 이루어지기 때문입니다.이 분산 접근 방식은 대기 시간을 줄여주며 퍼블릭 클라우드의 중앙 집중식 지역과 근본적으로 다릅니다.따라서 수백 개의 데이터 센터 네트워크에 코드를 배포하면 20개의 데이터 센터 네트워크의 경우보다 더 나은 성능을 얻을 수 있습니다.가장 진보된 에지 플랫폼에서는 복잡한 워크로드를 구축하기 위해 긴 CPU 런타임이 제공됩니다.
컨테이너가 아닌 격리를 사용합니다. 이 접근 방식을 사용하면 완화하는 데 비용이 많이 드는 컨테이너 기반 아키텍처 문제(콜드 스타트 및 CPU 제한)가 없어집니다.컨테이너와는 달리 격리 대상은 따뜻하게 유지할 필요가 없으므로 콜드 스타트는 문제가 되지 않습니다.또한 격리에는 메모리가 덜 사용되므로 오버헤드 및 CPU 제한 문제가 줄어듭니다.
사전 의사 결정 감소. 일부 최신 에지 서버리스 플랫폼에서는 성능과 보안을 위해 애플리케이션이 자동으로 최적화됩니다.또한 글로벌 에지 네트워크를 사용하는 솔루션에서는 네트워크의 모든 데이터 센터에 코드가 배포되므로 개발자가 워크로드를 호스팅할 지역을 선택할 필요가 없습니다.이러한 지루한 작업을 제거함에 따라 개발자 환경이 개선됩니다.
자세한 분석 및 로깅. 이전의 서버리스 플랫폼은 많은 분석, 디버깅 또는 로깅 기능을 제공하지 않았지만 고급 에지 서버리스 플랫폼은 향상된 관찰 가능성을 제공합니다.자세한 분석 및 로깅을 통해 개발 팀은 문제를 해결하는 데 필요한 정보를 더 쉽게 수집할 수 있습니다.또한 일부 플랫폼은 더 복잡한 애플리케이션에 필요할 수 있는 보다 정교한 모니터링 도구와 통합됩니다.
통합된 조정 및 스토리지. 이 기능으로는 서버리스를 통해 상태 저장 아키텍처가 가능합니다.상태 저장 아키텍처에는일관된 데이터 스토리지가 필요합니다. 데이터가 일시적인 상태 비저장 애플리케이션과는 다릅니다.상태 저장 아키텍처 없이는 대화형 실시간 애플리케이션을 만들 수 없습니다.
비용 효율적임. 경량인 격리 기반 에지 서버리스 플랫폼은 컨테이너 기반 이전 플랫폼에 비해 비용이 저렴합니다.격리 아키텍처에서는 클라우드와 관련된 모든 확장성 및 유연성 이점이 제공되지만, 숨겨진 요금과 비용 급증은 없습니다.
이러한 개선을 통해 차세대 서버리스 플랫폼에서는 전체 애플리케이션 개발 프로세스가 최적화됩니다. 지루한 작업이 제거되고 개발자가 집중할 수 있도록 하는 동시에 조직에서도 비용 절감 효과를 거둘 수 있습니다.
올바른 서버리스 플랫폼을 선택하면 확장성 제한이 사라지고 개발자의 부담이 줄며 애플리케이션 개발 프로세스의 전반적인 효율이 높아집니다. Cloudflare Workers는 스마트 인프라를 사용하여 개발자가 많은 사전 결정을 내릴 수 있도록 하는 에지 기반 서버리스 플랫폼입니다.Cloudflare의 인프라 덕분에 Workers를 기반으로 구축된 애플리케이션은 항상 보안, 성능, 안정성에 최적화되어 있습니다.
Workers는 125여 개국 330개 이상 도시에 걸쳐 있는 Cloudflare 전역 네트워크에서 실행되므로 확장성은 문제가 되지 않습니다. 코드는 추가 비용이나 구성 없이 모든 지역에 자동으로 배포됩니다. 개발 팀에서는 Workers Unbound를 사용하여 긴 CPU 런타임이 필요한 고급 애플리케이션을 에지에서 빌드할 수 있습니다. Workers 플랫폼은 컨테이너가 아닌 격리에서 실행되므로 콜드 스타트나 CPU 제한이 없습니다. Workers에서는 내장된 관찰 기능이 제공되며 Workers Command Line Interface(CLI)를 통해 사용할 수 있는 디버깅 및 로깅 도구 외에도 New Relic 및 Sentry와 같은 고급 모니터링 도구와 통합됩니다. Durable Objects는 Workers 플랫폼에 짧은 대기 시간 조정과 일관된 스토리지를 제공하므로 상태 저장 서버리스 애플리케이션이 실현됩니다. 동시에 Workers를 사용하면 숨겨진 수수료가 제거되고 업계 최고의 가격이 제공되므로 고객은 비용을 절약할 수 있습니다.
Workers를 통해 개발 팀에서는 유지 관리 및 구성이 아닌 제품 구축에 집중할 수 있으므로 개발자 경험이 개선되고 시간이 지남에 따라 회사에서 재정적으로 이득을 얻을 수 있습니다.
이 글은 오늘날의 기술 의사 결정자에 영향을 주는 최신 동향 및 주제에 대한 시리즈 중 일부입니다.
이 글을 읽고 나면 다음을 이해할 수 있습니다.
비효율적인 개발 아키텍처의 문제점
개발 방법이 발전하여 서버리스로 이어진 방법
서버리스의 초기 반복으로 애플리케이션 개발이 단순화되지 못한 방법
차세대 서버리스의 주요 차이점
Forrester New Wave: Function-as-a-Service Platforms 보고서에서 Workers와 같은 서버리스 플랫폼에 대해 자세히 알아보세요.