Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
オンデマンドインスタンスを極限まで減らしたらこうなった
Search
NAVITIME JAPAN
PRO
July 11, 2019
Technology
64
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
オンデマンドインスタンスを極限まで減らしたらこうなった
2019/07/11(木)開催の「X-Tech JAWS 【第8回】~時代を突き抜けるX-Tech企業の真髄~」にて発表した資料です。
NAVITIME JAPAN
PRO
July 11, 2019
More Decks by NAVITIME JAPAN
See All by NAVITIME JAPAN
株式会社ナビタイムジャパン 会社紹介資料2026
navitimejapan
PRO
1
5.6k
つよつよリーダーが 抜けたらどうする? 〜ナビタイムのAgile⽀援組織の変遷〜
navitimejapan
PRO
23
16k
実践ジオフェンス 効率的に開発するために
navitimejapan
PRO
3
1.2k
安全で使いやすいCarPlayアプリの 魅せ方:HIGと実例から学ぶ
navitimejapan
PRO
1
320
見えないユーザの声はログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~
navitimejapan
PRO
6
3.5k
ユーザーのためなら 『デザイン』 以外にも手を伸ばせる
navitimejapan
PRO
2
2k
フツーのIT女子が、 Engineering Managerになるまで
navitimejapan
PRO
3
510
不確実性に打ち勝つOKR戦略/How to manage uncertainty with OKR strategy
navitimejapan
PRO
4
4.2k
アジャイルを小さいままで 組織に広める 二周目 / Agile Transformation in NAVITIME JAPAN iteration 2
navitimejapan
PRO
4
1.6k
Other Decks in Technology
See All in Technology
Kiro Crewをはじめよう
kizawa2020
1
160
Browser Spec: Testing Hotwire with Ruby
takahashim
1
130
How to Design Configuration for Rails Applications
willnet
1
850
事業成長とデータ活用を止めないためのマネジメントへ挑戦
hiracky16
0
400
Post AI時代のリファクタリング実践記 / Refactoring in the post AI era
kaminashi
1
290
Gemini Intelligence 入門 ― AppFunctions と Gemini Nano
takuroabe
0
300
V8のArray.prototype.flatを最大約20倍速くするまでと、巨大OSSへの大規模コミットの道のり
riyaamemiya
0
310
野蛮なアジャイル [サイボウズ発!]組織の常識を覆した反骨のスクラム実践記 / Barbaric Agile - Enterprise Agile Study Group
ama_ch
0
100
SAENM ~Jupyterで残すPoCの試行錯誤、未来の自分と仲間を助ける記録!~
terapyon
0
120
スプシの手作業からの解脱 ~更新はClaude Codeに、見せ方と使い方はGASアプリに任せる~
kentarofujii
0
160
hackers_champloo_2026_tidb
makocchi
0
170
サブエージェントと Claude Mods で作る独自 Advisor ツールの話
kenichiodo
2
170
Featured
See All Featured
End of SEO as We Know It (SMX Advanced Version)
ipullrank
3
4.4k
KATA
mclloyd
PRO
35
16k
First, design no harm
axbom
PRO
2
1.3k
Speed Design
sergeychernyshev
33
2.2k
The browser strikes back
jonoalderson
0
1.8k
[RailsConf 2023] Rails as a piece of cake
palkan
59
7.1k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.7k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.6k
Test your architecture with Archunit
thirion
2
2.4k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
7k
Leo the Paperboy
mayatellez
10
2.4k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1.3k
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 まとめ
ご清聴ありがとうございました