da Agency

More value for less with Cloud SQL committed use discounts

Getting the best price in the cloud shouldn’t require sophisticated forecasting models or unnecessary financial risk. Today, we’re introducing committed use discounts for Cloud SQL, which reward your steady-state, predictable usage in a way that’s easy to use and can accommodate changes in your database environment. Cloud SQL committed use discounts give you a 25% discount off of on-demand pricing for a one-year commitment and a 52% discount off of on-demand pricing for a three-year commitment.These committed use discounts are flexible:No upfront payments are requiredAvailable and able to be shared between MySQL, PostgreSQL, and SQL Server instancesFully transferable between machine sizesWhy is flexibility important? It saves you time by reducing management overhead and maximizes your savings by allowing you to pool more resources and achieve higher utilization.You can see what you’ll save before purchasing using the built-in calculator in the Purchase Commitment dialog of your Google Cloud billing console. Here’s an example:We’re also simplifying our on-demand pricing. Cloud SQL previously offered sustained use discounts, which automatically lower the price of your instances when you use them for a significant portion of the month. Starting today, we’re lowering our list price to the previous sustained use discount price (and removing sustained use discounts). Now, our list price is our best on-demand price, regardless of your usage. These new committed use discounts are applied to this new, lower list price.How this simple and flexible pricing worksWe built committed use discounts so you actually attain the savings you expect—no matter how you configure your resources or which database you select. You commit to a consistent amount of usage, measured in USD per hour of equivalent on-demand spend, for a one- or three-year term. Cloud SQL Committed Use Discounts cannot be applied to licensing, storage, or networking. Instead, these discounts apply to all Cloud SQL database instance CPU and memory usage in the region in which you have committed, except shared CPU machine types (db-f1-micro and db-g1-small). The discounts also apply to usage from all databases supported by Cloud SQL, including MySQL, PostgreSQL, and SQL Server. Committed use discounts automatically apply to aggregate Cloud SQL instance usage in a region, giving you low, predictable costs, without the need to make any manual changes or updates yourself. This flexibility saves you time and helps you to save more by achieving high utilization rates across your commitments, without requiring sophisticated forecasting or imposing constraints on resource configuration.For example, say you run several Cloud SQL for SQL Server database instances for one month with aggregate vCPU and memory consumption of $10,000. Then, the next month, you migrate some of these instances to Cloud SQL for PostgreSQL and change instance sizes. As long as your aggregate resource consumption remains at $10,000, you receive the same discount both months even though your database environment footprint is different.Getting started is easySign in to the Manage billing accounts page in the Google Cloud ConsoleOn the Billing Overview page, look for the What’s new card, then click Purchase Cloud SQL Commitment.Check out our documentation for more details on committed use discounts. For Cloud SQL pricing information, including the new list price, take a look at our pricing page or try out our pricing calculator.Want to learn more about what else is new with Cloud SQL? Be sure to check out our session at Next OnAir. Get started and try Google Cloud for free now.
Quelle: Google Cloud Platform

da Agency

Your Next ‘20 OnAir journey starts here: Resources and session guides available now

