【Ltech#10】LIFULL HOME'S のAWSアカウントに Savings Plans を導⼊した話

LIFULL HOME'S のAWSアカウントに
Savings Plans を導⼊した話
Ltech #10 2020/01/28
株式会社LIFULL
鈴⽊健太郎
https://lifull.connpass.com/event/161930/

© LIFULL Co.,Ltd. 本書の無断転載、複製を固く禁じます。2
⾃⼰紹介
鈴⽊健太郎 | @szk3
2008年中途⼊社。『HOMEʻS』の不動産売
買カテゴリの追加開発、技術リーダーを経
て、iPhoneアプリの新規開発・メジャー
バージョンアップ、現『HOMEʻS』PCサイ
トの初期開発を担当。その後、パブリック
クラウドサービスのフィジビリティを担当
しAWS移⾏を牽引。現在は社内ソリュー
ションアーキテクト活動とAWSコスト最適
化に従事。
twitter note

⾃⼰紹介

はじめに

Savings Plans (SPs) とは?
ref: https://aws.amazon.com/jp/blogs/news/new-savings-plans-for-aws-compute-services/

ref: https://aws.amazon.com/jp/blogs/news/new-savings-plans-for-aws-compute-services/
AWSさんも⾃信有り👍

AWS の割引オプションのひとつ
• 構成変更不要で、コスト効果が⾼い
• EC2 / Fargate の利⽤料⾦を年間コミット
• ”最⼤”72% のコスト削減
• RIより柔軟性が⾼い

やば、神プランなの🤭

神プランだけど。。。
でも、導⼊はそんなに簡単ではなかった。

導⼊までの壁
導⼊までの壁
実際に購⼊しようしたら様々な障壁が… 
1. 精緻なコスト削減額の⾒積もりが不可能
2. ⼀括請求環境だと、各AWSアカウントごと
の推奨事項が⾒れない
3. RIリプレイス⽤途だと考慮することが多い

壁１
精緻なコスト削減額の⾒積もりが不可能
• 多様なインスタンスタイプが混在し、それ
らがオートスケールするような場合、割引
率が変動する
• 社内⼿続き（稟議など）で、費⽤対効果を
記述する場合、精緻なコスト削減幅を記述
することができない

壁２
⼀括請求(コンソリデートビリング)環境だと、
各AWSアカウントごとの推奨事項が⾒れない
• アカウントの予算管理が各サービス主管部
⾨ごとの場合、各アカウントごとにコミッ
ト⾦額を試算する必要があった

壁３
RIリプレイス⽤途には考慮が必要
• 切れるRIのオンデマンドコスト換算
• RIが切れるタイミングは、リソース最適化
チャンス
• インスタンスファミリーを変えたいとい
う要望が上がってくる

つまり、コミット⾦額が 
⾒積もりしづらい😢

今⽇の話

© LIFULL Co.,Ltd. 本書の無断転載、複製を固く禁じます。
LIFULL HOMEʼS の AWSアカウントに
Savings Plans (SPs) を適⽤した話
• SPs 導⼊までの道筋
• 導⼊して起きたこと
16
今⽇の話

ちょっと待って。

そのSPs、本当に必要ですか？🤔

そのSPs、本当に必要ですか？
アーキテクチャ変更を⾒据えてますか？
• EC2 使い続けますか？
• コンテナ化の計画はありませんか？
• マネージドサービスへの移⾏は？
• lambdaで⼗分じゃないですか？
• 落とす予定はありませんか？

他のコスト最適化は検討しましたか？
• Spot インスタンス使えませんか？
• Instance Scheduler が使えませんか？
• 不必要に⼤きいインスタンスはありません
か？
• その利⽤だと RIが適してませんか？

SPsが、たとえ神プランだとしても
• 何も考えず買えばいいってもんじゃない
• EC2 使い続けますか？
• Spot / Instance Scheduler 使えません
か？
• RI で⼗分じゃないですか？
• 何事もご利⽤は計画的に
• 基本的にキャンセルはできません

SPs 導⼊までの道筋

