Tweet
Tweet

Slide 1

Slide 1 text

AWSコスト削減をする前に 読むスライド AWS Startup Tech Meetup #13 @katsuhisa__ / 北野 勝久 Copyright (C) 2018 Studist Corporation. All Rights Reserved

Slide 2

Slide 2 text

#AWSLoft

Slide 3

Slide 3 text

● 北野 勝久 / @katsuhisa__ ● SRE @ Studist Corporation ● Organizer of SRE Lounge / Rails Developers Meetup ● Developers Summit, / July Tech Festa 登壇 etc. ● Linux カーネルと同い年

Slide 4

Slide 4 text

マニュアル作成・共有プラットフォーム

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

今回の経緯

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

AWS で開催される勉強会ですが… AWS のコストを ガンガン削ったお話を 持ってきました！！！！！！

Slide 10

Slide 10 text

今日の主題 AWS のコストをガンガン削る

Slide 11

Slide 11 text

AWS でコスト削減といえば

Slide 12

Slide 12 text

Reserved Instance ?

Slide 13

Slide 13 text

その前にやること はたくさんあ る！！！！！！

Slide 14

Slide 14 text

Agenda 1. コスト削減の原理原則 2. コスト削減前夜 3. 現状分析と方針策定 4. 見積もりと検証の話 5. まとめ

Slide 15

Slide 15 text

コスト削減の原理原則

Slide 16

Slide 16 text

さて、明日からコスト削減…

Slide 17

Slide 17 text

たぶんできない

Slide 18

Slide 18 text

「サイズいきなり落として、 性能障害起きない？」 「そのインスタンス、 勝手に落としちゃまずくね？」 「なぜかこれまで動いていた 処理が動かなくなった…」

Slide 19

Slide 19 text

原理原則1 モニタリングして現状分析が必要

Slide 20

Slide 20 text

よーし、モニタリングできた。 コストカットするぞー。

Slide 21

Slide 21 text

ちょっと待った。 そのままやっても 大して成果出ないっすよ。

Slide 22

Slide 22 text

なぜか ● 過去のシステム管理者は、 意味もなくサイズアップしてないはずだから ● 何かの問題があり、解決するために サイズを上げたはず ● つまり、何も考えずにサイズを落とすと 何か起こると考えるほうが自然

Slide 23

Slide 23 text

原理原則2 事前調査と想像力だいじ

Slide 24

Slide 24 text

いろいろ調べた結果… ある問題を解決しないと ダウンサイズできないようだ！

Slide 25

Slide 25 text

その問題、インフラだけで 対処できなくね？

Slide 26

Slide 26 text

よくあること ● アプリケーションのチューニングしないと 解決できない問題を短期的に札束で解決していた ● サービスローンチ以降、改修せずに、 無駄がない処理だけのサービスなんて存在しない （と思う。）

Slide 27

Slide 27 text

原理原則3 インフラチームだけで コスト削減は完結しない

Slide 28

Slide 28 text

アプリケーションの改修もした ついにコスト削減だー サイズ落とすぞー

Slide 29

Slide 29 text

本当にだいじょうぶ？

Slide 30

Slide 30 text

「適切な見積もりできてる？」 「実は関係ない指標みてない？」 「見積もりに自信あっても、 万が一のために検証した？」

Slide 31

Slide 31 text

原理原則4 マシンの気持ちになって考える

Slide 32

Slide 32 text

ふー、コスト削減できた… おれは天才だ… こんなに無駄があったのか、 信じられないぜ…

Slide 33

Slide 33 text

ダメぜったい！

Slide 34

Slide 34 text

なぜコスト削減できるのか ● 今たまたまコスト削減に意識を向けるフェーズに たどり着いただけに過ぎない ● 昔の人がわざわざ無駄を生んだわけではない ● 過去へのリスペクトは常にだいじ

Slide 35

Slide 35 text

原理原則5 人の気持ちになって考える

Slide 36

Slide 36 text

コスト削減の原理原則 1. モニタリングして現状分析が必要 2. 事前調査と想像力だいじ 3. インフラチームだけでコスト削減は完結しない 4. マシンの気持ちになって考える 5. 人の気持ちになって考える

Slide 37

Slide 37 text

コスト削減の原理原則 1. モニタリングして現状分析が必要 2. 事前調査と想像力だいじ 3. インフラチームだけでコスト削減は完結しない 4. マシンの気持ちになって考える 5. 人の気持ちになって考える コスト削減は、 インフラ⇔アプリ, マシン⇔人 を網羅する総合格闘技

Slide 38

Slide 38 text

Agenda 1. コスト削減の原理原則 2. コスト削減前夜 3. 現状分析と方針策定 4. 見積もりと検証の話 5. まとめ

Slide 39

Slide 39 text

コスト削減前夜

Slide 40

Slide 40 text

Monitoring

Slide 41

Slide 41 text

EC2 とりあえずこれだけは ● ロードアベレージ ● CPU ● I/O ● メモリ ● ディスク

Slide 42

Slide 42 text

