2020年1月からジョインした新人の木村と申します。家では2歳半の娘に「ずー」と呼ばれています(由来不明)。
前職ではperlやPHP、pythonなどのスクリプト系言語での開発、オンプレミスやAWSでの運用をしていました。
全力で頑張っていきますのでよろしくお願いします！
イベント参加
さて、ジョインして初めてのイベント参加として、1/9に (株)Fusicで開催された「AWS re:Invent Recap with Serverless in Fusic」に参加してきましたのでそのレポートをお送りします。
AWS re:Inventとは
AWS re:Inventは、毎年年末にラスベガスで開催されるAWS(Amazon Web Services)の一大イベントです。ここで多くの新サービスのリリースや既存サービスのアップデートが発表されます。
昨年末のre:Invent 2019、とにかく圧倒的な数のアップデートがありました。イベント期間中の発表対象から漏れたものについてはイベント開始2週間前から発表され、最終的にイベント終了までに合計178件ものアップデートにもなりました。
さすがにこの数ですと、概要だけであってもとても2時間程度のre:Capイベントで全てを確認するのは困難です。今回は特にサーバレスの分野に絞っての振り返りとなりました。
このレポートでは、さらにAWS Lambda関連のアップデートに焦点を絞ってレポートしたいと思います。
AWS Serverless Services update
今回のイベントでは、AWS下川さんが「AWS Serverless Services update」というタイトルで、re:Invent 2019で発表された物を含め最近発表されたサーバレスに関するアップデートについて紹介されました。
紹介されたアップデートの中でも特にAWS Lambdaと関連するものは以下の3つです。
- RDS Proxy
- Provisioned Concurrency for Lambda Functions
- VPCに接続する実行環境のコールドスタートの速度の改善
以下、簡単にそれぞれについて触れてみたいと思います。
RDS Proxy
Lambda関数は、イベントなどの起動トリガーに応じて同時起動数の上限(標準では1000)までスケールし、並列に実行されます。そのため、Lambda関数からRDSなどのリレーショナルデータベースサービス(RDBMS)に接続しようとすると、RDBMS側の同時接続数が枯渇してしまいます。
RDBMSの同時接続数には上限があり、これを増やすためにはCPUやメモリを多く割り当てる必要があります。また、同時接続数の範囲であっても、接続や切断はRDBMSにとってそれなりにCPUやメモリを使う処理なので、短時間に大量の接続と切断が繰り返されるのは大きな負荷となります。
いつLambdaがスケールするか分からない(そして、それがごく短期間かもしれない)状態でRDBMSに大きなリソースを割り振るのは無駄が多いです。これが、所謂「LambdaとRDBMSは相性が悪い」と呼ばれる問題点です。
これに対して、これまでは
- LambdaからはRDBMSを使わず、DynamoDBなどのスケールするバックエンドを使う
- Lambdaの同時並行数を、RDBMSの同時接続数より少なくなるように制限する
といった対応が必要でした。
今回発表されたRDS Proxyは、マネージドなRDBMSコネクションプール機能になります。RDBMSへの接続をRDS Proxyがプールしてくれることにより、RDBMS側の負荷が軽減されます。RDS Proxyを利用することで、RDBMS側の負荷やリソースの枯渇を気にせずにLambdaからRDBMSに接続できるようになります。
同時接続数の問題については、最大値に達したときにRDS Proxy側でクライアントの接続を待たせるような処理があるようですが(ドキュメントでは「接続プールからアプリケーション接続にすぐに対応できない場合、これらの接続を順序付けたり調整したりします」とある)、そうするとLambdaの実行時間が接続待ちで長くなり、今度はLambdaの同時並列数にも影響が出てくるのではないか、という点が現在気になっています。
また、接続に関する処理の負荷をRDBMSからオフロードする以外にも、RDBMSを複数のサーバでレプリケーション構成で運用していて、問題が発生してフェイルオーバーする際にクライアント側に再接続や処理の再実行をする機能を持たせないでもRDS Proxy内でうまく処理してくれないか、と期待しています。
この2つの動作については、是非実際に検証してみたいと思います。
RDS Proxyは現在プレビューですので、検証した結果をフィードバックすることでより使いやすくなることに期待したいです。
Provisioned Concurrency for Lambda Functions
Lambda関数は、起動時に実行環境の初期化が行われ、それから実行されます。全く何もない状態からの起動は「コールドスタート」と呼ばれ、それなりに(場合によっては数十秒程度)時間がかかります。
前回の実行から一定期間内に再度起動する際は、前回作られた実行環境が使い回されるため、短時間で処理が開始されます。これを「ウォームスタート」と呼びます。
Provisioned Concurrency for Lambda Functionsは、事前に指定した同時実行数分だけLambda実行環境をプールしておくことで、その数までは常にウォームスタートになるという機能です。
これにより、例えばスパイクするサービスでコールドスタンバイでの起動時間が問題になるといったケースが解決できます。
これまでは定期的な自動実行で適度な負荷をかけてウォームスタートになるようにする、といった対応をすることがありましたが、それが不要になります。
VPCに接続する実行環境のコールドスタートの速度の改善
先述のRDS ProxyをLambdaから利用する場合は、LambdaをRDS Proxyの属しているVPCに接続する必要があります。RDS Proxyを使わないで直接RDBMSに接続するとしても、接続先のRDBMSはVPCの中に配置することが多いかと思いますのでやはりLambdaをそのVPCに接続する必要があります。
これまではLambda実行環境をVPCに接続するように設定した場合、コールドスタートする際に、VPC内にENI(Elastic Network Interface：仮想的なネットワークインターフェース)を作成してクロスアカウント接続を行う処理に非常に時間がかかっていました。
今回、これが大幅に改善されました。それによって、RDS Proxyを安心して使うことができます。
また、このコールドスタートに時間がかかることから、これまではLambdaでVPCを使う構成は敬遠されていたのですが、今後はむしろベストプラクティスになるのではないでしょうか。
Lambdaから各種リソースに安全に接続できるのももちろんですが、他にも例えば、外部のAPIにアクセスするLambda関数のアクセス元IPアドレスを限定したいのでNAT Gatewayを用いる、というような場合にも適用できますね。
このアップデートは2019年9月に発表されていたのですが、それがre:Invent 2019のRDS Proxyの話にも繋がって、成程！と思いました。
感想
この3つのアップデートにより、LambdaはRDBMSとの相性問題を解決し、スパイクアクセスにも対応し、よりパフォーマンス・利便性・サービス安定性・セキュリティなどの実用性が高まりました。
AWS Lambdaは最初の発表から5年経って事例も増えてきており、そこからのフィードバックを受けてサービスとして円熟の域に達しつつあるという印象を強く受けました。ますます目が離せないので今後も注目していきたいと思います。