Get ready. Get set. Get solving. Google Cloud Next ‘20 OnAir kicks off July 14, offering nine full weeks of programming to help you solve your toughest business challenges in the cloud. And the best part is you can join in, for free, no matter where you are, and at a time that works for you. Here’s how to get ready.Watch the keynote with Thomas Kurian on-demand starting July 14We’ll be kicking off Next ‘20 OnAir on July 14 (July 15 in Asia Pacific) with a keynote by Google Cloud CEO Thomas Kurian. Each week thereafter, there’ll be solution keynotes hosted by Google Cloud leaders. This means, for example, you can hear Javier Soltero, VP & GM, G Suite, talk about the future of cloud-native productivity and collaboration, or catch Eyal Manor, GM & VP, Engineering share the latest on app modernization. Find the full list of solution keynotes.Browse the session catalog and create your own playlistEach week during Next we’ll be adding a new batch of breakout sessions you can watch on demand. To plan ahead, you can browse the full session roster, and once you’ve registered for the event and are signed in, you can create your own customized playlist. Click “Filter” to search by speakers, topics, or industries. When you see a session you like, click “Add to playlist” to include it in your all-digital schedule. Toggle “My Playlist” to switch between the full session catalog and just the sessions you’ve bookmarked.Introducing session packagesOnly interested in a specific topic or learning area? Our curated session packages are an easy way to get recommendations on what to watch.Cloud in practiceAI for technologistsApplication developmentCost managementData analyticsData engineeringData security, disaster recovery, and backupMigrationSupporting high performance computing workloadsFor business leadersAI for business leadersBusiness continuityDigital transformationCloud essentials for business leadersWorkforce productivityFor startupsStartups: IntroductoryStartups: AdvancedBy industryFinancial servicesGamingHealthcareManufacturingMedia & entertainmentPublic sector: EducationPublic sector: GovernmentRetailTelecommunicationsStart your learning journeyWe’ve created a unique learning series for technical practitioners of all experience levels. Each week, we’ll focus on a different theme to help you boost your skills–from the fundamentals to more advanced topics, including infrastructure, analytics, AI, and more. You can find our full schedule of learning content on our Learning Hub.If you’re new to Google Cloud, or brushing up on the basics, join us during our weekly Cloud Study Jam where experts will walk you through relevant training and certification resources, lead you through hands-on labs, and answer your questions live.Attending a Cloud Study Jam event will also prepare you to earn your first skill badge on Qwiklabs. Digital skill badges allow you to demonstrate your growing Google Cloud-recognized skillset and share your progress with your network. You can earn the badges by completing a series of hands-on labs, including a final assessment challenge lab, to test your skills.Once you’re more confident in your skills, join our weekly Cloud Hero game. In this competitive challenge, you’ll find a curated collection of relevant hands-on labs to help you practice and track your progress with a live leaderboard.We also invite you to join us weekly for Google Cloud Talks by DevRel. Each Friday of Next OnAir, we’ll do a recap of the week’s topic focusing on the content most relevant to developers and technical practitioners, host a Q&A session with members of the Google Cloud Developer Relations team, and deliver technical talks that supplement the week’s programming. To see the full schedule and to register, visit the program website. Sign up for 1:1 time with Google Cloud expertsHave a specific cloud challenge facing you today? Get help solving it during a 15-minute appointment with a Google expert aligned with the session topic of the week.Please note: Appointments are limited, subject to availability, and not eligible for job inquiries.Stay up-to-date with weekly coverage and recapsThe Google Cloud blog will be posting updates and recaps each week on the key news from Next. You can find all our coverage here. Or follow us on social media:Twitter: Google Cloud, GCP, G Suite, and Google Cloud PartnersFacebook: Google Cloud, GCP, and G SuiteLinkedIn: Google Cloud and G SuiteWe can’t wait to get started with Next OnAir—we hope you’ll join us!
Quelle: Google Cloud Platform

da Agency

Increase visibility into Cloud Spanner performance with transaction stats

