AWSのリソース使用状況レポートを自動生成しインスタンスタイプの最適化を図る【Excelレポート生成編】

こんにちは、井下です。

先日父の日に何を贈ろうかと考えていたところ、父からの直接のオーダーがありました。
内容は「肩たたき1時間」。…小型マッサージ機なら去年贈ったはずなんですが。

はじめに

前回はメトリクスデータの収集を行うバッチ2、バッチのデータを整形するバッチ3について説明しました。
今回はバッチ3で整形されたファイルから、Excelレポート生成を行うバッチ4について説明します。

おさらいになりますが、用意する全バッチは下表の通りです。

バッチ名	処理内容	実行周期
バッチ1	インスタンス内でデータを取得し、カスタムメトリクスとしてCloudWatchへ送信します。	1分ごと
シェル1	バッチ1のシェル版です。Linuxのカスタムメトリクスを取得・送信したい場合は、こちらを利用します。	1分ごと
バッチ2	前日分の標準メトリクス・カスタムメトリクスのデータを取得します。	日次
バッチ3	バッチ2で取得したデータをまとめ、OSSのEmbulkを利用して整形します。	月次
バッチ4	バッチ3で整形されたデータから、レポートとしてExcelのグラフを作成します。	月次

バッチ4(Excelレポート生成)

処理概要

バッチ3で整形されたファイル群を元に、Excelレポートを出力します。

パラメータ

第1パラメータ（必須） ：バッチ3で整形されたファイル群の保存先パス（※）
第2パラメータ（必須） ：バッチ3で整形されたファイル群に付与されているインスタンスID
第3パラメータ（必須） ：ファイルの出力先パス（※）

※ ブランクパスを指定する場合、パスの前後を「"」で括ってください。

リターンコード

0 ： 正常終了しました
4 ： パラメータの指定が不正
8 ： 第1パラメータで指定したパスのファイル群が不足しているか、ファイルオープンに失敗しました
12： 第3パラメータで指定したパスが存在しないか、Excelレポートの出力に失敗しました
16： Excelがインストールされていません

サンプルバッチ

AWSのリソース使用状況レポートを自動生成しインスタンスタイプの最適化を図る【メトリクスデータ収集・整形編】

こんにちは、井下です。

スマフォのカバーをつけてから2ヵ月ほど、既に傷だらけになっているので、そろそろ買い換えようかなと思っているところです。
スマフォ自体も劣化してる部分があるのですが、デザインは気に入っているので、中身だけ取り換えたいと思っています。あまりスペックのこだわりはないのですが、そういうところ考えもあってAraには期待しています。(Araで気に入るデザインが出てからの話になりますが)

はじめに

さて、前回はカスタムメトリクスのデータを送信するバッチ・シェルについて説明しました。
今回は標準メトリクス・カスタムメトリクスからデータを収集するバッチ（バッチ2）と、データを整形するバッチ（バッチ3）について説明します。

おさらいになりますが、用意する全バッチは下表の通りです。

バッチ名	処理内容	実行周期
バッチ1	インスタンス内でデータを取得し、カスタムメトリクスとしてCloudWatchへ送信します。	1分ごと
シェル1	バッチ1のシェル版です。Linuxのカスタムメトリクスを取得・送信したい場合は、こちらを利用します。	1分ごと
バッチ2	前日分の標準メトリクス・カスタムメトリクスのデータを取得します。	日次
バッチ3	バッチ2で取得したデータをまとめ、OSSのEmbulkを利用して整形します。	月次
バッチ4	バッチ3で整形されたデータから、レポートとしてExcelのグラフを作成します。	月次

バッチ2（メトリクスデータ収集）

処理概要

バッチ実行日の前日分のメトリクスデータを収集します。
なお、収集するメトリクスのデータは下記の7つです。

• CPU使用率（%）
• 空メモリー容量（MByte）
• メモリー使用率(%)
• ロードアベレージ(個)
• 仮想メモリー使用率(%)
• ネットワーク受信バイト数(Byte)
• ネットワーク送信バイト数(Byte)

パラメータ

第1パラメータ （必須）：リージョンコード
第2パラメータ （必須）：インスタンスID
第3パラメータ （任意）：ave：平均値（省略時デフォルト）
　　　　　　　　　 　　　　　max：最大値

※CloudWatchでは、収集するメトリクスデータは平均値、最大値、最小値などから選択することができます。本バッチでは、maxかaveを指定します。

リターンコード

0 ： 正常終了しました
1 ： データが0件のメトリクスがありました
4 ： パラメータの指定が不正
8 ： メトリクスデータ収集に失敗しました
12： 収集したデータ出力に失敗しました

サンプルバッチ

AWSのリソース使用状況レポートを自動生成しインスタンスタイプの最適化を図る【カスタムメトリクスデータ送信編】

こんにちは、井下です。

新人研修の講師の時期が近づいてきて、資料の見直しと更新をしていますが、1年も経つと既に古い技術になっていたり、新しい概念が出てきたりして、更新する部分が意外と多いものだとしみじみと感じています。

はじめに

さて、今回から「AWSのメトリクスを自動で収集・レポート作成し、インスタンスタイプの最適化を図る」というテーマで3回ほどブログを掲載することを予定しています。

