cloud Archive

Japan AWS User Group (JAWS-UG) – Osaka勉強会 第3回に参加してきました。

すっかり恒例になってきたJAWS-UG Osaka勉強会に参加してきました。今回も濃いセッション満載で楽しかったです。会場提供頂いたテレビ大阪さんありがとうございました。

せっかく参加するならということで、今回は Selenium を使って AWS の課金情報を取得して、Twitter で投稿するという内容でLTをやってきました。

SeleniumでAWSへの愛を叫ぶ

当日は真面目なものとそうでないものの2つ発表ネタを持って行っていたのですが、発表前にこちらにしました。

スライドを用意していましたが、このタイトルの解説を延々と書いているだけなので表紙だけアップしておきます:D

SeleniumでAWS課金情報を取得する

やっていることは単純で、Selenium で AWSサイトにログインして、Account Actibityページで今月の課金（=愛）を取得、そしてそれをTwitterで投稿するだけです。

デモで使った Selenium テストケースのソースは以下です。（AWS アカウントのメールアドレスとパスワードは仮の値に変えています。）

ポイントは、課金情報をstoreTextで取得している点と、課金情報に含まれる単位（$）をJavaScriptで削除している点ですね。

Seleniumを使えば、単純なスクレイピングならこれだけでできます。

テストケースをxUnitのソースに変換して、Selenium RCと組み合わせると、cronやJenkinsなんかで定期的に課金情報を取得することも可能です。

みなさんも愛を確認して、叫んでみて下さい:D

雑感

• Beanstalk の PHP 対応が来るらしい！
• Hadoop / EMR 分かりやすかったです。
• Hadoop のデモは地味:D
• 決戦に参加できて勝てて良かった！
• 今回のLTは（自分以外）レベル高かったー。
• おっぱいぷるぷる。

春ということで、Amazon Web Services（AWS）をはじめてみませんか。

AWS盛り上がっていますね。2011年3月に東京リージョンができたことで、そろそろ触ってみようかなというPHPユーザの方も多いかと思います。

そんなあなたへ、AWSをはじめる際に役立つ情報をご紹介です。

1. AWSアカウントを新規作成して、EC2の利用申し込みを行う

まずAWSのアカウントを作成して、EC2の利用申し込みを行います。

手順については、AWSエバンジェリストの @KenTamagawa さんが書かれた以下の資料が参考になります。このとおりに進めていけば、おおよそ問題無いと思います。

進める中で自分が詰まった点は以下。

郵便番号、電話番号にはハイフンを

郵便番号、電話番号はハイフンが必要なので入力するようにして下さい。

書式は日本国内のもの、郵便番号8ケタ（ハイフン入り）、電話番号は12〜13ケタ（ハイフン入り）で大丈夫です。

電話にびびらない

EC2の利用申し込みでAmazonから電話がかかってくる場面があります。

実は、はじめてアカウントを作成して利用しようとした時は申込画面も英語版しか無かったので、英語な人から電話がかかってくるのかと思って、それはそれはびびっていました。気持ちの整理を付けるために2,3日かかった記憶があります:D

まあ冷静に考えてみれば分かりますが、人がかけてくるわけではなく、機械がかけてきます。電話を取るとアナウンスが流れるので、あとは画面に表示された暗証番号をプッシュで入力すればokです。（人がかけてくる場面を想像すると面白いですが:-p）

暗証番号を入力するとすぐに次の画面に遷移するので、これはこれで近未来な感じがして感動しました。

クレジットカードが必要

アカウント作成、EC2の利用申し込みは無料ですし、サービスを利用（EC2インスタンスを起動など）しない限りは費用は発生しませんが、クレジットカードの登録は必須となります。ご注意を。

2. EC2を触ってみる

では実際にブラウザでAWS Management ConsoleへアクセスしてEC2インスタンスを起動してみましょう。

この手順についても、@KenTamagawa さんが書かれた資料が参考になります。

補足としては以下の点あります。

SSHログインユーザ

このスライドのようにAmazon Linuxを利用する場合は「ec2-user」ユーザでSSHログインして下さい。他のOSで起動した際は、rootユーザでログインする場合もあるので間違えないようにご注意を。

SSHコマンドでログイン

SSHでログインするツールは、sshコマンドでも何でも良いです。その際はダウンロードした秘密鍵を -i で指定して下さい。

$ ssh -i /path/to/demo-key.pem ec2-user@PUBLIC_DNS_HOST

なお手元のMacではPublic DNSにあるFQDNを指定すると「ControlPath too long」というエラーが発生します。こういった場合は、Public DNSからIPを引いて、IP直で指定すればログインできます。（ただしIP変更が起こる場合があるので、可能ならFQDNでログインした方が良いです。）