RDS とりあえずこれだけは ● コネクション数 ● CPU ● メモリ ● スロークエリログの収集と可視化 （閾値は、0.5s あたり）

Slide 43

Slide 43 text

Performance 改善

Slide 44

Slide 44 text

Performance 改善 ● Performance Working Group を運営した ○ はてなさんの取り組みを真似した ■ http://hatenacorp.jp/recruit/operation_engineer ○ 開発部 複数チームからなるPrj. ○ 定期的にパフォーマンス改善サイクルを 回す場として運営

Slide 45

Slide 45 text

改善内容 ● バルクインサート化 ● 無駄なジョイン・ソートの撲滅 ● 0.5s 以上かかるスロークエリ 98 % 削減

Slide 46

Slide 46 text

改善内容 ● バルクインサート化 ● 無駄なジョイン・ソートの撲滅 ● 0.5s 以上かかるスロークエリ 98 % 削減 DB まわりの処理改善が、 システム負荷軽減に効いた →サイズを安心して落とせる状態に

Slide 47

Slide 47 text

Agenda 1. コスト削減の原理原則 2. コスト削減前夜 3. 現状分析と方針策定 4. 見積もりと検証の話 5. まとめ

Slide 48

Slide 48 text

現状分析

Slide 49

Slide 49 text

いろいろ考えた結果、 神スプレッドシートをつくった

Slide 50

Slide 50 text

Why スプレッドシート ? ● 現状のリソースを一覧化するだけなら スプレッドシートでなくともよい ● が、削除・変更理由や、変更後の情報を整理し、 人間にレビューしてもらうことを考えると、 スプレッドシートでがんばろうという気持ちに…

Slide 51

Slide 51 text

Why スプレッドシート ? ● 現状のリソースを一覧化するだけなら スプレッドシートでなくともよい ● が、削除・変更理由や、変更後の情報を整理し、 人間にレビューしてもらうことを考えると、 スプレッドシートでがんばろうという気持ちに… きっと世の中に もっと良いやり方はあるだろう…

Slide 52

Slide 52 text

スプレッドシートの内容 ● サービス名（EC2, RDS, ElasticCache ...） ● リソース名（EC2 の場合は、Name Tag） ● 現行サイズ（c5.large, r5.large ...） ● 削除フラグ ● 変更フラグ ○ 変更後サイズ ● 削除 or 変更理由 ● レビュー

Slide 53

Slide 53 text

スプレッドシートの内容 ● サービス名（EC2, RDS, ElasticCache ...） ● リソース名（EC2 の場合は、Name Tag） ● 現行サイズ（c5.large, r5.large ...） ● 削除フラグ ● 変更フラグ ○ 変更後サイズ ● 削除 or 変更理由 ● レビュー Trusted Advisor を参照し、 対象の見極め 変更後コストは、 SIMPLE MONTHLY CALCULATOR で計算すると楽

Slide 54

Slide 54 text

Trusted Advisor AWS がリソース使用状況を見て、 いい感じにコスト削減の提案を出してくれる

Slide 55

Slide 55 text

SIMPLE MONTHLY CALCULATOR ←これを埋めると ←これが出る https://calculator.s3.amazonaws.com/index.html

Slide 56

Slide 56 text

スプレッドシートの内容 ● サービス名（EC2, RDS, ElasticCache ...） ● リソース名（EC2 の場合は、Name Tag） ● 現行サイズ（c5.large, r5.large ...） ● 削除フラグ ● 変更フラグ ○ 変更後サイズ ● 削除 or 変更理由 ● レビュー 記載したほうが良い。 過去にスペックを決定した人がいる ↓ ちゃんと変更背景を残しておくべき

Slide 57

Slide 57 text

スプレッドシートの内容 ● サービス名（EC2, RDS, ElasticCache ...） ● リソース名（EC2 の場合は、Name Tag） ● 現行サイズ（c5.large, r5.large ...） ● 削除フラグ ● 変更フラグ ○ 変更後サイズ ● 削除 or 変更理由 ● レビュー 記載したほうが良い。 過去にスペックを決定した人がいる ↓ ちゃんと変更背景を残しておくべき CloudFormation / Terraform などで コード化できていれば、 変更背景はより管理しやすいはず

Slide 58

Slide 58 text

スプレッドシートの内容 ● サービス名（EC2, RDS, ElasticCache ...） ● リソース名（EC2 の場合は、Name Tag） ● 現行サイズ（c5.large, r5.large ...） ● 削除フラグ ● 変更フラグ ○ 変更後サイズ ● 削除 or 変更理由 ● レビュー 記載したほうが良い。 過去にスペックを決定した人がいる ↓ ちゃんと変更背景を残しておくべき Terraform 導入の話は、 またどこかで・・・

Slide 59

Slide 59 text

方針策定

Slide 60

Slide 60 text

方針策定1 どこまでがんばるか決めておく

Slide 61

Slide 61 text

どこまでやるか ● はじめに決めておかないと際限がない ● うちの場合は、大まかには以下方針にした ○ インスタンスファミリー: T ■ 基本は、不要リソース削除のみ対応 ○ インスタンスファミリー: C, M, R ... ■ サイズ変更まで対応

