【図解】AWS API Gatewayとは。デプロイまで公開されない4階層まとめ

Lambdaで関数は作れた。なのにブラウザから呼べるURLが無い。 この記事はAWS勉強シリーズの15本目で、関数を「世界中から呼べるURL」に変えるAPI Gatewayを扱います。読み終わると、初心者が踏む2つの症状を自分で切り分けられます。1つ目は「デプロイしようとしたら The REST API doesn't contain any methods と言われて止まる」。2つ目は「設定を変えたのに、URLを叩くと古い動きのまま」。どちらも今日、モックAWSでわざと踏んで、止まる場所を確かめました。

対象読者は、AWSをこれから学ぶ人と、シリーズを1本目から読んでいる人です。アカウントが無くても大丈夫で、コードは全部手元のPythonだけで動きます。

[toc]

API Gatewayとは何か

API Gatewayは、レストランの注文カウンターです。

前回までに作ったLambdaは「厨房のコックさん」でした。料理(処理)はできるけれど、お客さん(利用者)を厨房に直接入れるわけにはいきません。誰でも入れたら冷蔵庫を漁られます。そこで店の入口に注文カウンターを置き、メニューに載っている注文だけを受けて、厨房に通す。この係がAPI Gatewayです。

AWSの言葉で言い直すと、「インターネットからのHTTPリクエストを受け取り、決められたルールに合うものだけをLambdaなどの中身に渡し、結果を返す玄関」です。玄関なので、URLの発行、注文の選別、混みすぎたときの入場制限までここが受け持ちます。

何に使うか

一番よくある使い方は、Lambda関数に公開URLを付けることです。

• スマホアプリのバックエンド。「GET /users なら一覧、POST /users なら登録」のようにURLと処理を対応させる
• Webサイトの問い合わせフォームの送信先
• 外部サービスからのWebhook(通知)の受け口

シリーズ5本目のLambda回で、関数を作って手元から invoke で呼びました。あれはAWSの内側からの呼び出しです。外の世界、つまりブラウザやスマホから呼ぶには、玄関が要ります。その玄関がAPI Gatewayです。

既出サービスとの違い

シリーズで似た顔ぶれが増えてきたので、位置関係を整理します。

Route 53は場所調べ、CloudFrontは配達で、どちらも処理はしません。処理への入口はAPI Gatewayが初めてです。

今AWSの地図のどこにいるか

全20本の地図で言うと、部品編12本が終わり、公開編の3本目です。Route 53で名前を持ち、CloudFrontで配る仕組みを持ちました。今回のAPI Gatewayで「処理を受け付ける玄関」が付きます。公開編の残りはECSで、その先に運用編が控えています。

今はこれだけ分かればOK

覚える言葉を3つに絞ります。

1. リソース … URLのパスのこと。/hello や /users という「棚」を作る
2. メソッド … 棚ごとの受付方法。GET(見る)、POST(送る)など
3. デプロイ … 作った設定を世に出す操作。これをするまで1文字も公開されない

逆に、統合タイプの種類(MOCK、AWS_PROXYなど)、オーソライザー、使用量プランは後回しでいい。最初の1本を通すのに要るのは上の3つだけです。

仕組みの要点

API Gatewayの中身は4階層の組み立てラインです。

1. リソース: パス /hello を作る
2. メソッド: そのパスにGETを生やす
3. 統合: メソッドの先をLambdaなどに配線する
4. デプロイ: ステージ(prod や dev)という名前を付けて公開する

できあがるURLは次の形です。

https://API番号.execute-api.ap-northeast-1.amazonaws.com/prod/hello
                                                        ~~~~ ~~~~~
                                                        ステージ  リソース

1〜3をいくら作り込んでも、4のデプロイをするまで外からは何も見えません。Lambdaは作った瞬間から invoke できましたが、API Gatewayにその感覚を持ち込むと404を探し回ることになります。

使い方(最小コード)

