エンドポイントURLの末尾は「z」にしないほうがよい

はじめに

Cloud Runにデプロイしたbackendサービスに対しリクエストを送った際，突如404エラーが出て驚きました．今回はその経緯を記載しようと思います．結論，原因としては，「Cloud Runの既知の問題」に記載されている「z」に関してでした．

末尾が z のパス。予約済みのパスと競合しないように、末尾が z のパスを避けることをおすすめします。

お題

簡単なAPIを作成し，ローカルとCloud Runでデプロイしたときの挙動の違いについて確認します．それぞれエンドポイントのURLで挙動の違いを確認します．

簡単なAPIを作成

以下のように2つのエンドポイント(/healthと/healthz)を作成しました．

main.py

from fastapi import FastAPI

app = FastAPI()


@app.get("/health", description="Health check", status_code=200)
def health() -> dict:
    """Health check endpoint

    Returns:
        dict: Health status
    """
    return {"health_check": "OK"}


@app.get("/healthz", description="Health check", status_code=200)
def healthz() -> dict:
    """Health check endpoint

    Returns:
        dict: Health status
    """
    return {"health_check_with_'z'": "OK"}

ローカルで挙動確認

ローカルのDockerでバックエンドのサーバーを起動してエンドポイントにアクセスすると，問題なくどちらのエンドポイントからもレスポンスが返ってきます．

curl -X 'GET' \
  'http://0.0.0.0:8080/health' \
  -H 'accept: application/json'

{"health_check":"OK"}                                                    

curl -X 'GET' \
  'http://0.0.0.0:8080/healthz' \
  -H 'accept: application/json'

{"health_check_with_'z'":"OK"}

Cloud Runで挙動確認

Cloud Runにデプロイし，それぞれのエンドポイントにアクセスしたところ以下のようになりました．冒頭に述べたように，エンドポイントURLの末尾をzにすると，404エラーとなってしまいます．

/health → 200

/healthz → Error 404

まとめ

今回はCloud Run利用時に直面した内容を記載しました．このような仕様があることを知らなかったので備忘として残しておきます．今回の件は，オープンソースのサービスを自分たちでホスティングし，ヘルスチェックをしたときに発覚しました．偶然気づくことのできた内容ですが，今後バックエンドの実装をする際はこのことも意識しながら扱いたいです．

参考

• Cloud Runの既知の問題