Amazon API Gatewayで29秒の壁と戦う人々は何と戦ってるの？

2024年1月13日

システム開発用語

寺田明日香

お疲れ様です。IT業界ビギナーのアラフォーマーケターあすりんです（長い）。

この記事は、表題の内容がわからない方のために、同じくわからない私が頑張って理解する記事です。

APIとは？（振り返り）

Amazon API Gatewayとは？

Amazon API Gatewayのタイムアウトとは？（29秒の壁の正体）

29秒の壁（タイムアウト）と戦う＝29秒以内にレスポンスを獲得するために色々やる

29秒の壁はレスポンスの待ち時間の限界だった

APIとは？（前回の復習）

まず何はともあれAPI。前回頑張って解読しました。

　※前回の記事「めっちゃ便利らしいAPIってなんなの？」はこちら。

前回の復習を兼ねて振り返っておくと、

APIとは、依頼側のアプリケーション（クライアント）からの要求に対して、受け手のアプリケーション（サーバー）が応答を返すこと、そのやり取りの仕組みのことでした。

WEB APIとは、そのやり取りの通信規則をHTTP/HTTPSによって行うものを言います。

で、今度はAmazon API Gatewayです。どんどん新しいものが出てきます。

というのも社内エンジニア同士の会話にて、

「大量データをAPI Gatewayで29秒の壁と戦いながら実装する」

という会話が飛び出しまして。

内心「！？？？？？」でしたが表面は冷静を装いつつこうして調べている次第です。

Amazon API Gatewayとは？

端的にいうと、Amazon（アマゾン）の提供するAPI関連サービスです。

色々やってくれる便利なサービスらしいのですが…。

“Amazon API Gateway は、あらゆる規模の REST、HTTP、および WebSocket API を作成、公開、維持、モニタリング、およびセキュア化するための AWS のサービスです。 https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/welcome.html”

すごい、また全然わからないです。

ひとまず、APIを作成できる便利なサービス、ってことでOKでしょうか。

一応、AWSのサイトに以下の説明がありますので載せておきます。

“API Gateway は、次のような RESTful API を作成します。
・HTTP ベース。
・ステートレスなクライアント/サーバー通信を有効にします。
・GET、POST、PUT、PATCH、DELETE などの標準の HTTP メソッドを実装します。”
https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/welcome.html

ふぅううん？？（全然わかってない顔）

今度は未修得のRESTful APIという単語が出てきましたが、もうわからない単語に慌てることはなくなった手だれのビギナーである私は、落ち着いてこれは何となく現代的なAPIであるということでとりあえず理解しておきます。（そのうち調べるリストに入れました）

問題はこれがこの後なぜ29秒の壁と戦う展開になるのかということです。

29秒を超えると何が起こってしまうのでしょうか。

エンジニアの皆様は一体何と戦っているんでしょうか。

順に調べていきましょう。

Amazon API Gatewayのタイムアウトとは？（29秒の壁の正体）

前回の学びにより、私たちはAPIがリクエストとレスポンスという応答のセットであることを知ったわけですが、今回のAmazon API Gatewayというサービスを利用する場合、その応答はいつまでも待ってくれるわけではなく、時間制限がある、ようです。

こちらのサイトで、タイムアウトに関する内容がまとめられていたので参照してみます。
参照元のサイトにわかりやすく図解されていましたのでぜひご覧ください。

“API Gatewayには
「最大統合タイムアウト」
という制約があります。
下の図で簡単に説明すると、API GatewayからSpring BootのAPIをリクエストし、レスポンスが返ってくるまでの時間が29秒を超えると、タイムアウトが発生します。
設定可能な最大値は29秒です。"
https://www.sun-m.co.jp/blog/cloud/440.html”
【徹底解説】Amazon API Gatewayの落とし穴！使用時の注意点とは？

なるほど、ざっくりの理解は合ってました。

29秒の壁（タイムアウト）と戦う＝29秒以内にレスポンスを獲得するために色々やる

エンジニアが戦うのは、ここ「29秒以内にどうやってレスポンスを獲得するか」という部分のようです。

つまり普通に考えると、29秒以内にレスポンスをもらうのは結構大変だ、ということですね。

同じサイトに以下の説明がありました。

“処理時間を29秒以内に収めるべく、DBやSQLのチューニングを行うことになりました。
既存システムの改修ということもあり、DBのテーブル構成は変えられないという制約もありましたが、SQLの実行計画と睨めっこをしながらトライアンドエラーを繰り返し、何とかタイムアウトが発生しないようにすることができました。https://www.sun-m.co.jp/blog/cloud/440.html”

おお、とても戦いっぽい。29秒に収めるためには、戦略が必要なようです。

戦い方は他にもあって、「一旦リクエスト受け取ったよ〜」という仮レスポンスを送る、みたいな方法もあるようです。

こちらのサイトに詳しく図解がありましたのでご参考に。

“やり方はいくつかあるみたいですが、今回は「Lambda発火API」と「Lambda状態取得API」の二つのAPIを用意することで解決します。https://qiita.com/haruki-lo-shelon/items/9e5781668b0c92e955be”

この方の言っていることは3割くらいしかわからないですが、とりあえず返事を送るAPIと、処理を終えてから改めて返事を送るAPIの二種類を用意して、最初のAPIで29秒以内に返事を送っておき、後から改めてお伺いを立てにいく、という感じになっていることはわかりました。

なるほど、これなら返事はサポートが一旦対応してくれるので、技術班はじっくり対応できます。

29秒の壁はレスポンスの待ち時間の限界だった

というわけでAmazon API Gatewayとの戦いは、レスポンスをいかに29秒以内に獲得するかという戦いであり、そのために色々な創意工夫を行なっていく、戦略的な戦いでもあり、体力を削ってプログラミングを修正していく肉弾戦でもある、という感じで理解しました！

ちなみになんで29秒という限界を設定する必要があるんだろう？というのも新たな疑問として湧いてきましたが、これはまた別の機会に調べてみたいと思います。
多分、サーバーの負荷とか、そういうことなんだと思います（だいぶ曖昧）。

とりあえず、今回出てきたRESTful APIについて次回は触れていきたい。
あとAmazon API Gatewayの関連で、Lambda（ラムダ）については調べたいなと思いました。
だってステートレスとかサーバーレスとか言われてもなんやねんってなるもんな。
そもそもレス以前の状態を知らんねんと。
そっから教えろやということで次回やっていきたいと思います。

補足

弊社の代表から補足で以下のレスポンスをいただきました。
めちゃくちゃわかりやすかったので初心者たちはみんなみて。

“ちなみにAPI Gatewayって「APIを作成できる」というのはちょっと違って、
API Gatewayはゲートウェイという言葉通り、「中継」するという機能がメインで、
クライアント（パソコンとかブラウザとか）からのリクエスト（通信）をその裏側にあるAPIサービスに送るときの関所みたいな感じです。

API Gatewayを間にかますことで、
・特定のAPI Keyがリクエストヘッダーになかったらエラーにする
・Authorizationの値をCognitoに送って認証をする
・特定のIPアドレス以外は制限する
などなど、独自にアプリケーション側でやると面倒なことをより簡単にセキュアにしてくれる感じです。”
たいしょうのリプより引用

なるほど！！！！！！関所だったんか！！！！！

私が百の言葉を費やすよりもわかりやすかったですね。
さすが百戦錬磨のエンジニアの説明は説得力が違います…この記事がより完璧になってしまったな…ありがとうございます！