Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Deep Dive AWS Lambda
Search
chimame
July 27, 2018
Technology
1
1.4k
Deep Dive AWS Lambda
HIGOBASHI.AWS #5
chimame
July 27, 2018
Tweet
Share
More Decks by chimame
See All by chimame
RemixでVersion skewに立ち向かう
chimame
1
860
私がエッジを使う理由
chimame
10
4k
GraphQL Server on Edge after that
chimame
1
1.3k
Accelerating App Dev with Cloudflare Workers
chimame
1
390
GraphQL Server on Edge
chimame
12
5.6k
エッジで輝くフロントエンド
chimame
11
6.5k
Cloudflare Workersと状態管理
chimame
4
1.6k
CSRなサイトを (疑似的な)ISRに変更した話
chimame
0
570
Cloud Runマネージドに適したアプリケーションを考える
chimame
1
280
Other Decks in Technology
See All in Technology
Fanstaの1年を大解剖! 一人SREはどこまでできるのか!?
syossan27
2
160
watsonx.ai Dojo #5 ファインチューニングとInstructLAB
oniak3ibm
PRO
0
160
Amazon SageMaker Unified Studio(Preview)、Lakehouse と Amazon S3 Tables
ishikawa_satoru
0
150
KubeCon NA 2024 Recap / Running WebAssembly (Wasm) Workloads Side-by-Side with Container Workloads
z63d
1
240
OpenAIの蒸留機能(Model Distillation)を使用して運用中のLLMのコストを削減する取り組み
pharma_x_tech
4
550
サービスでLLMを採用したばっかりに振り回され続けたこの一年のあれやこれや
segavvy
2
400
マルチプロダクト開発の現場でAWS Security Hubを1年以上運用して得た教訓
muziyoshiz
2
2.2k
Snowflake女子会#3 Snowpipeの良さを5分で語るよ
lana2548
0
230
あの日俺達が夢見たサーバレスアーキテクチャ/the-serverless-architecture-we-dreamed-of
tomoki10
0
440
株式会社ログラス − エンジニア向け会社説明資料 / Loglass Comapany Deck for Engineer
loglass2019
3
32k
20241220_S3 tablesの使い方を検証してみた
handy
3
370
LINEスキマニにおけるフロントエンド開発
lycorptech_jp
PRO
0
330
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.3k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.1k
The Pragmatic Product Professional
lauravandoore
32
6.3k
It's Worth the Effort
3n
183
28k
Typedesign – Prime Four
hannesfritz
40
2.4k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
28
900
Scaling GitHub
holman
458
140k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7k
Six Lessons from altMBA
skipperchong
27
3.5k
Transcript
Deep Dive AWS Lambda 2018/07/27 HIGOBASHI.AWS#5
Agenda - 自己紹介 - AWS Lambda - 事例 - まとめ
自己紹介
$ aws myperson describe { “name”: “rito(田又 利土)”, “job”: “software
developer”, “company”: “株式会社エイチームライフスタイル”, “skills”: [“Ruby(on Rails)”, “Nodejs”, “Reactjs”, “Docker”, “kubernetes”], “twitter”: “@chimame_rt”, “github”: “chimame” }
AWS Lambda
AWS Lambda AWS上で提供されている、 ”サーバーレス”のAPI実行環境。自前のサー バーを立てる必要なく、Lambda上でコードが実行される。 • インフラ周りの管理が不要 サーバレスなので、「サーバを管理する」ということがそもそも不要。 • 実行環境のオートスケール
サーバ負荷による実行環境のオートスケールを Lambda自身が行い、管理者が意識する必要はない。
ここで1つの疑問
“サーバーレス”っていうけどさ、実 際はサーバあるんでしょ?
こんなコード仕込んで調べてみた。 exports.handler = (event, context, callback) => { const exec
= require('child_process').exec // 子プロセスを起動する event.commands.forEach(command => { exec(command, (error, stdout, stderr) => { // 子プロセスでコマンドを実行する if (!error) { console.log('standard out: ' + stdout) // 標準出力結果をログに出力する } else { console.log(`error code: ${error.code} err: ${error}`) } }) }) return callback(null, JSON.stringify({ result: 'OK'})) }
コマンドの実施 $ ls -lah / dr-xr-xr-x 2 root root 4.0K
Jun 22 12:57 bin dr-xr-xr-x 2 root root 4.0K Jun 22 12:56 boot drwx------ 4 root root 4.0K Jun 22 12:57 builddir drwxr-xr-x 2 root root 4.0K Jul 26 14:59 dev drwxr-xr-x 60 root root 4.0K Jun 22 13:00 etc drwxr-xr-x 2 root root 4.0K Jan 6 2012 home drwxr-xr-x 2 root root 4.0K Jan 6 2012 mnt drwxr-xr-x 2 root root 4.0K Jan 6 2012 selinux ~~~~~ drwx------ 2 sbx_user1059 487 4.0K Jul 26 15:02 tmp drwxr-xr-x 13 root root 4.0K Jun 22 12:55 usr drwxr-xr-x 22 root root 4.0K Jul 26 14:59 var
コマンドの実施 $ pwd /var/task $ df -aTh Filesystem Type Size
Used Avail Use% Mounted on /dev/xvda1 ext4 7.8G 3.6G 4.2G 47% / /dev/xvda1 ext4 7.8G 3.6G 4.2G 47% /dev /dev/loop0 ext4 526M 440K 514M 1% /tmp none proc 0 0 0 - /proc /dev/xvda1 ext4 7.8G 3.6G 4.2G 47% /proc/sys/kernel/random/boot_id /dev/xvda1 ext4 7.8G 3.6G 4.2G 47% /var/runtime /dev/xvda1 ext4 7.8G 3.6G 4.2G 47% /var/lang /dev/loop1 squashfs 128K 128K 0 100% /var/task
コマンドの実施 $ cat /etc/system-release Amazon Linux AMI release 2017.03 $
ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 488 1 0.0 3.1 1117936 31544 ? Ssl 15:02 0:00 /var/lang/bin/node --expose-gc --max-semi-space-size=6 --max-old-space-size=115 /var/runtime/node_modules/awslambda/index.js 488 19 0.0 0.0 0 0 ? Z 15:12 0:00 [sh] <defunct> 488 20 0.0 0.0 0 0 ? Z 15:12 0:00 [ls] <defunct> 488 21 0.0 0.2 117216 2520 ? R 15:12 0:00 ps aux 488 22 0.0 1.0 1117936 10452 ? R 15:12 0:00 /var/lang/bin/node --expose-gc --max-semi-space-size=6 --max-old-space-size=115 /var/runtime/node_modules/awslambda/index.js
さらなる疑問
“Amazon linux”で動いているのは わかったけど、オートスケールする のってどうやってるの?
オートスケールといえば
None
こればっかりはわからんの中の人に聞いてみました。 「AWS Lambdaってコンテナで動いてるの?」 ⇒Yes(Dockerじゃないぽい) ただし、この質問をした時に”こいつそんなこと聞いて何考えてん だ?”的な雰囲気になったので突っ込んで聞けなかった。
事例
検索エンジンの結果がとても重要
なので複数の方式を用いて検索エン ジンの結果を取得している
検索エンジンの結果取得方法 • 各検索エンジンのSearch APIを使用 Googleならば「Google Custom Search API」というものが提供されており、検索 結果をJSONで取得することが可能 •
各検索サイト上での検索結果を使用 上記のSearch APIが提供されていなかったり、APIから取得できる以外の情報を 取得したい場合に直接検索サイト上での検索結果を取得(スクレイピング)
検索エンジンの結果取得方法 • 各検索エンジンのSearch APIを使用 Googleならば「Google Custom Search API」というものが提供されており、検索 結果をJSONで取得することが可能 •
各検索サイト上での検索結果を使用 上記のSearch APIが提供されていなかったり、APIから取得できる以外の情報を 取得したい場合に直接検索サイト上での検索結果を取得(スクレイピング) こっちは超えないといけないも のが多い
検索サイト上での検索結果取得で注 意しないといけないこと
None
短期間 で 同一IP からアクセスは 機械的アクセスとして遮断される
回避方法 • 長期に渡って検索結果を取得する 短期間がダメならば長期間(例えば取得のインターバルを長くすること)で取得す る • 複数のIP(発信元)から取得するようにする サーバを複数台用意し、複数のIPから取得するようにする
• 長期に渡って検索結果を取得する 短期間がダメならば長期間(例えば取得のインターバルを長くすること)で取得す る • 複数のIP(発信元)から取得するようにする サーバを複数台用意し、複数のIPから取得するようにする 回避方法 要件にもよるけど、待てないし …
• 長期に渡って検索結果を取得する 短期間がダメならば長期間(例えば取得のインターバルを長くすること)で取得す る • 複数のIP(発信元)から取得するようにする サーバを複数台用意し、複数のIPから取得するようにする 回避方法 そのためにわざわざサーバを 複数台用意するのは…
AWS Lambda これらの問題を解決するために、使用しています。
AWS Lambdaの特徴(おさらい) • コンテナで動いている 実行都度コンテナが作成/実行されると実行ホストも変わりIPも変わる • オートスケールする オートスケールするということは実行するホストが変わればIPも変わる
2つの疑問
• 疑問1 実行都度、コンテナを配置・実行してる の? • 疑問2 オートスケールってどれくらいやったらス ケールするの?
AWS Lambdaにおけるコンテナ再配置計測 • 調べる方法 冒頭に紹介したコマンドを実行Lambdaを一定期間毎に”curl inet-ip.info”を実行させGlobal IPを取得し変化を計測 • 計測間隔 インターバルを初回は5分として、次回以降に5分ずつ増加さ
せ、5分後、15分後、20分後…という計測
AWS Lambdaにおけるコンテナ再配置計測 • 計測結果 計測時間 Global IP 20時25分29秒(初回 13.115.170.77 20時30分31秒(5分後
13.115.170.77 20時40分35秒(10分後 13.115.170.77 20時55分40秒(15分後 13.115.170.77 21時15分42秒(20分後 13.115.170.77 21時40分46秒(25分後 13.115.170.77 22時10分51秒(30分後 13.231.194.161 22時45分00秒(35分後 13.231.153.34
AWS Lambdaにおけるコンテナ再配置方法 • 一定時間経過してからLambdaを呼び出す。 先の検証結果より、同一のLambdaを一定期間内に再度呼び出しても、コンテナ の再配置は行われないので、一度呼び出したLambdaは30分間使用しない。 • 同一処理のLambdaを複数用意し、コンテナ再配置時間まで は別のLambdaを使用する。 同一Lambdaを呼び出すのにインターバルが必要なので、同一処理の別
Lambdaを準備してそれを使用するようにすると上記対策のデメリットを消せる。
AWS Lambdaにおけるオートスケール計測 • 調べる方法 冒頭に紹介したコマンドを実行Lambdaに”curl inet-ip.info” を実行させGlobal IPを取得し変化を計測 さらに、該当の Lambdaを並列実行
させる • 並列実行方法 1つのLambdaから複数回に亘り別Lambdaを実行させる
AWS Lambdaにおけるオートスケール計測結果 • 計測結果 thread用のLambdaを介 して実行するとスケール しやすい。 左記の図では400個を同 時実行しているが、大体 3段組み100個くらいでス
ケールする。
AWS Lambdaにおけるオートスケール方法 • Lambdaを多重実行する 先の例で示したように同時100実行くらいのLambdaであれば簡単にスケールす る。ただし、アカウント毎のAWS Lambdaの同時実行数上限を必要に応じて、あ げる必要がある。 • 多重実行の場合は取得結果を検討する必要がある
同時実行されている複数のLambdaの結果を受け取るには受け取る側の負荷を 考慮する必要がある。
まとめ
AWS Lambdaって • 意外と中を見れます • コンテナで動いてる • 起動までは結構かかる 特性を踏まえて使用する
AWS Lambdaって • 意外と中を見れます • コンテナで動いてる • 起動までは結構かかる 特性を踏まえて使用する DoS攻撃には使っちゃ
ダメですよ
ご清聴 ありがとうございました rito@chimame_rt