re:invent2018以降に発表された新機能をサーバーレスアプリケーションの開発に採用してみて

Slide 1

Slide 1 text

re:invent2018以降に発表された新機能をサーバーレスアプリケーションの開発に採⽤してみて 2019年9⽉12⽇ CX事業本部岩⽥智哉

Slide 2

Slide 2 text

スライドは後で⼊⼿することが出来ますので発表中の内容をメモする必要はありません。写真撮影をする場合はフラッシュ・シャッター⾳が出ないようにご配慮ください Attention

Slide 3

Slide 3 text

3 ⾃⼰紹介 lクラスメソッド株式会社 lサーバーレス開発部改め CX事業本部 l⼤阪オフィス所属 l好きなAWSサービス: AWS Lambda 岩⽥智哉

Slide 4

Slide 4 text

4 今⽇話したいこと re:invent2018以降に発表された新機能を実際のシステム開発に採⽤してみて得られた知⾒についてお話しします・どう便利になったのか︖ ・どういうことに気をつけるべきなのか︖ 等

Slide 5

Slide 5 text

5 想定しているターゲット • サーバーレスの基礎的な知識を持っている⼈ • 実際にサーバーレスで開発を⾏っている⼈ • 過去に開発したサーバーレスアプリを改善したい⼈

Slide 6

Slide 6 text

6 アジェンダ無駄なコスト • AWSにおけるサーバーレス開発について 2分 • Lambda Layersについて • DynamoDB Transactionsについて • CloudWatch Logs Insightsについて 9分 9分 5分 • VPC Lambdaの改善について • まとめ 9分 3分

Slide 7

Slide 7 text

7 無駄なコスト • AWSにおけるサーバーレス開発について 2分 • Lambda Layersについて • DynamoDB Transactionsについて • CloudWatch Logs Insightsについて 9分 9分 5分 • VPC Lambdaの改善について • まとめ 9分 3分

Slide 8

Slide 8 text

8 AWSにおけるサーバーレス開発無駄なコスト • マネージドサービスをフル活⽤してシステムを開発 • AWSのサービスはどんどんアップデートされる • できなかったことができるようになったり... • アンチパターンだったアーキテクチャがそうではなくなったり...

Slide 9

Slide 9 text

9 多数の機能が直近1年間にリリース... • Lambdaのランタイム追加 • Lambdaのカスタムランタイム • Lambda Layers • ALBのLambdaサポート追加 • API GWのWebソケット対応 • DynamoDBのGSIが最⼤20個に • DynamoDBのオンデマンドモード • DynamoDB Transactions • AWS Lake Formation • Step Functionsの連携サービス追加 • Step Functionsのネスト対応 • SARのNested Applications • SARのリソースタイプサポート追加 • Cognitoに管理者向けパスワードリセットAPI追加 • Aurora Serverlessに Data API追加 • AWS ToolKit • AWS CDK • AWS Amplify Console サーバーレスアプリケーションの開発に関連しそうなアップデートを抜粋

Slide 10

Slide 10 text

10 AWSにおけるサーバーレス開発で重要なことこれらのアップデート情報を追いかけながらしっかりと追従していくことがより良いシステムを作るために重要

Slide 11

Slide 11 text

11 無駄なコスト • AWSにおけるサーバーレス開発について 2分 • Lambda Layersについて • DynamoDB Transactionsについて • CloudWatch Logs Insightsについて 9分 9分 5分 • VPC Lambdaの改善について • まとめ 9分 3分

Slide 12

Slide 12 text

12 DynamoDB Transactions 無駄なコスト • ACID特性を保証した⼀連の操作を複数テーブルに跨って提供 • ロックはされない • RDBのようにBEGIN,COMMIT,ROLLBACKの呼び出しはない • 分離レベルはSerializeとReadCommited • ※同時実⾏されるオペレーションによって異なる • 同⼀アイテムへの複数回操作は不可 • CUの消費が⼤きい

Slide 13

Slide 13 text

13 Batch...系APIとの違い DynamoDB Transactionsを利⽤することで、エラーチェックやリトライ処理の実装負荷が低減 Batch...系のAPIは処理の⼀部だけ成功し、処理の⼀部は失敗するというケースが起こり得る。レスポンスのチェックやリトライ処理の実装が煩雑

Slide 14

Slide 14 text

