-
웹 생태계의 변화를 가져다 줄 Edge Computing개발 블로깅/Web EcoSystem 2023. 9. 26. 17:09
최근 웹 서비스 운영 생태계의 변화를 가져다 줄 운영 매커니즘으로 Edge Computing이 많이 거론되고 있다.
아직은 일반적인 웹 서버의 운영이, 동적인 데이터 변경과 Dynamic한 Server Side Rendering 처리로 인해 기존의 Origin Server가 위치한 곳까지 네트워크 요청을 하며 느린 응답을 받는 형식을 띄고 있다.
그나마 퍼포먼스 향상을 위해 정적인 컨텐츠 파일들은 CDN 서버와 캐싱 처리를 통해서 빠르게 전송을 할 수 있다. 특히나 이미지 또는 영상 같은 컨텐츠는 용량 사이즈가 매우 커서, 이러한 문제를 해결해주는 CDN이 가져다주는 퍼포먼스 효과는 굉장하다.
그러나 동적인 컨텐츠 영역을 위해 Original Server까지 요청이 다다라야 하는 문제는 여전히 해결되지 않는 중에, Edge Computing이라는 개념이 등장하기 시작했고, 이는 웹 서비스 운영에 대한 변화를 만들 수 있을 것이라는 내용들이 나오고 있으며, 이미 Vercel, CCP 등 플랫폼에서는 이러한 Edge Computing에 대한 기능을 제공하고 있는 중이다.
뿐만 아니라 이러한 Javascript RunTime 환경의 개선에 포커싱하고 모인 그룹도 있을 정도로 Edge Computing이 앞으로 웹 서비스 생테계에 큰 전망을 가지고 있음이 분명하다.
그러나 Edge Computing에 대해 알아보면서 Edge Computing이 결국 CDN인가? Serverless인가? 하며 여간 헷갈렸던 내용들이 한,두 가지가 아니다.
그래서 이번에 Edge Computing에 대한 개념을 제대로 알 수 있도록 아래에 한번 정리를 해보았다.CDN과 Edge Computing의 차이
우선 CDN과 Edge Computing은 글로벌하게 유저들과 물리적으로 가까운 거리에 서버를 구축 시키고 빠르게 요청에 대한 응답 데이터를 전송한다는 공통점을 가지고 있다.
CDN
CDN은 RuntTime 환경을 지원하는 것이 아닌, 단순 정적 파일을 빠르게 전송시키는 목적만을 가지고 있다.
그래서 일반적으로 이미지나 동영상, JS 코드 등을 요청해서 빠르게 다운로드를 가능하도록 하기 때문에 우리가 구현한 웹 서버를 CDN에 배포할 수 없다.Edge Computing
이와 반대로, 글로벌하게 여러 지역의 서버에서 우리가 구축한 웹 서버를 배포할 수 있도록 해주는 것이 바로 이 Edge Computing이다.
글로벌 곳곳에 있는 유저에게 가까운 위치에 있는 서버에서 코드를 실행 시키고 캐싱할 수 있다.기존에 하던 Client-Side와 Server-Side 작업을 Edge로 옮기는 것만으로도 Application의 Performance를 크게 향상시킬 수 있다.
위 내용처럼 CDN과 Edge Computing이 각각 다른 목적성을 가진 클라우드 서버임을 알게 되었다.
그런데 Serverless의 어떤 기능과 너무 똑같다?
그런데 문득, Edge Computing이 AWS에서 제공하는 Serverless Lambda@Edge와 너무 비슷하다는 생각이 들었다.Lambda@Edge도 AWS의 CDN인 CloudFront 자체에 Function을 배포함으로써 물리적으로 각 지역에 가까운 서버에서 코드를 실행시키고 응답데이터를 전송하는 역할을 하지 않는가.
그러면 Edge Computing은 Serverless의 개념인걸까?
아니라면 Edge Computing이 Serverless와 어떤 차이가 있는걸까?Serverless VS Edge Computing
서버 구동 방식
우선 Serverless는 요청이 없으면 동작하지 않는 Off 상태에서 요청이 오면 서버가 가동되면서 코드를 실행시키다가 한동안 요청이 없는 상태면 다시 Off가 된다. 따라서 Off에서 On이 되기까지의 Cold Start 시간을 가지고 있다.
반면에 Edge Computing은 일반적인 웹 서버와 비슷하게 최소한으로만 돌아가는 상태만 유지하고 있기 때문에 Cold Start가 길지 않고 빠르게 응답이 가능하다.
요금 산정 방식
Serverless는 요청에 따라 반응을 하기 때문에 일반적으로 요청 수를 기반으로 요금을 산정한다. 따라서 사용된 만큼 요금이 나간다.
Edge Computing은 얼만큼 사용했냐와 상관없이, 구축된 인프라 환경 및 성능 장치를 기반으로 요금이 산정된다.
위치
AWS의 Lambda@Edge처럼 Global하게 Serverless를 운영할 수도 있지만, 일반적으로 Serverless는 구현한 함수를 특정 Region에만 배포하여 실행되므로 Region-First 성향을 가지고 있다.
Edge Computing은 CDN과 동일하게 배포 자체가 모든 글로벌 서버들에 배포하여 운영하기 때문에 Global-First 성향을 가지고 있다. 그러나 Edge Computing에서 이러한 방식에 대해서 유의해야 할 것이 있는데, 제공되는 DataSource(예를 들어 백엔드 API 서버 혹은 데이터베이스 서버)가 물리적으로 멀다면 결국 Response가 느릴 수도 있기 때문에, 이러한 관련된 서버 위치도 같이 고려가 되어야 한다.
Isolation Boundary
각 인스턴스 별로 독립적인 부분에 대한 것인데, 인스턴스끼리 서로 간섭하지 않고 의존하지 않도록 해야 보안성을 높이고 안전한 실행 환경을 유지할 수 있다.
Serverless의 경우, 이러한 Isolation Boundary를 위해 일반적으로 MicroVM으로 환경이 구성되어 있는데, MicroVM은 강력한 보안을 유지할 수 있으나 실행 시작 속도를 느리게 하고, OS가 켜질 때 집약적인 리소스가 많이 들어가면서 Start 시간이 많이 드는 문제가 있다. 이는 Cold Start Time이 많이 드는 의 원인 중 하나이기도 하다.
반면에 Edge Runtime은 표준적으로 정해진 환경이 있는 것은 아니지만, Vercel이나 Azion의 경우에는 Isolation:V8을 이용하여 컴퓨팅 환경을 구성함으로써, 빠른 인스턴스 시작 속도를 유지하면서 더불어 퍼포먼스도 MicroVM보다 더 증가시킬 수 있다고 한다.
더보기💡 Isolate:V8이란
LightWeight하고 독립된 인스턴스 V8환경을 구축하기 위해 제공되는 기능.
https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_isolate.html위 내용 외에도 더 많은 차이점을 가지고 있겠지만, 어느정도 Serverless와 Edge Computing은 완전히 다른 환경이란 것을 알 수 있었다.
Edge Computing에 대한 개인 생각
세계 모든 지역에 물리적으로 유저와 가까운 곳에서 각기 경량화된 웹 서버를 운영하면서 서비스를 제공할 수 있다는 것은 정말 굉장한 패러다임이다. 빠른 응답 속도는 물론이고, 한 곳의 서버에서 글로벌하게 모든 트래픽을 받고 수행되는 것이 아닌 각 분산된 서버에서 처리를 하니, 대규모 트래픽 처리에 대한 문제도 같이 해결될 것 같다.
그러나 요즘에는 하나의 애플리케이션이 수행되기 위해서는 웹 서버, API 서버는 물론이고, 앞단의 Istio Proxy 서버, 웹 로그 서버 등 인터렉션이 많이 이루어진다. 웹 서버가 물리적으로 유저와 가까이 있는 상태에서 페이지를 제공할 수 있다고 해도, 뒷 단의 API가 여전히 멀리서 위치한다면 속도 면에서 기존과 큰 차이가 없을 것이다.
그래서 사실 상 웹 서버만 Edge Computing이 되어야 할게 아니라, 인터렉션이 일어나는 모든 서버들이 Edge Computing이 되어야 하지 않을까 싶다.
그렇다고 정말로 프록시 서버 같은 모든 서버들까지 Edge Computing 환경을 구성해버린다면, 인프라 비용이 정말 만만치 않을 것 같다.
정말로 크고 안정적인 서비스를 운영하기에는.. 아직은 좋은 사례를 기다려보아야 하지 않을까 생각이 든다.
Reference
반응형'개발 블로깅 > Web EcoSystem' 카테고리의 다른 글
Bun 1.0 릴리즈 후, 서비스 개발에 문제 없을지 리서치 해본 결과 (1) 2023.10.04 Node.js가 왜 싱글 스레드로 불리는지 "정확한 이유"를 알고 계신가요? (44) 2023.09.28