資料が長すぎてポイントでまとめるのが厳しかったので、特に気になった点のピックアップとそれ以外のちょっと気になったところを抜き出してる。
Lambdaのライフサイクル：
1. (ENIの作成, VPC利用時のみで10-30秒かかる)
2. コンテナの作成
3. デプロイパッケージのロード
4. デプロイパッケージの展開
5. ランタイム起動・初期化
6. 関数/メソッドの実行
7. コンテナの破棄
1〜5.（資料には1〜6.と書かれてるけど）の部分を再利用するのがウォームスタートで、コールドスタートは1から始める。
安定的にリクエストが発生している場合はコールドスタートはほぼ発生しないらしい。
また、コンテナを維持するためにポーリングすることは、多くの場合は無駄、とのこと。
制限事項は緩和可能なものと緩和不能なものがある。
Lambdaを使うには、次の3つの選択肢がある。
* 一から作成
* 設計図の使用（一般的なユースケース用のサンプルコードと設定）
* Serverless Application Repositoryの参照
Custom Runtimeとして、Lambdaが公式には対応していない任意の言語をLambda関数で記述できるようになる。
AWSからOSSとしてC++やRustが使用可能。
その他、パートナーからPHP/Erlang/Elixir/COBOLなどが提供される予定。（COBOL！）
ユースケースとしては、下記。
* Lambdaがサポートしている言語の新しいバージョンを待てない
* Lambdaがサポートを打ち切った言語のバージョンを使いたい
* Lambdaがサポートしてない言語を利用したい
その他ポイントになりそうなところ：
* コード実行時間に対する課金でコスト効率が良い（=EC2と比べてかな）と言う話は特徴として何度も出てくる
* モバイルアプリからの呼び出しなどの場合、SDKによってClient Context（バージョンとか）が収集された上でLambdaに渡される
* リソース制約として処理が15分以内に完了すること、リクエスト・レスポンスのサイズはそれぞれ（と書いてあるけど要確認）6MBまで（確かAPI Gatewayは10MBまでだったかな）
* LambdaとCloudFlareの組み合わせでServerless@Edgeと称した取り回しができる（一度Lambdaを書けばグローバルに動く、CDNとの併せ技でWebサイトコンテンツを応答させることができる）
* サーバーレスの活用領域のトップは40%超で動的Webシステム、次いで30%台で機械学習、モバイルのバックエンド、イベント駆動の業務関連携
* AWS Lambdaの実行環境はAmazon Linux
* 同期実行だと実行完了時にレスポンスがあり、その内容はLambda関数にセット、非同期実行だとリクエストが正常に受け付けられたかどうかのみ
* 環境変数も使える、事前にセットされているものもある
* バージョニングはPublishVersionを実行するかpublishパラメーターを追加すればOKで、バージョンを発行するまでは"$LATEST"が唯一のバージョンとのこと
* エイリアス（prodとかdevとか）を指定可能で、routing-configを利用して異なるバージョンを一定の割合ずつに割り振るようなことができる（＝カナリアリリース的なことができる！）
* 複数のLambdaで共通利用するコンポーネントをLambda Layerとして定義して持つことができる
* Lambdaが保証しているのは呼び出されたら最低一回は実行すること＝呼び出し側で呼び出せてない or 複数回呼び出してしまっている、ということは発生しうるので全体の仕組みの中で解決する（e.g. S3ならイベント発火用バケットと処理済みバケットを作成するなど）
資料は [AWS Black Belt Online Seminar] Let's Dive Deep into AWS Lambda Part1 & Part2
この著者の西谷さんの資料は2015年のも見たことがあるけれど、AWSが機能充実したからか、著者の努力か、あるいはその両方のおかげかで、資料がだいぶ肉厚になってた。
初めはストーリーテリングでガー・レイノルズのやる手法みたいなのが組み込まれていたんだけど、そこから急に文字ばかりのスライドになったからちょっと落差が激しかったけど。
ちなみに、画像はVisual Huntから持ってきてた。さすが公式に載る資料だけあってきっちりしてる。
Part3とPart4の資料は見つけられなかったけど、セミナーの動画がYouTubeに上がっているのは見つけた。
* 【AWS Black Belt Online Seminar】 AWS Lambda Part3 - YouTube
* 【AWS Black Belt Online Seminar】AWS Lambda Part4 - YouTube
また、上記の資料を読み込んだ後に、デザインのパターン集を見るとアイデアが湧きやすくて良さそう。
ここから、少し派生の話。
まずはSAM。Serverless Application Model（SAM）はCloudFormationの拡張機能。
SAMで書くと純粋にCloudFormationに記述していくのの半分程度の記述でしかもわかりやすく書けて楽。実際にデプロイするときに、本来のCloudFormationの文法に変換される。
内側の変換の仕組みは、CloudFormationに元々あるTransformというセクション定義と変換方式（マクロ）の利用とのこと。
Serverlessの部分だけ該当のType指定をすれば良いので、別のリソース（e.g. S3）も一緒にSAMで書いても問題なし。
SAMを使うと検証目的でローカルでLambda関数を実行したり、テスト用のイベントを生成したり、APIエンドポイントを作成したりできる。
類似ツールとして、AWS Cloud Development Kit(CDK)やAWS Chaliceもある模様で、それらとの使い分けも整理されていて良かった。（管理対象がLambda以外にも多くたくさんある＝CDK、Pythonに特化しアプリ開発者とインフラエンジニアが同一な場合＝Chalice）
* [AWS Black Belt Online Seminar] AWS Serverless Application Model (AWS SAM)
ChaliceはWeb APIを作るときとほとんど同じ要領で作れるように見えるので、すごく良さそうに思えた。テストもかなりしやすそう。
AWS CDKなどで既に取り組んでいる仕組みを移してまで実施する必要があるかは検討の余地ありだけど。
また、Lambdaを使っていく上で、個々のパーツが分散してしまうのでモニタリングの仕組みが必要。
CloudWatchでメトリクスとログを、X-Rayでトレースを実現する。
メトリクスは意味の理解が重要。下記はLambdaのMetrics。
* Invocations: Lambdaの実行回数、課金カウント
* Duration: 実行時間、起動の時間を含まない
* Errors, Availability: 正常しなかった回数の計測
* Throttles: Throttle（同時実行回数制限）の発生回数
* IteratorAge: ストリーム（Kinesis, DynamoDB）でのみ使用する、イベントとして受信した時間とレコードの終端の時刻の時間差（＝ということはイベントを受けてから書き込みまでにかかった時間？）
* DeadLetterErrors: DLQを設定し、書き込みに失敗した回数
通常のモニタリング同様、ログを集めて分析してアクションに落とすところまでやることが重要。例えば、どの処理が多く課金を消費しているかなど。
Serverlessだとコンテナごとにログが分かれてしまうので、そこをフィルターをかけてうまく拾ってあげることも検討する。そして必要なら後続の処理（Elasticsearchとか）につなげて分析する。
[AWS Black Belt Online Seminar] Serverless モニタリング
Route 53やDynamoDB、ECSあたり読み込もうと思っていたけど、Lambdaだけでも結構ボリュームあってお腹いっぱいなのでまた今度。