14 DynamoDB Transactionsのユースケース無駄なコスト • 1つのエンティティを複数のアイテムで表現する設計 • ⾮キー属性に⼀意性を担保したい場合 • 1つの処理の中で複数のテーブルに跨るような処理を実⾏する場合等

Slide 15

Slide 15 text

15 DynamoDB Transactionsのユースケース① 1つのエンティティを複数のアイテムで表現する設計 • アイテムの属性を保持するために追加のアイテムを使うことで検索に柔軟性を持たせるパターン • アイテムの追加、更新、削除にTransactWriteItemsを利⽤ id(PK) attr_name(SK) attr_data 1 userName cm-iwata 1 email [email protected] 1 name 岩⽥テーブル GSI attr_name(PK) attr_data(SK) id userName cm-iwata 1 email [email protected] 1 name 岩⽥ 1

Slide 16

Slide 16 text

16 DynamoDB Transactionsのユースケース② ⾮キー属性に⼀意性を担保したい場合 • PKはパーティションキーなので、⼀意性が担保される • ユーザー名とメールアドレスについても⼀意性を担保したい id(PK) ユーザー名メールアドレス名前 f25e34e8-8882-48c9-b249- 8e387c252af4 cm-iwata [email protected] 岩⽥

Slide 17

Slide 17 text

17 DynamoDB Transactionsのユースケース② id(PK) ユーザー名メールアドレス名前 f25e34e8-8882-48c9-b249- 8e387c252af4 cm-iwata [email protected] 岩⽥ userName#cm-iwata email#[email protected] • 新規登録時︓3アイテム追加のTransactWriteItems • 更新時︓1アイテム追加、1or2アイテム削除、1or2アイテム追加の TransactWirteItems • 削除時︓3アイテム削除のTransactWriteItems Simulating Amazon DynamoDB unique constraints using transactions https://aws.amazon.com/blogs/database/simulating-amazon-dynamodb-unique-constraints-using-transactions/

Slide 18

Slide 18 text

18 DynamoDB Transactionsのユースケース③ 1つの処理の中で複数テーブルに跨るような処理を実⾏する場合 • データの削除ではなく無効化を⾏いたい • 無効化したデータは再度有効化できるようにしたい • 無効化したデータは⼀定時間経過後に⾃動削除 id(PK) 名称 1 hogehoge 2 fugafuga メインテーブル無効データテーブル id(PK) 名称 TTL

Slide 19

Slide 19 text

19 DynamoDB Transactionsのユースケース③ • 1アイテム追加、1アイテム削除のTransactWriteItems • 1つのテーブルで実現するよりも設計がシンプルに id(PK) 名称 1 hogehoge 2 fugafuga メインテーブル無効データテーブル id(PK) 名称 TTL 1 デバイス1 1567935907 ※説明簡略化のためにその他の詳細な要件は省略これだけの要件であれば1テーブルで設計する⽅がシンプル

Slide 20

Slide 20 text

20 直⾯した課題無駄なコスト • ユニットテストに使っていたライブラリmotoにTransact系のAPIが未実装⾃⼒でライブラリを拡張して対応 • DynamoDB Localへの乗り換えも検討したが、当時はDynamoDB LocalもTransact系のAPIに未対応(※現在は対応済み) • Lambda実⾏環境にバンドルされている boto3はバージョンが古く、 Transact系のAPIに未対応

Slide 21

Slide 21 text

21 DynamoDB Transactionsを使ってみた感想無駄なコスト • 複数テーブル、複数アイテムへの操作の安⼼感が違う • 異常系を想定したコードが単純に積極的にどんどん使いたい • モックを使ったテストに課題があるかも︖︖事前に確認を • DynamoDB Local、Local Stackは対応済み • オンデマンドモードを使えばCUの消費はあまり気にならない

Slide 22

Slide 22 text

22 無駄なコスト • AWSにおけるサーバーレス開発について 2分 • Lambda Layersについて • DynamoDB Transactionsについて • CloudWatch Logs Insightsについて 9分 9分 5分 • VPC Lambdaの改善について • まとめ 9分 3分

Slide 23

Slide 23 text

23 Lambda Layersとは無駄なコスト • 複数のLambda関数でコードを共有するための機能 • Lambda実⾏環境には関数とLayerのコード両⽅が展開される • システム全体で共通利⽤するロジックやライブラリの配置に最適

Slide 24

Slide 24 text

