サーバーレスで色々作ってみて良かったこととハマったこと
この一年ほど、業務やプライベートでサーバーレスで色々作ってみました。
その上で良かったこと、ハマったこと、サーバーレスの使い所などを書いています。
※ほぼAWS Lambdaの話です。
何を使って作ったか
- Lambda (Java, node.js, Python)
- API Gateway
- DynamoDB
- ElastiCache (Redis)
など
どんなものを作ったか
- モバイルアプリのバックエンド
- 短時間で完了するバッチ
- WebAPIのバックエンド
- メール配信システム
- リダイレクタ
- デプロイツール
など
良かったこと
安い
常にサーバーを起動させておく必要がなく、使った分だけお金を払えばいいので、うまく使えばサーバーを立てるより圧倒的に低コストで運用が可能です。
ただし、あまりにも実行時間が多いと、サーバーを立てた方が安上がりになるケースもあり得ます。
早い
例えばLambdaだとコードを書き始めてからデプロイまでの時間が早いですし、DynamoDBだとテーブルを作成してすぐにデータを投入できます。
わざわざ実行環境を用意する必要がないので、ちょっとしたツールなどを思い立ったときにすぐに作ろうという気にさせてくれます。
「思い立ったけどめんどくさくて結局作らない」というのが劇的に減りました。
いち開発者としてはここに一番のメリットを感じています。
安心
サーバーの状態を気にしなくても良いので安心です。
「xxサーバーのCPU負荷が上がってる」とか、気にしなくていいです。
そのコードを単体で実行するのに必要な性能を見積もるだけでOKです。
また、Lambdaなどでは実行環境が独立しているので、同時実行時のリソースの奪い合いなども起こりません。
もちろんハードウェア障害などで機能が停止することも(ほぼ)ありません。
サーバーのメンテナンスも不要なので、最初に挙げた「安い」というメリットにもつながります。
ハマったこと
(AWS Lambda)Cold startが遅い
これはWebAPIやモバイルアプリのバックエンドとして使う場合結構致命的な問題でした。
色々試してみるとJavaは特に遅く、Pythonであればそこそこ速いことがわかりました。
これが問題になったときはすでにJavaで作ってしまっていたので、定期的にLambda functionを実行して温め続けるという方法で乗り切りました。
この解決方法は後述する「VPC内のリソースへのアクセスの問題」の一部を解決してくれる副作用もありました。
現在はLambda functionを作るときはPythonを使用するようにしています。
(AWS Lambda)外部リソースへのコネクション管理が大変
当たり前のことですが、データベースのコネクションなどをプールしておくことができません。
これを実現しようとすると、コネクション管理用のサーバーを立てたりする必要がありそうです。
ですので毎回コネクションを張って、使い終わったら破棄するという実装になってしまいます。
(AWS Lambda)VPC内のリソースへのアクセスする際の諸問題
去年(2015年)の2月まではそもそもLambda functionからVPC内のリソースにアクセスすることができませんでした。
VPCにアクセスする際に仮想ネットワークインターフェースが作成されるのですが、その時間が長い。しかも一定時間アクセスがないとその仮想ネットワークインターフェースは削除されるという問題があります。
この問題については過去に記事を書いたのでそちらを参照してください。
[AWS]LambdaからVPC内のリソースにアクセスした際のレイテンシーについて
また、VPCアクセスの設定をすると、今度はインターネットに出ていくためにnatインスタンスが必要となるという問題もあります。
LambdaファンクションからのVPC内リソースへのアクセス
このあたりはどんどん改善されていくものだと思います。
ランニングコストの見積もりが難しい
基本的にはランニングコストは安いのですが、使った分だけの課金になるので、ランニングコストの見積もりが難しいです。
企業などで、正確な見積もりが必要な場合はここが導入のネックになることがあるかもしれません。
サーバレスの使い所
Lambdaなどのコード実行環境は基本的に使い捨てなので、ステートフルに何かをしようとすると色々課題が出てきます。
逆に言うとステートレスな処理では多くのケースでサーバーレスを検討する価値はあると思います。
またバッチ処理などはサーバーレスと非常に相性が良いのではないかと思います。(Lambdaの場合は実行時間の制限が結構短いので、そこがネックですが)
そして前述のとおり、気軽にコードが書けて実行できるので、普段の業務を助けるちょっとしたツールやCIツールみたいなものにも向いていると思います。
私も以下のようなものを作成し、業務に役立てています。
- 指定した時間になったら開発用のサーバーインスタンスを起動/停止する
- デザイナーが指定のディレクトリにファイルをアップしたらCDNのキャッシュを削除する
最後に
改めて書いてみて、ハマったところって単純に環境に依存する部分ばかりでサーバーレス自体のデメリットって思ったより少ないんじゃないかと思いました。
実際のところサーバーレス自体がまだまだこれからのアーキテクチャなので、現状では裏側のコンテナやOS、ハードウェアの存在を完全に無視することはできない部分もありますし、正直使いにくい部分もあります。
これらが解決される頃には当たり前のアーキテクチャとして、サーバーレスという言葉自体無くなっているのかもしれません。