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
150
Spring Fest 2017 の資料
thirosue
2
58
ブロックチェーンの講演@東京工業大学
thirosue
2
50
XP祭り2021 - LT
thirosue
2
44
Featured
See All Featured
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
Fontdeck: Realign not Redesign
paulrobertlloyd
84
5.5k
Building Applications with DynamoDB
mza
95
6.4k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.6k
Designing for humans not robots
tammielis
253
25k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
6
650
The World Runs on Bad Software
bkeepers
PRO
68
11k
Side Projects
sachag
453
42k
4 Signs Your Business is Dying
shpigford
183
22k
Mobile First: as difficult as doing things right
swwweet
223
9.6k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
228
22k
Testing 201, or: Great Expectations
jmmastey
42
7.5k
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利⽤でコストも劇的に低減できる
ご清聴ありがとうございました!