24 Lambda Layersができる前① ソースコードデプロイパッケージ Lambda関数 . ├── .gitignore ├── Makefile ├── docs ├── node_modules │ └── some_library ├── package-lock.json ├── sam.yml ├── src │ ├── func1.js │ ├── func2.js │ └── func3.js └── tests . ├── func1.js ├── func2.js ├── func3.js └── node_modules └── some_library handler handler handler

Slide 25

Slide 25 text

25 Lambda Layersができる前② ソースコードデプロイパッケージ Lambda関数 . ├── .gitignore ├── Makefile ├── docs ├── node_modules │ └── some_library ├── package-lock.json ├── sam.yml ├── src │ ├── func1.js │ ├── func2.js │ └── func3.js └── tests . ├── func1.js └── node_modules └── some_library handler handler handler . ├── func2.js └── node_modules └── some_library . ├── func3.js └── node_modules └── some_library

Slide 26

Slide 26 text

26 Lambda Layersができた後① ソースコードデプロイパッケージ Lambda関数 . ├── .gitignore ├── Makefile ├── docs ├── node_modules │ └── some_library ├── package-lock.json ├── sam.yml ├── src │ ├── func1.js │ ├── func2.js │ └── func3.js └── tests . ├── func1.js ├── func2.js └── func3.js handler handler handler レイヤー . └── nodejs └── node_modules └── some_library layer layer

Slide 27

Slide 27 text

27 Lambda Layersができた後② ソースコードデプロイパッケージ Lambda関数 . ├── .gitignore ├── Makefile ├── docs ├── node_modules │ └── some_library ├── package-lock.json ├── sam.yml ├── src │ ├── func1.js │ ├── func2.js │ └── func3.js └── tests . └── func1.js handler handler handler レイヤー . └── nodejs └── node_modules └── some_library layer layer . └── func2.js . └── func3.js

Slide 28

Slide 28 text

28 本当にそんなに便利︖︖

Slide 29

Slide 29 text

29 Lambda Layersが無かった頃... • 元々デプロイパッケージの作成にはSAM等のツールを利⽤ • デプロイパッケージの作成とデプロイはCI/CDで⾃動化全パッケージに共通部品を詰め込むのは⾮効率と理解しながらも、ツールが勝⼿にやってくれるので、⼤して困ってはいなかった

Slide 30

Slide 30 text

30 とりあえず使ってみることに • デプロイの⾼速化⽬的 • ライブラリはデプロイパッケージに含めずLayerで別途管理する • ライブラリに更新が無い限りは、Layerは更新しない • Pipfile.lockやpackage-lock.jsonのバージョンとLayerを1:1で管理⽅針とはいえデプロイが⾼速化できる可能性は魅⼒... まずは使ってみる

Slide 31

Slide 31 text

31 直⾯した課題 Layerと関数の関連性をどうテンプレートに落とし込むか • Layerと関数でテンプレートは分けたほうが良い︖ • CI/CDはどう変えるべきなのか︖

Slide 32

Slide 32 text

32 試⾏錯誤... • Layer⽤のテンプレートでLayerを⽣成し&Exportし、関数⽤のテンプレートから Fn::ImportValue • ContentUriが同⼀の場合Layerは更新されない • Fn::ImportValueされていると、LayerのContentUriを更新できない CloudFormationのクロススタック参照はLambda Layersと相性が悪い

Slide 33

Slide 33 text

33 結論 • ライブラリを管理するファイルのハッシュ値をObjectKeyとして Layer⽤のパッケージをS3にUP • PythonならPipfile.lock,Node.jsならpackage-lock.json • LayerのContentUriには上記ObjectKeyを指定 • これをCI/CDパイプラインの中で⾃動化するライブラリの依存関係ごとにContentUriが変わるように制御する

Slide 34

Slide 34 text

34 Lambda Layersを使ってみた感想 • デプロイしたLambda関数がマネコンから⾒える︕︕ • 開発段階ではマネコンから直接コードを編集できるのは結構魅⼒ • デプロイが早くなったのかは疑問 • Lambda関数作成〜作成完了までの時間が⻑くなった︖ • コールドスタートは早くなった原理は不明 • CI/CDの作り込みが少し⾯倒に • 気になるほどのレベルでは無い

Slide 35

Slide 35 text

35 無駄なコスト • AWSにおけるサーバーレス開発について 2分 • Lambda Layersについて • DynamoDB Transactionsについて • CloudWatch Logs Insightsについて 9分 9分 5分 • VPC Lambdaの改善について • まとめ 9分 3分