導⼊までの道のり
こんな流れがオススメ
• SPs に対する理解を深める
• プランを決める
• 稟議に必要な情報を集める
• コミット⾦額を決める
次のSPs購⼊担当は⾃分とは限らないので、
可能な限りのドキュメント化を推奨

SPsに対する理解を深める

なぜ必要？
• プラン / オプショ
ンを適切に選択で
きるようにする
• ステークホルダー
に説明責任がある
• 導⼊⽬的を明確に
するため

実態に沿った割引率を確認する
• ”最⼤”72%を鵜呑みにしない
26
ref: https://aws.amazon.com/jp/savingsplans/pricing/
割引率は、契約期間と
リージョンに大きく依存

SPsは適⽤範囲が広いので俯瞰できると便利
27

よく利⽤するインスタンスの傾向がわかる
28
r系は1年/3年ともに
コスパ良し
m3系1年のコスパ良し
3年との差分は低め
c系はコスパ低め

プランを決める

SPsに求めるものを明確にする
• 適⽤範囲(柔軟性)と割引率はトレードオフ
• 柔軟性を優先して、コスト最適化にかかる
⼈件費を下げるとか
• 割引率を優先して、最⼤限のコスト最適化
を狙うとか

割引率が⾼い割引率が低い
コスト最適化の
適⽤範囲が広い
適⽤範囲が狭い
Compute
Savings Plans
Reserved
Instance
(スタンダード)
Reserved
Instance
(コンバーチブル)
※適⽤範囲変更には⼿間がかかる
EC2
Savings Plans

割引率が⾼い割引率が低い
適⽤範囲が広い
適⽤範囲が狭い
Compute
Savings Plans
Reserved
Instance
(スタンダード)
Reserved
Instance
(コンバーチブル)
EC2
Savings Plans
将来の変更に強い
リソース割引率が⾼い
※ インスタンスファミリー
の変更前提
継続期間(1年/3年)は、
期間中の脱EC2の可能性と
割引率がトレードオフ
※適⽤範囲変更には⼿間がかかる

迷ったら、Compute SPsの1年を選ぶ
（個⼈的なオススメ）

オススメの理由
• Computeなら適⽤範囲が広い
• インスタンスファミリーを越境
• 旧世代インスタンスの変更可能性を維持
できる
• 契約期間が1年なら
• 変更へのリスクテイクしやすい
• イニシャルコストが⽤意しやすい

稟議で必要な情報の洗い出し

• 情報をまとめる
• 購買フロー
• 費⽤対効果
• 予算部署
• ステークホルダー
• 証憑のとり⽅
慣れない⼈にとって、
稟議はコスト⾼

SPsやRIは⾼額になりがち。
なので、稟議が必要になるケースが多い
• ⾦額次第で決済・承認者が変わるケースは
よくあるので、ステークホルダーは抑えて
おく
• 稟議に書く内容は部署ごとに変わるケース
はほぼないので、テンプレ化しておくと便
利
• RI購⼊にも応⽤できる

テンプレ化しておき、変数を
埋めてもらう感じにすると楽

コミット⾦額の決め⽅

⼤きくわけて2つ
• AWSさんにお願いする
• ⾃分で⾒積もる
• AWS Pricing calculator を利⽤する
• Cost Explorer を利⽤する
• Cost Usages and Report (CUR) を利⽤
する

⼤きくわけて2つ
• AWSさんにお願いする
• ⾃分で⾒積もる
• AWS Pricing calculator を利⽤する
• Cost Explorer を利⽤する
• Cost Usages and Report (CUR) を利⽤
する
今回の話はここ

まずはコスト可視化のツールを整える
• Cost Explorer で時間単位表⽰を有効化
• Cost and Usage Report (CUR) を
Athena で分析

Cost Explorer で、時間とリソースレベルの詳
細度をオプトインしておく
https://aws.amazon.com/jp/about-aws/whats-new/2019/11/aws-cost-explorer-supports-hourly-resource-level-granularity/

Cost and Usage Report (CUR) をAthenaで分
析できるようにしておく
https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/setting-up-athena.html

