Kategorie: Google Cloud Platform

AlloyDB for PostgreSQL under the hood: Columnar engine

Recently, at Google I/O, we announced AlloyDB for PostgreSQL, a fully-managed, PostgreSQL-compatible database for demanding, enterprise-grade transactional and analytical workloads. Imagine PostgreSQL plus the best of the cloud: elastic storage and compute, intelligent caching, and AI/ML-powered management. Further, AlloyDB delivers unmatched price-performance: In our performance tests, it’s more than 4x faster on transactional workloads, and up to 100x faster on analytical queries than standard PostgreSQL, all with simple, predictable pricing. Designed for mission-critical applications, AlloyDB offers extensive data protection and an industry leading 99.99% availability SLA, inclusive of maintenance. Multiple innovations underpin the performance, and availability gains of AlloyDB for PostgreSQL. In the first part of our “AlloyDB for PostgreSQL under the hood” series, we discussed AlloyDB’s intelligent storage layer, and today, we are covering AlloyDB’s vectorized columnar execution engine, which enables analytical acceleration. PostgreSQL and hybrid workload patternsGeneral-purpose databases like PostgreSQL often support a wide variety of workloads. Some of those workloads are purely transactional in nature, and in the previous post, we discussed how our intelligent storage layer contributes to making AlloyDB more than 4x faster than standard PostgreSQL for such workloads based on our performance tests. However, PostgreSQL also has rich querying functionality that many users leverage both inside and outside of their applications. Analytical queries, i.e., queries involving scans, joins, and aggregations over a large amount of data, are a core part of many relational database workloads. These can include:Queries within an application that serves end-users, for example: an ecommerce application that shows most popular products segmented by region based on recent sales across multiple propertiesReal-time business insights for analysis that requires access to the most up-to-date data. For example: a recommendation engine in a retail application that shows suggested add-on purchases based on what the user has in their cart, the time of day, and historical purchase behaviorAd-hoc querying, where a developer or user might need to query the database directly to answer a question, for example, running an audit on recent transactions for a regulatorTuning operational databases to perform well in these varying use cases can be difficult. Historically, users with these types of workloads have had to create indexes and optimize schemas to ensure sufficient query performance. This not only increases management complexity, but can also impact transactional performance. Slow query performance can also constrain what developers are able to deliver to their end users, and deter development of real-time business insights.AlloyDB provides a better way. Powered by a columnar engine, AlloyDB performed up to 100x faster than standard PostgreSQL for analytical queries based on our performance tests, with no schema changes, application changes, or ETL required. This technology keeps frequently queried data in an in-memory, columnar format for faster scans, joins, and aggregations. The embedded machine learning in AlloyDB makes accessing this technology easier than ever. AlloyDB automatically organizes your data between row-based and columnar formats, choosing the right columns and tables based on learning your workload, and converting them to columnar format automatically. The query planner smartly chooses between columnar and row-based execution plans, so transactional performance is maintained. This allows AlloyDB to deliver excellent performance for a wide range of queries, with minimal management overhead.A refresher on column-oriented data representationTraditional databases are row-oriented and store data in fixed-sized blocks. This organization is optimal for access patterns that request information across a whole row, for example, when an application needs to look up information pertaining to a particular user. Row-oriented storage is optimized for these types of access patterns. Analytical queries require different access patterns. In order to answer analytical queries from a row-oriented data store, whole tables need to be scanned, reading through every column of every row, even though much of the data stored in the table is not relevant to answering the questions. Column-oriented data representation enables answering analytical questions faster, by keeping the values in a single column together. By focusing access to only the relevant columns, column-oriented databases can deliver faster responses to analytical queries.AlloyDB columnar engine Google has a long history of innovation in large-scale data analytics, especially with services like BigQuery. These services offer fast, scalable query processing through the use of optimized, columnar data layouts, state-of-the-art query processing techniques, and hardware acceleration. AlloyDB embeds some of the same technological advancements directly into a PostgreSQL-compatible operational database. It combines a row-based format for transactional processing and storage with a columnar format and execution engine to provide the best of both worlds.The columnar engine is a modern, vectorized query processing engine that efficiently processes chunks of columnar data by making optimal use of the system caches and vector processing instructions provided by today’s CPUs.Beyond leveraging the capabilities of modern hardware, the columnar engine includes several algorithmic optimizations to further speed up query processing. It makes use of column-specific metadata, such as minimum and maximum values, to speed up scans, and can perform other operations like aggregation directly on the relevant columns without materializing the results of a scan. Finally, hybrid execution combines both columnar and row-oriented query processing techniques where beneficial.Columnar data formatThe columnar engine intelligently determines the data format and metadata for each column; it learns from both the content of the column and the type of query operations that are executed. Learned metadata is used both to encode the data values efficiently and to accelerate query processing. For example, when a string column that has a small number of distinct values is used in filters, the columnar engine may decide to generate a list of the distinct values as metadata. This can then be used to accelerate both equality and range-based filters. As another example, the columnar engine may keep minimum and maximum values of a date column (for a given range of rows) as metadata; this may then be used to skip that range of rows when processing certain filters. In addition, the columnar engine may also use compression techniques to make efficient use of memory and speed up query processing. Query accelerationThe columnar engine transforms queries into a series of operations on columns and their metadata. Typically this involves first looking up the metadata to determine the most efficient type of operation to perform on an array of column values. These operations on column values, called vectorized operations, are designed to be executed using hardware-accelerated vectorized (SIMD) instructions that are available on modern CPUs.The columnar engine can also perform table scan operations efficiently without fully materializing the result of the table scan; for example, if an aggregation operation needs to be performed after a table scan, it may use the result of evaluating the filters to directly perform vectorized aggregation operations on the relevant columns. Join operations are transparently accelerated using bloom filters, depending on selectivity; this optimization uses the power of vectorized filtering to reduce the number of rows that need to be processed by the join operation.Let’s take a look at how some of these optimizations apply to a simple query involving a table scan based on a schema similar to the Star Schema benchmark. This query scans the list of sales, filtering by shipping mode and date. The following figure illustrates how the table scan with two filters is executed. For the filter lo_shipmode = ‘MAIL’, the columnar engine first checks the column’s metadata to see if the value ‘MAIL’ is present in this dataset. If ‘MAIL’ does occur, the columnar engine proceeds by searching using SIMD instructions. The resulting bitmap of passing rows is further filtered using the result set from the next filter. Alternatively, if the value ‘MAIL’ had not occured in the column metadata, the columnar engine could have skipped searching a large number of values. Similarly, the columnar engine may also use min/max metadata on the lo_quantity column to skip some rows based on the range filter on that column.Figure 1: Example query operation with table scans with two filtersAutomatic, intelligent data populationWe designed AlloyDB with automation in mind, given that workloads vary widely and workload characteristics change over time. AlloyDB uses machine learning (ML) techniques along with analytical models to intelligently select  the best tables/columns to keep in columnar format, and provides mechanisms to automatically maintain this data in memory. It also determines the best format to use for the columnar data representation, and what metadata would be most useful for each column, based on the values in the column and the query operations performed on it. This allows end users to take advantage of columnar technology immediately, without evaluating the details of their queries. It also means that the columnar engine will continue to optimize performance as query patterns change.Query plan executionAfter the data is initially loaded into memory, AlloyDB monitors changes to the data and ensures that it is refreshed automatically. Depending on the data changes as well as the query operations being performed, it may be best to execute queries fully on columnar data, fully on row-oriented data, or a hybrid of the two. The AlloyDB query planner uses a costing model to automatically choose the best mode of execution for each node in the query plan.Figure 2: Hybrid scans can scan multiple columnar tables, and access the row-store at the same timeQuery performanceWhile we expect the columnar engine to significantly improve the performance of analytic queries in general, the magnitude of improvement will depend on the specific query.  The largest improvements from the columnar engine can be seen for queries with selective filters on wide tables (tables with a large number of columns — as is typical in many analytic use cases) that access a small fraction of the columns in the table. Selective joins, especially with small tables, will also benefit significantly from the columnar engine, through the use of efficient bloom filtering. We are continuously innovating in this area and building new capabilities to broaden the performance impact of the columnar engine on different query patterns. To illustrate how the magnitude of the performance improvement varies based on the above factors, we compared performance with and without the columnar engine for a few example queries. These queries are based on the Star Schema benchmark, and were run with Scale factor = 10 on a 16-vCPU AlloyDB instance:Example 1: Get the total revenue from sales with a specific discount and quantity; this query has a highly selective (0.18%) filter, along with aggregation on one column117x improvementcode_block[StructValue([(u’code’, u’select sum(lo_revenue) as revenuernfrom lineorderrnwhere lo_discount = 1rnand lo_quantity = 1′), (u’language’, u”)])]Example 2: For each ship mode, get the total revenue from sales where the discount and quantity were within a specific range; this query has a less selective (13%) filter, group by and aggregation on one column19x improvementcode_block[StructValue([(u’code’, u’select lo_shipmode, sum(lo_revenue) as revenuernfrom lineorderrnwhere lo_discount between 1 and 3 and lo_quantity < 25rngroup by lo_shipmode’), (u’language’, u”)])]Example 3: Get the total revenue from sales in a given year for which the discount and quantity were within a specific range; this query has a selective join (join selectivity = 14%) and the columnar engine uses a bloom filter to accelerate it. 8x improvementcode_block[StructValue([(u’code’, u’select sum(lo_revenue) as revenuernfrom lineorderrn left join date on lo_orderdate = d_datekeyrnwhere d_year = 1993 and lo_discount between 1 and 3rn and lo_quantity < 25′), (u’language’, u”)])]Example 4: Get the total revenue from sales in or before a given year for which the discount and quantity were within a specific range; this query has a much less selective join (join selectivity = 90%).2.6x improvementcode_block[StructValue([(u’code’, u’select sum(lo_revenue) as revenuernfrom lineorderrn left join date on lo_orderdate = d_datekeyrnwhere d_year <= 1997 and lo_discount between 1 and 3rn and lo_quantity < 25′), (u’language’, u”)])]We do not guarantee the same results illustrated by these examples because your results will be dependent on your data sets, database configurations and the queries that you run.Query plan exampleThe plan of a query executed using the columnar engine shows additional statistics that help identify various columnar optimizations that were invoked in order to make the query run faster. Key parts of the plan of example query 1:code_block[StructValue([(u’code’, u’Aggregate (cost=1006.43..1006.44 rows=1 width=8) (actual time=8.219..8.220 rows=1 loops=3)rn -> Parallel Append (cost=0.00..883.88 rows=49017 width=4) (actual time=0.221..8.208 rows=1 loops=3)rn -> Parallel Custom Scan (columnar scan) on lineorder (cost=20.00..879.88 rows=49016 width=4) (actual time=0.220..8.205 rows=36230 loops=3)rn Filter: ((lo_discount = 1) AND (lo_quantity = 1))rn Rows Removed by Columnar Filter: 19959121rn Rows Aggregated by Columnar Scan: 21216rn CU quals: ((lo_quantity = 1) AND (lo_discount = 1))rn Columnar cache search mode: nativern -> Parallel Seq Scan on lineorder (cost=0.00..4.01 rows=1 width=4) (never executed)rn Filter: ((lo_discount = 1) AND (lo_quantity = 1))’), (u’language’, u”)])]Understanding the query plan nodes:Custom Scan: This node is the Columnar Scan node that applies filters on the column store. It shows 19959121 rows removed by the Columnar Filter and 21216 rows aggregated by the columnar engine.Seq Scan: This node is the traditional Postgres row-store Sequential Scan node that is invoked only when the query planner decides to use hybrid execution mode, which it did not use in this case.Append: This node merges the results from Columnar Scan node (Custom Scan) and Row-store Sequential Scan node.ConclusionOur columnar engine enables analytical queries to run up to 100x faster than the traditional PostgreSQL engine based on our performance tests. This query processing technology enables you to run analytics and reporting directly against your operational database for real-time insights. Powered by ML-driven auto-population and management, the columnar engine automatically optimizes to your applications, completely transparently on each instance and with minimal management overhead, delivering fine-tuned performance with refreshing ease of use. To try AlloyDB out for yourself, visit cloud.google.com/alloydb.The AlloyDB technical innovations described in this and subsequent posts would not have been possible without the exceptional contributions of our engineering team.Related ArticleIntroducing AlloyDB for PostgreSQL: Free yourself from expensive, legacy databasesAlloyDB for PostgreSQL combines the best of Google with full PostgreSQL compatibility to achieve superior performance, availability, and …Read Article
Quelle: Google Cloud Platform