いつも通り、実際のAWSではなくmoto(AWSのそっくりさん)で動かします。お金は一切かかりません。

pip install boto3 moto

作る→公開する→確かめる、の最小コードです。

import boto3
from moto import mock_aws

@mock_aws
def main():
    apigw = boto3.client("apigateway", region_name="ap-northeast-1")

    # 1. API本体を作る
    api = apigw.create_rest_api(name="hello-api")
    api_id = api["id"]

    # ルート(/)のIDを調べる(pathが"/"のものを探す)
    items = apigw.get_resources(restApiId=api_id)["items"]
    root_id = [r for r in items if r["path"] == "/"][0]["id"]

    # 2. リソース /hello を作る
    res = apigw.create_resource(restApiId=api_id, parentId=root_id, pathPart="hello")

    # 3. GETメソッドを生やす
    apigw.put_method(restApiId=api_id, resourceId=res["id"],
                     httpMethod="GET", authorizationType="NONE")
    apigw.put_method_response(restApiId=api_id, resourceId=res["id"],
                              httpMethod="GET", statusCode="200")

    # 4. 統合を張る(今回は固定応答のMOCK)
    apigw.put_integration(restApiId=api_id, resourceId=res["id"], httpMethod="GET",
                          type="MOCK",
                          requestTemplates={"application/json": '{"statusCode": 200}'})
    apigw.put_integration_response(restApiId=api_id, resourceId=res["id"],
                                   httpMethod="GET", statusCode="200",
                                   responseTemplates={"application/json": '{"message": "hello"}'})

    # 5. デプロイ(ここで初めて世に出る)
    apigw.create_deployment(restApiId=api_id, stageName="prod")
    print(f"呼び出しURL: https://{api_id}.execute-api.ap-northeast-1.amazonaws.com/prod/hello")

main()

実行結果です。

呼び出しURL: https://rsgosywmky.execute-api.ap-northeast-1.amazonaws.com/prod/hello

rsgosywmky の部分はAPIを作るたびに変わるランダムなIDです。これはmotoが発行した偽物のIDなので、このURL自体をブラウザに貼っても繋がりません。実際のAWSで同じコードを流すと、本物のIDで同じ形のURLが発行され、貼ると {"message": "hello"} が返ります。

今あなたが作ったもの

いま手元にあるのはこれだけです。

• hello-api(API本体)
• GET /hello(メソッド1本)
• MOCK統合(固定の返事を返す配線)
• prodステージ(公開中)

今回は配線先をMOCK(固定応答)にしましたが、ここを type="AWS_PROXY" にしてLambdaのARNを渡すと、5本目で作った関数がそのまま応答を返すようになります。

1か所だけ変えてみる

ステージ名を変えて、もう1つ公開してみます。

apigw.create_deployment(restApiId=api_id, stageName="dev")

これだけで .../dev/hello というURLが増えます。本番は prod、実験は dev と分けておくと、devで壊してもprodには影響しません。

実際に叩くと止まるところ

ここからが本編です。実験スクリプトには「エラー1」から「エラー6」まで見出しを6つ用意して、順に踏んでいきました。先に白状すると、6つのうち2つ(エラー3とエラー4)は止まりませんでした。エラーになるはずの操作が成功で返ってきて、見出しだけが「エラー」のまま残った。この2つは節の最後に回します。あとエラー6(削除済みAPIをもう一度見る)はエラー2と同じ文言が返っただけなので割愛して、載せるのは止まった3つと止まらなかった2つです。

エラー1: メソッドが1つも無いままデプロイ

店を作った直後、メニューを置く前に開店しようとすると止まります。

ClientError: BadRequestException
  The REST API doesn't contain any methods

create_rest_api で返ってくるのはAPIのIDだけで、この時点では中身が空です。メソッドを1個作ってから同じ create_deployment を投げ直したら通りました。

エラー2: 存在しないAPI IDを見る

ClientError: NotFoundException
  Invalid Rest API Id specified

