교차 클라우드 네트워크는 분산형 애플리케이션을 조합할 수 있는 아키텍처를 지원합니다. 교차 클라우드 네트워크를 사용하면 여러 클라우드 및 온프레미스 네트워크에 워크로드와 서비스를 배포할 수 있습니다. 이 솔루션은 애플리케이션 개발자와 운영자에게 여러 클라우드에 걸쳐 단일 클라우드의 경험을 제공합니다. 이 솔루션은 하이브리드 및 멀티 클라우드 네트워킹의 기존 사용 사례를 사용할 뿐 아니라 더욱 확장합니다.
이 가이드는 Cross-Cloud Network에서 분산형 애플리케이션을 설계하고 빌드하려는 네트워크 설계자와 엔지니어를 대상으로 작성되었습니다. 이 가이드에서는 Cross-Cloud Network 설계 고려사항을 포괄적으로 설명합니다.
네트워크 세분화 및 연결: Virtual Private Cloud(VPC) 세분화 구조 및 VPC 간 및 외부 네트워크에 대한 IP 연결을 포함합니다.
서비스 네트워킹: 부하 분산되고 프로젝트와 조직 전반에서 사용할 수 있는 애플리케이션 서비스의 배포가 포함됩니다.
네트워크 보안: 기본 제공되는 클라우드 보안 및 네트워크 가상 어플라이언스(NVA)를 사용하여 클라우드 내 및 클라우드 간 통신에 보안을 적용할 수 있습니다.
네트워크 세분화 및 연결
세분화 구조와 연결은 설계의 기초입니다. 다음은 통합 또는 세분화된 인프라를 사용하여 구현할 수 있는 VPC 세분화 구조를 보여주는 다이어그램입니다. 이 다이어그램은 네트워크 간의 연결은 보여주지 않습니다.
이 구조에는 다음 구성요소가 포함됩니다.
전송 VPC: 외부 네트워크 연결 및 라우팅 정책을 처리합니다. 이 VPC는 다른 VPC 간의 연결도 제공할 수 있습니다.
서비스 액세스 VPC: 다양한 서비스에 대한 액세스 포인트를 포함합니다. 이러한 VPC의 서비스 액세스 포인트는 다른 네트워크에서 연결할 수 있습니다.
관리형 서비스 VPC: 다른 항목에서 생성한 서비스를 포함합니다. 이 서비스는 Private Service Connect 또는 비공개 서비스 액세스를 사용하여 VPC 네트워크에서 실행되는 애플리케이션에 액세스할 수 있습니다.
애플리케이션 VPC: 조직에서 직접 만들고 호스팅하는 소프트웨어 서비스를 구성하는 워크로드가 포함됩니다.
애플리케이션 VPC의 세분화 구조 선택은 필요한 애플리케이션 VPC의 규모, Cross-Cloud Network 또는 외부에 경계 방화벽을 배포할 계획인지 여부와 중앙 또는 분산 서비스 게시 선택에 따라 달라집니다.
교차 클라우드 네트워크는 리전 애플리케이션 스택 및 전역 애플리케이션 스택의 배포를 지원합니다. 이러한 두 애플리케이션 복원력 아키타입은 모두 VPC 간 연결 패턴을 사용하는 제안된 세그먼테이션 구조로 지원됩니다.
Network Connectivity Center를 사용하거나 VPC 네트워크 피어링과 HA VPN 허브 및 스포크 패턴을 조합하여 VPC 간 연결을 구현할 수 있습니다.
DNS 인프라 설계는 연결 패턴과 관계없이 세그먼트화 구조의 컨텍스트에서도 정의됩니다.
서비스 네트워킹
다양한 애플리케이션 배포 아키타입은 서비스 네트워킹의 다양한 패턴으로 이어집니다. 크로스 클라우드 네트워크 설계의 경우 애플리케이션 스택이 둘 이상의Google Cloud 리전의 여러 영역에서 독립적으로 실행되는 멀티 리전 배포 원형에 중점을 둡니다.
멀티 리전 배포 원형에는 Cross-Cloud Network 설계에 유용한 다음과 같은 기능이 있습니다.
DNS 라우팅 정책을 사용해서 들어오는 트래픽을 리전 부하 분산기로 라우팅할 수 있습니다.
그런 다음 리전 부하 분산기가 애플리케이션 스택으로 트래픽을 분산할 수 있습니다.
DNS 장애 조치 라우팅 정책을 사용하여 애플리케이션 스택의 DNS 매핑을 다시 고정하여 리전 장애 조치를 구현할 수 있습니다.
멀티 리전 배포 원형의 대안은 전역 배포 원형입니다. 이 원형에서는 단일 스택이 전역 부하 분산기를 기반으로 빌드되고 여러 리전에 걸쳐 있습니다.
Cross-Cloud Network 설계로 작업할 때는 이 archetype의 다음 기능을 고려하세요.
부하 분산기는 사용자에게 가장 가까운 리전으로 트래픽을 분산합니다.
인터넷 연결 프런트엔드는 전역이지만 내부 연결 프런트엔드는 전역 액세스가 있는 리전이므로 장애 조치 시나리오에서 연결할 수 있습니다.
애플리케이션 스택의 내부 서비스 레이어에서 위치정보 DNS 라우팅 정책과 DNS 상태 점검을 사용할 수 있습니다.
관리형 게시 서비스에 대한 액세스를 제공하는 방법은 연결해야 하는 서비스에 따라 다릅니다. 다양한 비공개 도달 가능성 모델은 모듈화되어 있으며 애플리케이션 스택 설계와 직교합니다.
서비스에 따라 비공개 액세스에 Private Service Connect 또는 비공개 서비스 액세스를 사용할 수 있습니다. 기본 제공 서비스와 다른 조직에서 게시한 서비스를 결합하여 애플리케이션 스택을 빌드할 수 있습니다. 서비스 스택은 필요한 수준의 복원력과 최적화된 액세스 지연 시간을 충족하기 위해 리전 또는 전역일 수 있습니다.
조직에서 보안 또는 규정 준수 요구사항을 충족하기 위해 추가 고급 기능이 필요한 경우 차세대 방화벽(NGFW) 네트워크 가상 어플라이언스(NVA)를 삽입하여 경계 보안 방화벽을 통합할 수 있습니다.
단일 네트워크 인터페이스(단일 NIC 모드) 또는 다중 네트워크 인터페이스(다중 NIC 모드)를 통해 NGFW NVA를 삽입할 수 있습니다. NGFW NVA는 보안 영역 또는 클래스 없는 도메인 간 라우팅(CIDR) 기반 경계 정책을 지원할 수 있습니다.
교차 클라우드 네트워크는 전송 VPC 및 VPC 라우팅 정책을 사용하여 경계 NGFW NVA를 배포합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-01-30(UTC)"],[[["\u003cp\u003eCross-Cloud Network enables the distribution of workloads and services across multiple cloud and on-premises networks, providing a unified cloud experience for application developers and operators.\u003c/p\u003e\n"],["\u003cp\u003eThis guide focuses on the design considerations for building distributed applications on Cross-Cloud Network, covering network segmentation, connectivity, service networking, and security.\u003c/p\u003e\n"],["\u003cp\u003eThe architecture is structured into functional layers, including network segmentation and connectivity, service networking, and network security, supporting both regional and global application stacks.\u003c/p\u003e\n"],["\u003cp\u003eInter-VPC connectivity within Cross-Cloud Network can be achieved through Network Connectivity Center or a combination of VPC Network Peering and HA VPN hub-and-spoke patterns.\u003c/p\u003e\n"],["\u003cp\u003eService networking patterns vary based on application deployment archetypes, with a focus on multi-regional and global deployments, allowing for regional failover and optimized access latency.\u003c/p\u003e\n"]]],[],null,["# Cross-Cloud Network for distributed applications\n\nCross-Cloud Network enables an architecture for the assembly of\ndistributed applications. Cross-Cloud Network lets you\ndistribute workloads and services across multiple cloud and on-premises\nnetworks. This solution provides application developers and operators the\nexperience of a single cloud across multiple clouds. This solution uses and also\nexpands the [established uses of hybrid and multicloud\nnetworking](/architecture/hybrid-multicloud-patterns).\n\nThis guide is intended for network architects and engineers who want to design\nand build distributed applications on Cross-Cloud Network. This\nguide provides you with a comprehensive understanding of\nCross-Cloud Network design considerations.\n\nThis design guide is a series that includes the following documents:\n\n- Cross-Cloud Network design for distributed applications (this document)\n- [Network segmentation and connectivity for distributed applications in Cross-Cloud Network](/architecture/ccn-distributed-apps-design/connectivity)\n- [Service networking for distributed applications in Cross-Cloud Network](/architecture/ccn-distributed-apps-design/service-networking)\n- [Network security for distributed applications in Cross-Cloud Network](/architecture/ccn-distributed-apps-design/security)\n\nThe architecture supports regional and global application stacks, and it's\norganized in the following functional layers:\n\n- **Network segmentation and connectivity**: involves the Virtual Private Cloud (VPC) segmentation structure and IP connectivity across VPCs and to external networks.\n- **Service networking**: involves the deployment of application services, which are load balanced and made available across projects and organizations.\n- **Network security**: enables the enforcement of security for intra-cloud and inter-cloud communications, using both built-in cloud security and network virtual appliances (NVAs).\n\nNetwork segmentation and connectivity\n-------------------------------------\n\nSegmentation structure and connectivity is the foundation of the design. The\nfollowing diagram shows a VPC segmentation structure, which you\ncan implement by using either a consolidated or segmented infrastructure. This\ndiagram doesn't show the connections between the networks.\n\nThis structure includes the following components:\n\n- **Transit VPC**: Handles external network connections and routing policies. This VPC can also provide connectivity between other VPCs.\n- **Services access VPCs**: Contain access points to different services. The service access points in these VPCs can be reached from other networks.\n- **Managed services VPCs**: Contain services produced by other entities. The services are made accessible to applications running in VPC networks by using Private Service Connect or private services access.\n- **Application VPCs**: Contain the workloads that make up the software services that your organization creates and hosts itself.\n\nYour choice of segmentation structure for the application VPCs\ndepends on the scale of application VPCs required, whether you\nplan to deploy perimeter firewalls in Cross-Cloud Network or\nexternally, and the choice of central or distributed service publication.\n\nCross-Cloud Network supports the deployment of regional\napplication stacks and global application stacks. Both of these\napplication resiliency archetypes are supported by the proposed segmentation\nstructure with the inter-VPC connectivity pattern.\n\nYou can achieve inter-VPC connectivity with Network Connectivity Center or by using\na combination of VPC Network Peering and HA VPN hub-and-spoke patterns.\n\nThe design of the DNS infrastructure is also defined in the context of the\nsegmentation structure, independent of the connectivity pattern.\n\nService networking\n------------------\n\nDifferent application [deployment\narchetypes](/architecture/deployment-archetypes) lead to different patterns for\nservice networking. For Cross-Cloud Network design, focus on\nthe [Multi-regional deployment\narchetype](/architecture/deployment-archetypes/multiregional), in which an\napplication stack runs independently in multiple zones across two or more\nGoogle Cloud regions.\n\nA multi-regional deployment archetype has the following features that are useful\nfor Cross-Cloud Network design:\n\n- You can use DNS routing policies to route incoming traffic to the regional load balancers.\n- The regional load balancers can then distribute the traffic to the application stack.\n- You can implement regional failover by re-anchoring the DNS mappings of the application stack with a [DNS failover routing\n policy](/dns/docs/policies-overview#failover-policy).\n\nAn alternative to the multi-regional deployment archetype would be the [global\ndeployment archetype](/architecture/deployment-archetypes/global), in which a\nsingle stack is built on global load balancers and spans multiple regions.\nConsider the following features of this archetype when working with\nCross-Cloud Network design:\n\n- The load balancers distribute traffic to the region that's nearest to the user.\n- The internet-facing frontends are global, but the internal-facing frontends are regional with global access, so you can reach them in failover scenarios.\n- You can use geolocation DNS routing policies and DNS health checks on the internal service layers of the application stack.\n\nHow you provide access to managed published services depends on the service that\nneeds to be reached. The different private reachability models are modularized\nand orthogonal to the design of the application stack.\n\nDepending on the service, you can use Private Service Connect or\nprivate services access for private access. You can build an application\nstack by combining built-in services and services published by other\norganizations. The service stacks can be regional or global to meet your\nrequired level of resiliency and optimized access latency.\n\nNetwork security\n----------------\n\nFor workload security, we recommend that you use [firewall\npolicies](/firewall/docs/firewall-policies-overview) from Google Cloud.\n\nIf your organization requires additional advanced capabilities to meet security\nor compliance requirements, you can incorporate perimeter security firewalls\nby inserting Next-Generation Firewall (NGFW) Network Virtual Appliances (NVAs).\n\nYou can insert NGFW NVAs in a single network interface (single-NIC mode) or over\nmultiple network interfaces (multi-NIC mode). The NGFW NVAs can support security\nzones or Classless Inter-Domain Routing (CIDR)-based perimeter policies.\nCross-Cloud Network deploys perimeter NGFW NVAs by using a\ntransit VPC and VPC routing policies.\n\nWhat's next\n-----------\n\n- Design the [network segmentation and connectivity](/architecture/ccn-distributed-apps-design/connectivity) for Cross-Cloud Network applications.\n- Learn more about the Google Cloud products used in this design guide:\n - [VPC networks](/vpc/docs/vpc)\n - [Shared VPC](/vpc/docs/shared-vpc)\n - [VPC Network Peering](/vpc/docs/vpc-peering)\n - [Private Service Connect](/vpc/docs/private-service-connect)\n - [Private services access](/vpc/docs/private-services-access)\n- For more reference architectures, design guides, and best practices, explore the [Cloud Architecture Center](/architecture).\n\nContributors\n------------\n\nAuthors:\n\n- [Victor Moreno](https://www.linkedin.com/in/vimoreno) \\| Product Manager, Cloud Networking\n- [Ghaleb Al-habian](https://www.linkedin.com/in/galhabian) \\| Network Specialist\n- Deepak Michael \\| Networking Specialist Customer Engineer\n- [Osvaldo Costa](https://www.linkedin.com/in/osvaldocostajr) \\| Networking Specialist Customer Engineer\n- [Jonathan Almaleh](https://www.linkedin.com/in/jonathan-almaleh) \\| Staff Technical Solutions Consultant\n\n\u003cbr /\u003e\n\nOther contributors:\n\n- [Zach Seils](https://www.linkedin.com/in/zachseils) \\| Networking Specialist\n- [Christopher Abraham](https://www.linkedin.com/in/christopher-abraham-33291b) \\| Networking Specialist Customer Engineer\n- [Emanuele Mazza](https://www.linkedin.com/in/emanuelemazza) \\| Networking Product Specialist\n- [Aurélien Legrand](https://www.linkedin.com/in/aurelienlegrand) \\| Strategic Cloud Engineer\n- [Eric Yu](https://www.linkedin.com/in/eyu719) \\| Networking Specialist Customer Engineer\n- [Kumar Dhanagopal](https://www.linkedin.com/in/kumardhanagopal) \\| Cross-Product Solution Developer\n- [Mark Schlagenhauf](https://www.linkedin.com/in/mark-schlagenhauf-63b98) \\| Technical Writer, Networking\n- [Marwan Al Shawi](https://www.linkedin.com/in/marwanalshawi) \\| Partner Customer Engineer\n- [Ammett Williams](https://www.linkedin.com/in/ammett) \\| Developer Relations Engineer\n\n\u003cbr /\u003e"]]