서버리스 컴퓨팅과 컨테이너는 모두 클라우드 호스팅 웹 애플리케이션의 오버헤드를 줄여 주는 아키텍처이지만, 몇 가지 중요한 면에서 차이가 있습니다. 컨테이너는 가상 머신보다 가볍지만, 서버리스 배포는 컨테이너 기반 아키텍처보다 훨씬 더 가볍고 쉽게 확장할 수 있습니다.
이 글을 읽은 후에 다음을 할 수 있습니다:
글 링크 복사
서버리스 컴퓨팅과 컨테이너 모두 사용할 경우 개발자가 기존 서버나 가상 머신에서 호스팅되는 애플리케이션보다 훨씬 적은 오버헤드와 유연성으로 애플리케이션을 빌드할 수 있습니다. 개발자가 어떤 아키텍처 스타일을 사용해야 하는지는 애플리케이션의 요구 사항에 따라 다르지만, 서버리스 애플리케이션은 확장성이 더 뛰어나고 일반적으로 비용 효율성이 더 높습니다.
컨테이너에는 애플리케이션과 시스템 라이브러리, 시스템 설정, 기타 종속성 등 애플리케이션이 제대로 실행되는 데 필요한 모든 요소가 '포함'되어 있습니다. '물만 넣으면 되는' 팬케이크 믹스처럼 컨테이너도 호스팅과 실행이라는 한 가지만 있으면 제 기능을 수행할 수 있습니다.
모든 종류의 애플리케이션을 컨테이너에서 실행할 수 있습니다. 컨테이너화된 애플리케이션은 호스팅 위치와 관계없이 동일한 방식으로 실행됩니다. 컨테이너는 표준 크기이므로 내용물과 관계없이 다양한 운송 수단(선박, 트럭, 열차 등)을 통해 어디든 배송할 수 있는 실제 운송 컨테이너와 마찬가지로 필요한 곳에 쉽게 이동하고 배치할 수 있습니다.
기술적인 측면에서 컨테이너는 장비 또는 서버를 별도의 사용자 공간 환경으로 분할하여 각 환경이 하나의 애플리케이션만 실행하고 장비의 다른 분할된 섹션과 상호 작용하지 않도록 하는 방식입니다. 각 컨테이너는 장비의 커널을 다른 컨테이너와 공유하지만(커널은 운영 체제의 기초이며 컴퓨터의 하드웨어와 상호 작용함), 마치 해당 장비의 유일한 시스템인 것처럼 실행됩니다.
가상 머신은 완전한 컴퓨터 시스템을 모방한 소프트웨어입니다.가상 머신은 호스팅하는 컴퓨터의 나머지 부분과 분리되어 있으며 자체 커널을 보유한 것을 포함하여 마치 유일한 운영 체제인 것처럼 작동합니다.가상 머신은 하나의 서버에서 여러 환경을 호스팅하는 또 다른 일반적인 방법이지만, 컨테이너보다 훨씬 더 많은 처리 능력을 사용합니다.
서버리스 애플리케이션은 여러 기능으로 나뉘고, 타사 벤더에서 호스팅되며, 각 기능이 실행되는 시간만을 기준으로 애플리케이션 개발자에게 비용이 청구됩니다.서버리스 컴퓨팅에 대하여 자세히 알아보려면 서버리스 컴퓨팅이란?을 참조하세요
'서버리스' 컴퓨팅은 실제로 서버에서 실행되지만, 애플리케이션에 필요한 서버 공간을 프로비저닝하는 것은 서버리스 벤더의 몫이며, 특정 기능이나 애플리케이션을 위해 특정 머신이 할당되지는 않습니다. 반면에 각 컨테이너는 한 번에 하나의 머신에 상주하며 해당 머신의 운영 체제를 사용하지만, 원하는 경우 다른 머신으로 쉽게 이동할 수 있습니다.
컨테이너 기반 아키텍처에서는 배포되는 컨테이너의 수를 개발자가 미리 결정합니다. 반면, 서버리스 아키텍처에서는 백엔드가 본질적으로 자동으로 확장되어 수요가 충족됩니다.
해운 컨테이너에 대한 비유를 계속하자면, 해운 회사에서는 특정 제품에 대한 수요가 증가할 것으로 예측하고 그 수요를 충족하기 위해 더 많은 컨테이너를 목적지로 배송하려고 시도할 수 있지만, 수요가 예상을 초과하는 경우 눈깜짝할 사이에 제품으로 가득 찬 컨테이너를 더 많이 생산할 수는 없습니다.
서버리스 아키텍처는 바로 이를 위한 방법입니다. 컴퓨팅 성능 측면에서 서버리스 컴퓨팅은 현대 가정의 상수도와 같습니다. 소비자는 수도꼭지만 틀면 언제든지 필요한 만큼의 물을 확보하여 사용할 수 있으며 사용한 만큼만 요금을 지불합니다. 이는 한 번에 물통 하나 또는 배송 컨테이너 하나를 구매하는 것보다 훨씬 더 확장성이 뛰어납니다.
컨테이너는 지속해서 실행되므로 클라우드 공급자는 당시 아무도 애플리케이션을 사용하고 있지 않더라도 서버 공간에 대한 요금을 청구해야 합니다.
서버리스 아키텍처에서는 호출되지 않는 한 애플리케이션 코드가 실행되지 않으므로 지속적인 비용이 발생하지 않습니다. 대신 개발자에게는 애플리케이션에서 실제로 사용되는 서버 용량에 대해서만 요금이 부과됩니다.
컨테이너는 클라우드에서 호스팅되지만, 클라우드 공급자는 컨테이너를 업데이트하거나 유지 관리하지 않습니다. 개발자는 배포하는 각 컨테이너를 관리하고 업데이트해야 합니다.
개발자의 관점에서 서버리스 아키텍처는 관리할 백엔드가 없습니다. 벤더는 코드를 실행하는 서버에 대한 모든 관리 및 소프트웨어 업데이트를 처리합니다.
컨테이너는 시스템 설정, 라이브러리 등을 구성해야 하므로 서버리스 기능보다 초기 설정에 시간이 오래 걸립니다. 컨테이너를 구성하고 나면 배포하는 데는 몇 초밖에 걸리지 않습니다. 하지만 서버리스 기능은 컨테이너 마이크로서비스보다 규모가 작고 시스템 종속성이 번들로 제공되지 않으므로 배포하는 데 몇 밀리초밖에 걸리지 않습니다. 서버리스 애플리케이션은 코드가 업로드되는 즉시 실행할 수 있습니다.
백엔드 환경은 로컬 환경에서 복제하기 어려우므로 서버리스 웹 애플리케이션은 테스트하기가 어렵습니다. 반면, 컨테이너는 배포 위치와 관계없이 동일하게 실행되므로 프로덕션 환경에 배포하기 전에 컨테이너 기반 애플리케이션을 상대적으로 간단하게 테스트할 수 있습니다.
서버리스 아키텍처를 지원하는 Cloudflare Workers의 경우, 우리는 개발 프로세스를 개선하는 데 도움이 되도록 가상 테스트 환경을 만들었습니다.
둘 다 클라우드 기반이며, 둘 다 인프라 오버헤드를 줄일 수 있지만, 컨테이너보다 서버리스 컴퓨팅이 더 많이 줄일 수 있습니다. 두 가지 유형의 아키텍처 모두 애플리케이션이 더 작은 구성 요소로 세분화되어 배포됩니다. 컨테이너 기반 아키텍처에서 각 컨테이너는 하나의 마이크로서비스를 실행합니다.
마이크로서비스는 애플리케이션의 세그먼트입니다. 각 마이크로서비스에서는 하나의 서비스가 수행되며, 여러 개의 통합 마이크로서비스가 결합되어 애플리케이션이 구성됩니다. 마이크로서비스는 이름만 보면 작다는 것을 암시하는 것 같지만, 반드시 그렇지는 않습니다.
마이크로서비스 모음으로 애플리케이션을 구축할 때의 장점 중 하나는 개발자가 변경을 필요로 할 때 전체 애플리케이션을 업데이트하는 대신 한 번에 하나의 마이크로서비스만 업데이트할 수 있다는 점입니다. 서버리스 아키텍처에서와 같이 애플리케이션을 기능 모음으로 빌드하면 동일한 이점이 제공되지만, 더 세분화된 수준에서 사용할 수 있습니다.
서버리스 아키텍처를 선택하는 개발자는 애플리케이션의 확장 가능 여부에 대해 우려할 필요 없이 새로운 애플리케이션을 빠르게 출시하고 반복할 수 있습니다. 또한 애플리케이션의 트래픽이나 사용량이 일정하지 않은 경우, 서버리스 컴퓨팅은 코드를 지속적으로 실행할 필요가 없으므로 컨테이너보다 비용 대비 효율성이 더 높습니다.
컨테이너를 사용하면 개발자는 애플리케이션이 실행되는 환경(유지 관리는 더 많이 필요하지만)과 사용되는 언어 및 라이브러리를 더 잘 제어할 수 있습니다. 따라서 컨테이너는 애플리케이션의 원래 실행 환경을 더 가깝게 복제할 수 있으므로 레거시 애플리케이션을 클라우드로 마이그레이션하는 데 아주 유용합니다.
마지막으로, 일부 서버리스 기능과 일부 기능을 컨테이너에 배포하면서 하이브리드 아키텍처를 사용할 수도 있습니다. 예를 들어, 애플리케이션 기능에 서버리스 벤더가 할당하는 것보다 더 많은 메모리가 필요한 경우, 기능이 너무 크거나 특정 기능만 장기 실행해야 하는 경우, 하이브리드 아키텍처를 사용하면 개발자는 서버리스가 지원하지 않는 기능에는 컨테이너를 계속 사용하면서 서버리스의 이점을 누릴 수 있습니다.
Cloudflare에서는 개발자가 Cloudflare Workers를 통해 고성능 서버리스 애플리케이션을 구축하도록 지원합니다.