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

こんにちは

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


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


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

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

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

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

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



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


１．目標
２．使用するAPI
３．Drive REST APIを実行するための準備
４．開発環境での準備
５．動作確認



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の実行に必要な準備が完了しました。

Embulkを使ってWordPressのデータを出力してみる

はじめに

こんにちは、井下です。

今までに何度かEmbulkについて書いてきましたが、プラグインの使い方が主な内容だったので、今回はEmbulkを使って何をするかに焦点を当ててみようと思います。

そこでタイトルの通り、Embulkを使い、ウェブサイトやブログの構築によく利用されているWordPressからデータを出力してみます。

WordPressは元々エクスポート機能を備えていますが、定期的に出力しているようなケースであれば、Embulkを使うことで作業の効率化を見込めます。

例えば、毎日のユーザ登録数の推移を見てみたい、という場合、毎日管理画面にログインしてデータをエクスポートするより、自動でデータがファイルにまとめられていて、そのファイルを見るだけになっている方が楽ですよね。

そういったちょっとした手間を省けるようになります。

※過去の関連ブログ
・データ転送のOSS「Embulk」を使って、MysqlからデータをCsvに落としてみる
・embulk-filter-evalでどんなデータ変換ができるのか試してみる

Embulkの準備

Embulkをまだインストールしていないのであれば、下記のクイックスタートを参考にして、Embulkが利用できるように準備します。
https://github.com/embulk/embulk#quick-start

Embulkについての情報を集めたいのであれば、下記のまとめを利用しましょう。
http://qiita.com/hiroysato/items/397f36c4838a0a93e352

Embulkはデータのインプット・アウトプット先をプラグインによって拡張する仕組みになっています。WordPressは各データの管理をMySQLで行っているため、MySQLをインプット先にできるように、embulk-input-mysqlプラグインをインストールしておきます。
https://github.com/embulk/embulk-input-jdbc/tree/master/embulk-input-mysql

embulk-input-mysqlプラグインはEmbulkをインストールした後、下記のコマンドによってインストールできます。

C:\～>embulk gem install embulk-input-mysql

WordPressのテーブル設計について

Embulkの準備が完了した後は、WordPressからどんなデータを取得するのかを決めておきます。
下記のWordPressの標準インストールで作成されるテーブル一覧を参考にして、欲しいデータがどのテーブルのどのカラムにあるのかを確認します。
http://wpdocs.osdn.jp/データベース構造#.E3.83.86.E3.83.BC.E3.83.96.E3.83.AB.E4.B8.80.E8.A6.A7

なお、プラグイン等の拡張によって追加された機能は、別途テーブルを作成しているので、その場合は機能ごとに対応したテーブルを調べる必要があります。

今回は例として、標準インストールで作成されるusersテーブルのID、user_login、user_registeredの3カラムを出力対象として話を進めていきます。

Embulkの実行

Embulkの実行は基本として、下記のコマンドで行います。

C:\～>embulk run config.yml

"config.yml"を入力パラメータとするような形式です。この"config.yml"にインプット・アウトプット先などを定義します。（"config.yml"は固定名ではなく、任意の名前に変更しても大丈夫です。）

サンプルとして、usersテーブルのID、user_login、user_registeredをcsvファイルに出力する設定のymlファイルを記載します。

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

こんにちは。

また鷲尾です。


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

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


さて、本題に戻ります。

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

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

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

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

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

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


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

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

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

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


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


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

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

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

こんにちは、井下です。

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

はじめに

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

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


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

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

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

みなさんこんにちは。


あの鷲尾です。


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

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

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


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

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


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


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



１．可用性と可用性セット

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

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

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

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

■可用性セットとは

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

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



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

embulk-filter-evalでどんなデータ変換ができるのか試してみる

こんにちは、井下です。

少し前のブログで、OSSのEmbulkについて書いてみましたが、MysqlからCsvへの変換という無難な内容だったので、今回はあまり使用例がアップされていないプラグインにフォーカスしてみます。

フォーカスするプラグインは、データの変換をRubyのコードで定義できる"embulk-filter-eval"です。

embulk-filter-evalの概要

embulk-filter-evalは"FILTER"に分類されるプラグインで、"INPUT"でデータを読み込んだ後、"OUTPUT"にデータを渡す前に、データに変換処理を加えられます。
また、出力するカラムを選択できるので、不要なカラムを切り捨てることもできます。

データの転送に際して、ちょっとしたデータの加工をしたい場合や、決まったフォーマットへの変換処理に使えそうですね。

データの変換内容はRubyのコードで定義できるそうですが、具体的にどんなことができるのか、使ってみて分かったことを書いていきます。
なお、出力カラムの選択に関しては、下記の資料を見ればすぐに分かる設定ですので、今回は特に触れません。