Introducing Network Analyzer: One stop shop to detect service and network issues

With networking at the foundation of all cloud deployments and business processes, proactively maintaining network health is mission-critical. The cloud is powerful and dynamic, but can sometimes feel complex, as customers often encounter network issues from unintentionally deploying suboptimal or error-prone configurations.  For example, organizations may deploy changes that unknowingly introduce misconfigurations, contradict best practices, exceed IP address utilization quotas, or suboptimally allocate unused external IPs.  To mitigate such network issues, teams often rely on reactive workflows – manually running time-consuming diagnostics to troubleshoot and resolve issues after a service disruption.  Google Cloud Networking developed a solution to prevent manual, time-intensive, reactive status quo – which is why we are excited to introduce Network Intelligence Center (NIC)’s  newest module: Network Analyzer.  With Network Analyzer, customers can transform reactive workflows into proactive processes and reduce network and service downtime. Network Analyzer empowers you by auto-detecting failures caused by the underlying network, surfacing  root cause analyses, and suggesting  best practices to improve the availability, performance, and security of services. Network Analyzer offers an out-of-the-box  suite of always-on analyzers that continuously monitor GCE and GKE network configuration. These analyzers run in the background, monitoring network services like load balancers, hybrid connectivity, and connectivity to Google services like Cloud SQL. As users continually push out config changes or the metrics for their deployment changes, the relevant analyzers will  automatically surface failure conditions or suboptimal configurations.Get automatic, proactive notification of service and network issuesNetwork Analyzer detects failures that can be caused by misconfigurations like setup errors or regressions caused by unintended changes. Customers can automatically detect if Google services like Cloud SQL are not reachable, or if network services like load balancing are not functioning as intended. Network Analyzer also detects the root cause for this failure, such as an invalid route or firewall rule blocking the service reachability.For example, Network Analyzer can detect:Connectivity issues to Google Services like Cloud SQL. This issue could be  due to an egress firewall rule or a routing issue. Common misconfigurations with load balancer health checks like firewall is not configured on the VPC network to allow health check probes used by the load balancer, or user-configured firewall rule is blocking the health check IP address rangeInvalid next hop of a route due to misconfigurations like stopped or deleted VM instance, VM instance with IP forwarding disabled, deleted Internal Load Balancer, deleted VPN tunnelDynamic routes shadowed by a subnet or static routes as a result of which the dynamic route is not effectiveGKE networking misconfigurations like connectivity between GKE nodes and their control plane is blocked by misconfigured firewall or routing issues.Improve availability and efficiency of your servicesNetwork Analyzer codifies Google Cloud’s best practice guidelines for improved availability and performance and helps you optimize usage of Google Cloud resources. It offers best practice recommendations that are relevant to your deployment.For example, Network Analyzer surfaces suggestions like:External IP address is reserved but not allocated to a resourceGKE cluster needs additional authorized network after expanding IP address rangeEnabling Private Google Access for a private GKE cluster’s subnet after the cluster has been createdPredict resource and capacity issuesNetwork Analyzer detects suboptimal configurations and capacity trends which may lead to network issues in the future. For example, it can detect high IP address utilization of a subnet, which can prevent automatically creating VMs or upgrading GKE clusters.Surfacing insights through Network AnalyzerNetwork Analyzer prioritizes and proactively surfaces insights to users at a project level or across multiple projects.It identifies the root cause of the surfaced insight and provides a link to the documentation with recommendations to fix the insight.You can refer to the complete list of analyzers here. We are continuously adding new analyzers to this module.Moving towards Proactive OperationsWe are excited to see customers use Network Intelligence Center’s Network Analyzer to adopt a more proactive, event-driven approach to network health and automatically detect and predict network and service issues. View insights for your organization in the Google Cloud Console. Learn more about Network Analyzer and view our complete list of analyzers in our documentationAnd as always, please feel free to reach out to the Network Intelligence Center team with your questions and feedback.Related ArticleIntroducing Media CDN—the modern extensible platform for delivering immersive experiencesWe’re excited to announce the general availability of Media CDN — a content and media distribution platform with unparalleled scale.Read Article
Quelle: Google Cloud Platform

