Jaringan untuk pengiriman aplikasi yang terhubung ke internet: Arsitektur referensi
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Last reviewed 2025-01-13 UTC
Dokumen ini adalah bagian dari rangkaian yang menjelaskan arsitektur keamanan dan jaringan
untuk perusahaan yang memigrasikan workload pusat data ke
Google Cloud.
Google menawarkan serangkaian produk dan kemampuan yang membantu mengamankan dan menskalakan aplikasi yang paling penting untuk internet. Gambar 1 menunjukkan arsitektur yang menggunakan layanan Google Cloud untuk men-deploy aplikasi web dengan beberapa tingkat.
Gambar 1. Aplikasi web multi-tingkat pada umumnya di-deploy di Google Cloud.
Arsitektur lift-and-shift
Saat aplikasi yang terhubung ke internet berpindah ke cloud, aplikasi tersebut harus dapat ditingkatkan skalanya,
dan mereka harus memiliki kendali keamanan dan visibilitas yang setara dengan kontrol di lingkungan lokal.
Anda dapat menetapkan kontrol ini dengan menggunakan
peralatan virtual jaringan yang tersedia di marketplace.
Gambar 2. Aplikasi dipaparkan dengan load balancing eksternal
berbasis alat.
Peralatan virtual ini memberikan fungsionalitas dan visibilitas yang
konsisten dengan lingkungan lokal Anda. Saat menggunakan alat
virtual jaringan, Anda memaparkan gambar alat perangkat lunak menggunakan pengelolaan skala otomatis kelompok Anda bebas memantau dan mengelola kondisi instance VM
yang menjalankan peralatan, dan mengelola update software untuk alat tersebut.
Setelah melakukan peralihan awal, sebaiknya Anda
beralih dari peralatan virtual jaringan yang dikelola sendiri ke layanan terkelola.
Google Cloud menawarkan sejumlah layanan terkelola untuk
menayangkan aplikasi dalam skala besar.
Gambar 2 menunjukkan alat virtual jaringan yang dikonfigurasi sebagai frontend
aplikasi tingkat web. Untuk mengetahui daftar solusi ekosistem partner, lihat halaman Google Cloud Marketplace di konsol Google Cloud .
Arsitektur layanan hybrid
Google Cloud menawarkan pendekatan berikut untuk mengelola aplikasi yang terhubung ke internet dalam skala besar:
Menggunakan jaringan global dari server nama DNS anycast yang menyediakan
ketersediaan tinggi dan latensi rendah untuk menerjemahkan permintaan nama domain
menjadi alamat IP.
Gunakan fleet Load Balancer Aplikasi eksternal global Google untuk merutekan traffic ke aplikasi yang dihosting di dalam Google Cloud, dihosting di infrastruktur lokal, atau dihosting di cloud publik lainnya. Load balancer ini menskalakan secara otomatis dengan traffic Anda dan memastikan bahwa setiap permintaan diarahkan ke backend yang responsif. Dengan menyiapkan
grup endpoint jaringan konektivitas hybrid,
Anda dapat memperoleh manfaat dari kemampuan jaringan Load Balancer Aplikasi eksternal untuk layanan yang berjalan di infrastruktur Anda yang ada di luar Google Cloud. Jaringan lokal atau jaringan cloud publik lainnya terhubung secara pribadi ke Google Cloud jaringan Anda melalui tunnel VPN atau melalui Cloud Interconnect.
Menggunakan layanan edge jaringan lainnya, seperti Cloud CDN untuk mendistribusikan konten, Google Cloud Armor untuk melindungi konten, dan Identity-Aware Proxy (IAP) untuk mengontrol akses ke layanan Anda.
Gambar 3 menunjukkan konektivitas hybrid yang menggunakan Load Balancer Aplikasi eksternal.
Gambar 3. Konfigurasi konektivitas hybrid menggunakan Load Balancer Aplikasi eksternal dan layanan edge jaringan.
Gambar 4 menunjukkan opsi konektivitas yang berbeda, yaitu menggunakan grup endpoint jaringan konektivitas hybrid.
Gambar 4. Konfigurasi Load Balancer Aplikasi Eksternal menggunakan grup endpoint jaringan konektivitas hybrid.
Gunakan Load Balancer Aplikasi (HTTP/HTTPS) untuk merutekan permintaan berdasarkan atributnya, seperti HTTP Uniform Resource Identifiers (URI).
Gunakan Load Balancer Jaringan proxy untuk menerapkan offload TLS, proxy TCP, atau dukungan untuk load balancing eksternal ke backend di beberapa region.
Gunakan Load Balancer Jaringan passthrough untuk mempertahankan alamat IP sumber klien, menghindari beban proxy, dan mendukung protokol tambahan seperti UDP, ESP, dan ICMP.
Lindungi layanan Anda dengan
Cloud Armor.
Produk ini merupakan produk pertahanan DDoS dan keamanan WAF yang
canggih tersedia untuk semua layanan yang diakses melalui load balancer.
Menggunakan
sertifikat SSL yang dikelola Google.
Anda dapat menggunakan kembali sertifikat dan kunci pribadi yang sudah Anda gunakan untuk produkGoogle Cloud lainnya. Dengan demikian, Anda tidak perlu mengelola
sertifikat secara terpisah.
Mengaktifkan caching pada aplikasi Anda untuk memanfaatkan jejak penayangan aplikasi yang terdistribusi dari Cloud CDN.
Menggunakan Cloud IDS untuk mendeteksi ancaman di traffic utara-selatan, seperti pada gambar 6.
Gambar 6. Konfigurasi Cloud IDS untuk mencerminkan dan memeriksa
semua traffic internet dan internal.
Arsitektur Terdistribusi Zero-Trust
Anda dapat memperluas Zero-Trust Distributed Architecture untuk menyertakan pengiriman
aplikasi dari internet. Dalam model ini, Load Balancer Aplikasi eksternal Google menyediakan load balancing global di seluruh cluster GKE yang memiliki mesh Cloud Service Mesh di cluster yang berbeda. Untuk skenario ini, Anda memakai model ingress komposit. Load balancer tingkat pertama menyediakan pemilihan cluster, lalu gateway ingress yang dikelola Cloud Service Mesh akan menyediakan load balancing dan keamanan ingress khusus cluster. Contoh multi-cluster ingress ini adalah arsitektur referensi Cymbal Bank seperti yang dijelaskan dalam cetak biru aplikasi perusahaan. Untuk mengetahui informasi selengkapnya tentang
ingress edge Cloud Service Mesh, lihat
Dari edge ke mesh: Mengekspos aplikasi mesh layanan melalui GKE Ingress.
Gambar 7 menunjukkan konfigurasi saat Load Balancer Aplikasi eksternal mengarahkan traffic dari internet ke mesh layanan melalui gateway traffic masuk.
Gateway adalah proxy khusus dalam mesh layanan.
Gambar 7. Pengiriman aplikasi di lingkungan microservice zero-trust.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)."]]
