You have an application that uses Cloud Spanner as a backend database. The application has a very predictable traffic pattern. You want to automatically scale up or down the number of Spanner nodes depending on traffic. What should you do?
You have an application that uses Cloud Spanner as a backend database. The application has a very predictable traffic pattern. You want to automatically scale up or down the number of Spanner nodes depending on traffic. What should you do?
To automatically scale the number of Cloud Spanner nodes based on traffic, you need a solution that reacts dynamically to changing conditions. Creating a Cloud Monitoring alerting policy to send an alert to a webhook ensures that you receive real-time notifications when the Spanner CPU usage exceeds or drops below specific thresholds. This alert can trigger a Cloud Function that listens to HTTP requests and resizes the Spanner resources accordingly, providing an automated, scalable, and responsive solution. This approach leverages Cloud Functions for automation without requiring manual intervention, which is crucial for efficiently managing variable traffic patterns.
D. Create a Cloud Monitoring alerting policy to send an alert to webhook when Cloud Spanner CPU is over or under your threshold. Create a Cloud Function that listens to HTTP and resizes Spanner resources accordingly.
Without knowing that much, you can discard easily B,C as they don't make any sense. Automation should be a key in this answer. Also you should discard "A" as with a CronJob you won't spann on time as it will be a fixed time checking. So the only one that is left is D, as just creating an alert and sending it to "something else" (in this case a webhook) in an automated way, should be the common sense way of handling this.
Isn't "fixed time chacking" appropriate for quote : very predictable traffic pattern?
Crossed my mind too, but why check every time when you can trigger a response when it happens. Predictability can also be used to determine the threshold.
D 205%
seriously? 205%?
https://cloud.google.com/architecture/autoscaling-cloud-spanner
It's a tricky question. The answer is 'A'. Question says traffic pattern is predictable. This means you can schedule the scalability. You can achieve this easily by using Cloud Spanner's API. https://cloud.google.com/spanner/docs/reference/rest/v1/projects.instances/patch
Really tricky indeed...But if you think about it and you don't stick religiously to "traffic pattern is predictable" sentence (that sentence is to trick you), you would think that despite the pattern is very predictable, it could vary at some point in time. With a cron job you can schedule a job using a fixed starting point and a a fixed ending, can't you? Well, what would happen if the app traffic suddenly spikes before your cron job starts running? Or after?. At this point, I go for D, making scalability automatic thanks to Cloud Funtions.
I would say A also, as your explanation doesn't satisfy me, as the question is really clear that traffic is predictable. It doesn't mention any wiggle room.
D is the answer
D is the answer
Answer is D. The keyword to look for is "automatically". A, B, C all have steps that are not automatic. Thus, only D is left.
Why not A is correct as question suggested specific time where as D is like an unpredectiable time?
Because even though the traffic has a clear pattern, if the traffic changes one day (like a special holiday for ecommerce websites), you wouldn't be able to serve accordingly. It's never a good practice use fixed jobs for time-based traffic issues.
Option D. There's an official repository that does something similar to provide autoscaling to Cloud Spanner. https://github.com/cloudspannerecosystem/autoscaler
Which uses a Cloud Scheduler so answer A
"...and then resize the Spanner instance accordingly." I think the last sentence says that the resize action is done manually. If so, then D is still the right answer.
For the D option, "Create a Cloud Function that listens to HTTP and resizes Spanner resources accordingly." The listen and resize actions is done by Cloud Function.
The most suitable approach to automatically scale the number of Cloud Spanner nodes based on predictable traffic patterns is: D. Create a Cloud Monitoring alerting policy to send an alert to a webhook when Cloud Spanner CPU is over or under your threshold. Create a Cloud Function that listens to HTTP and resizes Spanner resources accordingly. This option utilizes Cloud Monitoring alerts and Cloud Functions to dynamically scale Cloud Spanner resources based on CPU thresholds, providing an automated and responsive solution.
D is correct, It is part of Tutorials Dojo practice test
Correct answer is D
D is definitely correct .. people
D is the correct Answer as B or C does not do it automatically, and a doesnot use for long spanning
Correct answer is D.
Why not A if traffic very predictable?