素直なエラーです。IDのタイプミスでもこれが出ます。1つ補足すると、この文言はmotoのもので、実際のAWSは「Invalid API identifier specified 123456789012:abc123xyz」のようにアカウントIDが付いた形式で返してきます。

エラー5: ステージが残ったままデプロイ本体を消す

ClientError: BadRequestException
  Active stages pointing to this deployment must be moved or deleted

「このデプロイを指しているステージが残っている」と怒られます。消す順番はステージ→デプロイ→API本体。逆順で投げたら上のエラーで止まり、順番を守ったら全部消えました。

削除完了: ステージ→デプロイ→API本体の順で成功

止まらなかったエラー3とエラー4(motoの再現漏れ)

エラー3とエラー4は成功が返ってきました。moto(手元は5.2.3)では通るのに、実際のAWSでは止まる操作です。

エラー3に置いたのは、同じパス /hello の二重作成。motoでは201(成功)が返りましたが、実際のAWSでは同じ親に同じpathPartは作れず、ConflictExceptionで止まります。

エラー4に置いたのは、統合を張っていないメソッドを含むデプロイ。こちらもmotoでは通りましたが、実際のAWSは「No integration defined for method」で止めてきます。

エラー3で201が返ってきた時点でスクリプトのミスを疑い、motoのソース(apigateway/models.py の create_resource)を開きました。パス文字列の形式チェックだけで重複チェックは無く、そのまま子リソースを追加していました。スクリプトではなくmoto側の仕様です。この2つが実AWSで止まる方は、ドキュメントと過去のエラー報告で確認しただけで、私自身はまだ本番で踏んでいません。踏んだら追記します。

似たサービスとの使い分け

「Lambdaに公開URLを付ける」だけなら、実は他にも道があります。

Lambda Function URLは2022年に登場した軽量な選択肢で、関数の設定画面から1クリックでURLが出ます。メニューが1品で認証も要らないならこれで足ります。品数が増えて「GETは見るだけ、POSTは登録、DELETEは管理者だけ」のような選別が要る段階になったら、API Gatewayに乗り換える。シリーズ20本目で組む予定の写真アプリはパスが複数になるので、私はAPI Gatewayを使うつもりです。

料金の考え方

リクエスト数の従量課金です。作っただけなら0円。REST APIは100万リクエストあたり数ドル台(東京リージョン)、HTTP APIならその3分の1程度で、練習アプリなら月に数円も行きません。

1つだけ。公開URLは世界中から叩けます。誰かに大量に叩かれたらその分は課金されるので、使い終わったAPIは消してください。削除の順番は上で実測した通りです。

よくある注意点

一番踏まれているのは「設定を変えたのに反映されない」です。

原因はデプロイのやり忘れです。API Gatewayの設定変更は、リソースを足してもメソッドを変えても、再デプロイするまでステージには反映されません。編集画面では新しくなっているのにURLを叩くと古いまま、という状態が起きます。対処は、変えたら create_deployment をもう1回。それだけ。

もう1つは、404が出たときにURLのステージ名を疑うことです。.../hello と打って404でも、正しくは .../prod/hello かもしれません。URLの形(ステージ名がパスの先頭に入る)を思い出してください。

まとめ

「The REST API doesn't contain any methods」は、メソッドを1つも作らずデプロイしたときのエラーでした。リソースとメソッドを先に作れば通ります。「変えたのに古いまま」は再デプロイ忘れ。API Gatewayは4階層目のデプロイをするまで、何をどう変えても世に出ません。

消す順番はステージ→デプロイ→本体。作る順番の逆です。motoで通った操作が本番でも通る保証は無い。再現漏れ2つ(パスの二重作成と統合なしデプロイ)がその実例です。

次回はECSです。Lambda1個で捌けない規模の話をします。

参考

• Amazon API Gateway とは - AWS公式
• API Gateway の料金 - AWS公式
• Lambda Function URL - AWS公式
• moto - GitHub