ブログ BLOG

Tips

最近はバックエンド処理をAPIとして提供することが多くなりました。私が以前参画していたプロジェクトでは、Spring BootでREST APIを実装し、APIの定義はOpenAPI（旧：Swagger）で行っていました。環境はAWS（Amazon Web Service）を使用していたので、AWSが提供するAPI Gatewayというサービスを使用することになりました。

Amazon API Gateway（以降、API Gateway）を使用するのは初めてだったのですが、開発を進める中で思わぬ落とし穴に嵌りました。では、いったいどのような落とし穴に嵌ったのか？を以下で紹介します。 実際にはAWSのドキュメントに明確に書かれているので、事前の調査不足ということになりますが・・・

その１：タイムアウトの落とし穴

API Gatewayには「最大統合タイムアウト」という制約があります。下の図で簡単に説明すると、API GatewayからSpring BootのAPIをリクエストし、レスポンスが返ってくるまでの時間が29秒を超えると、タイムアウトが発生します。設定可能な最大値は29秒です。

この制約には設計段階で気が付くことが出来たので、１つのAPIの処理が29秒を超えることがないように、処理が重そうな機能は複数のAPIに分割するなどして工夫しましたが、複雑なSQLを実行して一覧情報を取得する機能は１つのAPIとして残さざるを得ませんでした。心配を抱えつつAWS環境でテストしてみると、一覧情報を取得するAPIはタイムアウトを連発・・・

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

その２：サイズオーバーの落とし穴

あるユーザーでログインした場合のみエラーとなる現象が発生しました。原因を調べると、HTTPヘッダーのサイズオーバーが原因でした。APIから別のAPIを呼び出す際に、ログインユーザー情報をHTTPヘッダーにセットして渡す仕様にしていたのですが、そのユーザーのみ想定外の量の情報が登録されており、API Gatewayの「リクエスト行とヘッダー値の合計サイズ」の上限10,240バイトを超えていました。

HTTPヘッダーのサイズに上限が設定されているのはよくあることで、かつ「10,240バイト」は一般的に見ても十分なサイズと言えます。これは正直なところ落とし穴というよりも、設計時の考慮漏れが原因ですね。まぁ、こういったところも考慮に入れて設計しないとダメ、という良い教訓になりました。

最後に

最近はクラウドのサービスを最大限に利用してシステム開発することが求められるようになっています。俗にいう、クラウドネイティブですね。パブリッククラウドが提供するサービスの内容をしっかりと把握して、それを踏まえたシステム設計を行う力が求められているのだな～と感じる今日この頃です。