ツールをどう使うか？
• Cost Explorer
• SPs 推奨事項を使う
• 時間単位のEC2オンデマンドコストを基
準にざっくり決める
• CUR + Athena + Solver
• 抽出した時間単位のEC2オンデマンドコ
ストに対して、Excelアドイン「Solver」
を使う

• Cost Explorer
ストに対して、Excelアドイン
「Solver」を使う

Cost Explorer を使う
SPs 推奨事項を使う
• ⼀番⽣産性が⾼い（簡単、早い）
• 基準の期間が重要
7⽇、30⽇、60
⽇から基準にする
期間を選択する

時間単位のEC2オンデマンドコストを基準に
ざっくり決める
• コスト削減にあまり時間をかけたくないと
きにオススメ
• ただし最⼤2週間前までのデータが参考値
• 時間単位の最低⾦額を基準に割引(想定)を引
いた額でコミットする
• やや安全⽬にコミットし、買い増し推奨

例）時間単位の最低⾦額ラインを$10と仮定
し割引率(想定)を25%と置くと$7.5がコミッ
トライン。そこからコミット割れリスクとし
て1$を引いて、$6.5をコミットする
49
$10：時間単位の最低⾦額
$6.5 : コミット⾦額

割引率(想定)やコミット割れリスクはどうやっ
て決めるの？
• 割引率は、SPsのプランと動いているインス
タンスを確認すればおおよそ概算できる
• コミット割れリスクは、買い増し前提での
調整バッファなので、コミット⾦額の⼤き
さに⽐例させて⼤きく取ったり⼩さく取っ
たりすればよい

• CostExplorer
ストに対して、Excelアドイン
「Solver」を使う

Cost Usage and Report (CUR) + Athena + Solver を使う
時間単位のEC2オンデマンドコストを抽出し、
Excelアドイン「Solver」を使う
• ⻑期間を対象する推奨コミット⾦額を算出
したい場合や、RIのリプレイス時に有効
• Amazon Athenaで参考範囲の時間単位EC2
オンデマンドコストを抽出
• 割引率を変数に、Solverで推奨コミット⾦
額を計算する

Cost Usage and Report (CUR) + Athena + Solver を使う
Solverとは
• What-If 分析⽤途
• 制約(制限)下の最
適値を算出する
ツール
https://support.ofﬁce.com/ja-jp/article/
%E3%82%BD%E3%83%AB%E3%83%90%E3%83%BC
%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6
%E5%95%8F%E9%A1%8C%E3%82%92%E5%AE%9A
%E7%BE%A9%E3%81%97%E3%80%81%E8%A7%A3
%E6%B1%BA%E3%81%99%E3%82%8B-5d1a388f-079
d-43ac-a7eb-f63e45925040

Cost Usage and Report (CUR) を使う
• Athenaで対象範囲の時間辺りのコストを抽出
し、csvファイルでDownloadする
※RIのオンデマンド換算コストが必要な場合、
抽出は各自のコンテキストで工夫する必要がある

• CUR(csv)に対しSolverを利⽤するための準備
割引率を決める
※現実的な値をいれること
CUR

• セルの関係性
=$B$1/(1-$B$3)
=$B+$C =MAX(0,$D-$B$3)
=$J$1 + $J$2
=$B$1*24*365
=SUM($E)

• ソルバーでコミット⾦額を算出
=$B+$C =MAX(0,$D-$B$3)
⽬的セルを、年間
コスト合計額に。
変数セルを、コミット⾦額に。

※ 留意事項
• 割引率はあくまでも想定
• Solverの計算結果は鵜呑みにせず、計算結
果のコミット⾦額から少し少なめにコミッ
トするのが安全でオススメ
• ⼀括請求であれば、仮に買いすぎたとして
も、他のアカウントに恩恵が移るだけなの
で、全体でみれば問題ないことが多い

