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
880
私がエッジを使う理由
chimame
10
4k
GraphQL Server on Edge after that
chimame
1
1.4k
Accelerating App Dev with Cloudflare Workers
chimame
1
400
GraphQL Server on Edge
chimame
12
5.7k
エッジで輝くフロントエンド
chimame
11
6.6k
Cloudflare Workersと状態管理
chimame
4
1.6k
CSRなサイトを (疑似的な)ISRに変更した話
chimame
0
580
Cloud Runマネージドに適したアプリケーションを考える
chimame
1
290
Other Decks in Technology
See All in Technology
My small contributions - Fujiwara Tech Conference 2025
ijin
0
1.4k
テストを書かないためのテスト/ Tests for not writing tests
sinsoku
1
170
今年一年で頑張ること / What I will do my best this year
pauli
1
220
re:Invent 2024のふりかえり
beli68
0
110
2025年のARグラスの潮流
kotauchisunsun
0
790
東京Ruby会議12 Ruby と Rust と私 / Tokyo RubyKaigi 12 Ruby, Rust and me
eagletmt
3
870
Bring Your Own Container: When Containers Turn the Key to EDR Bypass/byoc-avtokyo2024
tkmru
0
850
Formal Development of Operating Systems in Rust
riru
1
420
comilioとCloudflare、そして未来へと向けて
oliver_diary
6
440
Goで実践するBFP
hiroyaterui
1
120
I could be Wrong!! - Learning from Agile Experts
kawaguti
PRO
8
3.4k
月間60万ユーザーを抱える 個人開発サービス「Walica」の 技術スタック変遷
miyachin
1
140
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
960
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
230
52k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.6k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
173
51k
Raft: Consensus for Rubyists
vanstee
137
6.7k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.5k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.3k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Building an army of robots
kneath
302
45k
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