Eliminate hotspots in Cloud Bigtable

We’ve recently improved Cloud Bigtable’s observability by allowing customers to monitor and observe hot tablets. We now provide customers access to real-time hot tablets data through the Cloud Bigtable Admin API and gcloud command-line tool. In this post, we’ll present how hot tablets observability can be used in real world use cases to help customers understand better design choices based on access patterns and provide insight into performance-related problems.What are hot tablets?A Cloud Bigtable table is sharded into blocks of contiguous rows, called tablets, to help balance the workload of queries. Each tablet is associated with a Bigtable node (or “tablet server” in the original Bigtable paper), and operations on the rows of the tablet are performed by this node. To optimize performance and scale, tablets are split and rebalanced across the nodes based on access patterns such as read, write, and scan operations.A hot tablet is a tablet that uses a disproportionately large percentage of a node’s CPU compared to other tablets associated with that node. This unbalanced usage can happen due to unanticipated high volume of requests to a particular data point, or uneven table modeling during the initial schema design. This imbalanced node usage can cause higher latencies and replication delays called “hotspots” or “hotspotting.” Unlike cluster-level CPU overutilization, which can often be mitigated by horizontally scaling the number of nodes, hotspotting may require other mitigation techniques, some of which are discussed in this blog.Use cases for hot tablets data1) Use Case: Identify HotspotsHot tablets can help to diagnose if elevated latencies are due to a large amount of traffic made to a narrow range of row keys. In this example, a customer observed that P99 latencies have been elevated for the past few hours by monitoring query latencies on the Bigtable Monitoring page in the Google Cloud Console:This might be attributed to CPU overutilization, which means that the workload exceeds the recommended usage limits of a cluster. Overutilization typically means that the cluster is under- provisioned, which can be resolved by manually adding more nodes to the cluster or by using autoscaling to automatically add nodes. To identify if this is the underlying issue, the customer looks at the CPU utilization of this cluster and sees that the average CPU utilization of the cluster is at a healthy ~60%, which is below the recommended limit of 70%. However, the hottest node is running at nearly ~100% CPU utilization; this large difference in CPU usage between the average and hottest node is a strong indication of hotspots.The customer wants to understand the root cause of the hotspots, and runs the gcloud hot-tablets list (or the Bigtable API method) to investigate further:code_block[StructValue([(u’code’, u’$ gcloud bigtable hot-tablets list my-cluster –instance=my-instancernNAME TABLE CPU_USAGE START_TIME END_TIME START_KEY END_KEYrntablet1 test-data 89.3 2021-12-14T01:19:57+00:00 2021-12-14T01:20:57+00:00 user432958 user433124rntablet2 test-data 22.8 2021-12-14T01:04:59+00:00 2021-12-14T01:06:59+00:00 user312932 user312932{$content}rntablet3 test-data 20.9 2021-12-14T01:18:56+00:00 2021-12-14T01:20:56+00:00 user592140 user592192 rntablet4 test-data 16.5 2021-12-14T01:18:56+00:00 2021-12-14T01:20:56+00:00 user491965 user492864′), (u’language’, u”)])]The hot tablets output confirms that there are hotspots, as there are three tablets with more than 20% CPU usage. In the output, CPU usage refers to the amount of CPU that a single node (tablet server) has used for a single tablet from start time to end time for reads and writes. Remember that a tablet server has tasks other than serving tablets, including:ReplicationRebalancingCompactionGarbage collectionLoading and unloading tabletsOther background tasks A tablet server can be responsible for hundreds or thousands of tablets, so spending more than 20% of CPU on a single tablet is a relatively large allocation.The hot tablets method also provides the start and end keys of the tablets; this information can be used to identify the source of the hotspots downstream. In the example above, the customer designed their schema so that the row key is the user ID (<user-id>). That is, all reads and writes for a single user ID are made to a single row. If that user sends requests in bursts or if there are multiple workloads, this row key design would likely be mismatched with access patterns, resulting in a high amount of read and writes to a narrow range of keys.To resolve the hotspot, the customer can opt to isolate or throttle traffic associated with the users that correspond to the row keys in tablet1 (from user432958 to user433124). In addition, the output shows that tablet2 is a tablet that contains only a single row from a start key of user312932 to an end key of user31293200, which is the smallest possible tablet size. Heavily writing/reading on a single row key will lead to a single-row tablet. To resolve this problem, the customer can opt to isolate or throttle traffic associated with user312932.The customer can also decide to redesign the row key so that table queries are more evenly spread across the row key space, allowing better load balancing and tablet splitting. Using user ID as the row key stores all user-related information in a single row. This is an anti-pattern that groups unrelated data together, and potentially causes multiple workflows to access the same row. Alternative row key designs to consider are <workload-type>:<user-id> or <workload-type>:<user-id>:<timestamp>.In summary, the customer decides to resolve the hotspots by either:Redesigning the row key schema, orIdentifying downstream user(s) or workload(s) to isolate or throttle2) Use Case: Identify short-lived CPU hotspots (<15 min)Burst CPU usage in a narrow key range can cause short-lived hotspots and elevated P99 latencies. This type of hotspot can be difficult to diagnose because Key Visualizer has a minimum granularity of 15 minutes, and may not display any hotspots that are ephemeral. While Key Visualizer is an excellent tool at identifying persistent and long-lived hotspots, it may not be able to identify more granular burst usage. In our example, a customer notices that there are spikes in P99 read latencies in the Bigtable monitoring page:The customer further debugs these latency spikes by looking at the CPU utilization of the hottest node of the cluster:The CPU utilization of the hottest node is less than the recommended limit of 90%, but there are spikes in the CPU utilization that correspond to the latency spikes. While this suggests that there are no long-lived hotspots, it could indicate ephemeral hotspots within a key range. The customer investigates this possibility by viewing the Key Visualizer Heatmap:The Key Visualizer heatmap doesn’t indicate any clear hotspotting key ranges, but Key Visualizer aggregates metrics into 15 min buckets. If hotspots did occur over the course of 5 minutes, this usage would be averaged across 15 minutes, and may not show up as a high usage in the heatmap. The new hot tablets method can help customers diagnose these short-lived hotspots with more granular key space and minute-level usage metrics. Running the hot tablets command in gcloud, the customer is able to identify hotspots that lasted for only 2 minutes, but correspond to one of the latency spikes:code_block[StructValue([(u’code’, u’$ gcloud bigtable hot-tablets list my-cluster –instance=my-instancernNAME TABLE CPU_USAGE START_TIME END_TIME START_KEY END_KEYrntablet1 test-data 45.7 2022-01-04T12:43:32+00:00 2022-01-04T12:45:32+00:00 user719304 user725103′), (u’language’, u”)])]It’s possible with the new hot tablets method to identify the key ranges and tablets that have high CPU usage during the P99 tail latencies. This finer-grained reporting can help customers make more informed application design choices and help improve latency and throughput performance.Similar to the previous use case, the customer can decide if the ephemeral hotspots are problematic enough to warrant a row key redesign or isolate the offending user(s) and/or workload(s).3) Use Case: Identify noisy tables in a multi-table clusterMany customers use a single cluster for multiple workflows and tables. While this option is a reasonable and recommended way to get started with Cloud Bigtable, multiple workflows could potentially interfere with each other. For example, a customer has two tables on a cluster: table-batch and table-serve. As their names suggest, table-batch contains data to process batch workflows and table-serve contains data to serve requests. While throughput is prioritized for the batch workflows, latency is critical for serving requests. The customer notices that there is high cluster CPU utilization and periodic latency spikes from 3 pm to 6 pm. The customer wants to know if the batch workflows are interfering with request serving and causing the elevated latencies. Running the hot tablets command for this time period:code_block[StructValue([(u’code’, u’$ gcloud bigtable hot-tablets list my-cluster –instance=my-instance –start-time=”2021-12-14 15:00:00″ –end-time=”2021-12-14 18:00:00″rnrnNAME TABLE CPU_USAGE START_TIME END_TIME START_KEY END_KEYrntablet53 table-batch 43.2 2021-12-14T16:01:27+00:00 2021-12-14T16:03:27+00:00 user505921 user523452rntablet20 table-batch 28.1 2021-12-14T15:54:21+00:00 2021-12-14T15:56:21+00:00 user402934 user403923rntablet41 table-batch 19.3 2021-12-14T17:22:46+00:00 2021-12-14T17:24:46+00:00 user105932 user105990 rntablet32 table-serve 17.7 2021-12-14T17:18:05+00:00 2021-12-14T17:20:05+00:00 user930218 user942049rntablet77 table-batch 17.2 2021-12-14T16:37:11+00:00 2021-12-14T16:39:11+00:00 user773476 user783174′), (u’language’, u”)])]From the results, the customer sees that most of the tablets that exhibited high CPU usage during this time period are from the table-batch table. The output helped discover independent workflows that interfere with each other in a multi-table cluster. By identifying the table that exhibits the largest hotspots, the customer can move table-batch to a separate cluster.Likewise, if there are multiple workflows on the same table, the customer can decide to set up replication to isolate the batch workflow. Another approach to understand the breakdown of CPU usage among different workflows is to use custom app profiles.SummaryWe’ve walked through a few use cases on how the hot tablets method can be used to identify and troubleshoot performance problems. This additional observability can help resolve hotspots and reduce latency. To try this on your own Google Cloud project, see documentation about how to use the hot tablets method with the Cloud Bigtable API and the gcloud command.Related ArticleGoogle Cloud and MongoDB Atlas expand their partnershipNew integrations with Google Cloud will simplify discoverability, subscription, onboarding, and management of MongoDB Atlas when running …Read Article
Quelle: Google Cloud Platform