コミット⾦額の決め⽅ (まとめ）

コミット⾦額は、
• 推奨項⽬が使えるなら、それが⼀番コスト
最適化に対する⽣産性が⾼い
• ⾃分でがんばるなら、計算にちょっとだけ
コツがいる
• がんばって推奨⾦額を算出するのもありだ
が、検討しすぎず、買い増し前提でコミッ
トするほうが最適化に対する⽣産性は⾼い

コミット⾦額は、
• 必ずしも買いすぎ == 悪ではない。
• ⼀括請求であれば他アカウントに適⽤
• オンデマンドコストの変動が激しい場
合、時間単位で使い切れない時間があっ
たとしても、他の時間での割引効果が⾼
いのであれば、トータルではコストは下
がる
• 困ったらAWSさんに相談に乗ってもらおう

導⼊して起きたこと

導⼊しておきたこと
実例１
• いい感じに最適化された😆
実例２
• コスト最適化の⽟突き🤔

実例１

いい感じに最適化された😆
うまくいったパターン
• CUR + Athena + Solverを使ってコミット
⾦額を算出
• 全体的に古いインスタンスが多かったの
で、⽐較的割引率が⾼くなった
• インスタンスタイプに依存せず、きれいに
最適化された

いい感じに最適化された😆
SPsの柔軟性が効果的に効いている
• インスタンスタイプに依存しない最適化
SPs 購⼊のタイミング

実例２

とあるアカウントで、SPsを買い増したらコ
ミット⾦額を使い切れない時間帯が出てる
• 安全⽬にコミットしたはずなのに。。。
68
コスト最適化の⽟突き🤔
SPs 買い増し
コミットを使いきれてない?

オンデマンドコストが減ってるのはなぜ？🤔
• アカウントの管理者に確認
• アーキテクチャ変更しました？
• オンデマンドEC2落としました？
• RI / Spot とか他の最適化しました？
全部、⼼当たりがないとのこと

Cost Explorer を再度確認
• あれ？RIの適⽤が増えてる？
• でも、RIは買ってない
あきらかにRIの適⽤が増えている

わかった😮💡

関係各所に確認すると
• とあるアカウントで、アーキテクチャ変更
に伴い、インスタンスが停⽌された
• そのインスタンスにはRIが適⽤されてお
り、アカウント内でそのRIを利⽤するイン
スタンスはなかった

つまり、SPsの買い増し後
• 他アカウントで余ったRIが分配される
• RIが先に適⽤されるため、SPsを適⽤するた
めのオンデマンドコストがなくなる
• コミット⾦額が使い切れない状態が発⽣
• 使い切れないコミットはまた別のアカウン
トへ

コスト最適化の⽟突きが発⽣
74
アカウントA アカウントB アカウントC
RI余ったから
使ってよ
SPs余ったから
使ってよ
RI適⽤したら、
SPs余ったな
Savings
Plans
Reserved
Instance
Reserved
Instance
Savings
Plans
EC2落としたら、
RI余ったな
コスト浮いた
💰 💰 💰

SPsが余った場合、RI同様に⼀括請求された他
のアカウントに適⽤されるため組織全体として
無駄になるリスクはほぼない
• ただし、アカウントとして使われてないこ
とは確かなので、アカウント担当部署(予算
管轄)において、削減効果をどういう扱いに
するのかは確認しておいたほうがいい。
75

まとめ

まとめ
Savings Plans (SPs) とは、
• 簡単にコストを下げられる
• 極論、コミット⾦額決めて買うだけ
• コミット⾦額を決めるのは、慣れれば難し
くない
• プランの性質にあわせて、柔軟なコスト最
適化が可能

まとめ
コスト最適化のマネージドサービス🤖

まとめ
将来の変更に対して柔軟で強い💪

まとめ
コスト最適化の⼈件費さえも低減↘

やば、やっぱり神プランだった🤭

Happy Saving Cost !

ありがとうございました

【Ltech#10】LIFULL HOME'S のAWSアカウントに Savings Plans を導⼊した話

Recommended

Recommended

More Related Content

Similar to 【Ltech#10】LIFULL HOME'S のAWSアカウントに Savings Plans を導⼊した話

Similar to 【Ltech#10】LIFULL HOME'S のAWSアカウントに Savings Plans を導⼊した話 (20)

More from LIFULL Co., Ltd.

More from LIFULL Co., Ltd. (20)

【Ltech#10】LIFULL HOME'S のAWSアカウントに Savings Plans を導⼊した話