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

Developers.IO 2019 in Nagoyaの発表資料です

Transcript

1. re:invent2018以降に発表された新機能を サーバーレスアプリケーションの開発に採⽤ してみて 2019年9⽉12⽇ CX事業本部 岩⽥ 智哉
2. スライドは後で⼊⼿することが出来ますので 発表中の内容をメモする必要はありません。 写真撮影をする場合は フラッシュ・シャッター⾳が出ないようにご配慮ください Attention
3. 3 ⾃⼰紹介 lクラスメソッド株式会社 lサーバーレス開発部 改め CX事業本部 l⼤阪オフィス所属 l好きなAWSサービス: AWS Lambda 岩⽥ 智哉
4. 4 今⽇話したいこと re:invent2018以降に発表された新機能を 実際のシステム開発に採⽤してみて 得られた知⾒についてお話しします ・どう便利になったのか︖ ・どういうことに気をつけるべきなのか︖ 等
5. 5 想定しているターゲット • サーバーレスの基礎的な知識を持っている⼈ • 実際にサーバーレスで開発を⾏っている⼈ • 過去に開発したサーバーレスアプリを改善したい⼈
6. 6 アジェンダ 無駄なコスト • AWSにおけるサーバーレス開発について 2分 • Lambda Layersについて • DynamoDB Transactionsについて • CloudWatch Logs Insightsについて 9分 9分 5分 • VPC Lambdaの改善について • まとめ 9分 3分
7. 7 無駄なコスト • AWSにおけるサーバーレス開発について 2分 • Lambda Layersについて • DynamoDB Transactionsについて • CloudWatch Logs Insightsについて 9分 9分 5分 • VPC Lambdaの改善について • まとめ 9分 3分
8. 8 AWSにおけるサーバーレス開発 無駄なコスト • マネージドサービスをフル活⽤してシステムを開発 • AWSのサービスはどんどんアップデートされる • できなかったことができるようになったり... • アンチパターンだったアーキテクチャがそうではなくなったり...
9. 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 サーバーレスアプリケーションの開発に関連しそうなアップデートを抜粋
10. 10 AWSにおけるサーバーレス開発で重要なこと これらのアップデート情報を追いかけながら しっかりと追従していくことが より良いシステムを作るために重要
11. 11 無駄なコスト • AWSにおけるサーバーレス開発について 2分 • Lambda Layersについて • DynamoDB Transactionsについて • CloudWatch Logs Insightsについて 9分 9分 5分 • VPC Lambdaの改善について • まとめ 9分 3分
12. 12 DynamoDB Transactions 無駄なコスト • ACID特性を保証した⼀連の操作を複数テーブルに跨って提供 • ロックはされない • RDBのようにBEGIN,COMMIT,ROLLBACKの呼び出しはない • 分離レベルはSerializeとReadCommited • ※同時実⾏されるオペレーションによって異なる • 同⼀アイテムへの複数回操作は不可 • CUの消費が⼤きい
13. 13 Batch...系APIとの違い DynamoDB Transactionsを利⽤することで、エラーチェックや リトライ処理の実装負荷が低減 Batch...系のAPIは処理の⼀部だけ成功し、処理の⼀部は失敗すると いうケースが起こり得る。 レスポンスのチェックやリトライ処理の実装が煩雑
14. 14 DynamoDB Transactionsのユースケース 無駄なコスト • 1つのエンティティを複数のアイテムで表現する設計 • ⾮キー属性に⼀意性を担保したい場合 • 1つの処理の中で複数のテーブルに跨るような処理を実⾏する場合 等
15. 15 DynamoDB Transactionsのユースケース① 1つのエンティティを複数のアイテムで表現する設計 • アイテムの属性を保持するために追加のアイテムを使うことで検 索に柔軟性を持たせるパターン • アイテムの追加、更新、削除にTransactWriteItemsを利⽤ id(PK) attr_name(SK) attr_data 1 userName cm-iwata 1 email iwata@classmethod.jp 1 name 岩⽥ テーブル GSI attr_name(PK) attr_data(SK) id userName cm-iwata 1 email iwata@classmethod.jp 1 name 岩⽥ 1
16. 16 DynamoDB Transactionsのユースケース② ⾮キー属性に⼀意性を担保したい場合 • PKはパーティションキーなので、⼀意性が担保される • ユーザー名とメールアドレスについても⼀意性を担保したい id(PK) ユーザー名 メールアドレス 名前 f25e34e8-8882-48c9-b249- 8e387c252af4 cm-iwata iwata@classmethod.jp 岩⽥
17. 17 DynamoDB Transactionsのユースケース② id(PK) ユーザー名 メールアドレス 名前 f25e34e8-8882-48c9-b249- 8e387c252af4 cm-iwata iwata@classmethod.jp 岩⽥ userName#cm-iwata email#iwata@classmethod.jp • 新規登録時︓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/
18. 18 DynamoDB Transactionsのユースケース③ 1つの処理の中で複数テーブルに跨るような処理を実⾏する場合 • データの削除ではなく無効化を⾏いたい • 無効化したデータは再度有効化できるようにしたい • 無効化したデータは⼀定時間経過後に⾃動削除 id(PK) 名称 1 hogehoge 2 fugafuga メインテーブル 無効データテーブル id(PK) 名称 TTL
19. 19 DynamoDB Transactionsのユースケース③ • 1アイテム追加、1アイテム削除のTransactWriteItems • 1つのテーブルで実現するよりも設計がシンプルに id(PK) 名称 1 hogehoge 2 fugafuga メインテーブル 無効データテーブル id(PK) 名称 TTL 1 デバイス1 1567935907 ※説明簡略化のためにその他の詳細な要件は省略 これだけの要件であれば1テーブルで設計する⽅がシンプル
20. 20 直⾯した課題 無駄なコスト • ユニットテストに使っていたライブラリmotoにTransact系のAPIが 未実装 ⾃⼒でライブラリを拡張して対応 • DynamoDB Localへの乗り換えも検討したが、当時はDynamoDB LocalもTransact系のAPIに未対応(※現在は対応済み) • Lambda実⾏環境にバンドルされている boto3はバージョンが古く、 Transact系のAPIに未対応
21. 21 DynamoDB Transactionsを使ってみた感想 無駄なコスト • 複数テーブル、複数アイテムへの操作の安⼼感が違う • 異常系を想定したコードが単純に 積極的にどんどん使いたい • モックを使ったテストに課題があるかも︖︖事前に確認を • DynamoDB Local、Local Stackは対応済み • オンデマンドモードを使えばCUの消費はあまり気にならない
22. 22 無駄なコスト • AWSにおけるサーバーレス開発について 2分 • Lambda Layersについて • DynamoDB Transactionsについて • CloudWatch Logs Insightsについて 9分 9分 5分 • VPC Lambdaの改善について • まとめ 9分 3分
23. 23 Lambda Layersとは 無駄なコスト • 複数のLambda関数でコードを共有するための機能 • Lambda実⾏環境には関数とLayerのコード両⽅が展開される • システム全体で共通利⽤するロジックやライブラリの配置に最適
24. 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
25. 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
26. 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
27. 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
28. 28 本当にそんなに便利︖︖
29. 29 Lambda Layersが無かった頃... • 元々デプロイパッケージの作成にはSAM等のツールを利⽤ • デプロイパッケージの作成とデプロイはCI/CDで⾃動化 全パッケージに共通部品を詰め込むのは⾮効率と理解しながらも、 ツールが勝⼿にやってくれるので、⼤して困ってはいなかった
30. 30 とりあえず使ってみることに • デプロイの⾼速化 ⽬的 • ライブラリはデプロイパッケージに含めずLayerで別途管理する • ライブラリに更新が無い限りは、Layerは更新しない • Pipfile.lockやpackage-lock.jsonのバージョンとLayerを1:1で管理 ⽅針 とはいえデプロイが⾼速化できる可能性は魅⼒... まずは使ってみる
31. 31 直⾯した課題 Layerと関数の関連性をどうテンプレートに落とし込むか • Layerと関数でテンプレートは分けたほうが良い︖ • CI/CDはどう変えるべきなのか︖
32. 32 試⾏錯誤... • Layer⽤のテンプレートでLayerを⽣成し&Exportし、関数⽤のテンプレートから Fn::ImportValue • ContentUriが同⼀の場合Layerは更新されない • Fn::ImportValueされていると、LayerのContentUriを更新できない CloudFormationのクロススタック参照はLambda Layersと相性が悪い
33. 33 結論 • ライブラリを管理するファイルのハッシュ値をObjectKeyとして Layer⽤のパッケージをS3にUP • PythonならPipfile.lock,Node.jsならpackage-lock.json • LayerのContentUriには上記ObjectKeyを指定 • これをCI/CDパイプラインの中で⾃動化する ライブラリの依存関係ごとにContentUriが変わるように制御する
34. 34 Lambda Layersを使ってみた感想 • デプロイしたLambda関数がマネコンから⾒える︕︕ • 開発段階ではマネコンから直接コードを編集できるのは結構魅⼒ • デプロイが早くなったのかは疑問 • Lambda関数作成〜作成完了までの時間が⻑くなった︖ • コールドスタートは早くなった 原理は不明 • CI/CDの作り込みが少し⾯倒に • 気になるほどのレベルでは無い
35. 35 無駄なコスト • AWSにおけるサーバーレス開発について 2分 • Lambda Layersについて • DynamoDB Transactionsについて • CloudWatch Logs Insightsについて 9分 9分 5分 • VPC Lambdaの改善について • まとめ 9分 3分
36. 36 CloudWatch Logs Insightsとは • CloudWatch Logsのログデータを検索・分析できるサービス • 独⾃のクエリ⾔語が利⽤可能 • 最⼤20個のロググループに跨って検索可能(2019/7 Update!!) • 簡単な可視化も可能 • 検索範囲は最⼤で24時間までしか指定できない
37. 37 できること クエリコマンド できること fields 指定したフィールドをログイベントから取得 filter クエリの結果を1つ以上の条件に基づいてフィルタ stats フィールドの値に基づいて集約・統計を計算 sort 取得したログイベントをソート limit 取得するログイベントの数を制限 parse ログフィールドをパースして名前を付与、後続のクエリで利⽤可能にする これらのクエリコマンドをパイプ(|)で繋いで利⽤する
38. 38 CloudWatch Logs Insightsによるクエリの例① AWS IoTのログからtest-thing-1の デバイスシャドウ更新に失敗し たログを抽出 fields @timestamp, @message | filter deviceShadowName = 'test-thing-1’ and status = 'Failure'
39. 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
40. 40 CloudWatch Logs Insightsによるクエリの例③ Lambdaのログストリーム別に所 要時間の最⼩値、最⼤値、平均 値を取得 fields @message | filter @type = 'REPORT' | limit 10 | stats min(@duration), max(@duration), avg(@duration) by @logStream
41. 41 CloudWatch Logs Insightsによるクエリの例④ API GWのログからレスポンスボディの JSONをパースし、レスポンスJSONに含 まれるcmd_idがxxxのログを抽出 parse @message /¥((?<request_id>¥S+)¥)¥s+(?<msg>Meth od response body after transformations:¥s)(?<req_body>.*)/ | filter ispresent(request_id) | parse req_body /.*"cmd_id":¥s"(?<cmd_id>.*)".*/ | filter cmd_id = ‘xxx'
42. 42 CloudWatch Logs Insightsではできないこと • 複雑なクエリ • 例えばSQLのWindow関数 • 凝った可視化 • 24時間以上にわたる検索 CloudWatch Logs Insightsでは不⼗分なユースケースでは Athena & QuickSightやAmazonES & Kibanaの利⽤を検討
43. 43 CloudWatch Logs Insightsを使ってみた感想 • 諸々の調査が楽チンに • 多少クエリの学習コストアリ • 指定できる範囲が最⼤で24時間なので注意 • ログを出⼒するならJSONで︕︕JSONは正義 • 複数のログを横断的に繋げるために必要な項⽬をログに出そう
44. 44 無駄なコスト • AWSにおけるサーバーレス開発について 2分 • Lambda Layersについて • DynamoDB Transactionsについて • CloudWatch Logs Insightsについて 9分 9分 5分 • VPC Lambdaの改善について • まとめ 9分 3分
45. 45 ※まだ実戦投⼊できていないですが インパクトの⼤きいUPDATEなのでご紹介します
46. 46 VPC Lambdaの改善とは︖︖ • re:invent2018でアナウンスされた VPC Lambdaのアーキテクチャ改善 • VPC Lambdaが抱える問題点を改善 するために、ENI周りの処理をアー キテクチャ⾒直しを実施 • 2019/9/3より順次適⽤開始のアナ ウンス
47. 47 元々VPC Lambdaが抱えていた問題 • ENIもしくはIPアドレスが枯渇するリスク • ENI作成を伴うコールドスタート時の⼤幅な遅延 • インターネットアクセスにNAT Gatewayが必要 さらに、VPC Lambdaの主なユースケースであるRDB利⽤に当たっては • コネクションプーリングの問題 • 同時接続数の問題 等の課題も
48. 48 改善されること、改善されないこと • ENIもしくはIPアドレスが枯渇するリスク • ENI作成を伴うコールドスタート時の⼤幅な遅延 • インターネットアクセスにNAT Gatewayが必要 さらに、VPC Lambdaの主なユースケースであるRDB利⽤に当たっては • コネクションプーリングの問題 • 同時接続数の問題 等の課題も これらの問題が改善される これらの課題は引き続き残る
49. 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
50. 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
51. 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を共有
52. 52 改善効果 https://aws.amazon.com/jp/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/ AWSのブログでは、コールドスタートが1秒未満の例が公開
53. 53 VPC Lambda Before & After • ENI作成のオーバーヘッドが無くなる • ENIの上限、IPアドレスの枯渇といった問題が改善 変わること • コールドスタートという概念は残る • インターネットアクセスにはNAT Gatewayが必要 変わらないこと コールドスタートの遅延を理由にVPC Lambdaの採⽤を⾒送っていた ようなケースでは、VPC Lambdaの利⽤が有⼒な選択肢に
54. 54 VPC LambdaとRDBの組み合わせ • 同時接続数に関する考え⽅ • コネクションプーリングは使えない • 従量課⾦モデルのメリットが薄れる RDBを利⽤する場合は引き続き意識したいポイント
55. 55 無駄なコスト • AWSにおけるサーバーレス開発について 2分 • Lambda Layersについて • DynamoDB Transactionsについて • CloudWatch Logs Insightsについて 9分 9分 5分 • VPC Lambdaの改善について • まとめ 9分 3分
56. 56 まとめ AWSのサービスはどんどんバー ジョンアップされていきます。 アンテナを⾼く張り、 変化に追従していきましょう︕︕
57. 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のアナウンスを正座待機しているメンバーも...
58. 58 ご静聴ありがとうございました