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
2022/6/27(月) AWS好きエンジニア LT会 vol.2 #2
Search
Thirosue
June 27, 2022
230
2
Share
2022/6/27(月) AWS好きエンジニア LT会 vol.2 #2
2022/6/27(月) AWS好きエンジニア LT会 vol.2 #2 の資料です。
Thirosue
June 27, 2022
More Decks by Thirosue
See All by Thirosue
2022/2/24(木) AWS好きエンジニア LT会 vol.1 #2
thirosue
2
170
Spring Fest 2017 の資料
thirosue
2
75
ブロックチェーンの講演@東京工業大学
thirosue
2
64
XP祭り2021 - LT
thirosue
2
58
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
72
12k
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
160
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
140
Testing 201, or: Great Expectations
jmmastey
46
8.1k
Joys of Absence: A Defence of Solitary Play
codingconduct
1
360
Ruling the World: When Life Gets Gamed
codingconduct
0
220
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
How GitHub (no longer) Works
holman
316
150k
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
1
3.6k
Faster Mobile Websites
deanohume
310
31k
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
450
Accessibility Awareness
sabderemane
1
110
Transcript
コンテナを使ったバッチ実⾏ 環境を考える 〜FARGATE SPOTの使いどころ〜 ビッグツリーテクノロジー&コンサルティング 廣末丈⼠
廣末 丈⼠ • ⾃称フロントエンジニア • Serverless / コンテナ好き
AWSでコンテナを利⽤したバッチ環境 にどのサービスを使うか 悩んだことある⼈いますか?
EKS? ECS? Batch? Lambda? FARGATE? EC2?
どれでも良くない?
正解! ( 適材適所 ) プロジェクトコンテキスト ⾮機能要件(バッチレスポンス、コスト他)、運 ⽤要件、チーム構成を考慮の上であれば
バッチ処理とは 逐次⽣み出されるデータを⼀定期間集めたもの をバッチといい、このバッチ単位で⾏う処理の こと 今回対象とするバッチ処理 単位時間の処理量が決まっていないバッチ について検討
Lambda
props cons • 初期構築が容易 • バッチレスポンス(反映時間)が短い(イベント駆動、スト リーム処理) • 15分でタイムアウトする •
コスト施策の打ち⼿が少ない(SPOTなし) イベント駆動アーキテクチャのコンポーネントであり、「単位時間の 処理量が決まっていないバッチ」には不適切なため、除外
EKS
props cons • 可搬性(ポータビリティ) • 運⽤コストが⾼い • コスト施策の打ち⼿が限られる(FARGATE_SPOTなし) ⾃ら本番で構築・運⽤したことないため、除外 2年以上前
ようやく本題
EKS? ECS? Batch? Lambda? SPOTは本番で使えるのか?
ü 業務継続性(稼働率) ü バッチレスポンス(起動 のオーバーヘッド) 確認ポイント
ü 業務継続性(稼働率) ü バッチレスポンス(起動 のオーバーヘッド)
業務継続性 ü 稼働率 ü バッチリトライ
SPOTの強制終了怖い?
ほぼ落ちません! 本番運⽤で困った記憶なし
スポットインスタンスアドバイザー https://aws.amazon.com/jp/ec2/spot/instance-advisor/
スポット価格履歴 EC2マネジメントコンソール「スポットリクエスト」→「料⾦設定履歴」
バッチリトライ ECS Batch キューを経由するためAPIレベルでサポート →業務継続性を平易に向上可能 未サポート サポート
AWS Batch 優勢か?
ü 業務継続性(稼働率) ü バッチレスポンス(起動 のオーバーヘッド)
起動のオーバーヘッド ‒ Batch FARGATE_SPOT 概ね20-30秒程度で起動する、定期実⾏に問題ない範囲
起動のオーバーヘッド ‒ Batch EC2(SPOT) EC2の初回起動コストが⾼い 反⾯、リソースがある場合の起動コストは、 FARGATEと同等かそれ以上 稼働しているリソース(EC2)がない場合は遅い
起動のオーバーヘッド ‒ ECS Task FARGATE_SPOT 概ね20秒程度で起動する、定期実⾏に問題ない範囲 10秒の差でリトライオプションが選択可能なら、私はそちらを選択したい
AWS Batchって⼤量データ向けでしょ?
リソース 0.25vCPU、512Mから実⾏可能 コスト - 1時間ごと、1回あたりの実⾏時間 15分、2vCPU、4Gの場合 Lambda FARGATE On Demand(最⼤
70% 割引) → 8USD
まとめ ü ⾼レベルな業務継続性、バッチレスポンス(*1)を求められない場合 (ビッグデータ作成など)、Batch FARGATE_SPOTは有効な選択肢 となる *1) 引⽤元:⾮機能要求グレード https://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html ü
FARGATE利⽤で、0.25vCPU、512MByteから実⾏可能 ü FARGATE利⽤で、起動のオーバーヘッドも緩和される ü SPOTの強制終了は、リトライオプションでカバー ü SPOT利⽤でコストも劇的に低減できる
ご清聴ありがとうございました!