Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

2,427 views

Published on

「Applibot presents SmartphoneGame on AWS !!」セミナーにて使用したスライドです。アプリボットでは、AWSを利用しており、運用をしていく上での「データの可視化とコスト管理」について紹介しています。

Published in: Engineering
  • Be the first to comment

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

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

×