ラベル A-AUTO 50 の投稿を表示しています。 すべての投稿を表示
ラベル A-AUTO 50 の投稿を表示しています。 すべての投稿を表示

2015年8月27日木曜日

コストを掛けずにサーバマシンの電源ON/OFFのスケジューリングを自動化する

こんにちは、渡辺です。


皆さんは、定期的なコンピュータの起動停止はどうされていますか?

数台だったらまだよいですが、コンピュータの台数が多くなるとこれらを手動で行う労力はバカになりませんね。
もちろん、数台であっても手動で行うには、深夜や早朝に時間を拘束されることになります。

みなさんも何かしらのツールを利用されている方が多いのではないかと思いますが、そのためだけに高価なツールを利用していたり、完全自動化となっていなかったりしませんか?

そこで、今回は、まだ自動化されていない方も、既に自動化されている方にも Wake On Lanを用いリモートからサーバマシンの電源ON/OFFを自動化する手順について書いていきます。

イメージはこんな感じです。



以下のとおり、大きく2つのパートに分けて書いていきます。

  1. 電源ON/OFFバッチの準備
  2. A-AUTOでの自動化手順


1. 電源ON/OFFバッチの準備

先ずは、電源ON・OFFのバッチファイルの準備です。


電源OFFバッチ
poweroff.batというファイル名で作成しておきます。

@echo off
echo ### Shutdown Start ###

set RC=99

if "%1"=="" (
  goto PARAM_INVALID
)
set NAME=%1
echo ### Shutdown Target = %NAME% ###


shutdown /m %NAME% /s

if not "%ERRORLEVEL%" == "0" (
  goto SHUTDOWN_FAILED
) else (
  set RC=0
  goto END
)

:PARAM_INVALID
echo ### parameter invalid.
set RC=4
goto END

:SHUTDOWN_FAILED
set RC=%ERRORLEVEL%
goto END

:END
echo ### Shutdown End rc=%RC% ###

exit %RC%



電源OFFは、Widnowsのshutdown を利用します。
上記バッチでは、自動化時に汎用性を持たせるため、電源をoffするコンピュータ名(またはIPアドレス)をパラメータで渡すようにしています。



電源ONバッチ
poweron.batというファイル名で作成しておきます。

@echo off
echo ### Power On START ###

set RC=99

if "%1"=="" (
  goto PARAM_INVALID
)
set PORT_NO=%1

if "%2"=="" (
  goto PARAM_INVALID
)
set IP=%2

if "%3"=="" (
  goto PARAM_INVALID
)
set SUBNET=%3

if "%4"=="" (
  goto PARAM_INVALID
)
set MAC_ADDR=%4

echo ### Power On Target: Port=%PORT_NO% Ip=%IP% SubNet=%SUBNET% MAC_Addr=%MAC_ADDR% ###

"C:\BSP\AUW\BIN\poweron.exe" -p=%PORT_NO% %IP% %SUBNET% %MAC_ADDR%


if not "%ERRORLEVEL%" == "0" (
  goto POWERON_FAILED
) else (
  set RC=0
  goto END
)

:PARAM_INVALID
echo ### parameter invalid.
set RC=4
goto END

:POWERON_FAILED
set RC=%ERRORLEVEL%
goto END

:END
echo ### Power On  END rc=%RC% ###
exit %RC%




電源ONは、上記サンプルでは自社作成した poweron.exe というツールを利用しています。

また、上記バッチでは、自動化時に汎用性を持たせるため、UDPのポート番号、IPアドレス、サブネットマスク、MACアドレスをパラメータで渡すようにしています。

電源ON用のフリーツールはいろいろとあるので、任意のツールをご利用いただければと思います。
ちなみに、フリーツールの使用が禁止されているお客様の場合、こちらからご連絡いただければ、弊社から提供に関してのご連絡をさせていただきますので、お気軽にご相談ください。



  • 上記バッチで電源ONするマシンのMACアドレス、IPアドレスなどを渡す必要がありますが、以下のコマンドで確認可能です。
     ipconfig /all
  • 電源ONするマシンは、有線LANで繋がれている必要があります
  • マジックパケットを送信するために、BIOSやデバイスマネージャにて設定する必要があります
    以下のサイトなどを参考に設定を行ってください
    http://www.atmarkit.co.jp/ait/articles/0602/25/news014.html


2. A-AUTOでの自動化手順

ここからは、準備したバッチファイルをA-AUTOで自動化する手順について記載します。


2015年7月7日火曜日

個人情報流出問題にみる、標的型攻撃の脅威と情報セキュリティを考える上で大切なこと

こんにちは。

鷲尾です。

今は梅雨真っ盛りで、どうも天気がパッとしないですね。
天気だけでなく、湿度も高くてジトジトしていますが、実は湿度と気温は大きく関連しています。

なにをいまさらと思うかもしれませんが、湿度が高ければ高いほど暑く感じ、低ければ低いほど寒く感じます。夏は気温が高いうえに湿度も高く、冬は気温が低いのに乾燥していて湿度も低いため、より寒く感じるということなんですね。

