인프라 수준의 환경 구성, 확장 및 프로비저닝에 대한 우려는 사라졌으며, 분산만이 마지막 문제로 남아 있다. 이 문제의 해결책으로 등장한 것이 바로 엣지 서버리스(Edge Serverless)로, 데이터와 컴퓨트를 수많은 데이터센터에 걸쳐 분산 배포한다. 엣지 서버리스는 컴퓨팅을 사용자와 더 가까운 곳으로 가져와 지연시간을 줄일 수 있다.
 |
<이미지를 클릭하시면 크게 보실 수 있습니다> |
엣지 서버리스는 거의 15년 전에 IaaS(Infrastructure-as-a-Service)로 시작된 클라우드 아키텍처 진화의 정점이다. 클라우드 진화의 다음 단계는 서버리스 ‘빌딩 블록’의 분산을 촉진하고 개발자가 더 쉽게 소비할 수 있도록 하는 것이다.
서버리스 아키텍처는 현재 어디에 있는지, 어디로 향하는지 좀 더 자세히 살펴보자.
계층화 아키텍처
IaaS(Infrastructure as a Service)클라우드 컴퓨팅 혁명은 IaaS의 등장으로 본격화되었다. IaaS를 통해 기업은 로컬 인프라를 호스팅된 ‘클라우드’ 인프라로 옮겨 운영할 수 있다. 사용한 스토리지와 컴퓨팅 시간에 대해서만 비용을 지불하며, 어떠한 하드웨어나 네트워크도 설치하거나 관리할 필요가 없다.
처음에는 IaaS가 비싸 보였지만, 일반 기업은 구현할 수 없는 수준의 가용성을 보장했기 때문에 빠르게 확산됐다. 실제로 자체적으로 인프라를 구매하고 유지하는 비용이 IaaS 서비스 요금보다 비싼 경우가 많았다. 가장 큰 장점은 하드웨어 유지보수와 프로비저닝이 필요없기 때문에 개발자가 비즈니스 가치에만 집중할 수 있다는 것이다.
PaaS(Platform as a Service)
그 후 서비스 업체는 클라우드 컴퓨팅을 한 단계 더 발전시켜 PaaS를 제공했다. PaaS는 애플리케이션을 구축하는 데 필요한 모든 것을 임대해 준다. 여기에는 서버뿐만 아니라 운영체제, 프로그래밍 언어 환경, 데이터베이스 및 데이터베이스 관리 툴이 포함된다.
IaaS를 이용하면 임대한 서버의 관리자가 되지만, PaaS 업체는 소프트웨어 설치나 보안 업데이트와 같은 서버 관리 작업을 넘겨 받고, 때로는 코드의 환경 요구사항을 예측하려고 한다. PaaS의 목표는 애플리케이션 배치를 위한 손쉬운 방법을 제공하는 것이다. IaaS보다 한 단계 더 발전한 PaaS는 개발자가 시스템 관리 업무에서 벗어나 가장 중요한 것, 즉 애플리케이션에 집중할 수 있게 해준다.
SaaS(Software-as-a-Service)
SaaS는 일반적으로 다양한 구독을 통해 이용할 수 있는 온라인으로 호스팅하는 애플리케이션을 가리킨다. 이들 애플리케이션은 클라우드에서 완전히 작동하며 인터넷과 브라우저를 통해 접속한다. 본질적으로, 클라우드에서 실행되고 가입 기반의 가격책정 모델을 갖는 모든 애플리케이션이 SaaS 애플리케이션으로 간주된다.
SaaS 애플리케이션에는 2가지 유형이 있다. 최종 사용자에게 초점을 맞춘 서비스와 개발자에게 초점을 맞춘 서비스가 그것이다. 후자는 다른 애플리케이션을 위한 기반을 제공한다. 최종 사용자에게 초점을 맞춘 SaaS 애플리케이션의 대표적인 예는 지메일, 드롭박스, 지라, 비트버킷, 슬랙 등이며, 스트라이프(Stripe)와 슬라스크(Slaask)처럼 자사 SaaS 솔루션을 기업 자체 애플리케이션에 통합할 수 있는 API를 제공하는 곳도 있다.
CaaS(Container as a Service)
컨테이너 플랫폼은 IaaS의 최신 구현 방식이다. CaaS 업체는 완전한 서버 호스트를 제공하는 대신 기업이컨테이너 내에서 서비스나 애플리케이션을 호스팅할 수 있도록 해주고, 컨테이너를 대신 관리한다. 컨테이너는 가상머신보다 기반 호스트 자원을 더 효율적으로 활용할 수 있다. ‘작은 가상머신’이라고 생각할 수도 있다. 컨테이너는 실행도 빠르고, 단일 서버에서 여러 인스턴스를 실행할 수 있다.
CaaS 업체는 서버에 컨테이너를 배치하고 컨테이너 인스턴스 수를 늘리고 줄이는 툴을 제공한다. 가장 진보적인 솔루션은 기반 서버를 완벽하게 관리하므로, 기업이 인프라 대신 코드(또는 컨테이너)에 집중할 수 있게 해준다.
CaaS는 금방 PaaS와 SaaS의 빌딩 블록 중 하나로 자리 잡으며 계층화 아키텍처를 구성한다. 하나의 플랫폼이 모든 애플리케이션 요구 사항을 제공할 만큼 유연하지는 않기 때문에, 복잡한 애플리케이션은 여전히 SaaS, PaaS 및 CaaS의 조합으로 이루어져 있다.
 |
