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については後日のブログにて説明します。

AzureVMの起動・停止自動化によるコストの最適化【準備編】

みなさんこんにちは。

社内のボウリング大会で米5キロがあたって歓喜している鷲尾です。


さて、みなさん「Azure」はご存知ですよね。
Azureとは、Microsoftが提供するクラウドサービスのことです。


先月のブログでAWSインスタンスの起動・停止自動化について書きましたが、今回はAzureVMの起動・停止自動化について書いていきます。

AWSではインスタンスを起動している間は料金がチャージされ、停止している間は料金はかからないというものでしたが、Azureも基本的には同じ要領で課金されます。

しかしAzureは、AWSとくらべて課金に関して少し癖があります。
それは、「VM（インスタンス）が停止していても、リソースの割り当てが解除されていない限り、課金は継続される」というものです。

例えば、AzureにもAWSのコンソール画面のように、「ポータル」と呼ばれるWebページがあります。このポータルから該当のインスタンスをシャットダウンした場合は、課金されません。
しかし、リモートデスクトップなどで実際にインスタンスにログインしている状態で、「OSの中から」シャットダウンした場合、実は課金の対象になってしまうんです。
これは気をつけなければいけませんね。

インスタンスを課金されないようにシャットダウンするには、ポータルから直接操作する他に、Microsoftで用意されている「コマンドレット」を使用し、WindowsPowerShellから該当のインスタンスをシャットダウンさせるという方法があります。

そこで今回は、このコマンドレットとWindowsPowerShellを使って、A-AUTO 50でAzureVMの起動・停止を自動化していきたいと思います。

ボリュームがあるので、2回に分けて書きたいと思います。

第１回：準備編
第２回：コマンドレット利用編（A-AUTO設定含む）

なお、本連載では、社内環境からAzure上に作成したWindows Server 2012R2のVMの起動・停止を行います。ローカル環境からだとファイアウォールの設定などが原因で外部へアクセスできないという場合は、常時稼働するAzureVMから操作する形をとっていただければと考えます。

・接続元（ローカル環境）
Windows Server 2008R2

・接続先（Azure）
Windows Server 2012R2
※　AzureのVMは、MicrosoftAzureの公式サイトからMicrosoftアカウントでポータルにログイン後、種類やサイズを自由に設定して作成することができます。

ということで、ここから第１回目の「準備編」の内容に入っていきます。

■準備編

AzureVMの起動・停止を制御するためには、AzureVMをコマンドレットで制御するための「Windows　Azure　PowerShell」、実際に起動処理もしくは停止処理を行うスクリプトファイル、Microsoftアカウントによる認証が必要です。

また、A-AUTOからPowerShellを実行するためのバッチファイルを用意します。

準備編では、AzureVMの起動・停止を行うために必要となる事前準備と、動作確認を行います。AzureVMを操作するには別途Windows　Azure　PowerShellという別のソフトウェアが必要です。このソフトウェアをインストールすることで、Azure上のVMに自由にコマンドを実行することが出来ます。

※Windows　Azure　PowerShellインストール後は、Windows　PowerShellからも、コマンドレットを実行できるようになります。

ということで、第１回目の目標は、「Windows　Azure PowerShellからAzureVMにコマンドを実行できるようにするところまで」です。

それでは以下の順に説明していきます。

１．Windows Azure PowerShellとは
２．Windows Azure PowerShellのダウンロードとインストール
３．認証情報（クレデンシャル）の設定と、動作確認

４．Windows PowerShellの実行ポリシー設定
５．自動化するための前提


1．Windows Azure PowerShellとは

"Azure PowerShell は、Azure のワークロードの展開と管理の制御および自動化に使用できる強力なスクリプト環境です。Windows PowerShell を使用したことがあるかないかにかかわらず、仮想マシンのプロビジョニング、仮想ネットワークおよびクロスプレミス ネットワークの設定、Azure でのクラウド サービスの管理を始めるための手順が示されます。（公式サイトより）"

→　　・・・ちょっとわかりにくいですね。簡単に言うと、AzureVMを操作するためにいろいろなものが揃っている、Windows PowerShellの強化版　みたいな感じです。Windows　Azure PowerShellをインストールすると、Windows Azure PowerShellもしくはWindows PowerShell上から、コマンドレットを使ってAzureVMを操作することが出来ます。操作範囲も、Azureのポータル画面から行えることは基本的に行うことが出来ます。

