サーバレスアンチパターンが無くなった日

# Amazon RDS ProxyがGAに！
[Amazon RDS Proxy](https://aws.amazon.com/jp/rds/proxy/)がGAされたことで、[@Keisuke69](https://twitter.com/Keisuke69) さんのツイートの最後のパーツが揃ったので、名実共に今年がサーバレス元年に。
これまでサーバレスアンチパターンと言われていた構成でも使えるようになり、サーバレスアンチパターンがほぼ無くなりました。

今月になってサーバレス関連のイベントや、Webinarが増えていて、いくつか参加して聴いた内容をまとめておこうと思います。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">今年がサーバーレス元年な理由. それはLambdaに以下が揃ったから. <br><br>・カスタムランタイムで実質どんな言語でも利用可能<br>・VPC利用時のコールドスタート改善<br>・Provisioned Concurrencyでスパイク対応も可能<br>・RDS ProxyでRDBとの接続が現実的に<br><br>これまで5年で受けたフィードバックがついに結実. 強い</p>&mdash; Keisuke Nishitani (@Keisuke69) <a href="https://twitter.com/Keisuke69/status/1219030038005178368?ref_src=twsrc%5Etfw">January 19, 2020</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

# lambda × RDS
lambdaはイベントやリクエストのたびにコンテナが起動され、そのタイミングでDBへのコネクションが張られるため、同時に処理すべきリクエスト数分のコネクションが張られることになります。RDBMSは同時接続数に限界があるため、DBへの都度接続のオーバーヘッドを回避したいのですが、コンテナ間でコネクションプールを共有することは難しいため、スケールアップが前提のRDSにおいて、lambdaとRDSの組み合わせはアンチパターンと言われてきました。なので、lambdaはこれまで分散型データベースであるDynamoDBと組み合わせて使うことが前提になっていました。[こちら](https://www.keisuke69.net/entry/2017/06/21/121501)から要約させてもらったので、詳しい内容は見てみてください。

# RDS Proxy登場
RDS Proxyが登場したことで、lambdaとRDSのコネクションプールの役目をRDS Proxyが担うことができるようになり、コネクションを有効活用してLambdaからRDSにアクセスできるようになりました。ただ、RDS Proxyを使う場合にはコストが余計にかかることと、RDSがスケールアップが前提というのは変わらないので、RDS Proxy側でRDS側の最大接続数に対してコネクションを許可する割合を設定したりしながら、RDSのCPUやメモリなどのリソースが逼迫しないようにチューニングする必要性はありそうです。

# lambda × EFSと新しいアンチパターン
lambdaからEFSをマウントできるようになったことで、lambda間でデータを保存、共有できるようになったのですが、その結果　lambdaでステートフルなアプリケーションを作ってしまう可能性が高まりそうです。これまでのサーバレスアンチパターンは解消されましたが、新しいアンチパターンが生まれることもありそうです。全てを無理にlambdaでやろうとすることが最大のアンチパターンという話もありました。

# それでも制限や制約もある
lambdaは水平方向のスケーラビリティは確保されているものの、スパイクなどの急激なリクエスト数の変化や、リクエスト数が少なくてもUXのために遅延を回避したい場合、またはlambdaバースト制限の緩和に対しては、Provisioned Concurrencyを活用してチューニングする必要がありそうです。また、lambdaの実行時間15分を超えるような処理の場合は、Fargateの活用も考えるべきでしょう。

Provisioned Concurrencyのチューニングについては、[ServerlessJP](https://twitter.com/serverlessjp)でのAWS下川さんのスライドを参考にさせてもらいました。

[![thumbnail](https://files.speakerdeck.com/presentations/5eb45ff4ea8b4db79162a9e8a65e5bcd/preview_slide_0.jpg)](https://speakerdeck.com/_kensh/aws-lambda-provisioned-concurrency-dive-deep-and-practice)

# モノリスだっていいところもある
これだけサーバレスのアンチパターンが無くなると、モノリスは無くなっていく（無くしていきたい）と思ったりしたのですが、[@tcsh](https://twitter.com/tcsh)さんのツイートを読んでなるほどと。安定を求めるか変化を求めるか。やっぱりサーバレスを考える上では、ビジネスや文化や組織論的な話につながっていくんでしょうね。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">変化しない環境で固定的な業務ならモノリス(密結合)の方が低遅延、高効率、安定動作なのは間違いない。<br><br>環境や使い方が変化しやすい時代だからマイクロサービスで疎結合にする。<br>高遅延、低効率、不安定動作を呑み込むメリットがある場合ならば、という前提で。(単一障害点の原則が重視される理由 <a href="https://t.co/gp0zgzlCyp">https://t.co/gp0zgzlCyp</a></p>&mdash; HATANO Hirokazu (@tcsh) <a href="https://twitter.com/tcsh/status/1280684397511847936?ref_src=twsrc%5Etfw">July 8, 2020</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

# モノリスからサーバレスへ
なんでもサーバレスはアンチパターンとはいえ、適切な手順を経てサーバレスに移行することで得られるビジネス上の価値も大きいとは思います。AWS Expert Onlineの下川さんのセッションに、ベストプラクティスがギュッと詰まってました。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">JAWS-UG でサーバーレス でのAPI管理の考え方について話しました。<br><br>モノリスだったアプリをサーバーレス にしていく中で課題が出てきます。課題→解決、課題→解決という流れで進んでいきます！<br><br>スライドはこちら<a href="https://t.co/1z3nJKFumn">https://t.co/1z3nJKFumn</a><br><br>YouTubeも一般公開にしています。<a href="https://t.co/B9mlsJCPFC">https://t.co/B9mlsJCPFC</a></p>&mdash; kensh (@_kensh) <a href="https://twitter.com/_kensh/status/1281138329354788864?ref_src=twsrc%5Etfw">July 9, 2020</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>