본 콘텐츠는 사용자의 편의를 고려해 자동 기계 번역 서비스를 사용하였습니다. 영어 원문과 다른 오류, 누락 또는 해석상의 미묘한 차이가 포함될 수 있습니다. 필요하시다면 영어 원문을 참조하시기를 바랍니다.
지난 4월, 저희는 Cloudflare에서 글로벌 가상 프라이빗 클라우드에 대한 비전을 공유했습니다.
오늘, 우리는 Workers VPC 이니셔티브의 첫 번째 이정표인 VPC 서비스를 발표합니다. VPC 서비스를 사용하면 전 세계 어디에서나 실행되는 Workers 에서 Cloudflare Tunnels 을 통해 지역 사설 네트워크에 있는 APIs, 컨테이너,가상 머신, 서버리스 기능, 데이터베이스 및 기타 서비스에 연결할 수 있습니다.
원하는 네트워크에 Tunnel을 설정한 후에는 호스트 또는 IP 주소를 구성하여 Workers에 노출하려는 각 서비스를 등록할 수 있습니다. 그러면 다른 Workers 서비스 바인딩 처럼 VPC 서비스에 액세스할 수 있습니다. Cloudflare의 네트워크는 Worker가 실행하는 위치와 관계없이 Cloudflare의 네트워크를 통해 VPC 서비스에 자동으로 라우팅합니다.
export default {
async fetch(request, env, ctx) {
// Perform application logic in Workers here
// Call an external API running in a ECS in AWS when needed using the binding
const response = await env.AWS_VPC_ECS_API.fetch("http://internal-host.com");
// Additional application logic in Workers
return new Response();
},
};
이제 Workers VPC를 사용하는 모든 사람은 Cloudflare Tunnel과 마찬가지로 베타 기간 동안 추가 비용 없이 Workers를 사용할 수 있습니다. 지금 사용해 보세요. 아래에서 작동 방식을 자세히 알아보세요.
애플리케이션은 온프레미스 또는 외부 클라우드에 관계없이 여러 네트워크에 걸쳐 있습니다. 하지만 Workers에서 사설 네트워크로 보호되는 APIs 및 데이터베이스에 연결하기가 어려웠습니다.
지금까지는 기존의 가상 프라이빗 클라우드와 네트워크가 기존 클라우드에 어떻게 고정되는지 설명했습니다. 워크로드 격리 및 보안을 제공하지만, 기존 가상 프라이빗 클라우드의 경우 여러 클라우드에 구축하고, 자체 애플리케이션에 액세스하며, 스택에 적합한 기술을 선택하는 것이 어려워집니다.
클라우드 종속의 상당 부분은 안전하고 분산된 워크로드를 구축하는 데 내재된 복잡성입니다. VPC 피어링에서는 연결을 보장하기 위해 클라우드 전반의 네트워킹에 의존하므로 라우팅 테이블, 보안 그룹, 네트워크 액세스 제어 목록을 구성해야 합니다. 많은 조직에서 이는 승인을 얻기 위해 몇 주 동안 논의하고 많은 팀이 참여하는 것을 의미합니다. 이러한 종속은 복잡성을 해결하기 위해 발명된 솔루션에도 반영되어 있습니다. 각 클라우드 공급자마다 교차 네트워크 연결을 용이하게 하기 위해 자체 맞춤형 버전의 "Private Link"를 보유하고 있으므로, Cloudflare와 통합한 해당 클라우드 및 벤더에 더 많이 제한됩니다. 확인할 수 있습니다.
Workers VPC를 통해, 저희는 이 작업을 극적으로 간소화하고 있습니다. 사설 네트워크에 액세스하는 데 필요한 권한으로 Cloudflare Tunnel을 한 번 설정하면 됩니다. 그런 다음 Workers에 노출하려는 서비스의 터널 및 호스트 이름(또는 IP 주소 및 포트)으로 Workers VPC 서비스를 구성할 수 있습니다. 해당 VPC 서비스에 대한 모든 요청은 이 구성을 사용하여 네트워크 내의 지정된 서비스로 라우팅합니다.
{
"type": "http",
"name": "vpc-service-name",
"http_port": 80,
"https_port": 443,
"host": {
"hostname": "internally-resolvable-hostname.com",
"resolver_network": {
"tunnel_id": "0191dce4-9ab4-7fce-b660-8e5dec5172da"
}
}
}
이렇게 하면 Workers VPC 서비스로 표현되고 나면 사설 네트워크의 서비스가 Workers 바인딩 모델을 사용하여 다른 Cloudflare 바인딩과 동일한 방식으로 보호될 수 있습니다. 간단한 VPC 서비스 바인딩 예시를 살펴보겠습니다.
{
"name": "WORKER-NAME",
"main": "./src/index.js",
"vpc_services": [
{
"binding": "AWS_VPC2_ECS_API",
"service_id": "5634563546"
}
]
}
다른 Workers 바인딩과 마찬가지로, VPC 서비스에 연결을 시도하는 Worker 프로젝트를 배포하면 배포 시 액세스 권한을 확인하여 Worker가 문제의 서비스에 액세스할 수 있는지 확인합니다. 일단 배포되면 Worker는 VPC 서비스 바인딩을 사용하여 해당 VPC 서비스 및 네트워크 내의 해당 서비스에만 요청할 수 있습니다.
이는 전체 네트워크를 Worker에 노출하는 대신, Worker가 특정 VPC 서비스에만 액세스할 수 있도록 하는 것입니다. 이 액세스는 배포 시 확인되어 기존 네트워크 및 액세스 제어 목록보다 더 명시적이고 투명한 서비스 액세스 제어를 제공합니다.
이는 Workers 바인딩 설계의 핵심 요소입니다. 관리가 더 간단한 사실상 보안을 유지하고 Workers를 서버 측 요청 위조(SSRF) 공격으로부터 보호하는 것입니다. 우리는 과거의 바인딩 보안 모델을 심층적으로 다루었고, 사설 네트워크에 액세스할 때 훨씬 더 중요해졌습니다.
특히, Workers가 Cloudflare의 전역 네트워크에서 실행되는 스크립트를 고려할 때 바인딩 모델도 중요합니다. 기존의 클라우드와 달리 IP 주소를 가진 개별 컴퓨터가 아니며, 네트워크 내에 존재하지 않습니다. 바인딩은 Cloudflare 계정 내의 다른 리소스에 대한 보안 액세스를 제공하며, Workers VPC 서비스에도 동일하게 적용됩니다.
그렇다면 VPC 서비스와 해당 바인딩은 Cloudflare의 전역 네트워크 상의 Workers의 네트워크 요청을 터널을 사용하는 지역 네트워크로 어떻게 라우팅할까요? 이제 VPC 서비스의 전용 fetch() 요청에서 나온 샘플 HTTP 요청의 수명 주기를 살펴보겠습니다.
이 모든 것은 Worker 코드에서 시작되며, 여기에서 .fetch() 표준 JavaScript 요청과 함께 호출됩니다(1단계). Workers 런타임은 다른 많은 Workers 바인딩과 마찬가지로 Cap'n Proto 원격 절차 호출을 사용하여 원래 HTTP 요청을 추가 컨텍스트와 함께 보냅니다.
VPC 서비스 시스템의 바인딩 Worker는 바인딩 컨텍스트와 함께 HTTP 요청을 수신합니다(이 경우에는 호출되는 VPC 서비스의 서비스 ID). 바인딩 Worker는 HTTP CONNECT 연결 내의 Iris 서비스에 이 정보를 프록시 설정합니다. 이는 Cloudflare의 바인딩 전반에 걸쳐 표준 패턴으로, Workers 런타임 자체가 아닌 Worker 코드 내에서 Cloudflare의 에지 서비스에 대한 연결 로직을 배치하기 위한 것입니다(2단계).
Iris 서비스는 Workers VPC의 기본 서비스입니다. 그 역할은 VPC 서비스에 대한 요청을 수락하고 이를 VPC 서비스가 있는 네트워크로 라우팅하는 것입니다. Cloudflare One은 내부 서비스인 Apollo 와 통합하여 이를 수행합니다. 아폴로는 다양한 네트워킹 계층에 걸쳐 네트워크와 터널에 안전하게 연결하는 복잡성을 해소하는 통합 인터페이스를 제공합니다.
Iris가 아폴로와 통합하려면, 두 가지 작업을 완료해야 합니다. 먼저, Iris는 메타데이터에서 VPC 서비스 ID를 구문 분석하고 구성 저장소에서 이와 연결된 터널의 정보를 가져옵니다. 여기에는 구성 저장소(3단계)의 터널 ID와 유형이 포함되며, 이는 홍채가 원래 요청을 올바른 터널로 보내는 데 필요한 정보입니다.
둘째, Iris는 VPC 서비스 호스트 이름의 A 및 AAAA 레코드에 대한 DNS 질문을 포함하는 UDP 데이터그램을 생성합니다. 이 데이터그램은 먼저 아폴로를 통해 전송됩니다. DNS 확인이 완료되면 확인된 IP 주소 및 포트와 함께 원래 요청이 전송됩니다(4단계). 이는 4~7단계가 첫 번째 요청에 대해 차례로 두 번 발생한다는 것을 의미합니다. 한 번은 DNS 확인을 위한 것이고 두 번째는 원래 HTTP 요청을 위해서입니다. 후속 요청은 Iris의 DNS 확인 정보 캐싱을 활용하여 요청 대기 시간을 최소화합니다.
5단계에서 아폴로는 DNS 확인 UDP 데이터그램 또는 HTTP 요청 TCP 패킷과 함께 액세스해야 하는 Cloudflare Tunnel의 메타데이터를 수신합니다. 터널 ID를 사용하여 Cloudflare Tunnel에 연결된 데이터 센터를 결정합니다. 이 데이터 센터는 Cloudflare Tunnel과 가까운 지역에 있으므로, 아폴로는 DNS 확인 메시지와 원래 요청을 해당 데이터 센터에서 실행 중인 Tunnel Connector 서비스로 라우팅합니다(5단계).
Tunnel Connector 서비스는 나머지 Cloudflare 네트워크에 Cloudflare Tunnel에 대한 액세스를 제공하는 역할을 합니다. DNS 확인 질문을 받은 후 원래 요청이 QUIC 프로토콜을 통해 터널에 전달됩니다(6단계).
마지막으로 Cloudflare Tunnel이 속한 네트워크의 DNS 확인자에게 DNS 확인 질문을 보냅니다. 그런 다음 자체 IP 주소에서 원래 HTTP 요청을 대상 IP 및 포트로 보냅니다(7단계). 요청의 결과는 터널에 가장 가까운 데이터 센터로부터 Worker 요청을 실행하는 원래 Cloudflare 데이터 센터까지 원래 Worker에게 다시 전달됩니다.
이를 통해 Cloudflare에 구축할 수 있는 완전히 새로운 애플리케이션의 영역을 확보할 수 있습니다. 수년간 Workers는 에지에서 두각을 발휘했지만, 대부분 핵심 인프라 "외부"에 있었습니다. 퍼블릭 엔드포인트만 호출할 수 있어, 비공개 계정 API 또는 내부 인벤토리 데이터베이스와 같이 스택의 가장 중요한 부분과 상호 작용하는 기능이 제한됩니다. 이제 Workers는 VPC 서비스를 통해 이러한 비공개 APIs, 데이터베이스, 서비스에 안전하게 액세스하여 가능성을 근본적으로 변화시킬 수 있습니다.
이렇게 하면 Cloudflare Workers 및 AWS, GCP, Azure 등의 다른 클라우드에 걸친 진정한 크로스 클라우드 애플리케이션을 즉시 사용할 수 있습니다. 저희는 많은 고객이 비공개 베타 기간 동안 이 패턴을 채택하여 외부 클라우드와 Cloudflare Workers 사이에 비공개 연결을 수립하는 것을 확인했습니다. Cloudflare는 심지어 이를 직접 수행했으며, 다수의 Cloudflare 서비스에 대해 제어판 APIs를 구동하기 위해 Workers를 코어 데이터 센터의 Kubernetes 서비스에 연결했습니다. 이제 여러분은 이미 신뢰하고 있는 네트워크에 스테이트풀 백엔드를 유지하는 동시에 글로벌 규모로 Workers를 사용하여 똑같이 강력한 분산 아키텍처를 구축할 수 있습니다.
즉, Workers에서 온프레미스 네트워크에 연결하여 Workers의 성능과 무한한 확장성으로 레거시 애플리케이션을 최신화할 수 있습니다. 더욱 흥미로운 것은 개발자 워크플로에 대한 새로운 사용 사례입니다. 저희는 개발자가 노트북에서 cloudflared 를 실행하여 실시간 디버깅을 위해 배포된 Worker를 다시 로컬 컴퓨터에 연결하는 것을 확인했습니다. Cloudflare Tunnel의 완전한 유연성은 이제 Worker에서 직접 액세스할 수 있는 프로그래밍 가능한 기본 요소로, 다양한 가능성을 제공합니다.
VPC 서비스는 더 큰 Workers VPC 이니셔티브의 첫 번째 이정표이지만, 이제 이제 시작입니다. 우리의 목표는 전 세계 어디에서나 모든 서비스와 네트워크에 원활하게 연결하는 것을 Workers 경험으로 만드는 것입니다. 다음과 같은 작업을 진행하고 있습니다.
심층 네트워크 통합. Cloudflare Tunnel로 시작한 것은 신중한 선택이었습니다. 가용성이 높고, 유연하며, 친숙한 솔루션으로 구축하기에 완벽한 기반입니다. 엔터프라이즈 네트워킹을 위한 더 많은 옵션을 제공하기 위해 표준 IPsec 터널, Cloudflare 네트워크 상호 연결(CNI), AWS Transit Gateway에 대한 지원을 추가하여 더 많은 선택권과 잠재적인 최적화를 여러분과 여러분의 팀에 제공할 예정입니다. 결정적으로, 이러한 연결은 양방향이 되어, 사설 서비스가 Queues로 이벤트를 푸시하거나 R2에서 가져오는 등 Cloudflare 리소스로 다시 연결할 수 있게 됩니다.
프로토콜 및 서비스 지원 확장. HTTP의 다음 단계는 TCP 서비스에 대한 액세스를 활성화하는 것입니다. 이를 위해서는 먼저 Hyperdrive와 통합해야 합니다. 저희는 Cloudflare Access를 추가하고 보안 토큰을 관리할 필요가 없도록 개인 데이터베이스에 대한 Hyperdrive 지원을 VPC 서비스 구성을 통해 간소화하도록 진화시키고 있습니다. 이렇게 하면 Hyperdrive의 강력한 연결 풀링이 완성되어 더욱 자연스러운 경험이 만들어집니다. 이후 저희는 원시 TCP 연결에 대한 지원을 더 광범위하게 추가하여 Workers 'connect()'에서 Redis 캐시 및 메시지 대기열과 같은 서비스에 대한 직접 연결을 제공할 예정입니다.
생태계 호환성. 저희는 비공개 서비스에 대한 연결을 공개 서비스에 연결하는 것처럼 자연스럽게 느끼기를 원합니다. 이를 위해 각 Workers VPC 서비스에 대해 Hyperdrive의 연결 문자열과 유사하게 자동 생성된 고유 호스트 이름을 제공할 예정입니다. 이렇게 하면 호스트 이름이 필요할 수 있는 기존 라이브러리 및 개체 관계 매핑 라이브러리와 함께 Workers VPC를 더 쉽게 사용할 수 있습니다(예: 글로벌 'fetch()' 호출 또는 MongoDB 연결 문자열에서). Workers VPC 서비스 호스트 이름은 'fetch() '명령과 마찬가지로 자동으로 확인되어 올바른 VPC 서비스로 라우팅합니다.
오늘 Workers VPC 서비스를 오픈 베타로 출시하게 되어 기쁩니다. 저희는 Workers의 첫 번째 이정표를 비공개 네트워크 액세스로 구축하고 테스트하는 데 몇 달을 보냈습니다. 또한 클로즈드 베타 기간 동안 내부 팀과 고객이 제공한 피드백을 바탕으로 더욱 개선되었습니다.
이제 오픈 베타 기간 동안 무료로 제공되는 Workers VPC를 통해 모두가 Workers에서 크로스 클라우드 애플리케이션을 구축할 수 있게 되기를 기대하고 있습니다. Workers VPC를 사용하면 사설 네트워크의 앱을 사용자와 더 가까운 지구 지역으로 가져올 수 있으며 전 세계의 Workers가 사용할 수 있습니다.
지금 무료로 Workers VPC 서비스를 시작하세요.