Introducing high-performance Confidential Computing with N2D and C2D VMs

We’re excited to announce Confidential Computing on the latest Google Compute Engine N2D and C2D Virtual Machines. At Google Cloud, we’re constantly striving to deliver performance improvements and feature enhancements. Last November, we announced the general availability of general-purpose N2D machine types running on 3rd Gen AMD EPYC™ processors. Then, in February, we announced the general availability of compute-optimized C2D machine types running on the same 3rd gen processors. Today, we are excited to announce that both of these new N2D and C2D machine types now offer Confidential Computing. By default, Google Cloud keeps all data encrypted, in-transit between customers and our data centers, and at rest. We believe the future of computing will increasingly shift to private, encrypted services where users can be confident that their data is not being exposed to cloud providers or their own insiders. Confidential Computing helps make this future possible by keeping data encrypted in memory, and elsewhere outside the CPU, while it is being processed – all without needing any code changes to applications.General Purpose Confidential VMs on N2DThe first product in Google Cloud’s Confidential Computing portfolio was Confidential VM. A Confidential VM is a type of Compute Engine VM that helps ensure that your data and applications stay private and encrypted even while in use.Today, Confidential VMs are available in Preview on general-purpose N2D machine types powered by 3rd Gen AMD EPYC processors. We worked closely with the AMD Cloud Solution engineering team to help ensure that the VM’s memory encryption doesn’t interfere with workload performance. N2D VMs are a great option for both general-purpose workloads and workloads that require larger VM sizes and memory ratios. General-purpose workloads that require a balance of compute and memory, like web applications and databases, can benefit from N2D’s performance, price, and wide array of features. Compute-Optimized Confidential VMs on C2DWe’re also optimizing Confidential Computing for more types of workloads. Today, Confidential VMs are also available in Preview on compute-optimized C2D machine types. C2D instances provide the largest VM sizes within the compute-optimized VM family and are optimized for memory-bound workloads such as high-performance databases and high-performance computing (HPC) workloads. Adding the compute-optimized machine family to our Confidential Computing portfolio gives you the ability to optimize performance-intensive workloads while maintaining confidentiality and can expand which of your workloads can easily switch to be confidential. Early FindingsYellowDog, a cloud workload management company, is an early user of the new Confidential VMs in the C2D VM family.“At YellowDog, we believe there should be no barriers to adopting secure cloud computing. YellowDog tested workloads across tens of thousands of cores using the new Google C2D VMs running on 3rd Gen AMD EPYC processors.We were truly impressed to discover that the Confidential VMs’ provisioning times were fantastic and the C2D VMs ran with no discernible difference in performance when enabling and disabling Confidential Computing,” said Simon Ponsford, CTO at YellowDog. “We at YellowDog recommend that anyone running secure workloads in Google Cloud enable the Confidential Computing feature by default.”Expanding Confidential Computing availabilityWe are expanding the availability of Confidential Computing, and Confidential VMs are now available in more regions and zones than before, anywhere N2D or C2D machines are available. Confidential N2D VMs and Confidential C2D VMs are available today in regions around the globe including us-central1 (Iowa), asia-southeast1 (Singapore), us-east1 (South Carolina), us-east4 (North Virginia), asia-east1 (Taiwan), and europe-west4 (Netherlands). The underpinnings of Confidential VMsConfidential N2D and C2D VMs with 3rd Gen AMD EPYC processors utilize AMD Secure Encrypted Virtualization (SEV). With the AMD SEV feature, Confidential VMs offer high performance for demanding computational tasks, while keeping VM memory encrypted with a dedicated per-VM instance key that is generated and managed by the processor. These keys are generated by the processor during VM creation and reside solely within it, making them unavailable to Google or other VMs running on the host. We’re currently supporting SEV on 3rd Gen AMD EPYC processors but will bring more advanced capabilities in the future.PricingConfidential N2D and C2D VMs with 3rd Gen AMD EPYC processors are offered at the same price as the previous generation Confidential N2D VMs. You can also take advantage of cost savings with spot pricing. To learn more, visit Confidential VM pricing. Ongoing Confidential Computing InvestmentToday’s announcement comes off the heels of the review that the Google Cloud Security team, Google Project Zero, and the AMD firmware and product security teams collaborated on of the technology and firmware that powers AMD Confidential Computing technology. Google Cloud and AMD are committed to securing sensitive workloads and shaping future Confidential Computing innovations. Getting StartedUpgrading your existing Confidential N2D VMs to use 3rd Gen AMD EPYC processors is easy. If you already use Confidential N2D machines or are just getting started, you can use the latest hardware by simply selecting “AMD Milan or later” as the CPU platform.To create a Confidential C2D VM, choose the C2D option when creating a new VM and check the box under “Confidential VM service” in the Google Cloud Console.With Confidential Computing, you can protect your data and run your most sensitive applications and services on N2D and C2D VMs.Related ArticleN2D VMs with latest AMD EPYC CPUs enable on average over 30% better price-performanceCompute Engine N2D VMs with 3rd Generation AMD EPYC processors deliver, on average, over 30% better price-performance compared to prior g…Read Article
Quelle: Google Cloud Platform

