$30 off During Our Annual Pro Sale. View Details »

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

katsuhisa_
PRO
October 10, 2018

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

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

katsuhisa_
PRO

October 10, 2018
Tweet

More Decks by katsuhisa_

Other Decks in Business

Transcript

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

    View Slide

  2. #AWSLoft

    View Slide

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

    View Slide

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

    View Slide

  5. View Slide

  6. 今回の経緯

    View Slide

  7. View Slide

  8. View Slide

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

    View Slide

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

    View Slide

  11. AWS でコスト削減といえば

    View Slide

  12. Reserved Instance ?

    View Slide

  13. その前にやること
    はたくさんあ
    る!!!!!!

    View Slide

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

    View Slide

  15. コスト削減の原理原則

    View Slide

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

    View Slide

  17. たぶんできない

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  29. 本当にだいじょうぶ?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  33. ダメぜったい!

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  39. コスト削減前夜

    View Slide

  40. Monitoring

    View Slide

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

    View Slide

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

    View Slide

  43. Performance 改善

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  48. 現状分析

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  56. スプレッドシートの内容
    ● サービス名(EC2, RDS, ElasticCache ...)
    ● リソース名(EC2 の場合は、Name Tag)
    ● 現行サイズ(c5.large, r5.large ...)
    ● 削除フラグ
    ● 変更フラグ
    ○ 変更後サイズ
    ● 削除 or 変更理由
    ● レビュー
    記載したほうが良い。
    過去にスペックを決定した人がいる

    ちゃんと変更背景を残しておくべき

    View Slide

  57. スプレッドシートの内容
    ● サービス名(EC2, RDS, ElasticCache ...)
    ● リソース名(EC2 の場合は、Name Tag)
    ● 現行サイズ(c5.large, r5.large ...)
    ● 削除フラグ
    ● 変更フラグ
    ○ 変更後サイズ
    ● 削除 or 変更理由
    ● レビュー
    記載したほうが良い。
    過去にスペックを決定した人がいる

    ちゃんと変更背景を残しておくべき
    CloudFormation / Terraform などで
    コード化できていれば、
    変更背景はより管理しやすいはず

    View Slide

  58. スプレッドシートの内容
    ● サービス名(EC2, RDS, ElasticCache ...)
    ● リソース名(EC2 の場合は、Name Tag)
    ● 現行サイズ(c5.large, r5.large ...)
    ● 削除フラグ
    ● 変更フラグ
    ○ 変更後サイズ
    ● 削除 or 変更理由
    ● レビュー
    記載したほうが良い。
    過去にスペックを決定した人がいる

    ちゃんと変更背景を残しておくべき
    Terraform 導入の話は、
    またどこかで・・・

    View Slide

  59. 方針策定

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  68. 見積もりの話

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  74. 検証の話

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  81. 良いコスト削減ライフを

    View Slide