AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp
•
69 recomendaciones•56,478 vistas
2017-06-30 #ssmjp AWS LambdaとDynamoDBがこんなにツライはずがない
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp
Similar a AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp (20)
Más de Masahiro NAKAYAMA
Más de Masahiro NAKAYAMA (20)
Último
Último (9)
AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp
- 3. サーバーレスアーキテクチャ #とは • 視点1：3種類の「サーバ」を捨てていく 1. 自分で管理する物理的・仮想的な「サーバ」を捨てて、 上の「機能」だけを利用する 2. プロビジョニング単位としての「サーバ」を捨てて、 確保サーバ数から消費したリソース量への転換 3. 処理全体に責任を持つ「指揮者としてのサーバ」を捨てて、 リアクティブな非同期メッセージングでシステムを構成 • 視点2：クラウドが提供する「ありもの」を最大限に活用する
- 4. 続きは書籍で！ • SoftwareDesign 2016/04号 • 電子版が技評で買えます https://gihyo.jp/dp/ebook/2017/978-4-7741-8409-8 • サーバーレスの薄い本 • 電子書籍版 https://gumroad.com/l/memotr201608 • ダイジェスト https://www.slideshare.net/nekoruri/20161109-serverless-meetup
- 5. サーバーレス三種の神器 • サーバーレスにシステムをつくるために必要なもの • 勝手にスケールするデータストア • Amazon DynamoDB • Amazon S3 • 勝手にスケールするソフトウェア実行環境 • AWS Lambda • （クライアント側ブラウザ上で動くJavaScript） • それらをつなげる枠組み • Amazon Kinesis Streams • Amazon Simple Queue Service(SQS) • AWS Step Functions • Amazon API Gateway
- 6. サーバーレス三種の神器 • サーバーレスにシステムをつくるために必要なもの • 勝手にスケールするデータストア • Amazon DynamoDB • Amazon S3 • 勝手にスケールするソフトウェア実行環境 • AWS Lambda • （クライアント側ブラウザ上で動くJavaScript） • それらをつなげる枠組み • Amazon Kinesis Streams • Amazon Simple Queue Service(SQS) • AWS Step Functions • Amazon API Gateway
- 7. 背景 某社のIoTっぽいデータ収集のしくみ • BLEメッシュ ← センサー情報 ↓ • SORACOM Funnel ↓ • Kinesis Streams ↓ • AWS Lambda ↓ • DynamoDB ⇒ 収集したデータの活用♥
- 8. 背景 サーバーレス環境の構築とデプロイ • Terraform • システム全体をTerraformで一括構築 • AWS Lambdaの関数定義までは行い、ダミーZIP食わせておく • memory_sizeとかは初期値のみに使いignoreしておく • Apex • AWS Lambdaを関数単位でデプロイ（apex -e ENV deploy） • ログとかも見られる（apex -e ENV logs -f ） • 実際のmemory_sizeとかはこちらで管理・設定 • 全部まるっとGitで管理
- 10. AWS Lambda ログ • AWS Lambdaでログを保存（例：console.log(“message”)） • CloudWatch Logsに保存されて、API経由で閲覧できる • 同期実行するとリアルタイムでも見られる（が今回は不可） • Apex経由で-fで追いかけていると遅れる • どっかでバッファリングされているっぽい？ • 昔のログを掘ろうとすると結構面倒 • 出力先Log Stream（ファイル名）が不定 （＝FaaSの内部構造の引きずられている） • ログのチャンネルが一つしかない • 別にアプリケーション固有ログ用のキュー持つ？面倒……
- 11. AWS Lambda 確保メモリサイズの調整 • あらかじめ128MB～1.5GBの範囲で64MB単位で指定 • それを超えると死ぬ • 実行時のCPU割当時間も、これに比例する • 右から左に流すだけで128MBで十分だろ’`,､ ( ´∀｀) ‘`,､ → CPU性能足りなくて実行時間がうなぎ登り • ストリーミング処理だからと実行時間を最適化しようとすると職人芸 • 実行ごとの消費メモリ量・実行時間はログに出る • というか消費メモリ量はログにしか出ない （CloudWatchメトリクスに出ない） • ログにカスタムメトリクス出してDatadog等にサマらせるのが正解
- 12. AWS Lambda VPC環境 • VPC環境でのLambda動作は茨の道 • 内部的にはEC2 ENIを確保するので、 インスタンス数が勝手に増えたときの初期化に時間が掛かる（＞10s） • IPアドレスプール（これもクラウドの都合で勝手に増える） • ⇒基本的にVPCは使わない • きちんと認証機構のあるコンポーネントを利用 • Amazonモノなら普通にIAM Role • でも、たまにmemcachedとかRedisとか使いたくなる……
- 13. AWS Lambda RDBMS使いづらい問題 • 同時接続数コントロールできない • FaaSなのでインスタンス数が勝手に増減する • 上限をコントロールすることができない • 思っていたよりも増える（後述） • AWSの中の人も「相性が悪い」と名言
- 14. AWS Lambda RDBMS使いづらい問題 • 同時接続数コントロールできない • FaaSなのでインスタンス数が勝手に増減する • 上限をコントロールすることができない • 思っていたよりも増える（後述） • AWSの中の人も「相性が悪い」と名言 •じゃあなんとかしてよ！！！！！
- 15. AWS Lambda ＋ Kinesis Streams 渡されるアイテムの個数 • ストリーム上のアイテムをまとめてLambdaに渡して起動 • 一気に渡す最大個数は指定できる（batch size） • 最大個数に満たないときは……？ ⇒適当にぽろぽろ飛んでくる • もうちょっとコントロールさせて欲しい • たとえば最大待ち時間とか
- 16. AWS Lambda＋Kinesis Streams シャード毎の投入先Lambdaプロセス • Kinesis Streamsはシャードという単位で複数のパイプに分割 • パーティションキーとしてどのシャードに入れるかを指定 • 一つのLambda関数は、シャードの数だけ同時実行される • 「シャード数が同時実行の単位」 http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/concurrent-executions.html • 思い込みによる失敗事例 • Lambdaは連続実行している限りプロセスを使い回す ⇒Lambda起動を跨いだデータ保持が可能ではないか？ • 結論：同時「実行」されるのは1シャード1プロセスだが、 複数のプロセスが起動しないとは言っていない（別プロセスが交互動作？） • FaaSなんだから関数の実行を跨ぐ状態を持ってはいけない（戒め） • ちなみに外部DBへの同時接続数も増えるはず
- 17. Kinesis Streams パーティションキーの指定方法 • パーティションキーの分散度合いが重要 • いくらシャードを増やしても、キーが1種類だけだと分散しない • 例：SORACOM FunnelはSIMのIMSI（≒電話番号）がキーだった • 第三者がKinesisに投入する場合はうまくやってもらう • SORACOM Funnel で AWS Kinesis Streams を利用するときのオプショ ンが追加されました https://blog.soracom.jp/blog/2017/04/18/randomize-key/ • 「Partition Key をリクエスト毎にランダムな値に設定するオプション を導入」
- 18. DynamoDB そもそもKVSである • KVSってことは全てキー単位 • パーティションキーでのアクセスが必須 • その中をソートキーで並べ替えは可能 • セカンダリインデックスで多少は頑張れないことは無い （ただし書き込み課金は2倍） • JOINして一括で引っ張るとかは無理 • N+1問題をベタに書くしか無い • リストを取得⇒N件分クエリを個別に投げる • あくまでデータの分散はパーティションキー • ソートキーだけで頑張ろうとする⇒データ分散しない⇒いつか死ぬ • Scanクエリ⇒テーブル全舐め⇒⏳
- 19. DynamoDB 案外安くない • （状況にもよるが）N+1なクエリが必要 • 必然的にクエリの回数が増える • 1つの処理で200クエリをパラで投げてるとかザラ • それでもまともな時間で処理が終わる！すごいめう！ • DynamoDB課金体系（東京） • 1秒あたり最大1回の書き込み能力の予約＝月0.53USD（約60円） • 1秒で200個データ書き込もうとすると月12,000円💸 • 読込はもうちょっと安い • リザーブドキャパシティーで1年契約で半額ぐらい • 事実上の資産管理を強いるの、やめてくだしあ＞＜
- 20. DynamoDB キャパシティの調整 • 「確保量」であり「消費量」ではない • あらかじめ、必要な性能を確保する必要がある • 数字の上限で良いので、EC2のインスタンス管理よりは楽とはいえ…… • 一日に性能を減らせる回数には上限あり（条件付き9回） • 消費量から自動化は可能 • CloudWatchメトリクスで取得できる • 利用する時間帯や、実際の消費量からLambda等で調整することは可能 ⇒6/15、AutoScalingリリース！！！！！！！！！！！！！！！！！
- 21. DynamoDB AutoScalingリリースされたけど • CloudWatch Alarmで閾値引っかかると性能を増減 • まあLambdaで普通にやるのと一緒の機能 • 完全では無いので、導入してもメトリクスはきちんと注視 • 「消費量」を基にしていて、スロットリングがトリガでは無い • 一つのlambdaから呼ぶ複数のテーブルで性能不足が起きると、 互いに詰まって閾値まで消費量が上がってくれないことがある ⇒スロットリング起きてるのに性能引き上げが起こらない
- 22. DynamoDB バックアップ • 冗長化はクラウドが勝手にやってくれる • が、バックアップは自前で取る必要がある • Google: “DynamoDB Backup” ⇒ AWS DataPipelineつかってElacticMapReduceでS3に出力 • 動作確認用にベースバックアップ取り込みとか考えるとちょっと カジュアルじゃない
- 23. DynamoDB っていうかKVS（再） • そもそもKVSだけでモノを作るのが大変 • ソシャゲ系の人がだいたい一度やってみて死んで覚える系あるある • きちんとKVS系分散DBの特性抑えていないと設計ができない • せめて集約関数とか使わせてください • 同じ立ち位置のAzure CosmosDB(旧DocumentDB)にはある • 全部取ってきて自分で集約するしかない • まとめでデータぶっこ抜く系が弱い • ソートキーやスキャンで一定範囲ぶっこ抜き ⇒APIレスポンス1回1MB制限で再送を強いられて（開発者が）死ぬ
- 24. Kinesis Firehose 東京に来ない • 手軽にS3に保存するためだけに太平洋を往復ビンタしたくない （本末転倒） • Athenaの方が先に来ちゃったぞ！おい！
- 25. Kinesis Analytics 東京に来ないし上手く動かない • Analyticsさらっと使えるようになるとNoCodingの夢が広がる • ポテンシャルは高いはず • RANK系関数が何をどうやっても動かなかった • 誰か教えてください
- 26. とはいえ • Lambdaはこのユースケースでは圧倒的に楽 • エラー再送とかKinesis Streamsでうまくやってくれる • ただしイテレータの遅延時間の監視は必須 • （なので極力処理毎にlambdaは分割してKinesisに複数ぶらさげる） • DynamoDB、十分に速い • 性能確保してパラレルで投げれば、きちんと返ってくる • 200クエリ束ねてPromise.all • 性能という数字の管理だけで上手く動いてくれるのは幸せ • とにかくスタートアップ的には札束ビンタで時間を稼げる
- 27. マルチクラウド？ • 使いたい機能を一番適合するクラウドのモノを使いたい • どうしても密結合が必要な部分はある （Kinesis⇒Lambda等） • データストアやBIなどは上手く「つまみ食い」できるのでは • ユーザ面どうするか • 現状はAWS特化でやっている • ID基盤は、ひとまず利用者側はAuth0で外部化はしてある • API Gatewayのサービスプロキシ等でうまくやれるはず • どうやっていくかが今後の課題
- 28. まだまだ道半ば • モノが足りない • KVSだけでシステムを作ることを強いられている • Firehose/Analyticsとか便利なサービスがまだ東京に来ない • ノウハウが足りない • 各コンポーネントの特性に基づくリソース割当の監視、運用 • あるていどの内部動作への理解が必要 • もうちょっとサーバーレスで頑張ってみようというお気持ち • 基盤から全部自分で作るよりは相当に楽 • サービスデリバリの高速化には既に十分寄与している • 全部おひとりさまサーバサイドエンジニアでなんとかなっている
- 29. で、誰？ • Aki (@nekoruri) • BLEなIoTシステムの クラウド側担当 • ちょろっと執筆も • 「薄い本」も出しています • 最近はすっかり セキュリティ教育畑に…… • セキュリティ・キャンプ プロデューサー • SecHack365 実施協議会委員 • ProjectDIVA Arcade LV.624 / ミリシタはじめました NEW!