So, @vercel reverted all edge rendering back to Node.js 😬 Wanted to correct the record here as it's something I've advocated for in the past, and share what I've learned since then. Also, the "edge" naming has been a bit confusing, so let's clear that up here as well. What is…
2분
왜 Vercel은 Edge 렌더링을 다시 Node.js 로 되돌렸을까?
들어가면서
저는 얼마전부터 edge 컴퓨팅, edge 런타임, edge Function 등 edge
서비스에 대해서 관심을 가지고 있었습니다.
사실 edge
라는 용어에 대한 느낌, 뉘앙스, 의미 등이 헷갈리는 부분이 조금은 있습니다.
제가 이해한 바로는 클라이언트와 가까운 곳에서 실행하여 더 빠른 사용자 경험을 제공하기 위한 런타임(또는 컴퓨팅)이라고 이해하고 있습니다.
(즉, CDN 서버같은. 그런데 Dynamic을 곁들인)
사용자에게 점점 더 가까운 곳에서 서비스를 제공한다면 더 빠를 것이라고 저도 예상했습니다. 그런데 edge 로 바꾼다면 더 빨라져야 되었을 거 같은데 사실은 그렇지 않았다고 Vercel의 Lee Robinson이 트윗을 했네요.
그 내용을 옮겨보았습니다.
최근에 Vercel은 모든 edge 렌더링을 Node.js로 되돌렸습니다.
edge
라는 명칭이 꽤 혼란스러웠기 때문에, 여기에서 이를 명확히 하려고 합니다.
edge가 무엇일까요? (edge 이름이 들어간 제품이 너무 많습니다. 😅)
먼저, Vercel에 Edge Network가 있습니다. 사이트에 요청이 들어오면 edge 영역은 사이트에 필요한 HTML, JavaScript를 가져와서 신속하게 응답할 수 있습니다.
라우팅 룰을 사용하는 경우가 있습닌다. 사이트에 요청이 들어오면 리디렉션하거나 다른 곳으로 프록시하거나 미들웨어처럼 headers에 값을 추가할 수도 있습니다.
파일에서 라우팅 또는 설정 룰을 읽어야할 경우가 있습니다. (모든 리전에서 동일 JSON 파일을 읽는 것, 예를 들어 Edge Config)
위 3가지 케이스 모두 좋습니다.
그럼 이제 edge로 애플리케이션을 렌더링하는 것은 어떨까요?
그다지 좋지 않습니다...
처음에는 사이트 방문자와 가까운곳에서 실행하는 것이 좋게 보였습니다.
(이론적으로) 사이트가 제한된 런타임을 사용하고 Node.js 패키지 에코시스템에 액세스한다고 하면 더 나은 성능을 얻을 수 있습니다.
하지만 이 방법은 두 가지 이유로 효과가 없었습니다.
첫째, 가장 명백한 이유는 컴퓨팅은 데이터베이스에 가까워야 한다는 것입니다.
대부분의 데이터는 전 세계에 복제되지 않습니다.
여러 region(us-east
데이터베이스에 연결되는)에서 컴퓨팅을 실행하는 것은 의미가 없었습니다.
그렇다면 데이터베이스와 가까운 곳에서 실행하면 이 제한된 런타임이 더 낫지 않을까요?
이 또한 잘못된 생각이었습니다. v0로 광범위하게 테스트한 결과, Vercel Function(1 vCPU 옵션, Vercel "표준" 성능)에 대해 Node.js 런타임을 사용하면 startup 속도가 더 빨라졌습니다.
edge rendering에 다른 이유가 있는걸까요?
컴퓨팅이 실행될 때만 비용을 지불하고 I/O가 발생하지 않는 edge 컴퓨팅 요금 모델이 항상 더 저렴할 것이라고 예상했습니다.
하지만 이 역시 틀린 예상이었습니다. 더 저렴한 경우도 있습니다! 하지만 모든 경우에 적용되는 것은 아닙니다.
보안도 마찬가지입니다. 고객들은 다른 서비스(예: Vercel Secure Compute)에 대한 브라이빗 연결을 원하거나 글로벌 데이터 복제(예: 데이터 주권)에 대한 우려(또는 관심없음)가 있다고 계속해서 말했습니다.
또한 네트워크가 정말 많이 빨라졌습니다. edge rendering보다 Node.js로 SSR + 스트리밍하는 것이 v0를 통해 더 빠르다는 것을 확인했습니다.
edge rendering이 더 나은지/나쁜지 알아보기 위해 v0를 Partial Pre-Rendering과 함께 확인해보고 있습니다.(아직 실험중입니다)
Partial Pre-Rendering(PPR):
- 사용자가 요청을 할 때,
- edge 영역에서 빠른 초기 비주얼을 위해 HTML을 스트리밍하고,
- 컴퓨팅은 여전히
us-east
또는 데이터와 가까운 곳에서 실행됩니다.
지금까지는 SSR + 스트리밍보다 TTFB가 50% 더 빠릅니다!
마무리하여
처음 edge 컴퓨팅을 보았을 때 완벽하게 이해하진 못했지만 앞으로 미래에 많이 사용하게 될 거라고 예상했습니다. 모든 것을 해결해줄 마법 같은 해결책은 아니지만 성능, 비용, 보안 같은 측면에서 좋은 해결책이 될 거라고, 그리고 조만간 많은 부분 edge 컴퓨팅을 사용하게 될 거라고 예상했습니다. 그런데 Vercel의 모든 edge 렌더링을 node.js 런타임으로 다시 되돌렸다는 사실이 꽤 놀라웠습니다.
특히, 데이터와 컴퓨팅의 위치적 접근성이 성능에 중대한 영향을 미치는 결과가 나타났습니다. 생각해보면 어느정도 예상이 가능했지만 그보다 더 영향도가 크다는게 이번에 알게되었습니다.
이번 트윗을 보면서 기술이 제공하는 이점만을 볼게 아니라 그 한계를 이해하고, 현실적인 부분을 생각해보아야 한다는 것을 느꼈습니다. Vercel이 edge 서비스를 안한다는 것은 아니지만 기술적 향상을 위해 노력은 계속 될 것입니다. edge 컴퓨팅은 앞으로 많이 사용될 것이며, Vercel의 이런 노력이 기대가 되는 부분이기도 합니다.
reference
마지막 업데이트
4/29/2024