Slide 36

Slide 36 text

36 CloudWatch Logs Insightsとは • CloudWatch Logsのログデータを検索・分析できるサービス • 独⾃のクエリ⾔語が利⽤可能 • 最⼤20個のロググループに跨って検索可能(2019/7 Update!!) • 簡単な可視化も可能 • 検索範囲は最⼤で24時間までしか指定できない

Slide 37

Slide 37 text

37 できることクエリコマンドできること fields 指定したフィールドをログイベントから取得 filter クエリの結果を1つ以上の条件に基づいてフィルタ stats フィールドの値に基づいて集約・統計を計算 sort 取得したログイベントをソート limit 取得するログイベントの数を制限 parse ログフィールドをパースして名前を付与、後続のクエリで利⽤可能にするこれらのクエリコマンドをパイプ(|)で繋いで利⽤する

Slide 38

Slide 38 text

38 CloudWatch Logs Insightsによるクエリの例① AWS IoTのログからtest-thing-1のデバイスシャドウ更新に失敗したログを抽出 fields @timestamp, @message | filter deviceShadowName = 'test-thing-1’ and status = 'Failure'

Slide 39

Slide 39 text

39 CloudWatch Logs Insightsによるクエリの例② AWS IoTのログから clientId,eventType別の件数を取得 ※集計関数が含まれているので⾃動的に視覚化まで⾏われる fields @timestamp, @message | filter clientId not like /iotconsole/ and ispresent(clientId) | stats count(clientId) by clientId,eventType | sort clientId,eventType

Slide 40

Slide 40 text

40 CloudWatch Logs Insightsによるクエリの例③ Lambdaのログストリーム別に所要時間の最⼩値、最⼤値、平均値を取得 fields @message | filter @type = 'REPORT' | limit 10 | stats min(@duration), max(@duration), avg(@duration) by @logStream

Slide 41

Slide 41 text

41 CloudWatch Logs Insightsによるクエリの例④ API GWのログからレスポンスボディの JSONをパースし、レスポンスJSONに含まれるcmd_idがxxxのログを抽出 parse @message /¥((?¥S+)¥)¥s+(?Meth od response body after transformations:¥s)(?.*)/ | filter ispresent(request_id) | parse req_body /.*"cmd_id":¥s"(?.*)".*/ | filter cmd_id = ‘xxx'

Slide 42

Slide 42 text

42 CloudWatch Logs Insightsではできないこと • 複雑なクエリ • 例えばSQLのWindow関数 • 凝った可視化 • 24時間以上にわたる検索 CloudWatch Logs Insightsでは不⼗分なユースケースでは Athena & QuickSightやAmazonES & Kibanaの利⽤を検討

Slide 43

Slide 43 text

43 CloudWatch Logs Insightsを使ってみた感想 • 諸々の調査が楽チンに • 多少クエリの学習コストアリ • 指定できる範囲が最⼤で24時間なので注意 • ログを出⼒するならJSONで︕︕JSONは正義 • 複数のログを横断的に繋げるために必要な項⽬をログに出そう

Slide 44

Slide 44 text

44 無駄なコスト • AWSにおけるサーバーレス開発について 2分 • Lambda Layersについて • DynamoDB Transactionsについて • CloudWatch Logs Insightsについて 9分 9分 5分 • VPC Lambdaの改善について • まとめ 9分 3分

Slide 45

Slide 45 text

45 ※まだ実戦投⼊できていないですがインパクトの⼤きいUPDATEなのでご紹介します

Slide 46

Slide 46 text

46 VPC Lambdaの改善とは︖︖ • re:invent2018でアナウンスされた VPC Lambdaのアーキテクチャ改善 • VPC Lambdaが抱える問題点を改善するために、ENI周りの処理をアーキテクチャ⾒直しを実施 • 2019/9/3より順次適⽤開始のアナウンス

Slide 47

Slide 47 text

47 元々VPC Lambdaが抱えていた問題 • ENIもしくはIPアドレスが枯渇するリスク • ENI作成を伴うコールドスタート時の⼤幅な遅延 • インターネットアクセスにNAT Gatewayが必要さらに、VPC Lambdaの主なユースケースであるRDB利⽤に当たっては • コネクションプーリングの問題 • 同時接続数の問題等の課題も

Slide 48