<이미지를 클릭하시면 크게 보실 수 있습니다> |
SaaS에 대한 의존도를 최대한 높이면 프로비저닝 및 확장성에 대한 우려에서 벗어날 수 있다. 하지만 SaaS가 소화할 수 없는 나머지 부분은 보통 컨테이너에 자리를 잡는데, 이는 여전히 환경 구성과 프로비저닝에 대한 우려를 가지고 있다는 것을 의미한다.
이런 우려를 줄이기 위해 다섯 번째 해법인 서버리스 아키텍처가 탄생한 것이다.
서버리스 아키텍처
FaaS(Function as a Service)FaaS를 사용하면 확장, 서버 또는 컨테이너에 대한 생각 없이 코드를 업로드하고 실행할 수 있다. 그런 점에서 FaaS는 기존 계층화 아키텍처의 사용 편의성 기준을 능가한다. FaaS의 가장 큰 장점은 확장이다. FaaS는 PaaS나 CaaS보다 더 세밀한 단위로 확장할 수 있으며, 확장에 따르는 환경 구성이 필요없다. 또한 사용하지 않는 것에 대해서는 비용을 지불하지 않는다. 물론, PaaS만큼은 아니지만, 한계는 있다.
- 단위의 세밀성(Granularity) : PaaS 애플리케이션은 일반적으로 애플리케이션별로만 확장되는 반면, CaaS를 기반으로 구축된 애플리케이션은 컨테이너별로만 확장된다. FaaS 애플리케이션은 별도의 기능으로 세분화되어 기능별로 확장된다. 단점은 자주 애플리케이션의 아키텍처를 다시 생각해야 한다는 것이다. 하나의 애플리케이션이나 몇 개의 컨테이너를 관리하는 대신 더 소규모 작업을 수행하는 많은 기능을 관리해야 하므로 많은 오케스트레이션 작업이 필요할 수 있다.
- 환경 구성(Configuration) : 확장할 때 보통은 환경을 구성해야 하거나 실행해야 하는 애플리케이션과 컨테이너의 인스턴스 수를 수동으로 설정해야 하는 곳에서도 FaaS는 환경을 다시 구성하거나 특정 리소스를 프로비저닝할 필요가 없다.
- 비용 모델 : 코드가 실제로 실행되는지 여부와 관계없이 비용을 지불하는 컨테이너 배치(CaaS)와 달리, FaaS는 각각의 기능을 호출할 때만 비용이 부과된다. 이렇게 사용한 만큼 지불하는 요금 모델은 서서히 서버리스 환경의 가장 중요한 측면으로 자리 잡고 있다.
- 한계 : 일반적인 애플리케이션에서는 코드에 대한 메모리 제한 또는 실행 시간 제한을 정의할 수 있다. FaaS 업체는 기업이 이런 식으로 리소스를 구성할 수 있도록 지원하지만, 서비스 업체가 이를 최적화하는 데는 상한선이 있기 마련이다. 10GB의 RAM으로 기능을 생성하거나 몇 시간 동안만 실행한다면, 몇 대의 서버를 확보해야 할지 생각해보면, FaaS 업체가 자원을 최대한 효율적으로 사용하는 것이 얼마나 어려운 일인지 알 수 있다.
새로운 엣지 아키텍처
서버리스 아키텍처는 프로비저닝과 확장에 대한 우려는 없앴지만 분산은 여전히 어려운 문제로 남아 있다. 이상적으로 보면, 지연 시간을 줄이기 위해서는 코드를 최종 사용자에게 가장 가까운 곳에서 실행하는 것이 좋다. 하지만 최근까지 애플리케이션을 구축해 온 방식에는 여러 가지 문제가 있다.- 로직 분산(Distributing logic) : 다른 리전에 기능이나 컨테이너를 배치하고 클라이언트를 가장 가까운 곳의 기능이나 컨테이너로 경로를 지정하지 않는 한, 기능은 일반적으로 하나의 데이터센터에 남아 있다.
- 동적 데이터 분산(Distributing dynamic data) : 데이터를 분산하지 않고 로직만 분산하는 것은 지연 시간이 다른 위치로 이동할 뿐이기 때문에 큰 이점이 없다. 사용자가 백엔드에 더 가까울 수도 있지만 백엔드는 데이터 계층에서 여전히 멀리 떨어져 있다.
- 비용, 구성, 모니터링 : 2개 또는 3개 이상의 지역에 분산된 애플리케이션은 드물다. 일반적으로 그렇게 분산하려면, 추가 비용이나 구성이 필요하며, 여러 지역에서 기능이나 컨테이너를 모니터링해야 하기 때문이다.
서버리스에서 다음 진화는 분산을 더 발전시켜 환경 구성 없이 전달하는 것이다. 이는 로직과 데이터가 전 세계 여러 지역에 분산되어 최종 사용자의 대기 시간을 효과적으로 최소화한다는 것을 의미한다.
CDN과 잼스택(Jamstack)
자동 분산을 제공하는 가장 기본적인 형태의 서비스가 있다. 바로 컨텐츠 전송 네트워크, CDN이다. 네틀리파이(Netlify)와 자이트(Zeit) 같은 몇몇 눈에 띄는 업체는 가능한 한 애플리케이션을 사전 생성하고, 동적인 부분은 서버리스 기능과 SaaS API로 처리함으로써 이미 자동 분산을 구현할 수 있다고 본다.네틀리파이가 ‘잼스택’이라고 이름을 붙인 이 접근방식이 요즘 인기를 얻고 있는데, CDN이 엣지 아키텍처의 이점을 맛볼 수 있도록 해주기 때문이다. 물론, 순전히 서버측 렌더링에 기반을 둔 잼스택에는 한계가 있다. 예를 들어, 새로운 수신 콘텐츠에 대해 빌드를 트리거해야 한다. 이 때문에 잼스택은 빌드 시간이 상당한 고도로 동적인 웹사이트에 적용하는 것이 매우 어렵다.
 |
