AWS Startup Tech Meetup #013 で発表した資料です。 AWS コスト削減をする前におさえておきたい考え方を整理しました。 https://awsstartuptechmeetuptokyo13.splashthat.com/
AWSコスト削減をする前に読むスライドAWS Startup Tech Meetup #13@katsuhisa__ / 北野 勝久Copyright (C) 2018 Studist Corporation. All Rights Reserved
View Slide
#AWSLoft
● 北野 勝久 / @katsuhisa__● SRE @ Studist Corporation● Organizer of SRE Lounge/ Rails Developers Meetup● Developers Summit,/ July Tech Festa 登壇 etc.● Linux カーネルと同い年
マニュアル作成・共有プラットフォーム
今回の経緯
AWS で開催される勉強会ですが…AWS のコストをガンガン削ったお話を持ってきました！！！！！！
今日の主題AWS のコストをガンガン削る
AWS でコスト削減といえば
Reserved Instance ?
その前にやることはたくさんある！！！！！！
Agenda1. コスト削減の原理原則2. コスト削減前夜3. 現状分析と方針策定4. 見積もりと検証の話5. まとめ
コスト削減の原理原則
さて、明日からコスト削減…
たぶんできない
「サイズいきなり落として、性能障害起きない？」「そのインスタンス、勝手に落としちゃまずくね？」「なぜかこれまで動いていた処理が動かなくなった…」
原理原則1モニタリングして現状分析が必要
よーし、モニタリングできた。コストカットするぞー。
ちょっと待った。そのままやっても大して成果出ないっすよ。
なぜか● 過去のシステム管理者は、意味もなくサイズアップしてないはずだから● 何かの問題があり、解決するためにサイズを上げたはず● つまり、何も考えずにサイズを落とすと何か起こると考えるほうが自然
原理原則2事前調査と想像力だいじ
いろいろ調べた結果…ある問題を解決しないとダウンサイズできないようだ！
その問題、インフラだけで対処できなくね？
よくあること● アプリケーションのチューニングしないと解決できない問題を短期的に札束で解決していた● サービスローンチ以降、改修せずに、無駄がない処理だけのサービスなんて存在しない（と思う。）
原理原則3インフラチームだけでコスト削減は完結しない
アプリケーションの改修もしたついにコスト削減だーサイズ落とすぞー
本当にだいじょうぶ？
「適切な見積もりできてる？」「実は関係ない指標みてない？」「見積もりに自信あっても、万が一のために検証した？」
原理原則4マシンの気持ちになって考える
ふー、コスト削減できた…おれは天才だ…こんなに無駄があったのか、信じられないぜ…
ダメぜったい！
なぜコスト削減できるのか● 今たまたまコスト削減に意識を向けるフェーズにたどり着いただけに過ぎない● 昔の人がわざわざ無駄を生んだわけではない● 過去へのリスペクトは常にだいじ
原理原則5人の気持ちになって考える
コスト削減の原理原則1. モニタリングして現状分析が必要2. 事前調査と想像力だいじ3. インフラチームだけでコスト削減は完結しない4. マシンの気持ちになって考える5. 人の気持ちになって考える
コスト削減の原理原則1. モニタリングして現状分析が必要2. 事前調査と想像力だいじ3. インフラチームだけでコスト削減は完結しない4. マシンの気持ちになって考える5. 人の気持ちになって考えるコスト削減は、インフラ⇔アプリ, マシン⇔人を網羅する総合格闘技
コスト削減前夜
Monitoring
EC2 とりあえずこれだけは● ロードアベレージ● CPU● I/O● メモリ● ディスク
RDS とりあえずこれだけは● コネクション数● CPU● メモリ● スロークエリログの収集と可視化（閾値は、0.5s あたり）
Performance 改善
Performance 改善● Performance Working Group を運営した○ はてなさんの取り組みを真似した■ http://hatenacorp.jp/recruit/operation_engineer○ 開発部 複数チームからなるPrj.○ 定期的にパフォーマンス改善サイクルを回す場として運営
改善内容● バルクインサート化● 無駄なジョイン・ソートの撲滅● 0.5s 以上かかるスロークエリ 98 % 削減
改善内容● バルクインサート化● 無駄なジョイン・ソートの撲滅● 0.5s 以上かかるスロークエリ 98 % 削減DB まわりの処理改善が、システム負荷軽減に効いた→サイズを安心して落とせる状態に
現状分析
いろいろ考えた結果、神スプレッドシートをつくった
Why スプレッドシート ?● 現状のリソースを一覧化するだけならスプレッドシートでなくともよい● が、削除・変更理由や、変更後の情報を整理し、人間にレビューしてもらうことを考えると、スプレッドシートでがんばろうという気持ちに…
Why スプレッドシート ?● 現状のリソースを一覧化するだけならスプレッドシートでなくともよい● が、削除・変更理由や、変更後の情報を整理し、人間にレビューしてもらうことを考えると、スプレッドシートでがんばろうという気持ちに…きっと世の中にもっと良いやり方はあるだろう…
スプレッドシートの内容● サービス名（EC2, RDS, ElasticCache ...）● リソース名（EC2 の場合は、Name Tag）● 現行サイズ（c5.large, r5.large ...）● 削除フラグ● 変更フラグ○ 変更後サイズ● 削除 or 変更理由● レビュー
スプレッドシートの内容● サービス名（EC2, RDS, ElasticCache ...）● リソース名（EC2 の場合は、Name Tag）● 現行サイズ（c5.large, r5.large ...）● 削除フラグ● 変更フラグ○ 変更後サイズ● 削除 or 変更理由● レビューTrusted Advisor を参照し、対象の見極め変更後コストは、SIMPLE MONTHLY CALCULATORで計算すると楽
Trusted AdvisorAWS がリソース使用状況を見て、いい感じにコスト削減の提案を出してくれる
SIMPLE MONTHLY CALCULATOR←これを埋めると←これが出るhttps://calculator.s3.amazonaws.com/index.html
スプレッドシートの内容● サービス名（EC2, RDS, ElasticCache ...）● リソース名（EC2 の場合は、Name Tag）● 現行サイズ（c5.large, r5.large ...）● 削除フラグ● 変更フラグ○ 変更後サイズ● 削除 or 変更理由● レビュー記載したほうが良い。過去にスペックを決定した人がいる↓ちゃんと変更背景を残しておくべき
スプレッドシートの内容● サービス名（EC2, RDS, ElasticCache ...）● リソース名（EC2 の場合は、Name Tag）● 現行サイズ（c5.large, r5.large ...）● 削除フラグ● 変更フラグ○ 変更後サイズ● 削除 or 変更理由● レビュー記載したほうが良い。過去にスペックを決定した人がいる↓ちゃんと変更背景を残しておくべきCloudFormation / Terraform などでコード化できていれば、変更背景はより管理しやすいはず
スプレッドシートの内容● サービス名（EC2, RDS, ElasticCache ...）● リソース名（EC2 の場合は、Name Tag）● 現行サイズ（c5.large, r5.large ...）● 削除フラグ● 変更フラグ○ 変更後サイズ● 削除 or 変更理由● レビュー記載したほうが良い。過去にスペックを決定した人がいる↓ちゃんと変更背景を残しておくべきTerraform 導入の話は、またどこかで・・・
方針策定
方針策定1どこまでがんばるか決めておく
どこまでやるか● はじめに決めておかないと際限がない● うちの場合は、大まかには以下方針にした○ インスタンスファミリー: T■ 基本は、不要リソース削除のみ対応○ インスタンスファミリー: C, M, R ...■ サイズ変更まで対応
方針策定2完了フェーズを区切っておく
なぜ完了フェーズを区切るか● コスト削減は最優先にしにくい● 急遽割り込みタスクが入ると、中断しがち● あらかじめ完了フェーズと優先度を決めておくと「ここまで終わったら、その作業やります」を判断しやすい
方針策定3Reserved Instance 購入タイミングを意識する
Reserved Instance 購入タイミング● RI を購入すると、損益分岐を越えるまでは、使わないと損な状態が生まれる● 本当にやりたいことは RI を購入することではなく、最適なインスタンスサイズに変更すること○ RI 購入タイミングで、サイズ変更の判断が引きずられるのは本末転倒● とはいえ、後回しにしすぎると、「もっとはやく買っておけば…」ということに
Reserved Instance 購入タイミング● RI を購入すると、損益分岐を越えるまでは、使わないと損な状態が生まれる● 本当にやりたいことは RI を購入することではなく、最適なインスタンスサイズに変更すること○ RI 購入タイミングで、サイズ変更の判断が引きずられるのは本末転倒● とはいえ、後回しにしすぎると、「もっとはやく買っておけば…」ということに（余談）過去の利用履歴を見て、RI を自動購入するサービスがあるらしい
見積もりの話
https://blog.a-know.me/entry/2017/02/02/215641EC2サイズ変更時のメトリックの見方・考え方はこちらがオススメ
RDS の見積もり（Aurora MySQL）● CPU使用率● コネクション数○ max_connections デフォルト値を参照する● メモリ○ BUFFER POOL AND MEMORY
RDS の見積もり（Aurora MySQL）● CPU使用率● コネクション数○ max_connections デフォルト値を参照する● メモリ○ BUFFER POOL AND MEMORY専任のDBA がいる会社であれば、もっと多角的に分析できるはず性能検証で見積もり結果を検証することがだいじ
Redshift の見積もり● クエリ実行時間を俯瞰する○ 改善余地ありと感じるのであれば、分散キーとソートキーをチェック○ いずれも正しく選択できているのであれば、ノード数を変更&性能検証し、ノード数を決定● Redshift の最大のボトルネックは、ノードインターコネクトだと心得る
Redshift の見積もり● クエリ実行時間を俯瞰する○ 改善余地ありと感じるのであれば、分散キーとソートキーをチェック○ いずれも正しく選択できているのであれば、ノード数を変更&性能検証し、ノード数を決定● Redshift の最大のボトルネックは、ノードインターコネクトだと心得るCPU, I/O はノード数でスケールできるがネットワークはノード追加でスケールできない
検証の話
めっちゃ難しい● 本来、負荷試験はシステムのボトルネックを特定するために実施する● が、コスト削減の一貫で行う性能検証では、ローンチ済システムに対して行う前提○ そのため、これまでと同じワークロードに充分耐えうるかを検証するのが主目的となる● そして、実際のワークロード再現は 激むず
進め方● アクセスログのモニタリング結果を見て、検証対象の処理を決める○ 実行頻度や最大同時実行数など● 上記ワークロードのシナリオをつくって、負荷テストする○ もちろん、少し上積みしたリクエスト数で
進め方● アクセスログのモニタリング結果を見て、検証対象の処理を決める○ 実行頻度や最大同時実行数など● 上記ワークロードのシナリオをつくって、負荷テストする○ もちろん、少し上積みしたリクエスト数でJMeter でシナリオ組んでテストした（たいへんだった）
おすすめ本こんな素晴らしい本があるのか…と感動した
＜再掲＞コスト削減の原理原則1. モニタリングして現状分析が必要2. 事前調査と想像力だいじ3. インフラチームだけでコスト削減は完結しない4. マシンの気持ちになって考える5. 人の気持ちになって考える
良いコスト削減ライフを
katsuhisa91
sms_tech
moriyuya
eikohashiba
dt_dynamics
tanakamaiko
abenger
ecrowd
kyonmm
edvakf
fabrica_com
hakusansai
weddingpark
marcduiker
orderedlist
tanoku
mojombo
wjessup
jnunemaker
paulrobertlloyd
eitanlees
colly
eileencodes
hatefulcrawdad
hannesfritz