Slide 48 text

48 改善されること、改善されないこと • ENIもしくはIPアドレスが枯渇するリスク • ENI作成を伴うコールドスタート時の⼤幅な遅延 • インターネットアクセスにNAT Gatewayが必要さらに、VPC Lambdaの主なユースケースであるRDB利⽤に当たっては • コネクションプーリングの問題 • 同時接続数の問題等の課題もこれらの問題が改善されるこれらの課題は引き続き残る

Slide 49

Slide 49 text

49 VPC Lambdaのライフサイクル (ENIの作成) コンテナの作成デプロイパッケージのロードデプロイパッケージの展開ランタイム起動・初期化関数・メソッドの実⾏コンテナの破棄 20190402 AWS Black Belt Online Seminar Let's Dive Deep into AWS Lambda Part1 & Part2 https://www.slideshare.net/AmazonWebServicesJapan/20190402-aws-black-belt-online-seminar-lets-dive-deep-into-aws-lambda-part1-part2

Slide 50

Slide 50 text

50 Lambda実⾏環境のアーキテクチャ ※説明を簡略化するために⼀部省略詳細は AWS公式の資料「 Security Overview of AWS Lambda 」を参照 Micro VM Lambda 実⾏環境 Worker EC2モデル Firecrackerモデル Lambda 実⾏環境 Lambda 実⾏環境 Micro VM Lambda 実⾏環境 Worker Lambda 実⾏環境 Lambda 実⾏環境 Micro VM Micro VM • ENIはWorkerにアタッチされる • ENI Capacity = Projected peak concurrent executions * (Memory in GB / 3GB) Firecracker Firecracker Firecracker

Slide 51

Slide 51 text

51 どこが変わるのか︖︖ 画像はre:invent2018「 SRV409 A Serverless Journey: AWS Lambda Under the Hood 」の発表資料より引⽤ https://www.slideshare.net/AmazonWebServices/a-serverless-journey-aws-lambda-under-the-hood-srv409r1-aws-reinvent- 2018?ref=https://dev.classmethod.jp/cloud/aws/reinvent2018-srv409/ • コールドスタート時にENIを作成してWorkerにアタッチ • Lambda実⾏環境へのメモリ割り当て3G毎にENIを作成 • ENIとIPアドレスを消費しがちな構成 • Lambda関数作成時にENIを作成 • Hyperplane ENIによるNATを経由して事前作成したENIを利⽤ • より多くのLambda実⾏環境が1つのENIを共有

Slide 52

Slide 52 text

52 改善効果 https://aws.amazon.com/jp/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/ AWSのブログでは、コールドスタートが1秒未満の例が公開

Slide 53

Slide 53 text

53 VPC Lambda Before & After • ENI作成のオーバーヘッドが無くなる • ENIの上限、IPアドレスの枯渇といった問題が改善変わること • コールドスタートという概念は残る • インターネットアクセスにはNAT Gatewayが必要変わらないことコールドスタートの遅延を理由にVPC Lambdaの採⽤を⾒送っていたようなケースでは、VPC Lambdaの利⽤が有⼒な選択肢に

Slide 54

Slide 54 text

54 VPC LambdaとRDBの組み合わせ • 同時接続数に関する考え⽅ • コネクションプーリングは使えない • 従量課⾦モデルのメリットが薄れる RDBを利⽤する場合は引き続き意識したいポイント

Slide 55

Slide 55 text

55 無駄なコスト • AWSにおけるサーバーレス開発について 2分 • Lambda Layersについて • DynamoDB Transactionsについて • CloudWatch Logs Insightsについて 9分 9分 5分 • VPC Lambdaの改善について • まとめ 9分 3分

Slide 56

Slide 56 text

56 まとめ AWSのサービスはどんどんバージョンアップされていきます。アンテナを⾼く張り、変化に追従していきましょう︕︕

Slide 57

Slide 57 text

57 オススメの情報収拾源無駄なコスト • What's New with AWS (https://aws.amazon.com/new/) • AWS公式のアナウンス⽇本時間の早朝が更新頻度が⾼い • AWS Blog(https://aws.amazon.com/blogs/) • AWS公式のブログ様々な機能の詳細解説や、「やってみた」など • Developpers.IO(https://dev.classmethod.jp/) • 弊社の「やってみた」系ブログ • 毎朝早起きしてAWSのアナウンスを正座待機しているメンバーも...