<이미지를 클릭하시면 크게 보실 수 있습니다> |
클라이언트측 하이드레이션(Hydration)과 같은 증분 빌드 개념이 부분적인 해결책을 제공하지만, 결국 기업이 원하는 것은 복잡한 웹사이트가 최종 사용자를 위한 매우 낮은 지연 시간과 즉각적인 액세스가 가능한 새로운 콘텐츠라는 2가지 장점을 갖는 것이다.
분산형 서비스의 등장
많은 IT 전문가가 프런트엔드가 백엔드와 통신하고, 이어서 백엔드는 데이터베이스 및 다른 서비스와 통신하는 아키텍처를 기반으로 성장했다. 백엔드와 데이터베이스는 종종 백엔드와 데이터베이스 사이의 지연 시간을 낮게 유지하기 위해 함께 확장된다. 분산은 가능하지만 번거롭고, 그래서 제한적이다. |
<이미지를 클릭하시면 크게 보실 수 있습니다> |
미래의 아키텍처에서는 다른 분산 서비스를 이용함으로써 잼스택의 아이디어가 새로운 단계로 발전해 나갈 것이다. 각각의 서비스는 노드가 반드시 다른 서비스와 동일한 데이터센터에 있을 필요가 없는 분산 네트워크가 될 것이다. 대기 시간을 절대적으로 줄이기 위해 프론트엔드가 데이터베이스 및 기타 서비스 네트워크와 통신할 수 있도록 보안 모델을 재고해야 한다.
 |
