Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
Gauge your current knowledge
Gauge your current knowledge
Google Cloud offers two main Network Service Tiers that control how traffic flows across the internet. The Premium Tier routes traffic over Google's private global backbone network, which provides the lowest possible latency and highest reliability for users around the world. The Standard Tier is a more cost-effective option that routes traffic over the public internet and is suitable for workloads that do not require global performance. Choosing Premium Tier is essential for applications using Global Load Balancing that need to serve users across different continents with minimal delay.
A Global External Application Load Balancer uses Google Front Ends (GFEs) to manage connections from users. The GFE terminates the TCP connection close to the user, which speeds up the initial handshake process. It then maintains a persistent connection to the backend servers, which reduces the impact of physical distance. This architecture means a user in Asia can connect to a local GFE instead of sending every request all the way to a backend server in North America, significantly cutting down response time.
Cloud CDN (Content Delivery Network) caches static content like images, videos, and web files at Points of Presence (PoPs) located around the world. When a user requests this content, it is served from the cache at the nearest PoP instead of traveling back to the origin server. This reduces Time to First Byte (TTFB), lowers the load on your backend servers, and improves reliability. It is a key tool for improving performance for a geographically dispersed audience.
For certain types of traffic, like UDP or when the original client IP address must be preserved, an External Passthrough Network Load Balancer is used. This load balancer operates at a regional level and uses a method called Direct Server Return (DSR). In DSR, traffic flows from the load balancer to the backend server, but the server responds directly back to the client. This passthrough approach can be more efficient for non-HTTP traffic but does not provide the same global optimization as a proxy-based load balancer.
Choosing the right virtual machine (machine type) is critical for application speed. For database workloads, selecting a highmem instance provides a large amount of RAM relative to CPU, which allows more data to be held in the memory cache. This reduces the need for slower disk reads, which directly improves performance. The goal is to select a VM size where the application's "working set" of data fits into memory.
Google Cloud Hyperdisk is a flexible block storage service. With Hyperdisk Balanced, you can configure IOPS (Input/Output Operations Per Second) and throughput (data transfer speed) independently from the size of the disk itself. This separation allows you to precisely match storage performance to your application's needs—like high-speed transaction processing—without paying for unnecessary storage capacity, optimizing both cost and latency.
How you deploy your application across regions affects latency. A distributed frontend with a single backend places web servers close to users around the world but connects them all to one central database; this improves web response times but can still have delay for database calls. For the absolute lowest latency, a distributed frontend and backend pattern places full application stacks in multiple regions, so a user's request can be handled completely within their geographic region.
Performance is a balance between throughput (how much work is done) and latency (how long each task takes). As you increase load on a system, latency will stay low until a resource becomes exhausted. At that point, latency spikes and throughput plateaus. Common bottlenecks include CPU exhaustion on a database server or a network bandwidth limit between services. Monitoring this relationship helps you know exactly when to scale your infrastructure to maintain good performance.
To understand an application's performance limits, architects use load testing. This creates graphs showing how latency changes as throughput increases. The point where latency begins to rise sharply indicates the system's capacity limit. Analyzing these graphs helps you find the ideal performance point for your cost and speed requirements, which is crucial for setting accurate targets for autoscaling.
When end-users report slow web pages, frontend performance tools are used to find the cause. Chrome DevTools or Safari Web Inspector can record a performance profile to show where time is spent during page load (like rendering or scripting). Capturing a HAR file records all network requests made by the browser. These files help developers pinpoint specific delays and are essential for sharing detailed issues with support teams.
Cloud Monitoring provides the metrics needed to understand system health and performance. You can use PromQL to query specific data, and for specialized workloads like AI, track metrics such as GPU cache usage. By monitoring these metrics against real traffic, you can make informed, data-driven decisions to adjust resources—like scaling up a database before its CPU becomes a bottleneck—ensuring efficient resource use and sustained performance.
The Horizontal Pod Autoscaler (HPA) automatically adds or removes resources in a containerized environment based on a chosen metric. Selecting the correct metric is vital for meeting performance goals. For example, scaling based on num_requests_waiting optimizes for throughput and cost-efficiency, while scaling based on gpu_cache_usage_perc is better for latency-sensitive applications where response speed is the top priority. Proper testing is required to find the right average target value for the scaling metric.
TLS Early Data (0-RTT) is a feature that can be configured on a load balancer to reduce connection setup time. It allows a client to send application data during the very first message of the TLS handshake, before the secure connection is fully established. This must be managed carefully to avoid security risks like replay attacks. The load balancer can be set to STRICT mode (only for safe, simple requests), PERMISSIVE mode (more flexible but requires application safety checks), or DISABLED. When implemented safely, 0-RTT can significantly reduce latency for global users.
StudyCerts
StudyCerts