データ可視化とコスト管理 Slideshare

Transcript

• 1. データの可視化と コスト管理 2014/07/04 西村 遊
• 2. 自己紹介 西村　遊 AWS利用歴：2年3ヶ月 好きなAWSサービス：AutoScaling
• 3. なにしてるの？
• 4. ざっくりシスオペ 主にサーバーの構築・運用・構成管理 サーバー監視 障害対応 ミドルウェアの設定 サーバーリソース最適化 アプリ、開発支援系 Ansible使ってます 担当アプリは無し。全部見てます。
• 5. ざっくりシスオペ 主にサーバーの構築・運用・構成管理 サーバー監視 障害対応 ・障害を事前に防ぐ ・障害の発生に逸早く気づく ・リソース最適化 = コストの最適化 ! 全アプリ、全サーバーの状況を すぐに確認できるようにしておく必要がある ミドルウェアの設定 サーバーリソース最適化 担当アプリは無し。全部見てます。
• 6. 今日話したいこと
• 7. AWS内のデータを 手早くみれるようにして 無駄を省こう！
• 8. 目次 1. コスト管理 2. 可視化 3. まとめ
• 9. コスト管理
• 10. コスト = お金・手間
• 11. お金 = AWS料金 手間 = 構築・調査時間
• 12. AWSあるある？ たぶん
• 13. 無駄遣いしてない？
• 14. EC2 何サーバーかName Tagで判別できない 開発環境用？本番用？テスト用？ ***-newは本当にnew? newがあるのに無印も残っている？ そもそも使ってる？ 紐付けられていないElasticIP
• 15. EC2 & EBS EBSがめっちゃ多い stop状態のサーバー多いけど使う機会は？ EBS代($0.08/GB)がかかっている事を忘れる アタッチされていない数百GBのディスク… どのディスクが何の用途だったかを辿り辛い
• 16. RDS DB名に日付っぽい数字入ってる 何かのテストで使った？その後は… newを削除して新しく無印を作成、みたい な対応 例：guild-newを削除して、guildを作成
• 17. 結果 使っているかがわからないものがゴロゴロ ▶調査しないと削除できない ▶その間にも課金は進む… ▶返事がない…そして数ヶ月後…
• 18. そんな状況に陥らない為に
• 19. Billing Management Console サポート：ビジネス以上 ! Trusted Advisor
• 20. でも
• 21. ・アカウント多くて切り替え面倒 ! ・そもそもこまめに見れるなら苦労は無い ! ・ビジネスサポートなんて入ってない
• 22. ＿人人人人人＿ ＞　自動化　＜ ‾Y^Y^Y^Y‾
• 23. ＿人人人人人人人人人人人人人人＿ ＞　プログラマブルなインフラ　＜ ‾Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y‾
• 24. 扱いやすくしよう
• 25. どうしたら扱いやすいか アカウント内の片付けをする（見やすくする） Tagを巧く使う ▶Name Tagでサーバー種別毎の命名規則 ▶縛りすぎない。連番とかつけると追加・削除が多い場合混乱が おきる。 ▶CLIで情報を取る際に絞り込みが楽になる
• 26. どうしたら扱いやすいか アカウント監視 ▶使ってなさそうなのを通知 （EBSのstatusがavailable、ElasticIP： "InstanceId": null） ▶情報取得はawscli+jq 　▶スクリプト化しておけば楽 ▶お好きな言語で
• 27. AWS利用の上で感じる大切な事 なるべくマネージメントコンソールに入ら ないで調査できる環境 Nameタグの命名規則
• 28. 可視化
• 29. 可視化って？ 可視化とは、人間が直接「見る」ことのできない現 象・事象・関係性を「見る」ことのできるもの（画 像・グラフ・図・表など）にすることをいう。視覚 化・可視化情報化・視覚情報化ということもある。　 (Wikipediaより)
• 30. 目的 常に値を収集し見れるようにする（状態を可視化） 異常値が出た場合は通知する（問題を可視化） 暇しているサーバーがあれば構成見直し
• 31. 目的 常に値を収集し見れるようにする（状態を可視化） ▶値をグラフ化 異常値が出た場合は通知する（問題を可視化） ▶値の監視 暇しているサーバーがあれば構成見直し ▶コスト削減
• 32. 監視構成
• 33. Ganglia（リソースグラフ化） ・EC2インスタンスのサーバーリソースを取得してグラフ化 ・python pluginでredis,mysql等のグラフも取得
• 34. Icinga（リソース監視） ・閾値超えたら通知 ・プラグインでCloudWatchの値も監視 ・読み方（アイシンガ、イッティンガ）
• 35. CloudWatch（監視+モニタリング） EC2以外のサービスにはエージェント入れられないので
• 36. CloudWatch 特徴 AWS各種サービス起動時に自動で設定されている カスタムメトリクスとしてデータの送信を行う事で 簡単なリソースの可視（グラフ）化 閾値設定してSNSでメール送信（監視） AWSサービスとの連携（AutoScalingトリガー）
• 37. CloudWatch デメリット デフォルトではとれている情報が少ない（EC2） 見る為に手間がかかる。 コンソールログイン▶サービス選択▶インスタンス選択 表示が重い（複数インスタンス選択・遡っての表示） たまにうまく見れない（カーソルあわせているのに詳細がウィンドウの後ろに…） サービスまたぎ、アカウントまたぎでの表示× データの保存期間は２週間
• 38. CloudWatch デメリット デフォルトではとれている情報が少ない（EC2） 見る為に手間がかかる。 手間をかけずに見れて コンソールログイン▶サービス選択▶インスタンス選択 表示が重い（複数インスタンス選択・遡っての表示） 表示が重くなくて たまにうまく見れない（カーソルあわせているのに詳細がウィンドウの後ろに…） サービスまたぎ、アカウントまたぎでの表示× サービス・アカウントまたぎで データの保存期間は２週間 一括で見れて 保存期間自由なCloudWatchが欲しい
• 39. ＿人人人人人人人人人人人人＿ ＞　そんなあなたにGRAFANA　＜ ‾Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y‾
• 40. 特徴 ・バックエンドをGraphite,InfluxDBから選択 ・Dashboard情報をElasticsearch （JSON形式でダウンロード、アップロード可能） ・表示させるグラフの組み合わせ自由自在 ・2003ポートに[時間+タグ+値]を送るだけでグラフ化（Graphite） （fluentプラグイン使うと楽）
• 41. ①　fluentd-plugin-cloudwatchで値を取得 ②　fluentd-plugin-graphiteでGraphiteへ ③　Grafanaで閲覧
• 42. うれしい事 手間をかけずに見れて ・ログイン不要（セキュリティにはお気をつけて…） 　Basic認証、IP制限等 　ElasticSearchのポート開放にも気をつける
• 43. 表示が重くなくて ・複合グラフ、過去の時間指定してもサクサク 　現在467メトリクスを毎分取得しているが、 　r3.large（2CPU RAM:15GB）でサクサク 　▶過去のレンジを指定するときに 　　多数のグラフを表示しているとかなりCPUを喰ってしまう… 　whisperファイルはtmpfs領域に置き、 　rsyncで定期的にディスクに落とす。 　
• 44. ・アカウント・サービスまたぎ、組み合わせ自由自在 サービス・アカウントまたぎで 一括で見れて
• 45. ・一年ぐらい前のデータ見れるようにしたい 　グラフ作成時に指定できる（Grafite） /etc/carbon/storage-schemas.conf 保存期間自由なCloudWatchが欲しい [cloudwatch] pattern = ^cloudwatch. retentions = 60s:365d 1ポイント60秒*365日のグラフを作成 1ファイル当たり6.1M
• 46. 手間をかけずに見れて 要望全部表示満が重くたなくて せた！！ サービス・アカウントまたぎで 一括で見れて 保存期間自由なCloudWatchが欲しい
• 47. とにかくかっこいいので、 人に見せる時にドヤレる
• 48. 目的 常に値を収集し見れるようにする（状態を可視化） ▶値をグラフ化
• 49. 目的 異常値が出た場合は通知する（問題を可視化） ▶値の監視 （アイシンガ、イッティンガ）
• 50. 目的 暇しているサーバーがあれば構成見直し ▶コスト削減 ▶リソース可視化で調査コスト削減 あとはやるだけだ！
• 51. まとめ なるべくマネージメントコンソールに入らない 削除漏れによる無駄遣いリスク ▶命名規則決めてタグ付けすると楽（自動化し易い） ▶無駄使い監視（情報は自動で取得し通知）
• 52. まとめ 「使用していない」状態を見れるようにしよう Cloudwatchはfluentd + Graphite + Grafana 　構成おすすめ
• 53. ご清聴ありがとうございました
• 54. 参考 Fluentd を使って CloudWatch のメトリクスを Graphite で見れるようにする http://qiita.com/inokappa/items/ ee993b14f82e544ca6e4