$ dig ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com

xxx.xxx.xxx.xxx
$ ssh -i /path/to/demo-key.pem ec2-user@xxx.xxx.xxx.xxx

PHPのインストール

Amazon LinuxでPHPを利用するには、yumでインストールするだけです。

$ sudo yum -y install php

Amazon LinuxでインストールされるPHPのバージョンは、5.3.6です。（2011/04/12現在）

$ php -v
PHP 5.3.6 (cli) (built: Mar 29 2011 19:13:32)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

あとは必要に応じて、yumコマンドやpear、peclコマンドで追加していきましょう。

3. AWS SDK for PHP

まずAWSを利用する準備が整いました。

これからEC2インスタンス（サーバ）のセットアップをして、S3やEBS、RDSなどなどを活用していくと思うのですが、PHPerなら是非おさえておきたいのが「AWS SDK for PHP」です。

AWSはクラウド環境として多種多様なサービスを展開しているのですが、そういったサービスをAPIで操作することができます。例えばEC2インスタンスの起動、停止といった作業がどこからでもAPIで操作できるわけです。このAPIが揃っているのがAWSの特徴で、なかにはR53のようにAPIでのみ操作可能（AWS Management Consoleでは操作できない）なサービスがあるくらいです。

このAPIを活用すれば、独自の管理コンソールを構築することも可能で、実際そういったサービスも外部ベンダーから提供されています。

そんな便利なAPIなのですが、このAPIをPHPから簡単に操作できるようにSDKが提供されています。それが「AWS SDK for PHP」です。

3-1. 要件

AWS SDK for PHPは以下の環境で動作します。

PHPのバージョンさえクリアしておけば、あと必要なのはcURLくらいでしょうか。

ちなみに2.で構築したAmazon Linux環境のPHPでは、下記条件は全て満たされていました。

• PHP5.2以上（5.2.14 or 5.3.x推奨）
• SimpleXML / JSON / PCRE / SPL
• cURL PHPエクステンション（HTTPSサポート）
• file_get_contents() / file_put_contents() でファイルシステムを読み書きできる環境

3-2. インストール

AWS SDK for PHPはPHPソースで書かれたライブラリです。ダウンロードするだけで利用できますので、お好みの方法でインストールして下さい。

• http://aws.amazon.com/sdkforphp からダウンロード
• git
• subversion
• pear

ここではgitでインストールしています。

$ sudo yum -y install git  //git のインストール（git環境があれば不要）
$ git clone git://github.com/amazonwebservices/aws-sdk-for-php.git AWSSDKforPHP
$ ls
AWSSDKforPHP

要件やインストール方法はドキュメントがあるのでこちらを参考にして下さい。
=> Getting Started with the AWS SDK for PHP

3-3. 認証情報の取得

AWS SDK for PHPを実際に利用する際はAWSアカウントの認証情報が必要となります。

認証情報はAWSのWebサイトで取得できます。

まずグローバルナビの「アカウント」をクリックします。クリックするとアカウントのメニューが表示されるので下図のように「セキュリティ証明書」をクリックします。

セキュリティ証明書ページが表示されたら（もしログイン画面が表示されたらログインして下さい）、下図の「アクセス証明書」を表示します。ここにある「アクセスキーID」「シークレットアクセスキー」が認証情報となります。

3-4. サンプル

では実際にAWS SDK for PHP（以下、SDK）を使ってサンプルを作ってみます。

ここでは全リージョンのEC2インスタンスを取得して表示してみましょう。

サンプルファイルはSDKが入っているAWSSDKforPHPディレクトリと同じ階層に設置します。

$ ls
AWSSDKforPHP sample.php

サンプルソースは以下です。

まず require_once() でSDKを読み込みます(1)。これはどのサービスに対する処理を書く時も同じです。

次は、処理対象のリージョンを連想配列に格納しています(2)。SDKで処理を行う際は対象のリージョンをセットする必要があります。今回のサンプルでは全リージョンに対して処理を行うので、連想配列に格納しておきます。

次に、EC2へ処理を行うAmazonEC2クラスをインスタンス化します(3)。コンストラクタにて3-3で確認した認証情報をセットしています。第1引数が「アクセスキーID」、第2引数が「シークレットアクセスキー」となっています。

書籍のサンプルなどを見ると認証情報はSDK用の設定ファイルである「config.inc.php」に記載する例が多いのですが、個人的には認証情報は自分で管理したいのでコンストラクタで渡す方法がやりやすいです。

ここからAmazonEC2インスタンスに対して処理を行います。

