AWS LambdaとDjangoでRestfulAPIを作るデメリットについて

Question

閲覧いただきありがとうございます。

AWS LambdaでRestfulAPIを作るベストプラクティクスについてに質問です。

Webアプリケーションのバックエンドに使用する技術としてLambdaでサーバーレスにしようか検討しています。さらに、開発を効率化するためにDjangoの導入を考えているのですが、ネットで調べたところあまり事例がないようでした。

そこで以下のことが疑問です。

• AWS LambdaとDjangoを用いてRestfulAPIを作るのはなんらかのデメリットがあるから事例が少ないのでしょうか？

• LambdaでRestfulAPIを作成する時に一つのプロジェクトにAPIをまとめるのか、それともマイクロサービスみたいにプロジェクトを別々に分けた方が良いのでしょうか？

ご回答よろしくお願いします。

Answer 1

(1) AWS LambdaとDjangoを用いてRestfulAPIを作るのはなんらかのデメリットがあるから事例が少ないのでしょうか？

基本的に API Gateway + lambda の構成では Serverless Framework などのデプロイツールを組み合わせてプロジェクトを作成し、開発することが多いです。

URL のルーティングは API Gateway の設定パラメータで定義することになります。なので、質問者様がイメージなさるような、Webサーバーにアプリを置いてコードでルーティングを設定する、といったものとは少々イメージが異なります。

ルーティングの定義はコードではなくテンプレート (CloudFormation) の側でやってしまうことになるので、Django や Flask などの Webアプリフレームワークはここにはまらず、デプロイツールとの組み合わせによって効率化を図るのが良いでしょう...というのが答えになると思います。

※Zappa と呼ばれるデプロイツールがあり、これを使う場合ならば Django や Flask を書く要領でAPIを開発できます。よって、一応事例はゼロではないですが、私の把握する限り Zappa は主流の方法では全くないのでよほど強い動機がなければ Serverless Framework を使うのが良いと思います
※Serverless Framework の代替案としては、他に Terraform, AWS CDK などが挙げられます

(2) LambdaでRestfulAPIを作成する時に一つのプロジェクトにAPIをまとめるのか、それともマイクロサービスみたいにプロジェクトを別々に分けた方が良いのでしょうか？

Serverless Framework を使った開発であれば、1つのAPIサービス郡に対して1つのプロジェクト、という区切りが割と多いと思います。

その他

API Gateway + lambda の構成を採る場合は1つの path に対して lambda 1本、という対応関係になるよう構築するのが普通です。なので、別の回答者様が仰る「デプロイパッケージサイズ」の問題は、よほど追加パッケージを入れない限りは心配ないと思います。

RDSとの相性が悪い点も、今はかなり解消されましたが別の回答者様が仰る通りです。基本的にはDynamoDBをバックエンドとして想定することになると思いますが、それが開発工数に対してどうか、という点は検討が必要になるでしょう。

また、別の問題として「同時実行数」の制限は少々気にする必要があると思います同じリージョンの中で、同時に実行状態になれるlambda functionのインスタンス数は上限があります（東京リージョンなら1000/1minぐらいだったと思います）。リクエストのピークが高いシステムで採用されるのであれば、非同期なAPI、アーキテクチャ設計によって対処する必要が出てきます。

社内でひっそり使う程度のものであれば、同時実行数の制限は特に問題はないと思います。個人的にはそのユースケースでもサーバーレス構成はよく使うので、できれば使ってみていただきたいですし、良さを体感してほしいなとは思っています（開発環境さえあれば、Hello world的なAPIなら5分でデプロイまでできてしまいます）。
しかし、よくある Web app + RDB な構成とはちょっと勝手が違うことも事実なので、もし開発工数見合なご事情があってのご質問であれば、EC2やECSを使うのが確実かと思います。

Answer 2

これは私見ですが、単純にそれほどメリットがないからだと思います。

まず、Lambdaというサービスの特性について。
Lambdaはざっくりいうと
イベントドリブンにそれほど複雑じゃない処理を実行させる
ことが向いているサービスです。
一つのLambda関数にそんなに沢山のものを詰め込むのはあまり筋のいい方法ではありません。

AWS Lambda とは

また、Lambdaには様々な制限があります。
AWS Lambda の制限
引っかかる可能性が高いのは
呼び出しペイロードとデプロイパッケージサイズでしょう。

ペイロードは内容によるのでなんともですが、パッケージサイズについては

50 MB (zip 圧縮済み、直接アップロード)
250 MB (解凍、レイヤーを含む)

までのものしか上げられません。
ソースのサイズが膨れ上がってくるとここに引っかかる可能性はそれなりに高そうに思えます。

それであれば分割すれば、と思うかもしれませんが、せっかくフレームワークが全てまとめてくれている機能をわざわざ分割するのはフレームワークを使っている意味が薄くなってしまいます。
また、Lambdaを使ってAPIを作る場合API Gatewayが使えるので、それもわざわざフレームワークを使うことが少ない理由の一つかと思います。

それから、以前はLambdaとRDBMSの組み合わせはアンチパターンと言われていました。
なぜAWS LambdaとRDBMSの相性が悪いかを簡単に説明する
今はそうなっていた原因を解消する方法が記事中にも書いてありますが、これは結構最近の話です。
なのでこれも過去にそういった事例があまり見られなかった理由の一つでしょう。

djangoを使ったAPIを作りたいのならわざわざLambdaを使うより、普通にEC2インスタンス上に構成するか、ECSを使ってそこにコンテナとして載せるかのほうが筋がいいやり方だと思います。
Lambdaをわざわざ使うのは諸々の制限を考えるとデメリットのほうが大きいのかなと。