Google Cloud Run突发流量峰值错误

Question

我正在使用cloud run为我的Google App Engine异步发送的请求提供服务。当我发送一个大约10个异步请求的集群时，它似乎工作得很好。当我发送一个包含50个异步请求的集群时，我开始遇到500错误“该请求已中止，因为没有可用的实例”

我的最大实例数设置为500，所以我并不担心资源是否会耗尽。看起来Cloud run无法启动足够快的容器来处理大量涌入的请求。我想为每个单独的请求启动一个新的小型容器(尽可能小的内存和cpu)。

除了让最小数量的实例始终运行，这将是令人望而却步的昂贵之外，我还有其他配置选项可以帮助Cloud Run处理突然增加的流量吗？

我已经在下面包含了我的requirements.txt，我的一个依赖项是否以导致容器长时间启动而闻名？我很难从GCP那里获得关于启动容器所需时间的清晰指标

编辑:在找到解决方案之前，我决定使用一种变通方法。虽然我牺牲了一些速度，但我能够将异步请求批处理成可管理的数量，以便云运行可以扩展。

​

aiohttp==3.7.3
async-timeout==3.0.1
asyncio==3.4.3
attrs==20.3.0
authclient==1.0
CacheControl==0.12.6
cachetools==4.2.1
certifi==2020.6.20
cffi==1.14.4
chardet==3.0.4
charset-normalizer==2.0.5
click==7.1.2
colorama==0.4.4
ConfigArgParse==1.4
cycler==0.10.0
decorator==4.4.2
dnspython==1.16.0
ecdsa==0.14.1
enum-compat==0.0.3
et-xmlfile==1.0.1
eventlet==0.30.0
firebase-admin==4.5.3
Flask==1.1.2
Flask-BasicAuth==0.2.0
Flask-Caching==1.10.1
Flask-Cors==3.0.9
Flask-SQLAlchemy==2.4.4
future==0.18.2
gevent==21.1.1
geventhttpclient==1.4.4
google-api-core==1.26.3
google-api-python-client==2.1.0
google-auth==1.28.0
google-auth-httplib2==0.1.0
google-cloud-core==1.6.0
google-cloud-firestore==2.1.0
google-cloud-storage==1.37.0
google-crc32c==1.1.2
google-resumable-media==1.2.0
googleapis-common-protos==1.53.0
greenlet==1.0.0
grpcio==1.36.1
gunicorn==20.0.4
httplib2==0.19.1
idna==2.7
intuit-oauth==1.2.3
itsdangerous==1.1.0
jdcal==1.4.1
Jinja2==2.11.2
jose==1.0.0
kiwisolver==1.3.1
MarkupSafe==1.1.1
msgpack==1.0.2
multidict==5.1.0
mysql==0.0.3
mysql-connector==2.2.9
mysql-connector-python==8.0.22
mysqlclient==2.0.3
networkx==2.5
oauthlib==3.1.0
openpyxl==2.4.4
packaging==20.9
passlib==1.7.4
Pillow==8.0.1
proto-plus==1.18.1
protobuf==3.14.0
psutil==5.8.0
pyasn1==0.4.8
pyasn1-modules==0.2.8
pycparser==2.18
pycryptodome==3.10.1
pymongo==3.11.2
PyMySQL==0.10.1
pyparsing==2.4.7
python-dateutil==2.8.1
python-dotenv==0.18.0
python-jose==2.0.2
python-quickbooks==0.8.4
pytz==2020.5
pyzmq==22.0.3
rauth==0.7.3
requests==2.25.1
requests-oauthlib==1.3.0
rsa==4.7
simplejson==3.17.2
six==1.15.0
SQLAlchemy==1.3.20
typing-extensions==3.7.4.3
uritemplate==3.0.1
urllib3==1.24.3
Werkzeug==1.0.1
yarl==1.6.3
zope.event==4.5.0
zope.interface==5.2.0

​

Answer 1

问题很可能是您发送请求的速度快于Cloud Run可以扩展的速度，并且您没有实现重试策略。

1. Your requirements.txt不太可能影响云运行冷启动时间。当您构建容器时，将处理requirements.txt。您的代码中可能存在延迟响应请求的问题，但您的问题不包括源代码。

1. 查看云运行日志。您将能够看到正常响应的请求，随后是返回错误的请求。查找容器启动消息。然后，您可以确定冷启动的时间长度。通常，您希望容器实例在实例启动后60秒内运行。

1. 在向Cloud Run发送请求时，对失败的5xx错误的请求执行重试策略。这样，当一个实例达到其请求限制(并发)而另一个实例尚未达到运行状态时，您的代码可以等待，然后重试该请求。

1. 您的500错误也可能是由于实例大小太小而导致的。日志将指明500错误是什么。在这种情况下，请减少每个实例的最大请求数(--并发)或选择更大的大小。