以前からserverlessと呼ばれる領域の技術に興味があったのですが、チュートリアル止まりで、インプットを増やしたいな〜と思っていたので、勉強会に参加してみました。
どんな話があったのか?
発表者は3人で、サーバレス領域の技術(今回の勉強会では殆どがLambdaの話だった)を使って、サービス開発を行い、具体的な利用例やハマったところを共有してくれました。
ざっと概要をまとめると、
- 今まで手動でやっていた作業を、社内RPA(Robotics process automation)として自動化。Lambda上にヘッドレスブラウザを置き、定期実行するような仕組みを作った。
- CI/CD環境を、cloud buildやcloud formationを使い、Lambdaと連携して、自動デプロイする環境を構築した。
- CloudWatch eventでLambdaを定期実行。また、複数のLambdaを連携して複雑なバッチ処理機構を作った。
- インフラ構成を考える手間はあるが、その手間が一旦決まれば、エンジニアはビジネスロジックの開発に集中できるので、開発スピードを上げて開発に取り組めた話。
- たくさん動かしてもそこまでお金はかからなかった話(唯一お金がかかったのは諸事情で出口IPの固定に必要だったNAT Gatewayくらい)。
- フロントをReactにしてバックエンドをLambda上のGraphQLを叩くようにするナウい構成のサービスを作った。
- gitlab serverlessというサービスの紹介。
こんな感じ。どれも面白い内容で、その中でも気になったキーワードをピックアップして感想を書いていこうと思います。
LambdaLayerでデプロイ容量制限問題を回避
自分はLambdaにexpressサーバを置いて立ち上げるくらいしかやったことがなかったので全然知らなかったのですが、Lambdaは一度にデプロイできる容量に制限があり、Max50MBまでとなっているそうです。今回の話では、Lambdaにヘッドレスブラウザを入れるとそれだけで40MBも容量が必要で、デプロイ時に容量制限を超えてしまう可能性があったそうです。
しかし、LambdaLayerを利用すると、ヘッドレスブラウザなどのライブラリをLayerと呼ばれるところで管理することになるので、いままで50MBまででzipで固めてデプロイしていた制限が実質無くなるとのこと。さまざまなライブラリを利用できるので、Lambdaのできることの幅も広がるのは、非常に有益な機能だな〜という印象でした。 まだLambda上で制限より大きなApplicationを動かした経験がないのですが、これらを知れたのは得した気分でした。
AWS Step Functionで複数Lambdaを連携して複雑なバッチ処理も実現
今回の勉強会で一番面白かった内容が、AWS Step Functionの話でした。
CloudWatch eventでLambdaを定期実行し、とあるインプット情報を加工して別サーバに保存するようなETL(Extracting Transform Load)の仕組みを作った実例を交えて話をしてくれました。
ETLの機構で複雑なバッチ処理をLambda上で行いたかったのですが、Lambdaはあまり長い処理を行うのには向いてなく、設定でtimeoutの制限があり、複雑で長い処理をさばくには辛いところがありました。
ただ、AWS Step Functionを利用すれば、複数のLambdaを分割して連携し、プログラムで関数から別の関数を呼び出すような仕組みを実現できます。これを使えば複雑な処理をLambda単位で責務分割ができて、処理の流れがわかりやすくなるし、各Lambdaの保守・運用も責務を分割しているのでやりやすいとのこと。また、Step FunctionはLambda実行の遷移自体に課金が行われて、Lambdaの処理時間は課金範囲ではないので、結果的に課金を抑えることにも繋がるそうです。
これを聞いたとき、Lambda同士の連携すれば、いろいろなことが出来そうだな〜と聞いてるだけで面白かったし、しかも工夫次第でコストを抑えられる感じがあったのも良かったです(ちなみに、最近出たサービスなのかな?と思ったのですが、re:Invent 2016で発表されたものらしく、いままで知らなかったことを悔やみました)。
ref: AWS Step Functions で作る Serverless バッチシステム - Qiita
その他
- 新規サービスを早くローンチしたいんだけど、インフラ面の構成を早く作りたいので、サーバレスを採用した苦労話
- サーバー管理から解放
- Lambdaを複数立てるとDBに接続する数が増えて、オーバーフローするので、そのへんを耐えられるdynamo dbにするのが一般的だったけど、最近はRDS proxyを使えばコネクションプールを使って、接続数を抑える方法もある
- コールドスタート問題。この問題もあり、高トラフィックなサービスでは、Lambdaが応答に間に合わないことがあるので向いてないかも。
- サーバーレス構成は形で考えるサーバレス設計を最初に勉強するといい。
- ビジネスロジックに注力できるとはいえ、サーバーレス構成をちゃんと考えないといけないので、サーバレスデザインパターンを理解することは重要。
- Lambda上でエラーが起きたときに基本的には管理画面のログからしか見れない。場合によってはデバックが面倒。
- Lambdaのメモリは小さくしすぎると、面倒なので注意(ちょっと理由は聞き逃した...)。
- serverless界隈のランドスケープを見ると、なんか楽しい。
- Gitlab serverlessが日々開発されてる。
めちゃくちゃ有意義な時間だったし、インプットが捗って色んな場面で活かしたい欲を駆り立てられました。まずはLambda上でサーバーレスブラウザをおいてなんかできそうなので、土日に遊んでみます。 何か業務に活かせないかな〜。頑張って考えてみようっと。。。
楽しい勉強会でした ☺️