<이미지를 클릭하시면 크게 보실 수 있습니다> |
이런 것을 가능하게 하는 서비스에 대해 살펴보자.
분산 서비스 네트워크
알골리아(Algolia)와 센드그리드(SendGrid)와 같은 많은 SaaS 플랫폼은 다른 애플리케이션의 빌딩 블록이 되는 것을 목표로 한다. 이들은 일반적인 백엔드 애플리케이션에서 특정한 우려사항을 제거한 특정 서비스를 개발한다. 이들 중 일부는 스스로를 DSN(Distributed Search Network)이라고 부르는 알골리아와 같은 분산 서비스로 진화하고 있다. 많은 다른 Saas 플랫폼이 뒤따를 것이고, 조만간 SaaS 애플리케이션의 다음 발전 방향으로 분산 서비스 네트워크에 대해 이야기할 가능성이 있다.
분산 서버리스 데이터베이스
애저 코스모스 DB, 구글 클라우드 스패너 및 파우나DB와 같은 데이터베이스는 종량제 방식의 서버리스 모델을 채택하고, ACID 보증을 통해 뛰어난 분산 환경을 제공한다. 일부 데이터베이스는 보안 계층과 기본적인 GraphQL API를 제공하여 클라이언트 애플리케이션에서 안전하게 사용할 수 있으며, 서버리스 백엔드로 원활하게 작동한다. 보안 계층은 사용자 인터페이스가 백엔드만 사용하는 대신에 데이터베이스와 직접 상호 작용하는 것을 가능하게 한다. 이상적으로 프런트엔드 애플리케이션은 데이터베이스가 거의 로컬에서 실행되고 있는 것처럼 대기 시간이 낮고 ACID 보증이 있는 전세계적으로 분산된 데이터베이스와 통신할 수 있다.
분산 서버리스 엣지 컴퓨팅
클라우드플레어 워커(Cloudflare workers), 스택패스 서버리스 스크립팅(StackPath Serverless Scripting) 같은 새로운 서버리스 기능은 서버리스 기능을 엣지로 밀어내고 있다. 이들 서비스는 지연 시간을 절대적인 줄이기 위해 최종 사용자와 가장 가까운 곳에서 기능을 제공하는 것을 목표로 한다. 클라우드플레어 워커는 194개, 스택패스는 45개 이상의 PoP를 보유하고 있다.
새로운 엣지 아키텍처가 주목을 받는 이유는 분명하다. IaaS에서 엣지 서버리스로의 변환이라는 진화를 고려할 때 한 가지 장애물이 있는데, 바로 동적 데이터 처리 방안이다. 비교적 정적인 데이터를 호스팅하는 아마존 S3와 같은 서비스를 이용하고 있지만, 실제 데이터베이스는 서버리스 경험을 제공하는 데 어려움을 겪고 있다. 매우 일관된 분산 시스템을 구축하는 것이 믿기 어려울 만큼 힘들기 때문이다.
 |
<이미지를 클릭하시면 크게 보실 수 있습니다> |
오늘날, 우리는 내장 보안 기능을 갖춘 서버리스 데이터베이스를 이용하고 있다. 이 데이터베이스는 새로운 종류의 애플리케이션으로 향하는 문을 열었는데, 바로 기본 설정상 전세계적으로 분산된 방식으로 확장하는 애플리케이션이다. 이 문이 열린 후, 많은 개발자가 백엔드의 일부를 마이크로서비스와 API로 대체할 방법을 찾기 시작했고, 많은 SaaS 업체에 새로운 시장을 열어주었다.
최종 목적지는 레고처럼 작동하는 빌딩 블록의 생태계가 될 것이다. 곧 개발자는 필요한 빌딩 블록을 결합하면서 확장이나 분산에 대한 걱정은 더 이상 하지 않을 것이다. editor@itworld.co.kr
Brecht De Rooms editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지
이 기사의 카테고리는 언론사의 분류를 따릅니다.
기사가 속한 카테고리는 언론사가 분류합니다.
언론사는 한 기사를 두 개 이상의 카테고리로 분류할 수 있습니다.
언론사는 한 기사를 두 개 이상의 카테고리로 분류할 수 있습니다.
