僕個人としては、
という組合せは、現代に黄泉返った CGI みたいなモノだと認識しているのですが、この AWS Lambda + Amazon API Gateway 、上手く使えば Web サービスの質を向上させたり、あるいは、経費削減とかも可能になるのでないか (未検証) と思っています。
しかしながら、 AWS Lambda + Amazon API Gateway と言う組み合わせは、ひとクセもふたクセも有る代物なので、今回はその辺りも含め、ザックリと AWS Lambda + Amazon API Gateway の使い道について書いてみます。
※ ただし、僕の視点は、あくまで Web 開発者としてのモノです
1. この組合せで出来るコト・出来ないコト
基本的に、
- AWS Lambda + Amazon API Gateway という組合せ
の、出来るコト出来ないコトは、それぞれのサービスの制約の集合になります。
これは例えば、
- Amazon API Gateway は UTF-8 なレスポンスしか返せない
- AWS Lambda は、特別なコトをしなげれば、特定の言語しか動かせない
- AWS Lambda は、処理時間に制約が有る
という辺りなんですが、逆に言えば、これらの制約が問題と成らなければ、基本的に何にでも利用できます。
2. Lambda + API Gateway の使い道
今の所、
として僕が思い付いている使い方は、
- Node.js (Lambda) での Server-Side Rendering Frontend としての利用
- ランタイムを問わず、Web hook の callback 先としての利用
- 簡易フォームなどの、VM の インスタンスを立てるまでもない処理
辺りです。
それで、2 番と 3 番に関して言えば、これは CGI 代わりに使う、という感じのイメージですが、1 番についてもう少し説明と言うかアイディアの詳細を書くと、
- Lambda では Node.js v4 を Runtime とする
- API Gateway は Routing に用いる
- Lambda + API Gateway からの Backend の問合せには GraphQL 辺りを使う
という感じです。
そして、なぜ
とするのが良いのかと言うと、理由としては、AWS にインフラを集約している場合、 Node.js での Server-Side Rendering を行うためだけに VM のインタンスを用意する必要がない 、と言うのと、あとは、 GraphQL などの、API 用の Interface を間に挟む事によって、Backend 側の更新などが行いやすくなる、という辺りです。
まあ基本的には、
という辺りがメリットだ、と僕は思っています。
ただまあ、最近開発とか出来てない影響で、これについては未だに検証出来てないので、実際のサービス運営でそれが通じるかどうか、については、未知数ですが。
まあでも、基本的には Lambda + API Gateway は、あんまりコストが掛らない、という認識なので、まあ多少はなんとかなると思いますけども。
3. ただし、やり過ぎには注意
ただまあ、いくら Lambda + API Gateway がコストが抑えられて気楽に使えるから、と言っても、それですべてを完結させる CGI-like な 環境として使うのは、ちょっとどうかなーって思っています。
と言うのも、特に僕にとっては、
で完結させられるサービスを作るのは、楽だしコスト安いし、マネーを投下し続ければ無限にスケールするし、で、良い事づくめな印象なんですが、いかんせん AWS に強く依存してしまうので、インフラを乗り換えにくくなる、と考えられますし、また、AWS のインフラがなんらかの事情で止まってしまうと、そのサービスも無論死にます。
そのため、ミッションクリティカルと言うか、完全なサービス停止が要件上出来ないサービスに、この組合せを用いるのは、ちょっと止めといた方が良いんじゃないかな、と僕は思います。
ただ、そうは言っても、ちょっとした Web Application で、Heroku とかでもオーバースペックな用途だと、
と言うのは、結構良い選択肢なんじゃないかなー、と僕は思います。
と言う事で以上です
まあ、 AWS Lambda + Amazon API Gateway という組合せは、簡単な Web Application を載せたり、あるいは、 フロントエンドサーバ を コスト削減 しつつ用意する、という用途にはかなり向くのでは？と僕は感じているので、もし案件等に合えば、使ってみるのも手じゃないかなーと思います。
