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
2
210
2022/6/27(月) AWS好きエンジニア LT会 vol.2 #2
2022/6/27(月) AWS好きエンジニア LT会 vol.2 #2 の資料です。
Thirosue
June 27, 2022
Tweet
Share
More Decks by Thirosue
See All by Thirosue
2022/2/24(木) AWS好きエンジニア LT会 vol.1 #2
thirosue
2
140
Spring Fest 2017 の資料
thirosue
2
52
ブロックチェーンの講演@東京工業大学
thirosue
2
41
XP祭り2021 - LT
thirosue
2
39
Featured
See All Featured
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Thoughts on Productivity
jonyablonski
68
4.4k
Designing Experiences People Love
moore
139
23k
Side Projects
sachag
452
42k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Embracing the Ebb and Flow
colly
84
4.5k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.2k
How STYLIGHT went responsive
nonsquared
96
5.3k
The Pragmatic Product Professional
lauravandoore
32
6.4k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
Writing Fast Ruby
sferik
628
61k
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利⽤でコストも劇的に低減できる
ご清聴ありがとうございました!