ということは、室温をただ下げるのではなくて一緒に除湿機も使うとより涼しくなるということですね。(まぁエアコン自体、除湿もしてくれるんですけどね・・・)


さて、みなさんマイナンバー制度はもうご存知ですよね。
以前このブログでも軽く取り上げていますが、Googleトレンドを見てみると、ここ最近急に気になっている人が多いようです。

マイナンバーに関しては、先日の日本年金機構の個人情報125万件流出の件がありましたね。あれ、メールに記載されていた怪しい誘導URLをポチっと押してしまったことが直接の原因ではあるようですが、他にもまずいことがあったようですね。

とりあえず、今のところ今後のマイナンバー制度の施行スケジュールにあまり変化はないようですが、どうなんでしょう・・・


そこで今回は、日本年金機構の個人情報流出問題と照らし合わせながら、「標的型攻撃の脅威」と、「いかにサイバー攻撃に遭わないようにするか」、そして「情報セキュリティを考える上で大切なこと」について、書いていきたいと思います。


■標的型攻撃の脅威
今回の個人情報流出問題の原因は、"それっぽいメール"に書いてあった"それっぽいURL"を開いてしまったことが原因です。

ネット上では、「そんな怪しいURLすぐにわかるだろ」「業務に関係ないメールだと気が付かないほうがおかしい」といった意見もみられます。確かに、標的型攻撃ではなく、不特定多数に送るような"明らかに怪しい内容のメール"であれば、すぐに気がついたかもしれません。

しかし標的型攻撃の恐ろしいところは、実在する会社、部署名、名前、それに送信先の名前(○○様 など、自分の名前)などが正確に記載してあることです。

普段やりとりしているお客様の名前や、会社の上司を名乗るメールで、内容もおかしくなく、添付されているファイル名もなんら不審に見えないメールが届いたとして、みなさんは本当に簡単にわかるでしょうか。

標的型攻撃で作成されるメールは非常に巧妙で、こちらがファイルを開くことになんら懸念がないよう、うまーく作られているのです。




2015年6月30日火曜日

Drive REST APIを使ってJavaでGoogle Driveにファイルをアップロードする方法

こんにちは

鷲尾です。
このブログ記事、一度消えてしまって倒れそうになりました。
こんなことあるんですね・・・


さ、気を取り直してもう一度書きましょうか!


突然ですが、みなさんGoogleDrive使ってますか?
Google Driveが有名になる前は、Dropboxを使っていたという方も結構多いのではないでしょうか(Dropboxももちろん現役バリバリです!)

私もGoogle Driveは日々の業務で使いますし、私の周りではとりあえずドライブにあげておいたり、スマホからもファイルを確認したいといった場合によく使われてるようです。

そんなGoogle Driveですが、実は様々な言語でGoogle Drive内のファイルを操作できるAPIがGoogleから提供されています。

私もJava用のAPIを使って試してみようと思ったのですが、何箇所かひっかかかってしまった箇所がありました。

そこで今回は、Google Drive上にファイルをアップロードすることを目標に、APIの導入から実行確認までを整理していきたいと思います。



それでは、以下の流れで順に説明していきたいと思います。


1.目標
2.使用するAPI
3.Drive REST APIを実行するための準備
4.開発環境での準備
5.動作確認



1.目標
今回は、ローカル環境にある"LocalDocument.txt"というテキストファイルを"DriveDocument : 作成日時"という名前でGoogle Drive上にアップロードすることを目標とします。


2.使用するAPI
ここまでAPIの正式名称が出てきていませんでしたね。
今回使用するAPIの名称は、「Drive REST API」というものです。このDrive REST APIを使用すると、Google Drive上のファイルの一覧を取得したり、ファイルをアップロードしたりといったことが出来ます。Drive REST APIは様々な言語に対応していますが、今回はJavaを使って開発を行います。他の言語を確認したい方は、こちらから確認してください。
https://developers.google.com/drive/web/about-sdk
https://developers.google.com/drive/web/manage-downloads


3.Drive REST API実行をするための事前準備
Drive REST APIIを使用するためには、事前にいくつかの準備が必要です。まずは、APIを使用するための準備を行います。

■必要なもの
・Google アカウント
・開発環境
・プログラム実行用の外部Jarファイルのダウンロード
・Drive REST APIの使用許可設定
・認証情報

3-1.Googleアカウント
当然ですが、Googleアカウントが必要です。Google Driveを使用している方は既にお持ちだと思いますが、まだGoogleアカウントを作成していない場合は、作成しておきます。

3-2.開発環境
この記事では、Eclipse 4.4を使用しています。他のバージョンでも動作するかとは思いますが、開発環境の違いで動作しない場合もあるかと思いますので、その際はEclipse 4.4でお試しください。

なお、Javaのバージョンは1.7以上である必要がありますので、ご自身の環境のJavaのバージョンを事前に確認しておいてください。

3-3.プログラム実行用の外部Jarファイルのダウンロード
Drive REST APIを使用するためのJarファイルが必要です。事前にリンク①から「google-api-java-client.zip」をダウンロードし、解凍しておいてください。

