I have a process (Python) which is running more than 10min. Initially thought of running in Google cloud App Engine, since it has 60 sec time out window planning to run in google compute engine. But I come to know that compute engine also have 10min time out window, but I couldn't find that information in internet.
So thought of checking, Please let me know whether google compute engine also has time out window?
Thanks,
App Engine Standard
App Engine standard environment has a 60 second timeout for HTTP requests and 10 minute timeout for tasks in task queues. App Engine standard runs on a specialized sandboxed environment.
There is also some info here about various DeadlineExceededError messages you could get in App Engine standard and how to handle them.
App Engine Flexible
App Engine also provides an alternate environment (App Engine Flexible aka Flex) which in turn runs on Google Compute Engine (GCE) VMs. It has a timeout of 60 minutes. It also provides more flexibility in terms of languages and runtimes.
Both of the App Engine environments (Standard and Flex) are managed Platform-as-a-Service environments (as in, you need not worry about spinning up the underlying infrastructure and managing them). Google App Engine takes care of this automatically.
You can look at the comparison of App Engine Standard vs App Engine Flex.
Directly using GCE VMs
When you use Google Compute Engine (GCE) VMs directly, they do not have any associated timeouts (except for preemptible VMs which I've described below). A GCE VM will be fully managed by you and you control how long the instance runs.
There are times when your VM can be Live migrated due to ongoing maintenance events, which BTW is mostly transparent to you and your application running on the VM. Your machine could restart at times due to hardware failures which is out of your control, but that's where you need to make your application resilient to such failures. In fact by using App Engine, these details are abstracted from you and fully managed by Google.
Preemptible VMs
Preemptible VMs are lower cost and short-lived GCE VMs which have a maximum duration of 24 hours and can be terminated even before that if GCE wants to use the underlying resources for other purposes. This is more useful for processing batch workloads where there is no strict latency requirements.
Related
I'm using the Google Compute Engine instance of group, with autoscaling, to run a heavy script that varies the CPU usage during the day, but when I'm going to perform a stress test with a maximum of 4 VM's I notice that the CPU usage increases to 100% only on the main VM, while the other 3 remain at 0%. Wasn't it to divide the use between the 4 VM's according to the target I defined? Or did I misunderstand how this API works?
The role of GCE Autoscaler / Managed Instance Group in this case is to provision the correct number of VMs based on your CPU usage. This part works correctly as I understand, because you got 4 VMs.
Your role is to make sure you spread the load over all these VMs. Typically, a "script" running on a single machine will not automagically start executing on multiple machines.
For (web) serving workloads this is usually achieved using load balancers, which would distribute incoming requests between the machines automatically.
It is a lot more tricky for batch workloads (and you are in this category, if I understand correctly). I don't think Google offers any automated tools here.
I have a python Flask APIs deployed on cloud run. Autoscaling, CPU, concurrency everything is configurable in cloud run.
Now the problem is with the actual load testing with around 40k concurrent users hitting APIs continuously.
Does cloud run handle these huge volumes or should we port our app to GKE?
What are the factors decide Cloud run vs GKE?
Cloud Run is designed to handle exactly what you're talking about. It's very performant and scalable. You can set things like concurrency per container/service as well which can be handy where payloads might be larger.
Where you would use GKE is when you need to customise your platform, perform man in the middle or environment complexity, or to handle potentially long running compute, etc. You might find this in large enterprise or highly regulated environments. Kubernetes is almost like a private cloud though, it's very complex, has its own way of working, and requires ongoing maintenance.
This is obviously opinionated but if you can't think of a reason why you need Kubernetes/GKE specifically, Cloud Run wins for an API.
To provide more detail though; see Cloud Run Limits and Quotas.
The particularly interesting limit is the 1000 container instances but note that it can be increased at request.
Removing Compute Engine API results in an Unknown error, I don't have any instance, disk, image or anything else in Compute Engine, never used and still charged me few cents for "Storage Image".
Should I close this project and create a new one?
If you look into your Network Internet Egress in Compute Engine, it turns out that some other environment might be using compute engine to handle outgoing network traffic and calls it as "Compute Engine". Therefore the charges for Compute Engine did not stop, hence giving error while disabling Compute Engine API.
To completely stop this you can go ahead and shutdown your project, but be careful as shutting down a project releases all resources used within the project.
You can follow this link.
To automatically manage Cloud resources in order to meet the felt need of my infrastructure, I need to increase VM resources. But this is possible only while the machine status is TERMINATED.
The problem is that I have got applications on the VMs that must not stop running. Do you have any suggestions about how I could proceed, like increasing my machines resources without interrupting its services? (database, web, etc...)
The purpose of that is to automate my whole infrastructure, to ensure its quality of service even if I'm not monitoring it by myself.
I suggest to take a look to Managed Instance Groups. It will offer some of the characteristics you need: high availability, scalability and the ability to add the instance group to a load balancer.
According to the Google official documentation about MIGs:
Make your workloads scalable and highly available by taking advantage of automated MIG services, including: autoscaling, autohealing, regional (multiple zone) deployment, and automatic updating.
Regarding the need of automation of the services you want, I suggest to generally use fully managed services. You can check a summary of GCP services and you can always inspect if they fit your demands.
I am running django on google VM instance using apache and mod wsgi... i however am unsure of the concurrent requests that my app shall receive from the users and would like to know if i can transfer the surplus load of the VM to the App engine automatically to prevent the server from crashing.
I am unable to find any solution expect running kubernetes cluster or docket containers to effectively manage the load. but in need to be free of this hassle and send off the excess load to GAE.
If you want to analyze the traffic, latency and load of your resources and applications, I would recommend you to start with Stackdriver Trace.
As per documentation, Stackdriver Trace is a distributed tracing system that collects latency data from your applications and displays it in the Google Cloud Platform Console. You can track how requests propagate through your application and receive detailed near real-time performance insights. Stackdriver Trace automatically analyzes all of your application's traces to generate in-depth latency reports to surface performance degradations, and can capture traces from all of your VMs, containers, or Google App Engine projects.
Once you have determine the user traffic or you have a better idea about this, then you can try using "Instance Groups".
GCE offers two kind of VM instance groups:
Managed instance groups (MIGs) allow you to operate applications on multiple identical VMs. You can make your workloads scalable and highly available by taking advantage of automated MIG services, including: autoscaling, autohealing, regional (multi-zone) deployment, and auto-updating.
Unmanaged instance groups allow you to load balance across a fleet of VMs that you manage yourself.