[AWS Summit2017]サーバレスアプリのアンチパターンとチューニングメモ

AWS Summit2017で聞いてきたサーバレスアプリのアンチパターンとチューニングのメモです。
Lambdaの仕組みの中まで知らなかったのと、気をつけるべきところが多くあったので、とても参考にさせていただいております。
プラスで自分が他に参考にしたサイトもリンクさせていただきます。

アプリが遅くなる原因

① プログラムの問題

ロジックそのものの問題は、各言語のベストプラクティス、最適化手法はそのまま当てはめるべき
Node.jsで自分は書くことが多いので、下記を参考にしている

• Node.jsベストプラクティス

② コンピューティングリソース不足

メモリ設定は最適にすること
メモリサイズと比例してCPU処理能力も割り当てられる
コストを気にしがちだが、メモリを増やせば処理時間は早くなるので、結果的にコストはそこまで変わらないときもある
※ ちょっとずつ変更して性能が変わらないところが最適値

• Lambdaメモリによる性能のちがい

③ コールドスタート

Lambdaファンクションの実行時におきていること

1. ENIの作成（10秒から30秒かかる、Durationには含まれない）
2. コンテナの作成
3. デプロイパッケージのロード
4. デプロイパッケージの展開（S3からDLやZipのファイル展開、Durationには含まれない）
5. ランタイム起動・初期化（グローバルスコープの処理もこのタイミング）
6. 関数/メソッドの実行（ハンドラーで指定した関数・メソッド、Duration値はここの実行時間）
   全てを実行するのがコールドスタートという
   1-5は毎回同じ内容が実行される（再利用することで効率化できる）

コールドスタートが起こる条件

• コンテナが1つもない
• 利用可能な数以上の同時リクエスト
• コードや設定変更

早くするためにはどうしたらよいか？
コンピューティングリソースを増やす（メモリを増やす）
ランタイムを変える（各言語の仕様にもよる・・）
パッケージサイズを小さくする（展開に時間がかかるので）
VPCは必要でない限りしようしない（その分10ｰ30秒ぐらい余計に必要）
⇒ VPC内のリソースが必要であればDynamoDBStreamsとLambdaで非同期に
Global領域の遅延ロードを行えばいい

④ アーキテクチャの問題

同期でInvokeすると同時実行数の制限に引っかかる
できるだけ、非同期でInvokeするとスケーラビリティの観点ではいい
APIGatewayからの処理として、Put系であればSQSとかに流してしまう
いかに並列処理を行うかが大事
⇒ 1つあたりのイベントを小さくして、同時に並列で動かせるアーキテクチャにする

⑤ 同時実行数

同時実行数＝3s/exec x 10req/sec < default1000
ストリームベースの場合は少し違う
⇒ ストリームのシャードの数だけしか同時実行数しないといけない（これはSQSやKinesisのところを変える）

アンチパターン

LambdaでRDBMS使いがち問題

コネクション数の問題がある（Lambdaからの1リクエストに対してコネクションがそれぞれに貼られるから）
また、VPC内にRDBMSがあるからコールドスタート問題がある

RDBMS使うときはDynamoDBStreamとLambdaで転送

IP固定したがり問題

証明書や署名などで担保すべき（スケーラビリティがなくなる）

サーバーレスに夢見がち問題

サーバ管理は不要だが、運用は必要
複雑なことをやろうとすると設計開発コストが上がる可能性が・・
⇒ シンプルに使おう

監視しなくていいと思っている問題

適切にモニタリングしてあげる（CloudWatchでみる）
特に、ErrorsとThrottles

その他

Lambdaは最低一回実行は保証しているので、1回しか実行しないわけではない
DynamoDBを利用するときは冪等性を担保する