なお、「google-api-java-client.zip」内には含まれていない、Jarファイル(google-api-services-drive-v2-rev174-1.20.0.jar)がありますので、そちらはリンク②からダウンロードしてください。


リンク①:https://github.com/google/google-api-java-client
リンク②:http://mvnrepository.com/artifact/com.google.apis/google-api-services-drive/v2-rev174-1.20.0


3-4.Drive REST APIの使用許可設定
さて、ここまでダウンロードしたりアカウントを作成したりという作業が多かったと思いますが、
ここからは「Google Developers Console」という、Google が開発者向けに提供しているサイトから、操作を行います。

Google Developers Consoleでは、認証情報の発行や削除、APIの使用許可設定などを管理します。AWSやAzureを触ったことがある方は、なんとなくああいった管理画面と近いイメージです。

Google Developers Consoleには、ここからアクセスします。
https://console.developers.google.com

初めてアクセスする方は、プロジェクトを作成する必要があります。お好きな名前でプロジェクトを作成してください。ここでは例として、"PYPROTEST"というプロジェクトを作成しています。
プロジェクトを作成すると、以下の様な画面になると思います。




 画面左のメニューから、「APIと認証」→「API」を開くと、以下のようにAPIの一覧が表示されると思います。その中から、Drive APIを選択します。




画面ではDrive APIが既に有効になっているのでこのようになっていますが、有効になっていない場合は"APIを有効にする"をクリックしてください。




これでDrive REST APIの使用許可設定が完了しました。
続いて、認証情報の発行と取得です。


3-5.認証情報
認証情報は、「認証情報」画面から発行します。
初めに、APIの使用設定と同じく画面左メニューから「APIと認証」→「認証情報」を開きます。


そうすると、以下の様な画面になるかと思います。ここで「新しいクライアントIDを作成」を選択すると、アプリケーションの種類を聞いてきますので、"インストールされているアプリケーション"を選択します。インストールされているアプリケーションの種類は"その他"に設定します。





「クライアントIDを作成」を選択すると、新しくクライアントIDが作成されます。
(同じ画像に見えるのは気のせいです。)




ここで表示されている、"クライアントID""クライアントシークレット""リダイレクトURI"は、後ほど使用しますので、メモ帳などにメモしておくと楽です。


これで、Drive REST APIの実行に必要な準備が完了しました。


2015年6月23日火曜日

Azureのインスタンスサイズの変更をスケジューリングしインスタンスサイズを最適化する

こんにちは。

また鷲尾です。


私は車が好きなんですが、最近の新型デミオ、非常にかっこいいです。
マツダの鼓動デザイン、いいですねぇ。クリーンディーゼルの伸びるような加速に、同じBセグメントの中では群を抜く欧州車に勝るとも劣らないエクステリアの良さ。ガゾリン車にはガソリン車の良さがありますが、このデミオの真価は ・・・ 

すみません、ここらへんでやめておきましょう。


さて、本題に戻ります。

以前、Azureのインスタンスを自動で起動・停止をして、コストを最適化しましょうという内容のブログでもご紹介したように、Azureでは、インスタンスを使用していた時間で課金がされます。
しかし、実は使用するインスタンスの"サイズ"によっても課金額が変わり、またこのインスタンスサイズは自由に変更することができるのです。

通常の運用では、提供するサービスを安定的に提供するために、日々の監視実績データを基にサービスへの負荷状況の分析を行い、システムリソースの調整を行われると思います。

しかし、「この時間帯だけアクセスが集中して負荷がかかる」、「スペックを上げて処理をしたい」という時期にその都度手動でインスタンスサイズを変更していたとしたら、それは効率がいいとはいえませんよね。

一般的に、クラウド環境で処理能力を向上させる手段としては、「スケールアウト」と「スケールアップ」がありますが、今回は、負荷が高まるサイク ルと、どれくらいのスペックが必要であるかを分析結果から導き出した際に、「スケールアップ」で対応するといった際の自動化について説明していき ます。

サイクルとしては、例えば「毎週金曜日の特定の時間帯(数時間)」、「毎月特定の期間(数日間)」「毎年特定の期間(1、2カ月のみ)」といったように、様々なサイクルが考えられます。

特に、決まったシーズンだけ、手動でインスタンスのスケールアップをしているという方は、有効にご活用いただけます。


構成は、インスタンスサイズを変更するスクリプトとそれを呼び出すバッチファイルを用意し、その実行をA-AUTO 50で制御する下記のようにシンプルな構成です。





ここからはインスタンスサイズの変更スクリプトとバッチのサンプル、そしてA-AUTO 50への登録方法について記載します。今回Windows PowerShellで作成するスクリプトは、スクリプト単体でも動作しますが、今回は自動化のためにA-AUTOとの連携を行うので、バッチファイルからPowerShellを呼び出す構成としています。

作成するファイルは、以下の2つです。
・インスタンスサイズ変更バッチ(インスタンスサイズ変更スクリプトの呼び出しを行います)
CHANGEAZ.bat

・インスタンスサイズ変更スクリプト
ChangeInstanceSize.ps1


