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

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）

見る為に手間がかかる。

コンソールログイン▶サービス選択▶インスタンス選択

表示が重い（複数インスタンス選択・遡っての表示）

たまにうまく見れない（カーソルあわせているのに詳細がウィンドウの後ろに…）

サービスまたぎ、アカウントまたぎでの表示×

データの保存期間は２週間

CloudWatch

デメリット

デフォルトではとれている情報が少ない（EC2）

見る為に手間がかかる。

コンソールログイン▶サービス選択▶インスタンス選択

表示が重い（複数インスタンス選択・遡っての表示）

たまにうまく見れない（カーソルあわせているのに詳細がウィンドウの後ろに…）

サービスまたぎ、アカウントまたぎでの表示×

データの保存期間は２週間

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