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
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
15k
実践ジオフェンス 効率的に開発するために
navitimejapan
PRO
3
800
安全で使いやすいCarPlayアプリの 魅せ方:HIGと実例から学ぶ
navitimejapan
PRO
1
240
見えないユーザの声はログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~
navitimejapan
PRO
6
3.1k
ユーザーのためなら 『デザイン』 以外にも手を伸ばせる
navitimejapan
PRO
2
1.6k
フツーのIT女子が、 Engineering Managerになるまで
navitimejapan
PRO
3
370
不確実性に打ち勝つOKR戦略/How to manage uncertainty with OKR strategy
navitimejapan
PRO
4
3.6k
アジャイルを小さいままで 組織に広める 二周目 / Agile Transformation in NAVITIME JAPAN iteration 2
navitimejapan
PRO
4
1.3k
変更障害率0%よりも「継続的な学習と実験」を価値とする 〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜 / DevOps Transformation in NAVITIME JAPAN
navitimejapan
PRO
7
5.7k
Other Decks in Technology
See All in Technology
OPENLOGI Company Profile for engineer
hr01
1
46k
Amazon Athena で JSON・Parquet・Iceberg のデータを検索し、性能を比較してみた
shigeruoda
1
230
AIを使ってテストを楽にする
kworkdev
PRO
0
280
アノテーション作業書作成のGood Practice
cierpa0905
PRO
0
300
SRE × マネジメントレイヤーが挑戦した組織・会社のオブザーバビリティ改革 ― ビジネス価値と信頼性を両立するリアルな挑戦
coconala_engineer
0
300
データとAIで明らかになる、私たちの課題 ~Snowflake MCP,Salesforce MCPに触れて~ / Data and AI Insights
kaonavi
0
150
RemoteFunctionを使ったコロケーション
mkazutaka
1
150
dbtとAIエージェントを組み合わせて見えたデータ調査の新しい形
10xinc
7
1.5k
Retrospectiveを振り返ろう
nakasho
0
130
組織全員で向き合うAI Readyなデータ利活用
gappy50
5
1.7k
AWSが好きすぎて、41歳でエンジニアになり、AAIを経由してAWSパートナー企業に入った話
yama3133
2
190
20251027_findyさん_音声エージェントLT
almondo_event
2
500
Featured
See All Featured
How GitHub (no longer) Works
holman
315
140k
The Cost Of JavaScript in 2023
addyosmani
55
9.1k
Raft: Consensus for Rubyists
vanstee
140
7.2k
Facilitating Awesome Meetings
lara
57
6.6k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.7k
VelocityConf: Rendering Performance Case Studies
addyosmani
333
24k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
How to Think Like a Performance Engineer
csswizardry
27
2.1k
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
RailsConf 2023
tenderlove
30
1.3k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
116
20k
Fireside Chat
paigeccino
41
3.7k
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 まとめ
ご清聴ありがとうございました