서버리스 컴퓨팅을 사용하는 이유는? | 서버리스의 장단점

서버리스 컴퓨팅을 사용하는 이유는?

서버리스 컴퓨팅을 이용하면 기존 클라우드 기반 또는 서버 중심 인프라에 비해 여러 가지 이점이 제공됩니다. 많은 개발자는 서버리스 아키텍처를 이용하여 더 큰 확장성, 더 높은 유연성, 더 빠른 출시 시간, 비용 절감 등의 이점을 누릴 수 있습니다. 서버리스 아키텍처를 사용하면 개발자는 백엔드 서버의 구매, 프로비저닝, 관리에 대해 걱정할 필요가 없습니다. 하지만 서버리스 컴퓨팅이 모든 웹 애플리케이션 개발자에게 마법의 해결책이 되는 것은 아닙니다.

서버리스 컴퓨팅은 어떻게 작동할까요?

서버리스 컴퓨팅은 벤더가 필요에 따라 백엔드 서비스를 제공하는 아키텍처입니다.서버리스 컴퓨팅에 대해 자세히 알아보려면 서버리스 컴퓨팅이란?을 참조하세요

서버리스 컴퓨팅의 장점은 무엇입니까?

서버 관리가 필요하지 않습니다

'서버리스' 컴퓨팅은 실제로는 서버에서 이루어지지만, 개발자는 서버를 다룰 필요가 없습니다. 서버는 공급업체에서 관리합니다. 이렇게 하면 엔지니어링/개발에 필요한 투자를 줄여 비용을 절감할 수 있으며, 개발자가 서버 용량의 제약을 받지 않고 애플리케이션을 만들고 확장할 수 있습니다.

개발자에게는 사용한 서버 공간에 대해서만 요금이 부과되므로 비용이 절감됩니다

'종량제' 전화 요금제에서와 마찬가지로 개발자에게는 사용한 만큼만 요금이 청구됩니다. 서버리스 애플리케이션에서 백엔드 기능이 필요할 때만 코드가 실행되며, 필요에 따라 코드가 자동으로 확장됩니다. 프로비저닝은 동적이고 정확하며 실시간으로 이루어집니다. 일부 서비스는 100밀리초 단위로 요금을 세분화할 정도로 정확합니다. 반면, 기존의 '서버 풀' 아키텍처에서는 개발자가 필요한 서버 용량을 미리 예측한 다음 실제 사용 여부와 관계없이 해당 용량을 구매해야 합니다.

서버리스 아키텍처는 본질적으로 확장성이 뛰어납니다

우체국에서 우편 물량이 급증할 때(예: 어버이날 직전) 배송 트럭을 마음대로 늘리거나 줄이고, 배송이 덜 필요한 시간대에는 배송 트럭의 수를 줄일 수 있다고 상상해 보세요. 이것이 바로 서버리스 애플리케이션이 기본적으로 할 수 있는 일입니다.

서버리스 인프라로 구축된 애플리케이션은 사용자 기반이 증가하거나 사용량이 증가하면 자동으로 확장됩니다. 함수를 여러 인스턴스에서 실행해야 하는 경우 벤더의 서버는 컨테이너를 사용하여 필요에 따라 시작, 실행, 종료합니다. (최근에 실행한 경우 기능이 더 빨리 시작됩니다. 아래의 '성능에 영향이 미칠 수 있음' 참조). 그 결과로 서버리스 애플리케이션은 단일 사용자의 단일 요청을 처리하는 것처럼 비정상적으로 많은 수의 요청을 처리할 수 있습니다. 서버 공간이 고정되어 있는 기존 구조의 애플리케이션은 갑작스럽게 사용량이 증가하면 과부하가 걸릴 수 있습니다.

빠른 배포 및 업데이트가 가능함

