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
オンデマンドインスタンスを極限まで減らしたらこうなった
Search
NAVITIME JAPAN
PRO
July 11, 2019
Technology
0
29
オンデマンドインスタンスを極限まで減らしたらこうなった
2019/07/11(木)開催の「X-Tech JAWS 【第8回】~時代を突き抜けるX-Tech企業の真髄~」にて発表した資料です。
NAVITIME JAPAN
PRO
July 11, 2019
Tweet
Share
More Decks by NAVITIME JAPAN
See All by NAVITIME JAPAN
つよつよリーダーが 抜けたらどうする? 〜ナビタイムのAgile⽀援組織の変遷〜
navitimejapan
PRO
22
15k
実践ジオフェンス 効率的に開発するために
navitimejapan
PRO
3
440
安全で使いやすいCarPlayアプリの 魅せ方:HIGと実例から学ぶ
navitimejapan
PRO
1
170
見えないユーザの声はログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~
navitimejapan
PRO
6
2.6k
ユーザーのためなら 『デザイン』 以外にも手を伸ばせる
navitimejapan
PRO
2
1.4k
フツーのIT女子が、 Engineering Managerになるまで
navitimejapan
PRO
3
270
不確実性に打ち勝つOKR戦略/How to manage uncertainty with OKR strategy
navitimejapan
PRO
4
3.4k
アジャイルを小さいままで 組織に広める 二周目 / Agile Transformation in NAVITIME JAPAN iteration 2
navitimejapan
PRO
4
1.3k
変更障害率0%よりも「継続的な学習と実験」を価値とする 〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜 / DevOps Transformation in NAVITIME JAPAN
navitimejapan
PRO
7
5.4k
Other Decks in Technology
See All in Technology
Two Blades, One Journey: Engineering While Managing
ohbarye
4
2.3k
"TEAM"を導入したら最高のエンジニア"Team"を実現できた / Deploying "TEAM" and Building the Best Engineering "Team"
yuj1osm
1
220
Exadata Database Service on Cloud@Customer セキュリティ、ネットワーク、および管理について
oracle4engineer
PRO
2
1.5k
急成長する企業で作った、エンジニアが輝ける制度/ 20250227 Rinto Ikenoue
shift_evolve
0
180
E2Eテスト自動化入門
devops_vtj
1
100
Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ
j2yano
0
130
技術スタックだけじゃない、業務ドメイン知識のオンボーディングも同じくらいの量が必要な話
niftycorp
PRO
0
120
2/18 Making Security Scale: メルカリが考えるセキュリティ戦略 - Coincheck x LayerX x Mercari
jsonf
0
240
AWSアカウントのセキュリティ自動化、どこまで進める? 最適な設計と実践ポイント
yuobayashi
7
850
AWS Well-Architected Frameworkで学ぶAmazon ECSのセキュリティ対策
umekou
2
150
開発組織を進化させる!AWSで実践するチームトポロジー
iwamot
2
480
LINE NEWSにおけるバックエンド開発
lycorptech_jp
PRO
0
320
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
21
2.5k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
GraphQLの誤解/rethinking-graphql
sonatard
69
10k
GitHub's CSS Performance
jonrohan
1030
460k
What's in a price? How to price your products and services
michaelherold
244
12k
Automating Front-end Workflow
addyosmani
1369
200k
KATA
mclloyd
29
14k
The World Runs on Bad Software
bkeepers
PRO
67
11k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Transcript
オンデマンドインスタンスを 極限まで減らしたらこうなった 株式会社ナビタイムジャパン 田中 一樹
自己紹介 田中 一樹(たなかかずき) 株式会社ナビタイムジャパン • 2013年新卒入社 • 2017年〜クラウド担当
ナビタイムジャパンのAWS利用
AWS利用が増えるに連れ費用が爆増
バックエンド構成 AppServer API Server 経路探索 Server 地図配信 Server データ
サーバ系はECSで運用=EC2費用が爆増
よくある話
よくある話 ECSからFargateに移行したら安くなった!
よくある話 ECSからFargateに移行したら安くなった! Fargate使ったらインスタンスの管理しなくて良 くなった!
よくある話 ナビタイムジャパンではFargate使ってません
よくある話 ナビタイムジャパンではFargate使ってません 使えなかった
• ストレージが10GB ⇒地図データ/探索データでそれぞれ数十GB必要 Fargateを使うと
Fargateを使うと • ストレージが10GB ⇒地図データ/探索データでそれぞれ数十GB必要 • ECSのときと必要な台数が変わらない ⇒約1.2倍・・・費用がかさむ・・・
Fargateを使うと • ストレージが10GB ⇒地図データ/探索データでそれぞれ数十GB必要 • ECSのときと必要な台数が変わらない ⇒約1.2倍・・・費用がかさむ・・・ • 社内で移行が進んできたが、障害時の調査においてクラ ウドネイティブにはなってない
⇒調査に時間がかかりそう=運用工数Up
もう、EC2の費用を下げるしかない・・・ 可用性を下げて台数減らす・・・?
もう、EC2の費用を下げるしかない・・・ 可用性を下げて台数減らす・・・? Reserved Instance Spot Instance
Reserved Instance & Spot Instance • EC2インスタンスと共生するには必須 • Reserved Instance
◦ 年間契約することで30%〜の割引 • Spot Instance ◦ 途中で落とされるリスクを許容することで90%〜の割 引
• ナビタイムジャパンでは毎年たくさん購入 ◦ RI Utilization:90%〜 ◦ RI Coverage:80%〜 • 確保しにくいインスタンスはAZごとに購入
Reserved Instance
• 価格はオンデマンドインスタンスの半分程度で入札 ◦ 最近高騰してなかったので • SpotFleetで管理 ◦ スケーリング条件をOndemandとは別に管理 ◦ 管理が面倒に
▪ うまくスケーリングしないことも・・・ Spot Instance
• 今まで ◦ Ondemand Instance:AutoScaling Groupで管理 ◦ Spot Instance:Spot Fleetで管理
面倒・・・ ◦ ASG/SpotFleetそれぞれでスケーリング条件を設定 ◦ 管理が煩雑 Reserved Instance & Spot Instance https://aws.amazon.com/jp/blogs/news/ec2-fleet-manage-thousands-of-on-demand-and-spot-instances-with-one-request/
• AutoScaling GroupでOndemandもSpotも起動可能 • Ondemandの台数、割合が指定できる ◦ オンデマンドベース ▪ 何台オンデマンドで起動するか ◦
オンデマンド割合 ▪ オンデマンドベースを超えた際に どれだけオンデマンドを 起動させるか EC2フリート
• インスタンスタイプも複数指定可能 ◦ 基本的に先頭から順に起動しようとする ◦ 万が一、先頭のインスタンスタイプが起動できなければ 後続のインスタンスタイプが選択される EC2フリート
EC2フリート良さそうや・・・ よし、Ondemand ZEROにしよう。
こうやった CPUベースでスケールアウトするので 同じコア数 先頭はRI購入したインスタンスタイプ
こうやった CPUベースでスケールアウトするので 同じコア数 先頭はRI購入したインスタンスタイプ オンデマンドベース =RI購入台数
こうやった CPUベースでスケールアウトするので 同じコア数 先頭はRI購入したインスタンスタイプ オンデマンドベース =RI購入台数 オンデマンド割合0% =RI購入分以外すべてSpot
こうやった CPUベースでスケールアウトするので 同じコア数 先頭はRI購入したインスタンスタイプ オンデマンドベース =RI購入台数 オンデマンド割合0% =RI購入分以外すべてSpot RI5台、Spot3台 Ondemand
ZERO!!!
結果 変更前 変更後 OnDemand が減った!!!!
結果 変更前 変更後 あれ・・・ 増えてる・・・?
• インスタンスタイプは極力先頭のインスタンスタイプで 起動しようとする ◦ 起動できないと後続のインスタンスタイプを使う ◦ RIで購入してないインスタンスタイプでOndemand 起動する可能性がある・・・ ◦ RIが指定できるようにして欲しい・・・
結果
• EC2フリートを使うことでRI+Spotだけの構成が簡単に作 れる • 予想外のOndemand Instance起動とかに注意 • ECSのDraining処理はちゃんと入れておく ◦ Spot
Instanceは余裕で落ちる ◦ 落ちたときのDraining処理とかはちゃんとしておく 参考)https://logmi.jp/tech/articles/320723 まとめ
ご清聴ありがとうございました