AWSコスト削減をする前に読むスライド

AWS Startup Tech Meetup #013 で発表した資料です。
AWS コスト削減をする前におさえておきたい考え方を整理しました。
https://awsstartuptechmeetuptokyo13.splashthat.com/

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