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
コンテナセキュリティのためのLandlock入門
nullpo_head
2
320
複雑性の高いオブジェクト編集に向き合う: プラガブルなReactフォーム設計
righttouch
PRO
0
110
2024年にチャレンジしたことを振り返るぞ
mitchan
0
140
ゼロから創る横断SREチーム 挑戦と進化の軌跡
rvirus0817
2
270
DevOps視点でAWS re:invent2024の新サービス・アプデを振り返ってみた
oshanqq
0
180
re:Invent 2024 Innovation Talks(NET201)で語られた大切なこと
shotashiratori
0
310
DevFest 2024 Incheon / Songdo - Compose UI 조합 심화
wisemuji
0
100
小学3年生夏休みの自由研究「夏休みに Copilot で遊んでみた」
taichinakamura
0
150
KnowledgeBaseDocuments APIでベクトルインデックス管理を自動化する
iidaxs
1
260
どちらを使う?GitHub or Azure DevOps Ver. 24H2
kkamegawa
0
790
10分で学ぶKubernetesコンテナセキュリティ/10min-k8s-container-sec
mochizuki875
3
340
Oracle Cloudの生成AIサービスって実際どこまで使えるの? エンジニア目線で試してみた
minorun365
PRO
4
280
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Become a Pro
speakerdeck
PRO
26
5k
Code Reviewing Like a Champion
maltzj
520
39k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
111
49k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
A better future with KSS
kneath
238
17k
Typedesign – Prime Four
hannesfritz
40
2.4k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
Making the Leap to Tech Lead
cromwellryan
133
9k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Bash Introduction
62gerente
608
210k
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