Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

katsuhisa_
October 10, 2018

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

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

katsuhisa_

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
  2. • 北野 勝久 / @katsuhisa__ • SRE @ Studist Corporation

    • Organizer of SRE Lounge / Rails Developers Meetup • Developers Summit, / July Tech Festa 登壇 etc. • Linux カーネルと同い年
  3. Performance 改善 • Performance Working Group を運営した ◦ はてなさんの取り組みを真似した ▪

    http://hatenacorp.jp/recruit/operation_engineer ◦ 開発部 複数チームからなるPrj. ◦ 定期的にパフォーマンス改善サイクルを 回す場として運営
  4. 改善内容 • バルクインサート化 • 無駄なジョイン・ソートの撲滅 • 0.5s 以上かかるスロークエリ 98 %

    削減 DB まわりの処理改善が、 システム負荷軽減に効いた →サイズを安心して落とせる状態に
  5. スプレッドシートの内容 • サービス名(EC2, RDS, ElasticCache ...) • リソース名(EC2 の場合は、Name Tag)

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

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

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

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

    • 現行サイズ(c5.large, r5.large ...) • 削除フラグ • 変更フラグ ◦ 変更後サイズ • 削除 or 変更理由 • レビュー 記載したほうが良い。 過去にスペックを決定した人がいる ↓ ちゃんと変更背景を残しておくべき Terraform 導入の話は、 またどこかで・・・
  10. Reserved Instance 購入タイミング • RI を購入すると、損益分岐を越えるまでは、 使わないと損な状態が生まれる • 本当にやりたいことは RI

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

    を購入することではなく、 最適なインスタンスサイズに変更すること ◦ RI 購入タイミングで、 サイズ変更の判断が引きずられるのは本末転倒 • とはいえ、後回しにしすぎると、 「もっとはやく買っておけば…」ということに (余談) 過去の利用履歴を見て、 RI を自動購入するサービスがあるらしい
  12. RDS の見積もり(Aurora MySQL) • CPU使用率 • コネクション数 ◦ max_connections デフォルト値を参照する

    • メモリ ◦ BUFFER POOL AND MEMORY 専任のDBA がいる会社であれば、 もっと多角的に分析できるはず 性能検証で見積もり結果を 検証することがだいじ
  13. Redshift の見積もり • クエリ実行時間を俯瞰する ◦ 改善余地ありと感じるのであれば、 分散キーとソートキーをチェック ◦ いずれも正しく選択できているのであれば、 ノード数を変更&性能検証し、ノード数を決定

    • Redshift の最大のボトルネックは、 ノードインターコネクトだと心得る CPU, I/O はノード数でスケールできるが ネットワークはノード追加でスケールできない