まずset_region()で処理対象のリージョンを設定します(4)。そしてdescribe_instances()で対象リージョンのEC2インスタンス情報を取得して(5)、リージョン名とインスタンスIDをprintf()で出力しています。

この処理を各リージョン毎に行います。

3-5. 実行

ではサンプルソースを実行してみましょう。

下記結果から、us-westリージョンで1つ、ap-northeast（東京）リージョンで2つのEC2インスタンスが存在していることが分かります。

$ php sample.php
[us-west-1] i-xxxxxxxx
[ap-northeast-1] i-yyyyyyyy
[ap-northeast-1] i-zzzzzzzz

このようにAWS SDK for PHPを利用すると簡単な記述でAPIを実行して、AWSを操作することができます。

4. 参考書籍

Webに様々な情報があるとはいえ、これからはじめるなら、やはり書籍などまとまった情報をじっくり学びたいところです。

そこでAWSをこれからはじめるPHPerにおすすめな本をあげてみました。

G-CLOUD Magazine 2011

クラウド関連の情報が掲載されているムックです。AWSの特集があり、その中にAWS SDK for PHPの記事が掲載されています。

他にもAWSの記事も多く掲載されており、特にgumiさんの「Amazon EC2 API Tools」を活用したサーバ構築を自動化する記事が参考になりました。

Amazon Web Servicesガイドブック

AWSを活用するPHPerにはおすすめの定番本です。

この本ではAPIを利用してAWSを活用する実例が多数掲載されているのですが、それらのサンプルソースが全て「AWS SDK for PHP」を利用したものになっています。個人的にはタイトルを「AWS SDK for PHPガイドブック」にしても良いんじゃないかと思うくらいPHP満載のAWS本です。

内容も単に機能紹介を並べているのではなく、実際のWebサイトなどの構築を通じてAWSの各サービスを活用するアイデアが書かれています。

AWS SDK for PHP（aws.amazon.com)

書籍では無いですが、AWSサイトでは「AWS SDK for PHP」のドキュメントが公開されています。

導入方法にTips、そしてリファレンスが揃っており、SDKを活用していくには必須の内容となっています。

=> AWS SDK for PHP

AWSを触ってみましょう

いよいよクラウドの本格利用がはじまる今だからこそ、多種多様なクラウドサービスを個人で利用できるAWSを通じてクラウド利用の勘所を掴んでおくというのが大切だと思います。

さらに「AWS SDK for PHP」の存在により、PHPコードで手軽にそういったサービスをプログラムで操作することができます。

無料利用枠も提供されていますので、まだの人はぜひ一度AWSを使って、「プログラマブルデータセンター」と呼ばれるクラウド環境を体感してみてください。

第1回 JAWS(Japan AWS User Group) Osaka勉強会に行ってきました。

大阪では貴重なクラウド系の勉強会、しかもAWSの方が来られる、さらにちょうどAWSを使える案件が出てきたタイミング（というか提案したのですが:D）ということで、参加してきました。

おそらく他の参加される方は「はじめまして」の人ばかりですし、せっかくの機会なので LT もやってきました。

ちなみに人見知りしたり、自己紹介が苦手だったりする人は発表してしまうのが良いですよ。発表の上手下手は関係無く、発表した人は印象に残りやすいです。数分でも自分の話を参加者全員が聞いて貰えるってなかなか無いですからね。
@see 勉強会を楽しむなら発表しよう！

AWSで聞きたいあれこれ

「AWSで聞きたいあれこれ」というタイトルでLTしてきました。

せっかくAWSエバンジェリスト、さらに識者の方達が集まる場なわけですから、日頃AWSを使っていてふと気になる疑問、「自分はこうしているんだけど、他の人はどうやっているのかなー」という質問を逆に聞いてしまおうと思い、通常の発表とは逆にみなさんに質問を投げかけるという内容にしました。

本当は山ほど聞きたいことがあったのですが、とりあえずという事で基本的な 4 つについて聞いてきました。

1. Region

質問

AWSアカウントを作って、さあ AWS Management Console で EC2 インスタンスを起動してみようと思った時にまず迷うのが region の選択です。（勉強会時点は）4 つの Region（US East / US West / EU West / Asia Pacific）があるのですが、日本向け Web システムを構築するならどの Region を選びますか？

参考までに、各regionにmicroインスタンスを立てて、国内からpingを打ってみました。RTTを見るとUS WestかAsia Pacificかなーと思うのですが、日本向けWebシステムを作るとしたらどのregionを選びますか？もしくは選んでますか？

会場からの回答