Assembling and managing distributed applications using Google Cloud Networking solutions

In the cloud era, modern applications are assembled from services running across different environments. The benefit of this approach is that organizations can choose which services to use that best serve their needs when building applications. But assembling applications from disparate component services also brings complexity, including:How to connect services together in a reliable and secure mannerEfficiently managing traffic in a consistent way across distributed servicesDefining clear boundaries between the teams that build services vs teams that consume themAs we discussed at the Google Cloud Networking Spotlight, Next-generation application delivery with Google Cloud, we recently introduced solutions to help you reduce the complexity of assembling and managing distributed applications. These solutions include three core networking solutions that allow you to more efficiently orchestrate services into cohesive applications, and include:New Cloud Load Balancers based on the Open Source Envoy Proxy. These Load Balancers give you common traffic management capabilities when using our fully-managed Load Balancers, or when using xDS-based solutions, such as the Envoy Proxy. Ultimately, these Load Balancers allow common traffic management capabilities to be used in services running across different environments.Hybrid Load Balancing and Hybrid Connectivity solutions that connect services across hybrid network environments, so that services work together no matter in which environment the services reside. These include connecting services together that run in Google Cloud, in multicloud environments, or on-premises.Private Service Connect, which allows you to more seamlessly connect services together across different networks. This solution also clearly separates the organizations that develop and maintain services (service producers) from organizations that use the services (service consumers).The Google Cloud networking stackfig 1. Overview of core Google Cloud network productsTo put these solutions into context, let’s first review a high-level overview of core Google Cloud network products.At the foundation of the Google Cloud product stack are connectivity solutions such as Network Connectivity Center, which includes physical Interconnects and VPNs that enable secure and reliable connectivity to on-premises and multicloud deployments into a single coherent connectivity layer.The next layer consists of cloud infrastructure tools that secure your network perimeter, allowing you to make enterprise-wide guarantees of what data can get in and out of your network. Layered on top of that, service networking products let your developers think in services. Instead of worrying about lower-level network constructs like IPs and ports,  these tools let developers think in terms of assembling reusable services into business applications. At the top of the stack are application delivery solutions, allowing you to deliver applications at massive scale. These solutions include Cloud Load Balancers, CDN and Cloud Armor products. And wrapped around it all is Network Intelligence Center, a single-pane of glass view of what’s happening with your network.Together, these solutions are enable three primary Google Cloud Networking capabilities, including:Universal advanced traffic management with Cloud Load Balancing and the Envoy ProxyConnecting services across multicloud and on-premises hybrid network deploymentsSimplifying and securing service connectivity with Private Service ConnectFor the remainder of this blog we will explore these solutions in more detail, and how they work together to give your users the best experience consuming your distributed applications, wherever they are in the world.Advanced traffic management with Cloud Load Balancing and Envoy ProxyWe are excited to introduce our next generation of Google Cloud Load Balancers. They include a new version of our Global External HTTPS Load Balancer and a new Regional External HTTPS Load Balancer. These new load balancers join our existing Internal HTTPS Load Balancer and represent the next generation of our load balancer capabilities. These new Cloud Load Balancers use the Envoy Proxy, a Cloud Native Computing Foundation (CNCF) open source project, providing a consistent data plane and feature set that supports advanced traffic management.fig 2. Overview of the next generation Google Cloud Load BalancersOur next-generation Cloud Load Balancers provide new traffic management capabilities such as advanced routing and traffic policies so you can steer traffic with the flexibility required for complex workloads. A few examples of the advanced traffic management capabilities include:Request mirroring for use cases such as out-of-path feature validationWeighted traffic splitting for use cases such as canary testingFault injection to enable reliability validation such as chaos testingNew load balancing algorithms and session-state affinity optionsAnd because our next-generation Load Balancers are based on open-source technology, they can be used to modernize and efficiently manage services across distributed environments. For example, you can use our Cloud Load Balancers in conjunction with open source Envoy sidecar proxies running in a multicloud or on-premises environment to create a universal traffic control and data-plane solution across heterogeneous architectures. You can optionally use Traffic Director, a fully managed control plane for service mesh architectures to more efficiently manage traffic across xDS-compatible proxies, such as Envoy Proxies.For an example of how to use this universal traffic management architecture across distributed applications, imagine you want to roll out a new service that is used in a distributed system, for example, a shopping cart service that is used in multiple commerce applications. To properly canary-test the rollout, you can use the weighted backend service capability built into Cloud Load Balancers, and in Envoy Sidecar proxies managed by Traffic Director. Here, by incrementally varying the weights, you can safely deploy a new feature or version of a service across distributed applications in a coordinated and consistent manner, and enable uniform canary testing of a new service across your full architecture.fig 3. Canary testing across distributed applicationsHere are more resources for learning about advanced traffic management on Google Cloud:Overview of Google Cloud load balancersAdvanced Traffic management overview for global external HTTP(S) load balancersExternal HTTPs LB with Advanced Traffic Management (Envoy) CodelabSolutions for managing hybrid architectures, multicloud and on-premises deploymentsConsider when you have distributed applications that run on on-premises, inside Google Cloud or in other cloud or software-as-a-service (SaaS) providers. Hybrid Load Balancing and Hybrid Connectivity lets you bring the distributed pieces together. It helps you take a pragmatic approach to adapt to changing market demands and incrementally modernize applications, leveraging the best service available and ultimately providing flexibility to adapt to changing business demands. Hybrid Load Balancing intelligently manages and distributes traffic across a variety of distributed application use cases.fig 4. Hybrid Load Balancing and Hybrid Connectivity use casesGoogle Cloud Hybrid Load Balancing and Hybrid Connectivity solutions include components designed to securely and reliably connect services and applications across different networks. These connectivity options include private Interconnects (Partner & Direct), VPN, or even the public internet, so you can use both private and public connectivity to assemble application services. And our Cloud Load Balancers can manage traffic regardless of where the backend services reside.fig 5. Hybrid Load Balancing deploymentsHybrid Load Balancing and Connectivity can be combined with our next generation of Google Cloud Load Balancers to provide advanced traffic management across Google Cloud, on-premises and in multicloud distributed application deployments. Check out these resources for more on managing hybrid, multicloud and on-premises architectures:Hybrid Load Balancing overviewExternal HTTP(s) Hybrid load balancer CodelabSimplifying and securing connectivity with Private Service ConnectServices that are used across distributed applications are often authored and maintained by one team (service producers) and used by other teams building individual applications (service consumers). This approach provides significant benefits when assembling distributed applications as it enables service reuse and separation of roles for teams building and using services. However, there are also complexities connecting and managing these services across environments.Private Service Connect provides a network-agnostic connectivity layer and a built-in service ownership structure to efficiently reuse services across distributed applications. Private Service Connect provides a method of connecting two cloud networks together without peering and also without sharing IP address space — a seamless way of communicating with services within Google Cloud or across on-premises or multicloud deployments.Private Service Connect provides you with a private IP address from inside your VPC. You can use it to privately access Google services such as Google Cloud Storage or BigQuery, third-party SaaS services such as MongoDB or Snowflake, or even your own services that may be deployed across different VPCs within your organization.fig 6. Private Service Connect overviewPrivate Service Connect also lets you separate the concerns of consumers (the teams that initiate a connection to a service) from the producers (the teams offering a service to be connected to). Because these roles are built-in to Private Service Connect, you don’t have to go through the toil of defining your own organizational structure, but can simply leverage the identity and access permissions already available to you on Google Cloud. Here are more resources on Private Service Connect:Private Service Connect OverviewPrivate Service Connect CodelabConclusionWe hope the solutions presented here give engineers and cloud architects the tools to build robust distributed applications in a hybrid and multicloud environment at scale, allowing you to think less about the details of your network, and more about assembling applications from services that deliver the best value to your users. To learn more about these advanced use cases — and to see how our customers use Google Cloud Networking tools in action — register for our Networking Spotlight today May 24, or on demand thereafter.Related ArticleIntroducing Media CDN—the modern extensible platform for delivering immersive experiencesWe’re excited to announce the general availability of Media CDN — a content and media distribution platform with unparalleled scale.Read Article
Quelle: Google Cloud Platform