インストール方法、ymlファイルの書式、出力カラムの選択方法などは下記のGitHubにアップされている資料をご参照ください。
https://github.com/mgi166/embulk-filter-eval

embulk-filter-evalの利用例

ここから具体的なデータ変換パターンについて、実際に試してみます。
 インプットのデータは"embulk example"で作成されるサンプルデータとし、ymlを編集する都度、"embulk preview config.yml"コマンドでどんな変換がされるのか確認していきます。
※どんな変換が行えるかの確認が目的なので、以降の利用例では計算の中身に深い意味は持たせていません

補足として、変換なしの"embulk preview config.yml"の結果は下記の通りです。
以降、embulk-filter-evalによる変換後の出力との比較として参考にしてください。

+---------+--------------+-------------------------+-------------------------+----------------------------+
| id:long | account:long |          time:timestamp |      purchase:timestamp |             comment:string |
+---------+--------------+-------------------------+-------------------------+----------------------------+
|       1 |       32,864 | 2015-01-27 19:23:49 UTC | 2015-01-27 00:00:00 UTC |                     embulk |
|       2 |       14,824 | 2015-01-27 19:01:23 UTC | 2015-01-27 00:00:00 UTC |               embulk jruby |
|       3 |       27,559 | 2015-01-28 02:20:02 UTC | 2015-01-28 00:00:00 UTC | Embulk "csv" parser plugin |
|       4 |       11,270 | 2015-01-29 11:54:36 UTC | 2015-01-29 00:00:00 UTC |                       NULL |
+---------+--------------+-------------------------+-------------------------+----------------------------+

数値の計算

GitHubにアップされている資料内にもありますが、手始めに数値計算から。
ymlファイルを次のように書き換えて、再度実行します。

filters: 
  - type: eval 
    eval_columns: 
      - id: value * 2
      - account: value / 3
      - time: value
      - purchase: value
      - comment: value

期待するデータの変換内容は

• idカラムの値が2倍になる
• accountカラムの値が3分の1になる

実行結果は次のようになりました。

+---------+--------------+-------------------------+-------------------------+----------------------------+
| id:long | account:long |          time:timestamp |      purchase:timestamp |             comment:string |
+---------+--------------+-------------------------+-------------------------+----------------------------+
|       2 |       10,954 | 2015-01-27 19:23:49 UTC | 2015-01-27 00:00:00 UTC |                     embulk |
|       4 |        4,941 | 2015-01-27 19:01:23 UTC | 2015-01-27 00:00:00 UTC |               embulk jruby |
|       6 |        9,186 | 2015-01-28 02:20:02 UTC | 2015-01-28 00:00:00 UTC | Embulk "csv" parser plugin |
|       8 |        3,756 | 2015-01-29 11:54:36 UTC | 2015-01-29 00:00:00 UTC |                       NULL |
+---------+--------------+-------------------------+-------------------------+----------------------------+

idカラムは期待通り2倍になっていますが、accountカラムは3分の1になったうえで小数点以下が切り捨てられてますね。整数同士の除算は整数になるRubyの仕様上、そうなっているのでしょうか。

Rubyの除算の仕様が原因だとすれば、除算している値のどちらかをfloatとして明示すれば、小数点以下も表示されるはずです。
そこで、ymlファイルを次のように書き換えてみます。

filters:
  - type: eval
    eval_columns:
      - id: value * 2
      - account: value / 3.to_f
      - time: value
      - purchase: value
      - comment: value

accountカラムの除算する数値を、floatとして明示しています。

ですが、結果は変わらず小数点が出ないまま…。
その後、色々試してみて分かりましたが、accountカラムの型がlong(整数)である以上、小数点以下は出ないようです。(accountカラムをdoubleにすると、最初のymlファイルでも小数点以下が表示されました)

embulk-filter-evalはデータ変換はするものの、根本的な型を変えたり、制約を越えられないようです。

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

サンプルバッチ

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

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

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

前回までのあらすじ
（第1回目はこちら　→　AzureVMの起動・停止自動化によるコストの最適化【準備編】）

• Windows Azure PowerShellをダウンロード、インストール
• Azure PowerShellでコマンドレットが利用できるように認証
• Get-AzureVMコマンドで、動作確認

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

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

５．使用するコマンド
今回使用するコマンドは、以下の３つです。

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

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

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

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

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

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

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

◆パラメータ
クラウドサービス名と、AzureVM名の２つのパラメータを用意します。
第１パラメータ：クラウドサービス名（必須）
第２パラメータ：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\（※１)

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名の２つのパラメータを受け取ります。
第１パラメータ：クラウドサービス名
第２パラメータ：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と連携させる前に、手動でバッチファイルとスクリプトファイルを実行して、正しく動作することを確認してみましょう。