※ダウンロードする各種サンプルは、2015年6月現在のインターフェースを基に記載しています。提供元でインターフェースが変更されるとことがありますので、最新の情報は各提供元でご確認ください。


なお、インスタンスサイズ変更スクリプトを実行するためには、事前にAzureの認証(クレデンシャル)が済んでいる必要があります。
クレデンシャルの認証については、以前のブログ(3.認証情報(クレデンシャル)の設定と、動作確認)をご参照ください。

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


2015年6月18日木曜日

AWSのインスタンスタイプの変更をスケジューリングしインスタンスタイプを最適化する

こんにちは、井下です。

梅雨入りしたという割には日差しの強い日が多いのですが、昨年も一昨年も同じようなことを感じていたので、梅雨とはそういうものなんだと思うようにしました。

はじめに

以前のブログでインスタンスタイプの最適化を図ろうという内容をご紹介しましたが、今回は"いつ"インスタンスタイプを上げるべきか(=スペックを上げるべきか)が分かっていて、その手順を自動化したい!というケースでの解決方法をご紹介します。

特に、決まったシーズンだけ、手動でインスタンスのスケールアップをしているという方は、有効にご活用いただけます。


構成はインスタンスタイプ変更バッチを用意し、その実行をA-AUTO 50(もしくは他のジョブ管理ツール)で制御する、下記のようにシンプルな構成です。



ここからはインスタンスタイプ変更バッチのサンプルと、A-AUTO 50への登録方法について記載します。

2015年6月16日火曜日

【Azure】 可用性セットとリソースグループ、ロードバランサとオートスケーリングの関係性について

みなさんこんにちは。


あの鷲尾です。


最近は年金のセキュリティ問題で騒がしくなっていますね。
メールを開いて、明らかにあやしいURLを信頼してしまって開いてしまったとのことですが、
これはどこの会社でも起きうることですね。

特に、社員のITリテラシに偏りがある企業や昔からのやり方を変えていない企業、もしくは同じ作業を同じ人が同じ技術で行っている場合などは、特にITリテラシー(情報セキュリティリテラシー)が偏ってしまうのではないかと思います。

この事件の余波はマイナンバー制度にももちろん大きく影響し、マイナンバー制度の採択にもいろいろと問題が発生していますね。この問題については近々追って触れたいなと思います。


さて、先日は、Azureのインスタンス起動と停止をA-AUTO 50で最適化して、コストを削減しましょう!という記事を書きました。

その際、Azureのことを調べていく上で、「可用性セット」「ロードバランサ」、「リソースグループ」「負荷分散エンドポイント」といったキーワードがたくさん出てきまして、初心者の私にはこんがらがってしまい、概念を理解するのが非常に大変でした...


そこで今回は、以上4つのAzureの機能について、なるべくわかりやすく紹介していきたいと思います。


※私も勉強中なので、記事に間違いなどがあればご指摘願います。



1.可用性と可用性セット

■そもそも可用性とは
可用性とは、一言でいうと「システムの壊れにくさ」です。
例えば、あるWebサービスがあるとします。このWebサービスは、サーバA上で動作しています。この状態でサーバAが壊れてしまった場合、当然ですがWebサービスは提供できません。サーバ1台で動かしていて、その1台が壊れた時の対策も特にしていない場合、これは可用性が低いと言えます。

では、サーバAの他に待機用サーバBを用意しておき、なにかあったらサーバBに切り替えよう!という体制をとっていた場合はどうでしょう。サーバAになにか障害などが発生したとしても、待機用のサーバBがWebサービスを提供できるため、Webサービスの提供は止まりません。これは先ほどの例に比べて可用性が高いと言えます。

まとめると、可用性とは、「どれだけいつでも使える状態にあるか」を意味しているということになります。

Azureでは、システムの可用性を高めるために「可用性セット」というものが用意されています。セットとありますが、深く意識しすぎてしまうとまたこんがらがってしまうので、はじめは「そういう名前なんだ」と思っておけばよいかと思います。

■可用性セットとは
可用性セットというのは、「障害やメンテナンスで2台が同時に停止されないように予め指定しておくもの」のことです。
Azureは、インスタンスのアップデートやメンテナンスのために私たちが利用しているインスタンスを停止することがあります。これはAzure側で行うことなので私たちにはどうしようも出来ないのですが、この可用性セットを指定することで、少なくともインスタンス1台は停止されません。
※必ず1台は動作しているということです。
そうすることで、例えばメンテナンス時などにわざわざインスタンスを停止することを周知したりしなくて済むわけです。

ただし、この可用性セットは、あくまでも「Azure側」による操作(インスタンスのアップデートやメンテナンス、もしくはハード的な物理障害など)によってインスタンスを停止されてしまう場合にのみ有効な手段です。したがって、たとえ可用性セットを作成していたとしても、インスタンスが停止してしまうような操作(後述:インスタンスサイズの変更など)をユーザ自身で行なってしまうと、その間にAzure側のメンテナンスがあった場合にもう1台のほうが停止してしまう可能性があります。その点、注意しなければいけません。



ここまでで、可用性と可用性セットの説明になります。
可用性セットを設定しておくことで、急な障害などが発生したとしても、それに対応することができるというわけですね。
続いては、Azureの機能の代表格、オートスケールによるロードバランスです。