Cloud Spanner is Google’s fully managed scalable relational database service. We recently announced a new feature, Cloud Spanner transaction statistics, that lets you run SQL queries to retrieve transaction statistics for your database over several time periods. These transaction statistics give you greater visibility into what factors are driving the performance of your transactions.In this post, you’ll see how to use these transaction statistics to identify which transactions are involved in Cloud Spanner database contentions.Understanding transactions in SpannerA transaction in Spanner is used to perform a set of reads and writes that execute atomically at a single logical point in time across columns, rows, and tables in the database. It helps to understand how transactions work in Spanner to best troubleshoot any contentions. Transaction statisticsTransaction statistics bring you insight into how an application is using the database and are useful when investigating performance issues. For example, you can check whether there are any slow-running transactions that might be causing contention, or you can identify potential sources of high load, such as large volumes of updates to a particular column.Spanner provides built-in tables that store statistics about transactions. You can retrieve statistics from these SPANNER_SYS.TXN_STATS* tables using SQL statements.Aggregated transaction statisticsSpanner captures aggregated transaction statistics in the following system tables:SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: Transactions during one-minute intervalsSPANNER_SYS.TXN_STATS_TOTAL_10MINUTE: Transactions during 10-minute intervalsSPANNER_SYS.TXN_STATS_TOTAL_HOUR: Transactions during one-hour intervalsEach row in the above tables contains aggregated statistics of all transactions executed over the database during the specific time interval. So, the above tables contain only one row for any given time interval.Top transaction statisticsSpanner captures transaction statistics including latency, commit attempts, and bytes written in the following system tables.SPANNER_SYS.TXN_STATS_TOP_MINUTE: Transactions during one-minute intervalsSPANNER_SYS.TXN_STATS_TOP_10MINUTE: Transactions during 10-minute intervalsSPANNER_SYS.TXN_STATS_TOP_HOUR: Transactions during one-hour intervalsIf Spanner is unable to store statistics for all transactions run during the interval in these tables, the system prioritizes transactions with the highest latency, commit attempts, and bytes written during the specified interval.Find the root cause of a database contention in SpannerTransaction statistics can be useful in debugging and identifying transactions that are causing contentions in the database. Next, you’ll see how this feature can be used to debug, using an example database where write latencies are high because of database contentions.Step 1: Identify the time period with high latenciesThis can be found in the application that’s using Cloud Spanner. For example, the issue started occurring around “2020-05-17T17:20:00″.Step 2: See how aggregated transactions metrics changed over a period of timeQuery the TXN_STATS_TOTAL_10MINUTE table around the start of the issue. The results of this query may give clues about how latency and other transaction statistics changed over that period of time.For example, this query can get aggregated transaction statistics, inclusive from “2020-05-17T16:40:00″ to “2020-05-17T19:40:00″. This brings back results, one for each 10-minute interval. Here’s what that looks like:QueryOutputIn the results, you can see that aggregated latency and abort count is higher in the highlighted period of time. We can pick any 10-minute interval (for example, interval ending at “2020-05-17T18:40:00″) where aggregated latency and/or abort count are high. Then, in the next step, you can see which transactions are contributing to high latency and abort count.Step 3: Identify the exact transactions that are causing high latencyQuery the TXN_STATS_TOP_10MINUTE table for the interval you picked in the previous step. The results of this query can give some clue about which transactions are having high latency and/or high abort count.Use the below query to get top performance-impacting transactions in descending order of total latency for the interval ending at “2020-05-17T18:40:00″.QueryOutputThe highlighted row in the preceding table is an example of a transaction experiencing high latency because of a high number of commit aborts.Step 4: Check for similarities among high-latency transactionsWe can fetch read_columns, write_constructive_columns and write_delete_tables columns for transactions with high abort count (also note the fprint value, which will be useful in the next step). This is to check whether high-latency transactions are operating on the same set of columns.QueryOutputAs the output shows, the transactions with the highest average total latency are reading the same columns. We can also observe some write contention, since the transactions are writing to the same column: TestHigherLatency._exists. Step 5: See the shape of high-latency transactions over the affected period of timeYou can see how the statistics associated with this transaction shape have changed over a period of time. Use the following query, where $FPRINT is the fingerprint of the high-latency transaction from the previous step.QueryOutputIn the above output, you can see that total latency is high for the highlighted period of time. And, wherever total latency is high, both commit_attempt_count and commit_abort_count are also high, even though commit latency (commit_latency) has not changed very much. Since transaction commits are getting aborted more frequently, commit attempts are also high because of commit retries.By using the above troubleshooting steps, we found the transactions that are involved in the contentions. So, high commit abort count is the cause of high latency. The next step is to look at the commit abort error messages received by the application to know the reason for aborts. By inspecting logs in the application, we see the application actually changed its workload during this time. That likely means that some other transaction shape showed up with high attempts_per_second, and that a different transaction (maybe a nightly cleanup job) was responsible for the additional lock conflicts.Cloud Spanner transaction statistics provides greater observability and insight into your database behaviors. Use both transaction statistics and query statistics to tune and optimize your workloads on Spanner.To get started with Spanner, create an instance in the Cloud Console or try it out with aSpanner Qwiklab.
Quelle: Google Cloud Platform

