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
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
NAVITIME JAPAN
PRO
July 11, 2019
Technology
0
45
オンデマンドインスタンスを極限まで減らしたらこうなった
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
23
16k
実践ジオフェンス 効率的に開発するために
navitimejapan
PRO
3
930
安全で使いやすいCarPlayアプリの 魅せ方:HIGと実例から学ぶ
navitimejapan
PRO
1
260
見えないユーザの声はログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~
navitimejapan
PRO
6
3.2k
ユーザーのためなら 『デザイン』 以外にも手を伸ばせる
navitimejapan
PRO
2
1.8k
フツーのIT女子が、 Engineering Managerになるまで
navitimejapan
PRO
3
400
不確実性に打ち勝つOKR戦略/How to manage uncertainty with OKR strategy
navitimejapan
PRO
4
3.8k
アジャイルを小さいままで 組織に広める 二周目 / Agile Transformation in NAVITIME JAPAN iteration 2
navitimejapan
PRO
4
1.5k
変更障害率0%よりも「継続的な学習と実験」を価値とする 〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜 / DevOps Transformation in NAVITIME JAPAN
navitimejapan
PRO
8
5.9k
Other Decks in Technology
See All in Technology
AWS DevOps Agent x ECS on Fargate検証 / AWS DevOps Agent x ECS on Fargate
kinunori
2
230
外部キー制約の知っておいて欲しいこと - RDBMSを正しく使うために必要なこと / FOREIGN KEY Night
soudai
PRO
12
5.6k
Oracle AI Database移行・アップグレード勉強会 - RAT活用編
oracle4engineer
PRO
0
110
Kiro IDEのドキュメントを全部読んだので地味だけどちょっと嬉しい機能を紹介する
khmoryz
0
210
ブロックテーマでサイトをリニューアルした話 / 2026-01-31 Kansai WordPress Meetup
torounit
0
480
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
10k
AIエージェントに必要なのはデータではなく文脈だった/ai-agent-context-graph-mybest
jonnojun
1
250
Claude Code for NOT Programming
kawaguti
PRO
1
110
1,000 にも届く AWS Organizations 組織のポリシー運用をちゃんとしたい、という話
kazzpapa3
0
190
Ruby版 JSXのRuxが気になる
sansantech
PRO
0
170
予期せぬコストの急増を障害のように扱う――「コスト版ポストモーテム」の導入とその後の改善
muziyoshiz
1
2.1k
こんなところでも(地味に)活躍するImage Modeさんを知ってるかい?- Image Mode for OpenShift -
tsukaman
1
170
Featured
See All Featured
Designing for humans not robots
tammielis
254
26k
The Pragmatic Product Professional
lauravandoore
37
7.1k
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
1
58
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.4k
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
96
Design in an AI World
tapps
0
150
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
0
160
エンジニアに許された特別な時間の終わり
watany
106
230k
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
1
1.4k
Code Reviewing Like a Champion
maltzj
527
40k
Site-Speed That Sticks
csswizardry
13
1.1k
Thoughts on Productivity
jonyablonski
74
5k
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 まとめ
ご清聴ありがとうございました