2015年6月3日水曜日

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がインストールされていません

サンプルバッチ

2015年6月2日火曜日

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: 収集したデータ出力に失敗しました

サンプルバッチ

2015年6月1日月曜日

AzureVMの起動・停止自動化によるコストの最適化【コマンドレット利用編】

みなさんこんにちは。
鷲尾です。

本日は第2回目【コマンドレット利用編】となります。

前回までのあらすじ
(第1回目はこちら → AzureVMの起動・停止自動化によるコストの最適化【準備編】
  • Windows Azure PowerShellをダウンロード、インストール
  • Azure PowerShellでコマンドレットが利用できるように認証
  • Get-AzureVMコマンドで、動作確認


今回は実際に起動・停止それぞれのスクリプトとそれを呼び出すバッチを書いて、実行していきます。

※ここでは検証用環境として、クラウドサービス名に「TestCS-001」、AzureVM名に「TestVM-001」を使用します。


5.使用するコマンド
今回使用するコマンドは、以下の3つです。

  • Get-AzureVM    -  指定したAzureVMの一覧や、ステータスを取得します。
  • Start-AzureVM   -  指定したAzureVMを起動します。
  • Stop-AzureVM  -  指定してAzureVMを停止します。コマンド末尾に"-force"オプションをつけることで、コンファームオプションを省略することが出来ます。


6.起動用バッチと起動用スクリプト
今回Windows PowerShellで作成するスクリプトは、スクリプト単体でも動作しますが、今回は自動化のためにA-AUTOとの連携を行うので、バッチファイルからPowerShellを呼び出す構成としています。

作成するファイルは、以下の4つです。

・起動用バッチファイル
・起動用スクリプトファイル
・停止用バッチファイル
・停止用スクリプトファイル

それでは順に説明していきます。
※ダウンロードする各種サンプルは、2015年6月現在のインターフェースを基に記載しています。提供元でインターフェースが変更されるとことがありますので、最新の情報は各提供元でご確認ください。


【起動用バッチ:STARTAZ.bat】
起動用バッチのサンプルはこちらからダウンロードできます。
起動用バッチの概要は、以下のとおりです。

◆処理概要
パラメータの数をチェックし、StartAz.ps1からのリターンコードを受け取ります。
また、起動用スクリプトからの戻り値をA-AUTO 50へ返却します。

◆パラメータ
クラウドサービス名と、AzureVM名の2つのパラメータを用意します。
第1パラメータ:クラウドサービス名(必須)
第2パラメータ:AzureVM名(必須)

◆リターンコード
0:正常に終了した(AzureVMが正常に起動した)
1:起動しようとしたAzureVMが既に起動していた
4:必須パラメータが入力されていない
8:AzureVMの起動に失敗した



STARTAZ.bat
@echo off
set date1=%date%
set time1=%time: =0%
set dt1=%date1% %time1%

echo %dt1:~0,19% ### AzureVM start batch started. ServiceName=%1,Name=%2
cd %~dp0
set PowerShellPath=C:\Windows\SysWOW64\WindowsPowerShell\v1.0\(※1)
set ScriptPath=C:\BSP\AUW\INSTALL\PRIMSCRIPT\(※2)

if "%1"=="" (
  goto PARAM_INVALID
)

if "%2"=="" (
  goto PARAM_INVALID
)

%PowerShellPath%powershell.exe -NoProfile -command "%ScriptPath%StartAz.ps1 %1 %2 ;exit $LASTEXITCODE"

set RC=%ERRORLEVEL%
goto END

:PARAM_INVALID
set date2=%date%
set time2=%time: =0%
set dt2=%date2% %time2%
echo %dt2:~0,19% ### parameter invalid.
set RC=4
goto END

:END
set date3=%date%
set time3=%time: =0%
set dt3=%date3% %time3%
echo %dt3:~0,19% ### AzureVM start batch ended (RC=%RC%). ServiceName=%1,Name=%2
exit %RC%


※1 PowerShellのパスを設定する際は、ご自身の環境に合わせて、以下のように設定します。

【32ビットOSの場合】
    C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe 
     
    【64ビットOSの場合】
    C:\Windows\Sysnative\WindowsPowerShell\v1.0\powershell.exe 

    64ビットOSでの注意点
    A-AUTO モニタは32ビットアプリケーションのため、32ビット版のpowershell.exeのパスを指定してください。
なお、OSによってパス中のSysnativeの部分が、SysWOW64など異なることもありますので、パスの名前を確認してください。


※2 スクリプトファイルの保存先を指定してください。

サンプルはA-AUTO 50のバッチファイル格納ディレクトリと同一にしています。


【起動用スクリプトファイル:StartAz.ps1】
起動用スクリプトのサンプルはこちらからダウンロードできます。
起動用スクリプトの概要は、以下のとおりです。

◆処理概要
起動用バッチから受け取ったパラメータを使用して、指定したサービス名とAzureVM名が実在するかどうかをチェックし、AzureVMが停止していれば起動コマンドを発行します。
起動コマンド発行後、指定回数以内(サンプルでは30秒毎に10回ステータスを確認します)にAzureVMが起動できたかチェックし、起動結果を返却します。

◆パラメータ
クラウドサービス名と、AzureVM名の2つのパラメータを受け取ります。
第1パラメータ:クラウドサービス名
第2パラメータ:AzureVM名

◆リターンコード
0:正常に終了した(AzureVMが正常に起動した)
1:起動しようとしたAzureVMが既に起動していた
4:必須パラメータが入力されていない
8:AzureVMの起動に失敗した



StartAz.ps1
Param(
  $servicename,
  $vmname
 )

$cnt = 0
$checkloop = 10
$checkspan = 30
$VM_STARTED_RC = 0
$ALREADY_STARTING_VM_RC = 1
$PARAM_INVALID_RC = 4
$FAILD_VM_START_RC = 8

#サブルーチン定義

#インスタンス起動完了
function VM_STARTED($FinTime)
{
    echo "$FinTime ### VM start successful."
    RETURN_END $VM_STARTED_RC
}

#既にインスタンスが起動していた
function ALREADY_STARTING_VM($ReceiveVMname,$FinTime)
{
    echo "$FinTime ### Start-AzureVM not called because vm name $ReceiveVMname was allready running."
    RETURN_END $ALREADY_STARTING_VM_RC
}

#クラウドサービス名が不正
function NOT_FOUND_CLOUDSERVICE($ReceiveServicename,$FinTime)
{
    echo "$FinTime ### No deployment found in service: $ReceiveServicename"
    RETURN_END $PARAM_INVALID_RC
}

#インスタンス名が不正
function NOT_FOUND_VM($ReceiveVMname,$FinTime)
{
    echo "$FinTime ### $ReceiveVMname is not exist."
    RETURN_END $PARAM_INVALID_RC
}

#一定時間内にインスタンスの起動が確認できなかった
function FAILD_VM_START($FinTime)
{
    echo "$FinTime ### VM start failed."
    RETURN_END $FAILD_VM_START_RC
}

#バッチへリターンコードを返却
function RETURN_END($ReturnBatchRC)
{
    EXIT $ReturnBatchRC
}


#メイン処理

#クラウドサービスから情報取得
$azurevminfo = (Get-AzureVM -ServiceName $servicename)

#クラウドサービスの存在確認
if ($azurevminfo.length -eq 0)
{
    $time = get-date -Format "yyyy/MM/dd HH:mm:ss:ss"
    NOT_FOUND_CLOUDSERVICE $servicename $time
}

#インスタンスの存在確認
$azurevminfo = (Get-AzureVM -ServiceName $servicename -Name $vmname)
if ($azurevminfo.length -eq 0)
{
    $time = get-date -Format "yyyy/MM/dd HH:mm:ss"
    NOT_FOUND_VM $vmname $time
}
   
#クラウドサービス、インスタンス名がともに正しい
#インスタンスステータス確認
if ($azurevminfo.InstanceStatus -ne "StoppedDeallocated")
{
    $time = get-date -Format "yyyy/MM/dd HH:mm:ss"
    ALREADY_STARTING_VM $vmname $time
}

#インスタンス起動
Start-AzureVM -ServiceName $servicename -Name $vmname
$time = get-date -Format "yyyy/MM/dd HH:mm:ss"
echo "$time ### VM starting..."

#起動確認(<)
while ($cnt -lt $checkloop)
{
    # 30秒スリープ
    Start-Sleep -s $checkspan
    
    # 結果を変数に格納
    $time = get-date -Format "yyyy/MM/dd HH:mm:ss"
    echo "$time ### Checking vm status..."
    $azurevminfo = (Get-AzureVM -ServiceName $servicename -Name $vmname)
    $time = get-date -Format "yyyy/MM/dd HH:mm:ss"
    $str1 = "$time ### VM status : "        
    $str2 = $str1 + $azurevminfo.InstanceStatus
    echo $str2
    if ($azurevminfo.InstanceStatus -eq "ReadyRole")
    {
       $time = get-date -Format "yyyy/MM/dd HH:mm:ss"
       VM_STARTED $time
    }
    $cnt++
    $time = get-date -Format "yyyy/MM/dd HH:mm:ss"
    echo "$time ### VM status check count = $cnt"

#スタートに失敗  
$time = get-date -Format "yyyy/MM/dd HH:mm:ss"     
FAILD_VM_START $time 



【停止用バッチファイル:StartAz.ps1、停止用スクリプトファイル:StartAz.ps1】
停止用バッチ、停止用スクリプトは基本的に起動用ファイルと動作は変わらないので、説明は割愛します。なお、各ファイルの詳細はサンプルを参照してください。

停止用バッチのサンプルはこちらからダウンロードできます。
停止用スクリプトのサンプルはこちらからダウンロードできます。



※ バッチサンプル、スクリプトサンプルの拡張子は、".txt"となっています。
使用する際は、それぞれ以下のようにリネームしてご利用ください。

 ・起動
 STARTAZ.txt  → STARTAZ.bat
 StartAz.txt   → StartAz.ps1
 
 ・停止
 STOPAZ.txt  → STOPAZ.bat
 StopAz.txt    → StopAz.ps1



◆手作業による実行
それでは、A-AUTO 50と連携させる前に、手動でバッチファイルとスクリプトファイルを実行して、正しく動作することを確認してみましょう。


2015年5月29日金曜日

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


2015年5月27日水曜日

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

みなさんこんにちは。

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


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


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

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

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

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

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

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






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

第1回:準備編
第2回:コマンドレット利用編(A-AUTO設定含む)


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

・接続元(ローカル環境)
Windows Server 2008R2

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


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

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

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


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


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

1.Windows Azure PowerShellとは
2.Windows Azure PowerShellのダウンロードとインストール
3.認証情報(クレデンシャル)の設定と、動作確認
4.Windows PowerShellの実行ポリシー設定
5.自動化するための前提


1.Windows Azure PowerShellとは

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

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


2.Windows Azure PowerShellのダウンロードとインストール
(1)ダウンロード
Windows Azure PowerShellを、公式ページからダウンロードします。
"インストール"をクリックするとダウンロードが始まるので、任意の場所にダウンロードします。




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




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



【同意する】をクリック



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




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

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


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

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


2015年4月17日金曜日

AWS EC2インスタンス起動・停止自動化によるコストの最適化【自動化編】

こんにちは、井下です。
本日は、集中連載企画の第3回目【自動化編】となります。


前回のあらすじ
● ステータス確認、起動・停止、Elastic IPの関連付けといったAPIを実際に実行してみる
● インスタンスの起動・停止バッチを作成し、そのバッチで実際にインスタンスを起動・停止してみる
※ 過去のブログはこちらをご参照ください。
  第1回 準備編



今回は集中連載企画の最終回ということで、いよいよA-AUTO 50でインスタンスの起動・停止のスケジュール、実行を自動化し、最適化を図ります。


今回のAgendaは次のとおりです
  9.カレンダーの作成
 9.1 年間定休日を定義する
 9.2 カレンダーを作成する
10.スケジュール情報の登録
11.ジョブネットワーク情報の登録
12.ネットワークスケジュールの作成
13.バッチファイルの配置
14.インスタンスの起動・停止の監視


では、さっそく説明に入っていきますが、以降の説明は、既に基本ライセンスのインストール手順に従って、インストールが完了している前提で話を進めます。
このため、予めインストール手順に従ってインストールを完了させておいてください。

・ Webクライアントにログインできる状態にある
・ 監視ウィンドウのテンプレートを作成済みで監視画面が表示できる状態にある
・ 動作確認まで完了している



9.カレンダーの作成
はじめに、お客様独自の営業日カレンダーを作成します。

先ずは、カレンダー作成を考えるにあたり、いつが休みかを決めていきます。
一般的な休みの種類は、大きく以下の3つに分類できると思います。

(a) 週間定休日 : 毎週土曜日や毎週日曜日といったように毎週繰り返しやってくる休日
(b) 年間定休日 : 国民の祝日など毎年繰り返しやってくる休日
(c) 不特定の休日 : 会社固有の休日
             例えば、夏季休暇や年末年始休暇、GWを大型連休にするために
             休みを振り替えたりすることがあると思います。
             ※ 年末年始休暇などは、企業によっては毎年期間が同一だったりもしますね


次にA-AUTOのカレンダーを作成するうえでの休日の種類は次のようになります。

(ア) 週間定休日 : 毎週土曜日や毎週日曜日といったように毎週繰り返しやってくる休日
(イ) 年間定休日 : 毎年n月n日と言うように日付が固定され毎年やってくる休日
            元旦(1月1日)、建国記念日(2月11日)などがこれに相当します
            また、年末年始休暇が毎年12月29日~1月4日と固定されているようであれば、
            これも年間定休日として考えます
(ウ) 不特定の休日 : ハッピーマンデーや春分の日、秋分の日といった毎年日付が変わる国民の休日や、
            夏季休暇、GWの連休設定など、月日で固定化できない休日がこれに該当します

先ずは、一般的な休みの種類とA-AUTOの休日の種類で若干異なる部分があることが分かっていただけたかと思います。
※ 現時点でA-AUTOでは、”毎年n月のn週目のn曜日”といったハッピーマンデーには未対応としているため、不特定の休日に分類します




9.1 年間定休日を定義する
先ずは、A-AUTOの休日の考え方のうち(イ)の年間定休日を登録します。
年間定休日は、マスタメンテナンスメニュー[ホリデー]-[休日]を選んで表示される[休日定義一覧]から登録します。

A-AUTO 50をインストールした状態では、日付固定の国民の休日は予め登録してあります。
このほかに会社固有の年間定休日があれば、はここで登録してください。

  ※ 旧 日付固定の国民の休日も登録されているので、不要でしたら削除してください



会社固有の年間定休日は、[新規登録]ボタンをクリックして登録します。

”日付”フィールドで月日を入力または選択してください。
下記のサンプル画像は、「1月2日」を登録しています。”コメント”フィールドに「年末年始休暇」など後から見て分かるようなコメントを入れておくとよいです。


なお、[振り替え]チェックボックスがありますが、指定した日付がカレンダー上休日の日曜日であった場合、休日を翌日に自動振り替えするか否かを選択するためのものです。
※ 上記サンプル画像では、会社固有の休日であるため[振り替え]の設定は行っていません

下の画像は、同様に「1月3日、1月4日、12月29日~12月31日」も休日として定義した後の画像となります。



※ [振り替え]を行う設定をしている休日は、一覧表示をしたときに、日付の右横にアイコンが表示されます


9.2 カレンダーを作成する
お客様固有のカレンダーを作成します。
カレンダーは、マスタメンテナンスメニュー[ホリデー]を選んで表示される[ホリデー定義一覧]から登録します。

2015年4月15日水曜日

AWS EC2インスタンス起動・停止自動化によるコストの最適化【API利用編】

みなさんこんにちは。
鷲尾です。

本日は、短期集中連載企画の第2回目【API利用編】となります。


前回までのあらすじ

● ローカル環境に Amazon EC2 API Toolsを導入
● インスタンスの操作に必要となる情報を収集し、環境変数を設定するバッチファイルを作成
● 作成したバッチファイルとec2ver”コマンドでAmazon EC2 API Toolsが利用できることを確認

今回は「API利用編」ということで、インスタンスのステータスの確認、インスタンスの起動・停止が行えることを確認し、最終的に起動・停止用のバッチファイルの作成・実行まで行っていきます。

※なお、コマンドは各環境変数に値がセットされていないと実行することが出来ないため、ここでは、前回作成した環境変数設定バッチ(envSetup.bat)を実行した状態(環境変数に値がセットされている状態)であることを前提としています。

6.インスタンスのステータス確認
先ずは、ターゲットとするインスタンスIDの操作が行えることを確認するために、特定インスタンスのステータスを取得します。

ステータスを確認する場合は、以下のコマンドを使用します。
ec2-describe-instances インスタンスID


コマンドを投入したときの表示は以下のような表示となります。
■起動時



ここまでくれば、もうAPIでの起動・停止ができたも同然です!



7.インスタンスのStartStop
次は、いよいよインスタンスの起動・停止を制御してみます。
それでは、停止状態にあるインスタンスを再起動(Start)させてみましょう。

再起動させる場合は、以下のコマンドを使用します。
ec2-start-instances インスタンスID                                                                    


startコマンド投入サンプル

      ※ i-XXXXXXXXには、実在するインスタンスIDを指定してください


今度は、起動しているインスタンスを停止(Stop)させてみます。
停止させる場合は、以下のコマンドを使用します。

 
ec2-stop-instances インスタンスID       

stopコマンド投入サンプル


これで、APIからインスタンスの起動・停止が行えるようになりました!


なお、起動・停止用のAPIは、非同期処理となっています。このため、ec2-start-instances /ec2-stop-instances から処理が戻された時点で、指定したインスタンスの起動・停止は完了していません。
このため、ec2-start-instancesec2-stop-instancesを利用した場合、正しく起動・停止したかは、前述のec2-describe-instancesコマンドなどを利用して確認する必要があります。






8.Elastic IPアドレスの関連付け(EC2 Classicの場合のみ)
EC2(Classic)では、インスタンスを停止するとその時点で、インスタンスとElastic IPの関連付けが解除されてしまいます。
このため、停止・起動の自動化を行う場合、インスタンス再起動後に再度Elastic IPの関連付けを行う必要があります。
Elastic IPの関連付けには、以下のコマンドを使用します。
ec2-associate-address -i インスタンスID Elastic IP

Amzon EC2 VPCの場合は、インスタンスを停止してもElastic IPアドレスは開放されません。




9.起動・停止用バッチファイルを作成・実行してみる
インスタンスを起動・停止するためのバッチファイルを作成します。
ここでは、起動および停止バッチをインスタンス毎に作成しないよう、1つのバッチファイルを共用する前提でバッチファイルのパラメータを定義します。

【起動バッチ : ec2start.bat】

起動バッチのサンプルはこちらからダウンロード出来ます。
作成するバッチの概要は以下のとおりです。
パラメータ
1つのバッチファイルで複数のEC2インスタンスを起動するバッチとするため、パラメータを3つ用意します。
1パラメータ : リージョンコード (必須)
2パラメータ : インスタンスID  (必須)
3パラメータ : Elastic IP     (任意)

EC2 Classic環境で、Elastic IPアドレスの関連付けをする前提としているため第3パラメータを用意していますが、EC2 VPCであれば停止後にインスタンスとElastic IPアドレスとの関連付けが解除されないので第3パラメータは不要です。

◆リターンコード
  0 : インスタンスの起動に成功した
  1 : 起動しようとしたインスタンスIDが既に起動しているため、処理を中止した
  4  必須パラメータが入力されてない
  8  インスタンスへの接続に失敗した
12  Elastic IPアドレスの関連付けに失敗した(起動バッチのみ)
16 :インスタンスの起動に失敗 した

第3回の自動化編では、リターンコードが0、もしくは1であれば正常とみなすように設定します。