Slide 62

Slide 62 text

方針策定2 完了フェーズを区切っておく

Slide 63

Slide 63 text

なぜ完了フェーズを区切るか ● コスト削減は最優先にしにくい ● 急遽割り込みタスクが入ると、中断しがち ● あらかじめ完了フェーズと優先度を決めておくと 「ここまで終わったら、その作業やります」 を判断しやすい

Slide 64

Slide 64 text

方針策定3 Reserved Instance 購入タイミング を意識する

Slide 65

Slide 65 text

Reserved Instance 購入タイミング ● RI を購入すると、損益分岐を越えるまでは、 使わないと損な状態が生まれる ● 本当にやりたいことは RI を購入することではなく、 最適なインスタンスサイズに変更すること ○ RI 購入タイミングで、 サイズ変更の判断が引きずられるのは本末転倒 ● とはいえ、後回しにしすぎると、 「もっとはやく買っておけば…」ということに

Slide 66

Slide 66 text

Reserved Instance 購入タイミング ● RI を購入すると、損益分岐を越えるまでは、 使わないと損な状態が生まれる ● 本当にやりたいことは RI を購入することではなく、 最適なインスタンスサイズに変更すること ○ RI 購入タイミングで、 サイズ変更の判断が引きずられるのは本末転倒 ● とはいえ、後回しにしすぎると、 「もっとはやく買っておけば…」ということに （余談） 過去の利用履歴を見て、 RI を自動購入するサービスがあるらしい

Slide 67

Slide 67 text

Agenda 1. コスト削減の原理原則 2. コスト削減前夜 3. 現状分析と方針策定 4. 見積もりと検証の話 5. まとめ

Slide 68

Slide 68 text

見積もりの話

Slide 69

Slide 69 text

https://blog.a-know.me/entry/2017/02/02/215641 EC2サイズ変更時のメトリックの見方・考え方は こちらがオススメ

Slide 70

Slide 70 text

RDS の見積もり（Aurora MySQL） ● CPU使用率 ● コネクション数 ○ max_connections デフォルト値を参照する ● メモリ ○ BUFFER POOL AND MEMORY

Slide 71

Slide 71 text

RDS の見積もり（Aurora MySQL） ● CPU使用率 ● コネクション数 ○ max_connections デフォルト値を参照する ● メモリ ○ BUFFER POOL AND MEMORY 専任のDBA がいる会社であれば、 もっと多角的に分析できるはず 性能検証で見積もり結果を 検証することがだいじ

Slide 72

Slide 72 text

Redshift の見積もり ● クエリ実行時間を俯瞰する ○ 改善余地ありと感じるのであれば、 分散キーとソートキーをチェック ○ いずれも正しく選択できているのであれば、 ノード数を変更&性能検証し、ノード数を決定 ● Redshift の最大のボトルネックは、 ノードインターコネクトだと心得る

Slide 73

Slide 73 text

Redshift の見積もり ● クエリ実行時間を俯瞰する ○ 改善余地ありと感じるのであれば、 分散キーとソートキーをチェック ○ いずれも正しく選択できているのであれば、 ノード数を変更&性能検証し、ノード数を決定 ● Redshift の最大のボトルネックは、 ノードインターコネクトだと心得る CPU, I/O はノード数でスケールできるが ネットワークはノード追加でスケールできない

Slide 74

Slide 74 text

検証の話

Slide 75

Slide 75 text

めっちゃ難しい ● 本来、負荷試験はシステムのボトルネックを 特定するために実施する ● が、コスト削減の一貫で行う性能検証では、 ローンチ済システムに対して行う前提 ○ そのため、これまでと同じワークロードに 充分耐えうるかを検証するのが主目的となる ● そして、実際のワークロード再現は 激むず

Slide 76

Slide 76 text

進め方 ● アクセスログのモニタリング結果を見て、 検証対象の処理を決める ○ 実行頻度や最大同時実行数など ● 上記ワークロードのシナリオをつくって、 負荷テストする ○ もちろん、少し上積みしたリクエスト数で

Slide 77

Slide 77 text

進め方 ● アクセスログのモニタリング結果を見て、 検証対象の処理を決める ○ 実行頻度や最大同時実行数など ● 上記ワークロードのシナリオをつくって、 負荷テストする ○ もちろん、少し上積みしたリクエスト数で JMeter でシナリオ組んでテストした （たいへんだった）

Slide 78

Slide 78 text

おすすめ本 こんな素晴らしい本が あるのか…と感動した

Slide 79

Slide 79 text

Agenda 1. コスト削減の原理原則 2. コスト削減前夜 3. 現状分析と方針策定 4. 見積もりと検証の話 5. まとめ

Slide 80

Slide 80 text

＜再掲＞コスト削減の原理原則 1. モニタリングして現状分析が必要 2. 事前調査と想像力だいじ 3. インフラチームだけでコスト削減は完結しない 4. マシンの気持ちになって考える 5. 人の気持ちになって考える

Slide 81

Slide 81 text

良いコスト削減ライフを