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