4

I have a webserver running in App Engine and the client is a mobile app. I am seeing that a lot of requests on the mobile are starting to fail once we scaled up to a lot of users. I am not seeing any failures in our logs however. I noticed in our quotas that our ip address in use for Compute Engine API is at its max of 8 (even though we're not running any services on Compute Engine). I am not sure if this is the root cause but it wasn't like this before, I was wondering if there is any advice on how to address this problem or if there are better way to structure our server to meet our use case.

EDIT: Our current configuration is a flex environment on App engine, with minimum 2 instances. We also have a MySQL instance. Those pretty much so far everything we've used. 

runtime: php
env: flex

api_version: 1

handlers:
- url: /.*
  script: public/index.php

runtime_config:
  document_root: public

beta_settings:
    # for Cloud SQL, set this value to the Cloud SQL connection name,
    # e.g. "project:region:cloudsql-instance"
    cloud_sql_instances: "<project>:<region>:<sql-instance>"
LundinCast
  • 9,412
  • 4
  • 36
  • 48
Jamil Seaidoun
  • 949
  • 1
  • 11
  • 24
  • In the GCP Console, go to Networking -> VPC network -> External IP addresses. This will show you what services are using your static IP addresses. – John Hanley Oct 25 '18 at 01:14
  • @JohnHanley we don't have any external ip addresses configured, we are using currently just the url to the app engine webserver which looks like: -dot-.appspot.com, to make it better accessible from external networks should we be using static IP addresses – Jamil Seaidoun Oct 25 '18 at 03:39
  • That page will show you all the external IP addresses that you are using. Please add more information to your question on how you have configured app engine. – John Hanley Oct 25 '18 at 03:49
  • What I mean is when I go to the external ip addresses, it gives me the dialog to reserver a static ip address and nothing else. I've edited my question to add more information about how we've configured – Jamil Seaidoun Oct 25 '18 at 16:24

1 Answers1

5

You didn't mention it in your question but I believe you are using App Engine Flexible environment. Under the hood, App Engine flex apps run on (hidden from you) Compute Engine instances in your project. So it actually goes against Compute Engine quotas as well, including the "ip address in use" for your App Engine Region.

The "ip address in use" impacts your App Engine flex app in that it'll limit the number of instances your app will be able to scale up to, since each instance uses its own IP. For example, as per the app.yaml file you provided, your scaling setting defaults to automatic scaling with minimum 2 instances and maximum 20 instances. The "ip address in use" quota will prevent your app to upscale above 8 instances when the number of users using your app increases.

One other thing to note is that you may have previous versions of your service that are still running. If they have the same scaling setting, this means they'll have minimum 2 instances running each, which will count towards the "ip address in use" quota also.

Since you can't deploy your App Engine instances in a network in another region that the one you set for your App Engine app, the only solution here is to request a quota increase. In your Developer Console, got to IAM & admin > Quotas, select this particular quota and click on the "Edit Quotas" button at the top and follow the instructions.

LundinCast
  • 9,412
  • 4
  • 36
  • 48
  • You're right I am using Flex Environment. Just to understand first, what purpose do the ip address in use serve? I am having a hard time trying to figure out why the number of external connections from multiple phones are limited. (I also edited my question to contain more info about our configuration). – Jamil Seaidoun Oct 25 '18 at 16:55
  • 1
    I updated my answer to provide more details. Hope it helps. – LundinCast Oct 26 '18 at 12:09
  • thank you so much for updating the answer. This was useful to understand why we're reaching the limits on that quota but it doesn't seem to be the reason why we're dropping requests. – Jamil Seaidoun Oct 27 '18 at 03:08