• US West と Asia Pacific が半々くらい。US Eastもちらほら。EU Westはナシ。
• Asia Pacificでも経路によっては、国内からでも80msくらい出る。
  => たしかにさくらVPSからだと70msくらい出ますね。
• US Eastをあえて選ぶ理由は価格。
  => 速度を気にしなくて良い or 工夫できるなら、価格も大事な要素です。
• RTTだけが重要なわけでは無い。
• Asia Pacificを選んで困ったとこは特に無し。

感想

pingの結果を見ると、やっぱりUS Westを選ぶ人が多いように思っていたのですが、Asia Pacificの人も結構多かったです。ちょうどAsia Pacificのサーバを作っていたところだったので安心しました。

より近いregionができれば悩む必要の無くなるので、今後に期待したいですね。

2. AMI

質問

EC2インスタンスを起動するときに選ぶAMIですが、Amazon AMIやPublic AMIなどの公開されているAMIを利用しますか？それとも自分でイチからOSを入れて構築したAMIを使いますか？なお、前者の場合は起動したインスタンスをカスタムして別のAMIを生成することも含みます。

会場からの回答

• 全員公開されているAMIを利用で、OSをイチから入れるという人はいませんでした。
• 公開されているAMIを利用しつづけて困ったことは特に無い。
• やはりAmazonとしては、Amazon Linuxがおすすめ？
  => 必ずしもそうではない。利用者の自由。
• Amazon Linuxを利用すれば、AWS Premium Supportで有利？
  => 有利というわけではないが、Amazonで仕様を把握しているので回答は得られやすい。
• 会場でも何名かの人が実際にAmazon Linuxを利用しました。

感想

ここもEC2を使う上で悩むポイントでした。

Googleで「EC2 AMI」で検索すると、AMIをOSイメージから作成する情報が多くひっかかり、逆に公開されているこのAMIを使うと良いといった情報があまり無かったので、実はOSイメージからAMIを作成してそれをラウンチするのが一般的なのかと思っていました。

個人的にはrightscaleのAMIを利用していて、それで困ったことは無いのですが、やはり同じような使い方をしている人が多いということで安心しました。また、Amazon Linux を本稼働で利用しているという意見も聞けたので今後は利用してみようと思います。

3. Root Device

質問

AMIを選ぶ時にも絡むのですが、Root Deviceの選択です。instance storeとEBSの2種類が選択でき、それぞれ特徴があります。どちらを利用していますか？利用しますか？

これはあくまでRoot Deviceだけの話で、instance storeがRoot Deviceでもデータ領域にEBSをマウントする方法は、前者になります。

会場からの回答

• ほとんどの人がEBS。
• サーバ用途にもよる。
• 従来はinstance storeだったものをEBSへ移行している。
• Root Deviceをinstance storeにしているのは、以前はRoot DeviceにEBSが利用選択出来なかったからでは。
• EBSは速度的に不利という話があるが？
  => とくにそれで困ったという意見はありませんでした。

感想

EBSは数多くのメリット（インスタンス停止時にデータが消えない、スナップショット（バックアップ）が容易、AMIが簡単に作成できる、別サーバにattachできるなど）があるのでDevice Rootとして利用したいと思っていました。

速度的に不利という情報もあったので、実際のところどうなのかと思っていたのですが、とくに支障は感じないということだったので良かったです。

何か明確な理由が無いかぎりはEBSをRoot Deviceに選んで良さそうですね。

4. EBS Snapshot

質問

EBSの特徴でもあるスナップショットですが、簡単にボリューム全体のバックアップが取れるという優れものです。日々のバックアップとして利用しているのですが、実際のところ困ったこととかありませんか？

例えばスナップショットでバックアップを取っていたが、いざリストアしようとしたらデータが不完全で困った、など。

会場からの回答

• 困ったという意見はナシ。
• スナップショットはS3に保存される。S3の耐久性はイレブンナイン（99.999999999％）なので、まず大丈夫。
  => 自前でバックアップストレージ用意するよりはるかに安全ですね。。。
• ただファイルシステムの整合性は担保されていないので、これは自分でフォローする。
  => 書き込みロックする、DBはダンプする、など。
  => 書き込みが頻繁で無いなら、世代数を多めに取るという考えもあり。
• 念のため他のバックアップ方法と組み合わせている人は？
  => いませんでした。

感想

EBSのスナップショットは簡単にバックアップが取れるのでかなり便利なのですが、あまりに簡単過ぎて、根拠はないのですが若干不安があったりもしました。

そういった心配は不要でしたので、安心して利用できますね。

やってみて