意識されている方は多いと思いますが、EC2インスタンスの課金体系は基本的に 稼働時間 × インスタンスタイプ になっています。
つまり、できるだけ使わない時間は動かさずに、できるだけ無駄のないスペックのインスタンプタイプを選択することが、コストの最適化に繋がるということになります。

稼働時間に関しては、先月書いたインスタンスの起動・停止の自動化によって、無駄を省けるようになると思いますが、インスタンプタイプはどうでしょうか？

個人利用や検証であれば、最小のmicroインスタンスを利用しても問題は起きにくいですが、外部公開したり、業務に直結するインスタンスであれば、どれを選ぶか吟味しなくてはなりません。
また、インスタンスタイプを選択した後になってから、当初とは事情が異なってスペックが足りなくなったり、持て余してしまうことも考えられないことではありません。

インスタンスタイプが適切であるかを判断するためには、CPU使用率やメモリ使用率などのリソースの状況を確認すると思います。
また、リソースの状況は一時的なものではなく、例えば1日のリソースの監視結果など、ある程度の期間のものを確認したくなるのではないでしょうか。

そんな要望に応えるサービスとして、AWSから「CloudWatch」というサービスが提供されています。

実はインスタンスを作成すると、自動でCloudWatchが次の10個の項目について監視を開始しており、その結果はAWS マネージメントコンソールから確認することができます。（監視する項目は「メトリクス」と呼びます）

• CPUUtilization(CPU使用率)
• DiskReadOps(ディスク読み取り回数)
• DiskWriteOps(ディスク書き込み回数)
• DiskReadBytes(ディスク読み取りバイト数)
• DiskWriteBytes(ディスク書き込みバイト数)
• NetworkIn(ネットワーク受信バイト数)
• NetworkOut(ネットワーク送信バイト数)
• StatusCheckFailed_Instance(過去1分のインスタンスステータスチェックの成功可否)
• StatusCheckFailed_System(過去1分のシステムステータスチェックの成功可否)
• StatusCheckFailed(「StatusCheckFailed_Instance」と「StatusCheckFailed_System」の組み合わせ)

ここまで聞くと、「それじゃあ、気になったときにCloudWatchを確認すればいいじゃないか」と思うかもしれませんが、2つ問題があります。

1つ目は、例えばインスタンスのメモリ使用率を確認しようとしても、CloudWatchのメトリクスとして監視されていないので、メモリ使用率を確認することができません。
2つ目は、CloudWatchで保持できるデータは過去2週間までになっていることです。長期間や過去の実績をAWSマネジメントコンソールから確認することはできません。

それらの問題に対しては、AWSから提供されているCloudWatch用のコマンドラインツール「CloudWatch Command Line Tools」を使うことによって解決します。

「CloudWatch Command Line Tools」では、主に記録されている各メトリクスのデータ取得および、利用者側独自に定義するメトリクス（カスタムメトリクス）のデータを送信（記録）することができます。

1つ目の問題に対しては、監視対象となる環境から何らかの方法でデータを取得し、CloudWatchにカスタムメトリクスとして送信（記録）することで、AWS マネージメントコンソールから送信された独自のカスタムメトリクスのデータを確認することができます。
2つ目の問題に対しては、日次でデータを取得（エクスポート）することで、過去のデータを保管することができます。

今回から3回に渡って、「CloudWatch Command Line Tools」とA-AUTO 50、またOSSのEmbulkを利用して、1月分のメトリクスを自動で収集・レポート作成し、インスタンスタイプの見直しに活用できるようにします。

今回、収集・レポート作成の対象とするメトリクスは以下の7つとしています。

メトリクス	単位	メトリクスの種類
CPU使用率	%	標準メトリクス
空メモリー容量	Mbyte	カスタムメトリクス
メモリー使用率	%	カスタムメトリクス
ロードアベレージ	個	カスタムメトリクス
仮想メモリー使用率	%	カスタムメトリクス
ネットワーク受信バイト数	Mbyte	標準メトリクス
ネットワーク送信バイト数	Mbyte	標準メトリクス

全体的の構成図は次のようになります。

バッチとしては5つ（バッチ1のシェル版として、シェル1を用意しています）作成し、各々が決められた周期で実行することで、Excelレポートを自動生成できます。

各バッチの処理は下記のようになっています。

バッチ名	処理内容	実行周期
バッチ1	インスタンス内でデータを取得し、カスタムメトリクスとしてCloudWatchへ送信します。	1分ごと
シェル1	バッチ1のシェル版です。Linuxのカスタムメトリクスを取得・送信したい場合は、こちらを利用します。	1分ごと
バッチ2	前日分の標準メトリクス・カスタムメトリクスのデータを取得します。	日次
バッチ3	バッチ2で取得したデータをまとめ、OSSのEmbulkを利用して整形します。	月次
バッチ4	バッチ3で整形されたデータから、レポートとしてExcelのグラフを作成します。	月次

※掲載するバッチファイル内のCloudWatchやEmbulkは2015年5月現在のインターフェースを基に記載しています。提供元でインターフェースが変更されるとことがありますので、最新の情報は各提供元でご確認ください。

今回はバッチ1・シェル1について説明し、バッチ2、3、4については後日のブログにて説明します。