２．Windows Azure PowerShellのダウンロードとインストール

（１）ダウンロード

Windows　Azure　PowerShellを、公式ページからダウンロードします。

"インストール"をクリックするとダウンロードが始まるので、任意の場所にダウンロードします。

（２）インストール

ダウンロードしたファイルを実行すると、自動的にWeb Platform Installerが起動し、Windows Azure PowerShellがインストールされます。
※前提となるWindows PowerShellのバージョンについては、「５．自動化するための前提」を参照のこと。

↓

【インストール】をクリック

↓

【同意する】をクリック

↓

インストール欄が【インストール済み】になっていることを確認

上図のように、Web Platform Installerで"Windows Azure PowerShell"のインストール欄が"インストール済み"になっていれば、Windows Azure PowerShellのインストールは完了です。

続いて、認証情報の設定を行います。

３．認証情報（クレデンシャル）の設定と、動作確認

Windows Azure PowerShellをインストールしただけでは、コマンドは実行できません。コマンドレットを使うためには、操作を行うマシン内のWindows Azure PowerShellからあらかじめ認証を行っておく必要があります。この時に使用する認証情報のことをクレデンシャル（credential）といいます。

認証方法には、大きく２パターンあります。

データ転送のOSS「Embulk」を使って、MysqlからデータをCsvに落としてみる

こんにちは、井下です。

ゴールデンウィーク中はほぼ毎日出かけてましたが、おかげで財布が寒いことになってしまいました。もうクールビズ期間になるくらい、気温は上がっているというのに…。


さて、今回はOSSについて取り上げてみようと思います。
メジャーなOSSだけでも、サーバ監視のZabbix、メールサーバのPostfix、クラウド環境を構築できるOpenStack、A-AUTO 50サイトでも利用しているCMSのWordPressなど今や膨大な数になっています。

新しいOSSも次々とリリースされているので、1年もすればメジャーなOSSの数が倍くらいになっているかもしれません。また、消えていくものもたくさんあるので、OSSの選択は重要ですね。

そこで、今回は新しいOSSに着目し、2015/1/27にリリースされたデータ転送のOSS、Embulk（ｴﾝﾊﾞﾙｸ）についての紹介と、実際に利用してみます。


Embulkとは

Embulkとは、先に書いたようにデータ転送のOSSですが、特徴としてデータのインプット・アウトプットや、データの加工をプラグインとして拡張することができます。
既に一般的なDBからのインプット・アウトプットのプラグインや、Amazon S3からのインプット・アウトプとのプラグインが利用できるようになっています。

プラグイン一覧：http://www.embulk.org/plugins/


ご存知の方も多いと思いますが、同様の特徴を持つfluentdというOSSがあります。
Embulkはfluentdのバッチ版として位置づけられ、サーバに常駐してリアルタイムでログを送信するfluentdに対し、Embulkは定期実行や一度だけの実行に利用するものとされています。

例えばDBからcsvファイルとしてデータを落としたいものの、日次で取得できれば十分な場合などに使えそうですね。


とりあえず試してみたい方は下記のテスト実行手順を参考にしてみてください。サンプルデータの作成コマンドが用意されているので、試してみる敷居は低くなっています。
https://github.com/embulk/embulk#trying-the-example


ここからは、実際にDB（より具体的に言うとMysql）から、csvファイルとしてデータを落としてみます。
ちなみに今回はEmbulkの仕組みや、設定に関して詳しい説明はしません。（分かりやすい解説サイトもたくさんありますので…）

Embulkを使ってみて、こんなことができるだなという感じを掴んでもらればいいなと思っています。

実際にやってみる

特徴として挙げたように、Embulkはプラグインによってインプットやアウトプットの幅を広げることができます。
まず、WordPressのDBとして利用されているMySQLからデータを抜き出せるように、"embulk-input-mysql"をインストールします。

[embulk]# embulk gem install embulk-input-mysql 2015-05-11 02:32:29.417 -0400: Embulk v0.6.2 Fetching: embulk-input-mysql-0.4.0.gem (100%) Successfully installed embulk-input-mysql-0.4.0 1 gem installed

これでEmbulkを使ってMysqlのデータを取り出すことができるようになりました。

次にymlファイルを編集します。
ymlファイルとは、Embulk実行時にインプットにするいわば設計図にあたるファイルで、これによってインプットの種類や内容、同様にアウトプットの種類や内容、データの加工方法について記載します。