Slide 1

Slide 1 text

オンデマンドインスタンスを 極限まで減らしたらこうなった 株式会社ナビタイムジャパン 田中 一樹

Slide 2

Slide 2 text

自己紹介 田中 一樹(たなかかずき) 株式会社ナビタイムジャパン ● 2013年新卒入社 ● 2017年〜クラウド担当

Slide 3

Slide 3 text

ナビタイムジャパンのAWS利用

Slide 4

Slide 4 text

AWS利用が増えるに連れ費用が爆増

Slide 5

Slide 5 text

バックエンド構成 AppServer API Server 経路探索 Server 地図配信 Server データ

Slide 6

Slide 6 text

サーバ系はECSで運用=EC2費用が爆増

Slide 7

Slide 7 text

よくある話

Slide 8

Slide 8 text

よくある話 ECSからFargateに移行したら安くなった!

Slide 9

Slide 9 text

よくある話 ECSからFargateに移行したら安くなった! Fargate使ったらインスタンスの管理しなくて良 くなった!

Slide 10

Slide 10 text

よくある話 ナビタイムジャパンではFargate使ってません

Slide 11

Slide 11 text

よくある話 ナビタイムジャパンではFargate使ってません 使えなかった

Slide 12

Slide 12 text

● ストレージが10GB ⇒地図データ/探索データでそれぞれ数十GB必要 Fargateを使うと

Slide 13

Slide 13 text

Fargateを使うと ● ストレージが10GB ⇒地図データ/探索データでそれぞれ数十GB必要 ● ECSのときと必要な台数が変わらない ⇒約1.2倍・・・費用がかさむ・・・

Slide 14

Slide 14 text

Fargateを使うと ● ストレージが10GB ⇒地図データ/探索データでそれぞれ数十GB必要 ● ECSのときと必要な台数が変わらない ⇒約1.2倍・・・費用がかさむ・・・ ● 社内で移行が進んできたが、障害時の調査においてクラ ウドネイティブにはなってない ⇒調査に時間がかかりそう=運用工数Up

Slide 15

Slide 15 text

もう、EC2の費用を下げるしかない・・・ 可用性を下げて台数減らす・・・?

Slide 16

Slide 16 text

もう、EC2の費用を下げるしかない・・・ 可用性を下げて台数減らす・・・? Reserved Instance Spot Instance

Slide 17

Slide 17 text

Reserved Instance & Spot Instance ● EC2インスタンスと共生するには必須 ● Reserved Instance ○ 年間契約することで30%〜の割引 ● Spot Instance ○ 途中で落とされるリスクを許容することで90%〜の割 引

Slide 18

Slide 18 text

● ナビタイムジャパンでは毎年たくさん購入 ○ RI Utilization:90%〜 ○ RI Coverage:80%〜 ● 確保しにくいインスタンスはAZごとに購入 Reserved Instance

Slide 19

Slide 19 text

● 価格はオンデマンドインスタンスの半分程度で入札 ○ 最近高騰してなかったので ● SpotFleetで管理 ○ スケーリング条件をOndemandとは別に管理 ○ 管理が面倒に ■ うまくスケーリングしないことも・・・ Spot Instance

Slide 20

Slide 20 text

● 今まで ○ 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/

Slide 21

Slide 21 text

● AutoScaling GroupでOndemandもSpotも起動可能 ● Ondemandの台数、割合が指定できる ○ オンデマンドベース ■ 何台オンデマンドで起動するか ○ オンデマンド割合 ■ オンデマンドベースを超えた際に どれだけオンデマンドを 起動させるか EC2フリート

Slide 22

Slide 22 text

● インスタンスタイプも複数指定可能 ○ 基本的に先頭から順に起動しようとする ○ 万が一、先頭のインスタンスタイプが起動できなければ 後続のインスタンスタイプが選択される EC2フリート

Slide 23

Slide 23 text

EC2フリート良さそうや・・・ よし、Ondemand ZEROにしよう。

Slide 24

Slide 24 text

こうやった CPUベースでスケールアウトするので 同じコア数 先頭はRI購入したインスタンスタイプ

Slide 25

Slide 25 text

こうやった CPUベースでスケールアウトするので 同じコア数 先頭はRI購入したインスタンスタイプ オンデマンドベース =RI購入台数

Slide 26

Slide 26 text

こうやった CPUベースでスケールアウトするので 同じコア数 先頭はRI購入したインスタンスタイプ オンデマンドベース =RI購入台数 オンデマンド割合0% =RI購入分以外すべてSpot

Slide 27

Slide 27 text

こうやった CPUベースでスケールアウトするので 同じコア数 先頭はRI購入したインスタンスタイプ オンデマンドベース =RI購入台数 オンデマンド割合0% =RI購入分以外すべてSpot RI5台、Spot3台 Ondemand ZERO!!!

Slide 28

Slide 28 text

結果 変更前 変更後 OnDemand が減った!!!!

Slide 29

Slide 29 text

結果 変更前 変更後 あれ・・・ 増えてる・・・?

Slide 30

Slide 30 text

● インスタンスタイプは極力先頭のインスタンスタイプで 起動しようとする ○ 起動できないと後続のインスタンスタイプを使う ○ RIで購入してないインスタンスタイプでOndemand 起動する可能性がある・・・ ○ RIが指定できるようにして欲しい・・・ 結果

Slide 31

Slide 31 text

● EC2フリートを使うことでRI+Spotだけの構成が簡単に作 れる ● 予想外のOndemand Instance起動とかに注意 ● ECSのDraining処理はちゃんと入れておく ○ Spot Instanceは余裕で落ちる ○ 落ちたときのDraining処理とかはちゃんとしておく 参考)https://logmi.jp/tech/articles/320723 まとめ

Slide 32

Slide 32 text

ご清聴ありがとうございました