Cloud Functions の “no available instance” について
こんにちは、Cloud Support の Rnrn です。今日は Cloud Functions の実行時に時たま見られる The request was aborted because there was no available instance というエラーについて詳しく見ていきたいと思います。
エラーの概要
これはスケーリングに関連するエラーで、 2021 年 7 月のリリースから表示されるようになりました。ただし、最近のリリースで導入されたといっても新しいエラーのシナリオが増えたわけではありません。今まではスケーリングの問題で関数を実行できなかった場合に十分なエラーログが出力されていませんでしたが、今回のリリースでエラーがロギングに出力されるようになり、より詳しく原因がわかるようになりました。
エラーの原因
大きく分けてこのエラーには 2 種類あり、ログのステータスコードで判別ができます。 1 つはステータスコードが 429 で WARNING の場合、もう 1 つはステータスコードが 500 でERROR の場合です。どちらの場合もエラーメッセージは共通です。これからそれぞれの代表的な原因を見ていきますが、これ以外にも原因として考えられるものはいくつかあるのでぜひ公式ガイドも確認してくださいね🐤
429の場合
429のログは未処理のリクエストを処理するにあたって新しくインスタンスを起動する必要があったにも関わらず、既にインスタンス数が max_instancesの設定の上限に達してしまっていてそれ以上インスタンスを増やすことができずに失敗した時に発生します。高頻度で発生している場合は max_instances を見直してもいいかもしれません。
500の場合
500のログは関数の呼び出しに急激な増加があった場合や、Cloud Functions のリソースが一時的に不足している場合に Cloud Functions のスケールアップが間に合わずにリクエストの処理に失敗した時に発生します。これは時々発生することが想定されている一時的なものですぐに解消されることがほとんどです。
エラーの対処
429 と 500どちらの場合も主な対処としてはリトライが有効です。リトライと一口に言っても、関数の種類によって必要な手順が変わります。
HTTP トリガーベースの関数の場合は関数を呼び出しているクライアント側での指数バックオフによるリトライの実装を指しています。指数バックオフは Cloud Functions 以外でも多くの GCP プロダクトで推奨されている標準的なエラー対処法です。Cloud Functions のドキュメントではありませんが、Memorystore のページに詳しい説明が載っているので詳しく知りたい場合には確認してみてください。 と
Pub/Sub トリガーなどバックグラウンド / イベントドリブン関数の場合は実行保証があるため、自動再試行を設定しなくてもこのエラーが出た際には内部でリトライが実施されます。そのため、特別な設定は必要ありません。
もしも長い間ずっとエラーが出続けて一向に処理が成功しないことがあれば遠慮なくサポートにご連絡ください。
まとめ
以上でこのエラーについてのお話はおしまいです。突然見たことのないエラーがログに出てくるようになったので驚いてしまった方もいるかもしれません。この記事が理解の手助けになれば嬉しいです。それでは良い一日をお過ごしください🌞