서버리스 인프라를 사용하면 애플리케이션의 작동 버전을 출시하기 위해 서버에 코드를 업로드하거나 백엔드 구성을 수행할 필요가 없습니다. 개발자는 아주 빠르게 코드 조각을 업로드하고 새로운 제품을 출시할 수 있습니다. 애플리케이션은 단일 모놀리식 스택이 아니라 벤더에서 제공하는 기능 모음이므로 코드를 한 번에 모두 업로드하거나 한 번에 하나의 기능만 업로드할 수 있습니다.

또한 애플리케이션에 새로운 기능을 신속하게 업데이트, 패치, 수정, 추가할 수 있습니다. 전체 애플리케이션을 변경할 필요 없이 개발자가 한 번에 하나의 기능만 업데이트하면 됩니다.

코드를 최종 사용자에게서 더 가까운 곳에서 실행하여 대기 시간을 줄일 수 있습니다

애플리케이션은 원본 서버에서 호스팅되지 않으므로 어디서나 코드를 실행할 수 있습니다.따라서 사용하는 벤더에 따라 최종 사용자와 가까운 서버에서 애플리케이션 기능을 실행할 수 있습니다.이렇게 하면 사용자의 요청이 더 이상 원본 서버까지 이동할 필요가 없으므로 대기 시간이 줄어듭니다.Cloudflare Workers를 사용하면 이러한 종류의 서버리스 대기 시간이 줄어들 수 있습니다.

서버리스 컴퓨팅의 단점은?

더욱 까다로워진 테스트 및 디버깅

코드가 배포된 후 실제로 어떻게 작동하는지 확인하기 위해 서버리스 환경을 복제하는 것은 어렵습니다.개발자는 백엔드 프로세스에 대한 가시성이 없고 애플리케이션이 별도의 작은 함수로 나뉘어져 있으므로 디버깅이 더 복잡합니다.Cloudflare Workers Playground는 테스트 및 디버깅의 간극을 줄이는 데 도움이 되는 샌드박스입니다

서버리스 컴퓨팅은 새로운 보안 문제를 야기함

벤더가 전체 백엔드를 실행하는 경우 보안을 완벽하게 검사하지 못할 수 있으며, 이는 특히 개인 데이터나 중요한 데이터를 처리하는 애플리케이션에서 문제가 될 수 있습니다.

기업에는 개별적인 물리적 서버가 할당되지 않으므로 서버리스 공급자는 여러 고객의 코드를 단일 서버에서 동시에 실행하는 경우가 많습니다. 다른 당사자와 하나의 장비를 공유하는 것을 '다중 테넌트'라고 합니다. 여러 회사에서 동시에 사무실을 임대하여 사용하는 것을 생각해 보세요. 다중 테넌트는 애플리케이션 성능에 영향을 미칠 수 있으며, 다중 테넌트 서버가 제대로 구성되지 않은 경우 데이터가 노출될 수 있습니다. 다중 테넌트는 샌드박스가 올바르게 작동하고 충분히 강력한 인프라를 갖춘 네트워크에는 거의 영향을 미치지 않습니다. 예를 들어, Cloudflare에서는 서비스 저하를 완화할 수 있는 충분한 초과 용량을 갖춘 15Tbps 네트워크를 운영하며, Cloudflare에서 호스팅하는 모든 서버리스 기능은 자체 샌드박스에서 실행됩니다(Chrome V8 엔진을 통해).

서버리스 아키텍처는 장기 실행 프로세스를 위해 구축되지 않습니다.

따라서 서버리스 아키텍처에서 비용 효율적으로 실행할 수 있는 애플리케이션의 종류가 제한됩니다. 서버리스 공급자는 코드가 실행되는 시간만큼 요금을 청구하므로 서버리스 인프라에서 장기간 실행되는 프로세스가 있는 애플리케이션을 실행하는 데는 기존 인프라에 비해 더 많은 비용이 들 수 있습니다.

성능에 영향이 미칠 수 있음