Running a virtual event globally, how Gramercy Tech leveraged serverless technology

Editor’s note: In today’s guest post we hear from Gramercy Tech on their experience working with Google Cloud’s serverless technologies as both a customer and vendor. Large events are always a lot of work. By leveraging the pre-provisioned infrastructure of Cloud Run in multiple regions and global load balancing, the team could focus on content and event experiences.As the world gradually emerges from the Covid era, the lessons learned from fully online virtual events will have lasting effects on the way events are managed and attended. When Google Cloud approached Gramercy Tech for help running a global internal sales event we took the opportunity to look at how to enhance the capabilities of our Eventfinity platform to better take advantage of Serverless technologies and multi-regional deployments to deliver both a better user experience, more efficiently, and with less operational burden.With a global audience, the demands of an event site show highly varied loads both at different time zones, but also different parts of the event lifecycle. Registration windows may see bursts of activity at open and closing and during the event mixtures of live and recorded content can cause periods of both low and high traffic. Participants in a global conference are all integrating this time commitment into their busy schedules, and should be able to expect a quick and responsive event site throughout the experience. To meet these goals, we were able to easily adapt our platform to the following global serverless architecture:Deployed architecture across three regionsUsing standard containers, it was easy to package and deploy our primary application services in Cloud Run. We were able to deploy this to multiple regions and use Cloud Load Balancer to ensure that traffic from anywhere in the world was routed to the nearest instance. With Cloud SQL we were able to establish read replication globally. Core functions in our platform are kept speedy by using Redis and Memcache which we were able to deploy using Cloud Memorystore. By taking advantage of these managed services we were able to quickly get this architecture deployed and could focus on running our platform, setting up multi region infrastructure was something we didn’t realize could be so simple.Media and content could be offloaded to Cloud CDN letting us focus on experiences, not on moving bytes. As the application tier handles many of the direct user interactions with our platform, it sees very elastic demand. Cloud Run was a game changer for us, the speed to deploy updates across environments, as well as the scaling up and down instances saves so much time and money.Overall, this experience has guided our teams into using container systems more since so much of GCP leverages containers whereas our past infrastructure was all bare metal servers running code directly. This push has definitely caused us to replatform our entire design using containers and serverless infrastructure wherever possible, making us faster and more stable all around. After this experience we plan to move the bulk of our systems to GCP.  At Gramercy we’ve constantly evolved our technology to meet the needs of the time, from events going paperless pre-covid, to fully virtual during covid to the new world of hybrid events. It has been great to work with Google and Google Cloud to keep event management on the cutting edge.Related ArticleThe L’Oréal Beauty Tech Data Platform – A data story of terabytes and serverlessData warehousing at L’Oréal got a makeover when the company selected BigQuery and Cloud Run as the basis for its revamped data analytics …Read Article
Quelle: Google Cloud Platform