Netlify Edge Functions 성능 읽기: V8과 Firecracker만 보면 놓치는 것

핵심 요약

• V8 isolate와 Firecracker microVM은 서로 다른 층위에서 실행 환경을 격리하는 기술입니다.
• 전체 응답 시간은 코드 실행에 걸리는 시간뿐 아니라 네트워크를 오가고 데이터를 기다리는 시간에도 영향을 받습니다.
• 사용자에게 가까운 실행 위치가 데이터베이스에서도 가까운 것은 아닙니다.
• 성능이 좋아진 이유를 실행 환경에서 찾으려면 네트워크와 캐시 등 다른 조건의 영향을 구분해야 합니다.

가벼운 실행 환경을 쓴다고 웹 서비스가 무조건 빨라지는 것은 아닙니다. Netlify Edge Functions의 성능을 이해하려면 엔진 이름만큼 요청이 거치는 경로도 살펴봐야 합니다. 요청이 어디로 이동하고, 어느 구간에서 기다리는지에 따라 응답 시간이 달라지기 때문입니다.

V8 isolate와 Firecracker는 같은 층위의 기술이 아닙니다

V8 isolate는 자바스크립트 엔진 안에서 실행 상태와 메모리 영역을 분리하는 단위입니다. 하나의 프로세스 안에 여러 실행 공간을 둘 수 있습니다. 함수마다 운영체제를 통째로 띄울 때보다 작은 단위로 실행 환경을 구성하는 방식입니다.

Firecracker microVM은 하드웨어 가상화를 이용하는 작은 가상머신입니다. 게스트 운영체제와 그 안의 프로그램을 실행합니다. 범용 가상머신에서 필요한 기능을 줄여 시작 시간과 자원 부담을 낮추도록 설계됐습니다.

두 기술 중 반드시 하나만 골라야 하는 것은 아닙니다. 서로 다른 층위에서 작동하므로 microVM 안에서도 V8을 실행할 수 있습니다.

‘isolate에서 microVM으로 바꿨다’는 설명을 접하면 실제로 무엇을 바꿨는지 살펴봐야 합니다. 자바스크립트 엔진을 바꿨을 수도 있고, 엔진을 감싸는 격리 방식이나 요청을 처리하는 구조를 바꿨을 수도 있습니다. 두 기술의 이름만으로 성능 차이를 설명하기는 어렵습니다.

코드는 그대로인데 응답은 5배 빨라질 수 있습니다

간단한 가상 사례로 계산해보겠습니다. 시작 비용과 기타 대기 시간은 생략했습니다.

어떤 요청이 네트워크를 오가고 응답을 기다리는 데 90ms를 쓰고, 코드를 실행하는 데 10ms를 쓴다고 가정하겠습니다. 전체 응답 시간은 100ms입니다.

실행 위치와 연결 경로를 바꿔 네트워크 관련 시간을 10ms로 줄였다고 해보겠습니다. 코드 실행에는 여전히 10ms가 걸리지만, 전체 응답은 20ms에 끝납니다. 응답 시간이 기존의 5분의 1로 줄었습니다.

응답 시간에 5배의 차이가 나도 코드를 실행하는 속도는 그대로입니다.

이런 상황에서는 실행 환경의 시작 비용이 조금 늘어도 전체 응답은 빨라질 수 있습니다. 네트워크에서 기다리는 시간이 줄어 추가 비용을 상쇄하기 때문입니다. ‘더 무거운 실행 환경인데 더 빠르다’는 결과도 이렇게 나올 수 있습니다.

다만 이 계산은 원리를 설명하기 위한 가상 사례입니다. 특정 플랫폼에서 성능이 좋아진 이유를 알려면 실제 측정값에서 어느 구간의 시간이 줄었는지 확인해야 합니다.

엣지는 사용자에게 가깝지만, 데이터에서는 멀 수 있습니다

엣지 컴퓨팅의 장점은 사용자와 가까운 곳에서 요청을 처리한다는 데 있습니다. 그런데 함수가 일을 끝내려면 다른 서버에서 데이터를 가져와야 할 때가 많습니다.

서울의 사용자가 서울 근처 함수에 접속한다고 해보겠습니다. 이 함수가 미국에 있는 데이터베이스에 접속해야 한다면, 요청을 처리하는 동안 여전히 먼 거리를 오가야 합니다. 인증 정보를 확인한 뒤 주문 내역을 읽는 식으로 호출이 순서대로 이어지면 각 호출을 기다리는 시간도 쌓입니다.

반대로 함수가 데이터베이스 가까이 있으면 내부 통신에 걸리는 시간은 줄어들 수 있습니다. 대신 사용자와 함수 사이의 거리는 늘어날 수 있습니다.

어느 쪽이 유리한지는 함수가 하는 일에 달렸습니다. 간단한 리다이렉트를 처리할 때와 데이터를 여러 번 조회해 개인화 화면을 만들 때는 기다리는 구간부터 다릅니다.

따라서 사용자와의 거리만으로는 엣지 성능을 충분히 설명하기 어렵습니다. 함수가 데이터를 자주 주고받는 서버가 어디에 있는지도 함께 살펴봐야 합니다.

성능 개선을 읽을 때는 바뀐 조건부터 봐야 합니다

실행 환경을 옮기면서 다른 조건도 함께 바꿀 수 있습니다. 실행 리전이나 요청을 전달하는 중간 서버가 달라질 수 있고, 연결 재사용 방식이나 캐시 정책을 바꿔도 전체 응답 시간이 달라집니다.

여러 조건을 한꺼번에 바꿔 성능이 좋아졌다면 새 구성 전체가 낸 결과로 봐야 합니다. 그중 microVM이 얼마나 기여했는지 알려면 추가로 비교해야 합니다.

실행 환경 자체가 미친 영향을 보려면 같은 코드와 데이터 위치 등 주요 조건을 맞춰야 합니다. 네트워크 경로가 미친 영향을 보려면 실행 환경을 유지한 채 경로를 바꿔 비교해야 합니다.

무엇을 측정했는지도 살펴봐야 합니다. 실행 환경을 처음 준비하는 콜드 스타트와 이미 준비된 환경에서 처리하는 요청은 구분해야 합니다. 평균만 보지 말고 느린 요청은 얼마나 늦어지는지도 확인해야 합니다. 예를 들어 p95는 요청의 95%가 해당 시간 이내에 끝났다는 뜻입니다.

Netlify Edge Functions의 성능을 살펴볼 때도 요청의 어느 구간에서 시간이 줄었는지 확인해야 합니다. 실행 환경을 바꾼 효과와 네트워크 경로를 바꾼 효과를 나눠 보면 성능이 좋아진 이유를 이해할 수 있습니다. 서비스가 응답하는 동안 코드를 실행하는 데 시간이 걸리는지, 데이터가 돌아오기를 기다리는 데 시간이 걸리는지부터 살펴봐야 합니다.