da Agency

Detecting and responding to Cloud Logging events in real-time

Logging is a critical component of your cloud infrastructure and provides valuable insight into the performance of your systems and applications. On Google Cloud, Cloud Logging is a service that allows you to store, search, monitor, and alert on log data and events from your Google Cloud Platform (GCP) infrastructure services and your applications. You can view and analyze log data in real time via Logs Viewer, command line or Cloud SDK. These logging tools are built to help you find and understand your logs. You may have business or technical processes that may require an automated action or you may want to reduce toil for your DevOps team. For example, you may want to use changes in your Cloud Audit Logs to take action and remediate a security vulnerability caused by inadvertent infrastructure changes.Using a Logging sink, you can build an event-driven system to detect and respond to log events in real time. Cloud Logging can help you to build this event-driven architecture through its integration with Cloud Pub/Sub and a serverless computing service such as Cloud Functions or Cloud Run.Architecture overviewThe high-level architecture of this event-driven system is both simple and flexible. There are four main components:Log events – The applications and the infrastructure send logs to Cloud LoggingLogging –  Cloud Logging sinks in the Logs Router lets you send log events to Pub/Sub topics based on the specific filters you createPub/Sub – Initiates Cloud Functions asynchronously based on the received log eventsCloud Functions – The business logic to process and respond to the log eventsThis loosely coupled event-driven system can autoscale based on the volume of log events without any capacity planning or management from the user. Using a serverless computing option can also significantly reduce the cost and improve programmers’ productivity. For example, you can use Cloud Function code to help analyze log entries, store data, and invoke other APIs or services as needed. Log eventsEach log event written to Cloud Logging includes a LogEntry, which includes the log name, timestamp, resource of the log source, payload, and metadata. Depending on how the log is written, the payload could be data stored as one of three types: a Unicode string (textPayload), a JSON object (jsonPayload), or a protocol buffer (protoPayload). You can examine the payload of the logs and extract useful events such as errors, exceptions, or specific messages. This same payload is available to the Cloud Function logic.For example, if public read permission is added to a Cloud Storage bucket, an audit log entry similar to the following one will be sent to Cloud Logging. You can extract the payload and process based on the action.Use casesThere is a wide range of situations where you can implement an event-driven system to process and respond to log events. To provide examples, we have developed three different Cloud Functions as reference code which respond to three different types of log messages. In our reference code, we implemented the logic using Cloud Functions to host and run the code. If you prefer, you could also implement similar logic using Cloud Run or App Engine. If you’re not sure which serverless computing options you need, you can read more at the serverless options comparison page to help you decide.Here are three common use cases that you can use as reference for an event-driven architecture for log events.1. Automatically enforce firewall rulesOur first use case is to automate firewall changes against “obvious policy violations” on Google Cloud such as allowing full internet access for an internal company service. In many organizations, there are security policies that only allow Ingress traffic to applications from specific ports, such as 80, 443, or within a particular IP range. If a change made to firewall rules violates these policies, that could open a security vulnerability and potentially leave a system open for compromise. For example, a private service not meant to receive internet traffic may be exposed with a firewall rule that allows all ingress traffic (0.0.0.0/0). You can remediate a firewall change that doesn’t adhere to policy when it is detected. Based on our event-driven architecture, the implementation includes three components:Logging sink – Using a Logging sink, you can direct specific log entries to your business logic. In this example, you can use Cloud Audit logs for Compute Engine which use the resource type gce_firewall_rule to filter for the logs of interest. You can also add an event type GCE_OPERATION_DONE to the filter to capture only the completed log events. Here is the Logging filter used to identify the logs. You can try out the query in the Logs Viewer.resource.type=”gce_firewall_rule” operation.last=truePub/Sub topic – In Pub/Sub, you can create a topic to which to direct the log sink and use the Pub/Sub message to trigger a cloud function. Cloud Function – In Cloud Functions, you can create logic to evaluate the received logs based on your business requirements.The cloud function can then be invoked for any firewall rule changes that are captured in Cloud Audit Logs including:compute.firewalls.patch compute.firewalls.insertcompute.firewalls.updateIf one of the log entries above appears in the audit logs, that triggers the cloud function logic. In the reference implementation, the cloud function retrieves the entire firewall rule details using the Compute Engine API and checks all the items in it. In our example, we simply remove the firewall rule if we find a violation. You can also patch the rule or roll it back with additional logic.After you write the code, you can deploy it using an Infrastructure-as-Code approach. For instance, you can use the following configuration with Cloud Deployment Manager to automate the deployment. In this configuration, you can see how the Logging sink, Pub/Sub topic and Cloud Function are provisioned. Optionally, you can also configure Sendgrid to send an email notification to your specified email address.2. Automatically remediate a misconfigured bucketOur second use case focuses on preventing a misconfigured bucket in Cloud Storage. A misconfigured bucket can expose sensitive data and cause damage to your organization. To help protect against this, you can monitor the configuration changes to the bucket. For example, if an admin inadvertently opens a bucket to the public for read/write, you can capture this change and remove the public access using a cloud function. This is especially useful when combined with an aggregated sink that captures all logs for your Google Cloud organization.You can then invoke the cloud function for any Cloud Storage bucket changes that Cloud Audit Logs captures, including:storage.buckets.createstorage.buckets.updatestorage.setIamPermissionsIf one of the changes above appears in the audit logs, you can look up the bucket policy and remove rules associated with allUsers or allAuthenticatedUsers.3. Automate your business event logicFor our last use case, we’ll show you how to extend the system by integrating it with other services. In Cloud Logging, you can create logs-based metrics, which are custom metrics in Cloud Monitoring from log entries. For example, the payment service in an ecommerce app logs various exceptions during the payment process. You can create a logs-based metric to count all those exceptions. After that, you can create an alerting policy to send your primary on-call person an alert if the metric exceeds a threshold in a short period.Built-in logs-based metrics are good for counting the number of log entries and tracking the distribution of a value in your logs. However, it might not be adequate when you need to perform computation based on the log entry content or add business-specific labels to your metrics. For those use cases, you can use the logs-based event-driven architecture to write the metrics. For example, let’s say that you want to monitor product recommendations in real time for your ecommerce app. You can use logs-based metrics to capture your specific business metrics. As an example, this microservices demo app is a simple demo ecommerce app that you can deploy. In it, when a user clicks a product, a recommendation is generated for related products on the site and written as a log entry. Using a logs-based event-driven architecture pattern, you can capture the log entries in a cloud function and then create your custom business metrics with business-specific labels for the products recommended by the application. With these metrics, you can create alerting policies in Cloud Monitoring just like you can for any other Monitoring metrics.Re-using the Pub/Sub and Cloud Function patternIn fact, we recently launched a Pub/Sub notification channel for alerting, which means that you could also use the same event-driven architecture described in these three examples to instead automate alerts for metrics not created from your logs.Get startedIt’s easy for you to build an automated, real-time analysis and operation capability with our logging and serverless computing services. You can find the code for the examples we discussed previously on github. If you haven’t already, get started with Cloud Logging and Serverless Computing with the Monitoring and Logging for Cloud Functions qwiklab. We also invite you to join the discussion on our mailing list. As always, we welcome your feedback.
Quelle: Google Cloud Platform