Mais conteúdo relacionado
Semelhante a AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp (20)
Mais de Masahiro NAKAYAMA (20)
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
- 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とか使いたくなる……
- 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 をリクエスト毎にランダムな値に設定するオプション
を導入」
- 26. とはいえ
• Lambdaはこのユースケースでは圧倒的に楽
• エラー再送とかKinesis Streamsでうまくやってくれる
• ただしイテレータの遅延時間の監視は必須
• (なので極力処理毎にlambdaは分割してKinesisに複数ぶらさげる)
• DynamoDB、十分に速い
• 性能確保してパラレルで投げれば、きちんと返ってくる
• 200クエリ束ねてPromise.all
• 性能という数字の管理だけで上手く動いてくれるのは幸せ
• とにかくスタートアップ的には札束ビンタで時間を稼げる
- 28. まだまだ道半ば
• モノが足りない
• KVSだけでシステムを作ることを強いられている
• Firehose/Analyticsとか便利なサービスがまだ東京に来ない
• ノウハウが足りない
• 各コンポーネントの特性に基づくリソース割当の監視、運用
• あるていどの内部動作への理解が必要
• もうちょっとサーバーレスで頑張ってみようというお気持ち
• 基盤から全部自分で作るよりは相当に楽
• サービスデリバリの高速化には既に十分寄与している
• 全部おひとりさまサーバサイドエンジニアでなんとかなっている
- 29. で、誰?
• Aki (@nekoruri)
• BLEなIoTシステムの
クラウド側担当
• ちょろっと執筆も
• 「薄い本」も出しています
• 最近はすっかり
セキュリティ教育畑に……
• セキュリティ・キャンプ
プロデューサー
• SecHack365 実施協議会委員
• ProjectDIVA Arcade LV.624 / ミリシタはじめました
NEW!