Service Bindings를 사용하면 하나의 Vercel 서비스가 동일한 배포 내의 다른 서비스를 안전하게 호출할 수 있습니다.

한 서비스가 다른 서비스에 대한 바인딩 (binding)을 선언하면, Vercel은 구성된 환경 변수 (environment variable)를 자동으로 주입합니다. 즉, 사용자 코드는 해당 URL을 평소처럼 호출할 수 있으며, Vercel은 내부적인 재작성 (rewrite), 라우팅 (routing), 인증 (authentication) 및 TLS를 백그라운드에서 처리합니다.

이를 통해 Next.js 프론트엔드가 FastAPI 백엔드를 호출하는 것과 같이 Vercel에서 멀티 서비스 애플리케이션을 구현할 수 있으며, 서비스 격리 (service isolation)를 유지하면서 라우팅 설정을 단순하게 유지할 수 있습니다:

위의 예시에서, my_frontend는 fetch(BACKEND_INTERNAL_URL)를 호출함으로써 my_backend 서비스에 도달할 수 있습니다.

FastAPI 측에서는 my_backend가 일반적인 경로 (route)를 노출합니다:

이 URL은 공개 주소가 아닌 Vercel 내부를 가리킵니다. 코드가 이를 호출하면, 요청은 Vercel의 내부 네트워크를 통해 배포에 대한 다른 모든 요청을 처리하는 동일한 라우팅 계층으로 전달되며, 해당 계층이 대상 서비스로 요청을 보냅니다. 이 요청은 공개 라우팅 테이블 (public route table)을 거치지 않으며, Vercel이 TLS 신뢰 설정을 대신 해주므로 별도의 인증서 설정 없이 일반 HTTPS가 작동합니다.

서비스는 재작성 경로 (rewrite route)를 통해 공개적으로 노출하거나, 바인딩 (binding)을 통해 비공개로 노출하는 경우에만 도달 가능합니다.

서비스 간 호출 (Service-to-service calls)은 관측성 (observability)에도 나타나므로, 어떤 바인딩된 서비스가 호출되었는지와 요청이 얼마나 걸렸는지 확인할 수 있습니다:

서비스 간 호출은 Service Requests 및 Fast Origin Transfer로 과금됩니다. 이는 CDN Requests 또는 Fast Data Transfer로 과금되지 않습니다. 현재 요율은 services pricing and limits를 참조하세요.

바인딩을 선언하는 방법은 bindings documentation에서 읽어보시고 전체 참조를 확인하세요.

더 읽어보기

내부 동작 원리 (Under the hood)

관측성 (Observability)

요금 (Pricing)

더 알아보기 (Learn more)