서버리스 코드는 지속해서 실행되는 것이 아니므로 사용할 때 '부팅'해야 할 수 있습니다. 이 시작 시간으로 인해 성능이 저하될 수 있습니다. 그러나 코드가 정기적으로 사용되는 경우 서버리스 공급자는 코드를 활성화할 수 있도록 준비된 상태로 유지하며, 이 준비된 코드에 대한 요청을 '웜 스타트'라고 합니다. 한동안 사용하지 않은 코드에 대한 요청을 '콜드 스타트'라고 합니다.

Cloudflare Workers에서는 대부분의 경우 5밀리초 이내에 JavaScript코드를 시작하고 실행할 수 있는 Chrome V8 엔진을 사용하여 콜드 스타트 문제를 대체로 방지합니다.코드가 이미 실행 중인 경우 응답 시간은 1밀리초 미만입니다.다양한 서버리스 플랫폼의 성능에 대해 자세히 알아보세요.

벤더 종속은 위험함

벤더가 애플리케이션의 모든 백엔드 서비스를 제공하도록 허용하면 필연적으로 해당 벤더에 대한 의존도가 높아집니다. 특히 각 벤더가 제공하는 기능과 워크플로우가 조금씩 다르므로 한 벤더로 서버리스 아키텍처를 설정하면 필요한 경우 벤더를 바꾸기가 어려울 수 있습니다. (Cloudflare Workers는 JavaScript로 작성되고 널리 사용되는 서비스 작업자 API에 대해 작성되었므로 마이그레이션이 더 쉽습니다.)

누가 서버리스 아키텍처를 사용해야 할까요?

출시 기간을 단축하고 빠르게 확장하거나 업데이트할 수 있는 가볍고 유연한 애플리케이션을 구축하려는 개발자는 서버리스 컴퓨팅을 사용하면 큰 이점을 누릴 수 있습니다.

서버리스 아키텍처는 트래픽이 많을 때와 적을 때가 번갈아 가며 사용량이 일정하지 않은 애플리케이션의 경우에 비용을 절감할 수 있습니다. 이러한 애플리케이션의 경우, 사용하지 않을 때에도 지속해서 실행되고 항상 사용 가능한 서버 또는 서버 블록을 구입하는 것은 리소스 낭비일 수 있습니다. 서버리스 설정은 필요할 때 즉시 응답하며 유휴 상태에서는 비용이 발생하지 않습니다.

또한 애플리케이션 기능의 일부 또는 전부를 최종 사용자에게 가깝게 푸시하여 대기 시간을 줄이려는 개발자는 일부 프로세스를 원본 서버 밖으로 이동시켜야 하므로 적어도 부분적으로 서버리스 아키텍처가 필요합니다.

개발자는 언제 서버리스 아키텍처 사용을 피해야 할까요?

자체 관리형 또는 서비스로 제공되는 전용 서버를 사용하는 것이 비용 측면과 시스템 아키텍처 측면에서 더 합리적인 경우가 있습니다. 예를 들어 워크로드가 상당히 일정하고 예측 가능한 대규모 애플리케이션의 경우 전통적인 설정이 필요할 수 있으며, 이러한 경우 전통적인 설정이 더 저렴할 수 있습니다.

또한 레거시 애플리케이션을 완전히 다른 아키텍처의 새로운 인프라로 마이그레이션하는 것은 엄청나게 어려울 수 있습니다.

Cloudflare에서는 개발자가 서버리스 아키텍처를 구축하는 것을 어떻게 지원할까요?

Cloudflare Workers는 개발자가 JavaScript 함수를 작성하여 Cloudflare 네트워크의 에지에 배포할 수 있도록 해주는 제품입니다. 이를 통해 최종 사용자와 최대한 가까운 서버리스 아키텍처에서 애플리케이션 코드를 실행하여 대기 시간을 최소화하고 'The Network is the Computer®'라는 원칙을 구현할 수 있습니다.