Google은 가장 중요한 인터넷 기반 애플리케이션을 손쉽게 보호하고 확장할 수 있는 일련의 제품과 기능을 제공합니다. 그림 1은 Google Cloud 서비스를 사용하여 여러 계층으로 웹 애플리케이션을 배포하는 아키텍처를 보여줍니다.
그림 1. Google Cloud에 배포된 일반적인 다중 계층 웹 애플리케이션
리프트 앤 시프트 아키텍처
인터넷 연결 애플리케이션이 클라우드로 이전됨에 따라 확장할 수 있어야 하며 온프레미스 환경에 있는 제어와 동일한 보안 제어 및 가시성을 가져야 합니다. Marketplace에서 제공되는 네트워크 가상 어플라이언스를 사용하여 이러한 제어를 제공할 수 있습니다.
그림 2. 어플라이언스 기반 외부 부하 분산기로 배포된 애플리케이션
이러한 가상 어플라이언스는 온프레미스 환경과 일치하는 기능 및 가시성을 제공합니다. 네트워크 가상 어플라이언스를 사용하면 자동 확장된 관리형 인스턴스 그룹으로 소프트웨어 어플라이언스 이미지를 배포합니다. 사용자는 어플라이언스를 실행하는 VM 인스턴스의 상태를 모니터링하고 관리해야 하며 어플라이언스의 소프트웨어 업데이트도 유지해야 합니다.
이전을 처음 수행한 후 자체 관리형 네트워크 가상 어플라이언스에서 관리형 서비스로 전환할 수 있습니다.Google Cloud 는 애플리케이션을 대규모로 제공할 수 있는 다양한 관리형 서비스를 제공합니다.
그림 2는 웹 계층 애플리케이션의 프런트엔드로 구성된 네트워크 가상 어플라이언스를 보여줍니다. 파트너 생태계 솔루션 목록은 Google Cloud 콘솔의 Google Cloud Marketplace 페이지를 참고하세요.
하이브리드 서비스 아키텍처
Google Cloud 는 인터넷으로 연결된 애플리케이션을 대규모로 관리할 수 있도록 다음과 같은 접근 방식을 제공합니다.
고가용성과 짧은 지연 시간을 제공하는 Google의 글로벌 애니캐스트 DNS 네임서버 네트워크를 사용하여 도메인 이름 요청을 IP 주소로 변환하세요.
Google의 외부 애플리케이션 부하 분산기 전역 Fleet을 사용하여 Google Cloud내부, 온프레미스, 다른 퍼블릭 클라우드에서 호스팅되는 애플리케이션으로 트래픽을 라우팅합니다. 이러한 부하 분산기는 트래픽에 따라 자동으로 확장되며 각 요청이 정상적인 백엔드로 전달되도록 합니다. 하이브리드 연결 네트워크 엔드포인트 그룹을 설정하면 외부 애플리케이션 부하 분산기의 네트워킹 기능을 Google Cloud외부의 기존 인프라에서 실행되는 서비스에 활용할 수 있습니다. 온프레미스 네트워크 또는 기타 퍼블릭 클라우드 네트워크가 VPN 터널 또는 Cloud Interconnect를 통해 Google Cloud 네트워크에 비공개로 연결됩니다.
Cloud CDN과 같은 다른 네트워크 에지 서비스를 사용하여 콘텐츠를 배포하고, Google Cloud Armor를 사용하여 콘텐츠를 보호하고, IAP(Identity-Aware Proxy)를 사용하여 서비스에 대한 액세스를 제어합니다.
그림 3은 외부 애플리케이션 부하 분산기를 사용하는 하이브리드 연결을 보여줍니다.
그림 3. 외부 애플리케이션 부하 분산기 및 네트워크 에지 서비스를 사용하는 하이브리드 연결 구성
그림 4는 하이브리드 연결 네트워크 엔드포인트 그룹을 사용하는 다른 연결 옵션을 보여줍니다.
그림 4. 하이브리드 연결 네트워크 엔드포인트 그룹을 사용하는 외부 애플리케이션 부하 분산기 구성
애플리케이션 부하 분산기(HTTP/HTTPS)를 사용하여 HTTP 통합 리소스 식별자(URI)와 같은 속성을 기반으로 요청을 라우팅합니다.
프록시 네트워크 부하 분산기를 사용하여 TLS 오프로드, TCP 프록시 또는 멀티 리전에 위치한 백엔드에 대한 외부 부하 분산 지원을 구현합니다.
패스 스루 네트워크 부하 분산기를 사용하여 클라이언트 소스 IP 주소를 보존하고 프록시 오버헤드를 방지하고 UDP, ESP, ICMP와 같은 추가 프로토콜을 지원합니다.
Cloud Armor로 서비스를 보호하세요.
이 제품은 부하 분산기를 통해 액세스되는 모든 서비스에서 사용 가능한 에지 DDoS 방어 및 WAF 보안 제품입니다.
Google 관리형 SSL 인증서를 사용합니다.
이미 다른Google Cloud 제품에서 사용하는 인증서와 비공개 키를 재사용할 수 있습니다. 이렇게 하면 별도의 인증서를 관리할 필요가 없습니다.
Cloud CDN의 분산 애플리케이션 배포 공간을 활용하려면 애플리케이션에서 캐싱을 사용 설정합니다.
그림 6과 같이 Cloud IDS를 사용하여 north-south 트래픽에서 위협을 감지합니다.
그림 6. 모든 인터넷 및 내부 트래픽을 미러링하고 검사하는 Cloud IDS 구성
제로 트러스트 분산 아키텍처
제로 트러스트 분산 아키텍처를 확장하여 인터넷에서의 애플리케이션 전송을 포함할 수 있습니다. 이 모델에서는 Google 외부 애플리케이션 부하 분산기가 고유한 클러스터에서 Cloud Service Mesh 메시가 있는 GKE 클러스터에서 전역 부하 분산을 제공합니다. 이 시나리오에서는 복합 인그레스 모델을 채택합니다. 첫 번째 계층 부하 분산기는 클러스터 선택을 제공하고 Cloud Service Mesh 관리형 인그레스 게이트웨이는 클러스터별 부하 분산 및 인그레스 보안을 제공합니다. 이 멀티 클러스터 인그레스의 예시로는 엔터프라이즈 애플리케이션 청사진에서 설명한 Cymbal Bank 참조 아키텍처가 있습니다. Cloud Service Mesh 에지 인그레스에 관한 자세한 내용은 에지에서 메시로: GKE 인그레스를 통해 서비스 메시 애플리케이션 노출을 참조하세요.
그림 7은 외부 애플리케이션 부하 분산기가 인그레스 게이트웨이를 통해 인터넷에서 서비스 메시로 트래픽을 전달하는 구성을 보여줍니다.
게이트웨이는 서비스 메시의 전용 프록시입니다.
[[["이해하기 쉬움","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-13(UTC)"],[[["\u003cp\u003eThis document focuses on networking architectures for delivering internet-facing applications in Google Cloud, covering migration from on-premises environments.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Cloud offers managed services like external Application Load Balancers, Cloud CDN, and Cloud Armor to scale and secure internet-facing applications, replacing self-managed network virtual appliances.\u003c/p\u003e\n"],["\u003cp\u003eHybrid services architectures can be implemented, allowing the use of Google's global network for DNS and load balancing while connecting to services hosted on-premises or in other clouds.\u003c/p\u003e\n"],["\u003cp\u003eThe document covers various approaches to load balancing, including HTTP/HTTPS Application Load Balancers, proxy Network Load Balancers, and passthrough Network Load Balancers, each with specific use cases.\u003c/p\u003e\n"],["\u003cp\u003eZero Trust Distributed Architecture is discussed, detailing how external Application Load Balancers can integrate with Cloud Service Mesh for secure, multi-cluster application delivery.\u003c/p\u003e\n"]]],[],null,["# Networking for internet-facing application delivery: Reference architectures\n\nThis document is part of a series that describes networking and security\narchitectures for enterprises that are migrating data center workloads to\nGoogle Cloud.\n\nThe series consists of the following documents:\n\n- [Designing networks for migrating enterprise workloads: Architectural approaches](/architecture/network-architecture)\n- [Networking for secure intra-cloud access: Reference architectures](/architecture/network-secure-intra-cloud-access)\n- Networking for internet-facing application delivery: Reference architectures (this document)\n- [Networking for hybrid and multi-cloud workloads: Reference architectures](/architecture/network-hybrid-multicloud)\n\nGoogle offers a set of products and capabilities that help secure\nand scale your most critical internet-facing applications. Figure 1 shows an\narchitecture that uses Google Cloud services to deploy a web application\nwith multiple tiers.\n\n**Figure 1**. Typical multi-tier web application deployed on Google Cloud.\n| **Note:** You need to consider limitations of using Application Load Balancers. For more information, see the [Limitations](/load-balancing/docs/https#limitations) section in the \"External Application Load Balancer overview\" documentation.\n\nLift-and-shift architecture\n---------------------------\n\nAs internet-facing applications move to the cloud, they must be able to scale,\nand they must have security controls and visibility that are equivalent to those\ncontrols in the on-premises environment. You can provide these controls by using\nnetwork virtual appliances that are available in the marketplace.\n\n**Figure 2**. Application deployed with an appliance-based external load\nbalancer.\n\nThese virtual appliances provide functionality and visibility that is\nconsistent with your on-premises environments. When you use a network virtual\nappliance, you deploy the software appliance image by using autoscaled managed\ninstance groups. It's up to you to monitor and manage the health of the VM\ninstances that run the appliance, and you also maintain software updates for the\nappliance.\n\nAfter you perform your initial shift, you might want to\ntransition from self-managed network virtual appliances to managed services.\nGoogle Cloud offers a number of managed services to\ndeliver applications at scale.\n\nFigure 2 shows a network virtual appliance configured as the frontend\nof a web tier application. For a list of partner ecosystem solutions, see the\n[Google Cloud Marketplace](https://console.cloud.google.com/marketplace/browse?filter=category:networking)\npage in the Google Cloud console.\n\nHybrid services architecture\n----------------------------\n\nGoogle Cloud offers the following approaches to manage\ninternet-facing applications at scale:\n\n- Use Google's global network of anycast DNS name servers that provide high availability and low latency to translate requests for domain names into IP addresses.\n- Use Google's global fleet of external Application Load Balancers to route traffic to an application that's hosted inside Google Cloud, hosted on-premises, or hosted on another public cloud. These load balancers scale automatically with your traffic and ensure that each request is directed to a healthy backend. By setting up [hybrid connectivity network endpoint groups](/load-balancing/docs/negs/hybrid-neg-concepts), you can bring the benefits of external Application Load Balancer networking capabilities to services that are running on your existing infrastructure outside of Google Cloud. The on-premises network or the other public cloud networks are privately connected to your Google Cloud network through a VPN tunnel or through Cloud Interconnect.\n- Use other network edge services such as Cloud CDN to distribute\n content, Google Cloud Armor to protect your content, and\n Identity-Aware Proxy (IAP) to control access to your services.\n\n Figure 3 shows hybrid connectivity that uses external Application Load Balancer.\n\n **Figure 3**. Hybrid connectivity configuration using external Application Load Balancer and\n network edge services.\n\n Figure 4 shows a different connectivity option---using hybrid\n connectivity network endpoint groups.\n\n **Figure 4**. External Application Load Balancer configuration using hybrid\n connectivity network endpoint groups.\n- Use a Application Load Balancer (HTTP/HTTPS) to route requests based on\n their attributes, such as the HTTP uniform resource identifier (URI).\n Use a proxy Network Load Balancer to implement TLS offload, TCP proxy, or support for\n external load balancing to backends in multiple [regions](/docs/geography-and-regions#regions_and_zones).\n Use a passthrough Network Load Balancer to preserve client source IP addresses, avoid the\n overhead of proxies, and to support additional protocols like UDP, ESP, and\n ICMP.\n\n- Protect your service with\n [Cloud Armor](/armor).\n This product is an edge DDoS defense and WAF security product that's\n available to all services that are accessed through load balancers.\n\n- Use\n [Google-managed SSL certificates](/load-balancing/docs/ssl-certificates/google-managed-certs).\n You can reuse certificates and private keys that you already use for other\n Google Cloud products. This eliminates the need to manage separate\n certificates.\n\n- Enable caching on your application to take advantage of the distributed\n application delivery footprint of Cloud CDN.\n\n- Use [Cloud Next Generation Firewall](/vpc/docs/firewalls) to inspect and filter traffic in your VPC networks.\n\n- Use Cloud IDS to detect threats in north-south traffic, as\n shown in figure 6.\n\n **Figure 6**. Cloud IDS configuration to mirror and inspect\n all internet and internal traffic.\n\nZero Trust Distributed Architecture\n-----------------------------------\n\nYou can expand Zero Trust Distributed Architecture to include application\ndelivery from the internet. In this model, the Google external Application Load Balancer provides\nglobal load balancing across GKE clusters that have\nCloud Service Mesh meshes in distinct clusters. For this scenario, you adopt a\ncomposite ingress model. The first-tier load balancer provides cluster\nselection, and then a Cloud Service Mesh-managed ingress gateway provides\ncluster-specific load balancing and ingress security. An example of this\nmulti-cluster ingress is the\n[Cymbal Bank reference architecture](/architecture/blueprints/enterprise-application-blueprint/cymbal-bank)\nas described in the enterprise application blueprint. For more information about\nCloud Service Mesh edge ingress, see\n[From edge to mesh: Exposing service mesh applications through GKE Ingress](/architecture/exposing-service-mesh-apps-through-gke-ingress).\n\nFigure 7 shows a configuration in which a external Application Load Balancer directs\ntraffic from\nthe [internet to the service mesh](/architecture/exposing-service-mesh-apps-through-gke-ingress)\nthrough an\n[ingress gateway](/architecture/exposing-service-mesh-apps-through-gke-ingress).\nThe gateway is a dedicated proxy in the service mesh.\n\n**Figure 7**. Application delivery in a zero-trust microservices environment.\n\nWhat's next\n-----------\n\n- [Networking for secure intra-cloud access: Reference architectures](/architecture/network-secure-intra-cloud-access).\n- [Networking for hybrid and multi-cloud workloads: Reference architectures](/architecture/network-hybrid-multicloud).\n- [Use Cloud Armor, load balancing, and Cloud CDN to deploy programmable global front ends](/architecture/deploy-programmable-gfe-cloud-armor-lb-cdn)\n- [Migration to Google Cloud](/solutions/migration-to-gcp-getting-started) can help you to plan, design, and implement the process of migrating your workloads to Google Cloud.\n- [Landing zone design in Google Cloud](/architecture/landing-zones) has guidance for creating a landing zone network.\n- For more reference architectures, diagrams, and best practices, explore the [Cloud Architecture Center](/architecture)."]]