逆質問という形式でやってみたのですが、多く方々から様々な意見を頂いて、とても勉強になりました。まだまだ聞きたい内容はあるので、また次回以降でやってみたいと思います。

回答頂いたみなさんありがとうございました！

雑感

こんなにAWSについて聞いたり話したりしたのは初めてでした:D

他の方の発表ももちろんですし、懇親会でも（ここでは書けない）色々なお話を聞くことができて楽しかったです。やはり「生の声」が聞けるのは勉強会の醍醐味ですね。進化が速いAWSだけに最新情報を共有できるこういった場は貴重です。

懇親会でJAWSの方々から「コアメンバーになる？」と声をかけて頂いたので、コアメンバーとしてお手伝いさせて頂くことになりました。具体的に何をやるのかはまだ分かっていませんが、コミュニティ活動に関わって行ければと思います。

会場提供頂いた富士ソフトさん、AWSのお二方、JAWSのみなさん、ありがとうございました！

日本国内のパブリッククラウドをざくっと集めてみました。

クラウドがすっかり盛り上がってきました。新聞等ではいわゆるASP的なSaaSのクラウドが良く言われていますが、Webシステム屋としては IaaS / PaaS が気になります。

代表的なのは、Amazon EC2やGoogle App Engine、Azureの海外勢ですが、日本国内でもパブリッククラウドが立ち上がってきています。

2010/07現在で、どういったパブリッククラウドが国内にあるかをざっと並べてみました。

ここもあるよ！これ間違ってるよ！等々あれば教えて下さいm(_ _)m

対象

「クラウド」を謳っているサービスは多数あるのですが、ここでは以下に限定しました。

• Webサイト（サービス）構築目的
• IaaS もしくは PaaS
• ユーザが任意にコントロールパネルでサーバ構成（リソース）を変更できる
• 急激なアクセスに備えてオートスケール機構があれば尚良い

1. NIFTY Cloud

http://cloud.nifty.com/

• NIFTY
• IaaS
• 法人のみ
• 時間 / 月額課金
• 勉強会やTwitter等でのPRが活発
• ソーシャルアプリコンテスト等でサーバ提供を行っている
• オートスケールは今後提供

2. ユニットホスティング

http://www.unit-hosting.com/

• ディノ
• IaaS
• 個人 / 法人
• 時間 / 月額課金
• オートスケール機構は要問い合わせ

3. CUMO

http://cu-mo.jp/

• 沖縄クロス・ヘッド
• IaaS
• 法人のみ
• 月額課金
• ロードバランサーは2010年秋提供予定

4. ホワイトクラウド（シェアードHaaSスタンダード）

http://tm.softbank.jp/business/white_cloud/haas_std/index.html

• ソフトバンクテレコム
• HaaS（IaaS）
• 法人のみ
• 月額課金
• 提供サーバは1種類
• Webからサーバ追加ができるかは不明

5. オンデマンド仮想システムサービス

http://oviss.jp.fujitsu.com/portal/ctrl/top

• FUJITSU
• IaaS
• 個人 / 法人
• 時間 / 月額課金
• API提供アリ

番外. クラウドブースター

http://www.kagoya.jp/option/web/cloudbooster01.html

• カゴヤ・ジャパン
• ホスティング
• 個人 / 法人
• 時間課金
• オートスケール可能なホスティング
• クラウド程の自由度は無いが、実用はこれで十分かも

番外. NOAHプラットフォームサービス

http://www.idcf.jp/services/hosting/noah_p/platform.html

• IDCフロンティア
• IaaS
• 法人のみ？
• 月額課金
• サーバ構成変更のリードタイムが？

番外. True CLOUD

http://www.truecloud.jp/

• アイル（GMO）
• IaaS
• 個人 / 法人
• 日 / 月額課金
• 一日単位でのノード追加プランは2営業日前に申込が必要

番外. GrowServer2010-II

http://www.itcore.jp/growserver/

• ITコア
• ホスティング
• 個人 / 法人
• 月額課金
• 回線トラフィック、ロードバランサー無料

番外. IIJ GIO

http://www.iij.ad.jp/GIO/

• IIJ
• ホスティング
• 個人 / 法人
• 日 / 月額課金
• サーバ構成変更のリードタイムが？

まだ少ない。

EC2のように自由にリソースを変更できるクラウドを想像すると国内はまだまだ少ないですね。

正直、リストアップする前はもっとあると思っていたので、上手く見つけられていないのかもしれません。（教えて下さい！）

個人だとユニットホスティングしか選択肢が無いのが何とも厳しいですね。。。

いよいよEC2が国内に拠点を持つという話も出ているので、国内でも良いパブリッククラウドサービスが増えると良いですね。