Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
オンデマンドインスタンスを極限まで減らしたらこうなった
Search
NAVITIME JAPAN
PRO
July 11, 2019
Technology
0
41
オンデマンドインスタンスを極限まで減らしたらこうなった
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
870
安全で使いやすいCarPlayアプリの 魅せ方:HIGと実例から学ぶ
navitimejapan
PRO
1
250
見えないユーザの声はログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~
navitimejapan
PRO
6
3.2k
ユーザーのためなら 『デザイン』 以外にも手を伸ばせる
navitimejapan
PRO
2
1.7k
フツーのIT女子が、 Engineering Managerになるまで
navitimejapan
PRO
3
380
不確実性に打ち勝つOKR戦略/How to manage uncertainty with OKR strategy
navitimejapan
PRO
4
3.7k
アジャイルを小さいままで 組織に広める 二周目 / Agile Transformation in NAVITIME JAPAN iteration 2
navitimejapan
PRO
4
1.4k
変更障害率0%よりも「継続的な学習と実験」を価値とする 〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜 / DevOps Transformation in NAVITIME JAPAN
navitimejapan
PRO
8
5.7k
Other Decks in Technology
See All in Technology
エンジニアリングマネージャー はじめての目標設定と評価
halkt
0
290
EM歴1年10ヶ月のぼくがぶち当たった苦悩とこれからへ向けて
maaaato
0
280
文字列の並び順 / Unicode Collation
tmtms
3
590
MapKitとオープンデータで実現する地図情報の拡張と可視化
zozotech
PRO
1
140
2025年 開発生産「可能」性向上報告 サイロ解消からチームが能動性を獲得するまで/ 20251216 Naoki Takahashi
shift_evolve
PRO
1
180
初めてのDatabricks AI/BI Genie
taka_aki
0
180
AWS CLIの新しい認証情報設定方法aws loginコマンドの実態
wkm2
6
740
regrowth_tokyo_2025_securityagent
hiashisan
0
250
プロンプトやエージェントを自動的に作る方法
shibuiwilliam
11
9.2k
業務のトイルをバスターせよ 〜AI時代の生存戦略〜
staka121
PRO
2
200
Database イノベーショントークを振り返る/reinvent-2025-database-innovation-talk-recap
emiki
0
190
大企業でもできる!ボトムアップで拡大させるプラットフォームの作り方
findy_eventslides
1
790
Featured
See All Featured
Faster Mobile Websites
deanohume
310
31k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Code Review Best Practice
trishagee
74
19k
4 Signs Your Business is Dying
shpigford
186
22k
Bootstrapping a Software Product
garrettdimon
PRO
307
120k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Done Done
chrislema
186
16k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.8k
Site-Speed That Sticks
csswizardry
13
1k
Scaling GitHub
holman
464
140k
A Tale of Four Properties
chriscoyier
162
23k
GraphQLとの向き合い方2022年版
quramy
50
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 まとめ
ご清聴ありがとうございました