code.rock

S3のバケット名はよく考えて命名しましょう！

2012-02-21T16:18:00.000+09:00

この間のJAWS-UG札幌勉強会で話しそびれた小ネタの一つです。タイトルを一読して「そんなことわざわざブログに書かなくても(ry」というAWSエキスパートな方は読み飛ばしてくださいねw

オブジェクトのURLについておさらい

S3に保存したオブジェクトは、すべてURLがつきます。例えば、東京のS3に「hoge」というバケットを作り、そこに「fuga.jpg」を保存したとすれば、

http://s3-ap-northeast-1.amazonaws.com/hoge/fuga.jpg

というURLが割り当てられます。また、バケット名をサブホストとしても有効なので、

http://hoge.s3-ap-northeast-1.amazonaws.com/fuga.jpg

でもOKです。

SSLも使えるよ！

さらに、S3はSSLも使えます。つまり、上記のオブジェクトは

https://s3-ap-northeast-1.amazonaws.com/hoge/fuga.jpg
https://hoge.s3-ap-northeast-1.amazonaws.com/fuga.jpg

でも行けちゃうわけですね。スバラシイ！

ヤバいのはどれだ？

さてここで問題です。以下のURLで、ヤバいのが一つだけあります。それはどれでしょう？（すべてパブリックにしてありますので、ブラウザで確認する事が出来ます。）

正解

実際にリンク先に飛んでみると分かるのですが、問題なのは4番です。要するに、バケット名に「ピリオド（ドット）」が入ったパターンです。SSL証明書の警告が出ましたよね？

S3のSSL証明書は、ワイルドカード証明書です。でも、ピリオドが含まれていると問題になります。ちょっと考えればすぐ分かる事なのですが、S3を直に参照させてSSLも通したい場合は、バケット名に気を使わないと後で泣く事になりますので要注意です！！

CNAMEも同じ事

もうひとつのURLパターン、手持ちのドメインでS3バケットに対してCNAMEしてあげるという方法もあります。例えば、

suberu.dateofrock.com

というバケットを作成して、なおかつ

images.hoge.com CNAME images.hoge.com.s3-ap-northeast-1.amazonaws.com

としてやれば、

http://suberu.dateofrock.com/index.html

のように、まるで自分のサーバーのようにURLを作る事が出来ます。
ですが、これもSSLだと証明書の問題が発生します。そもそも証明書とドメイン名違いますから！

https://suberu.dateofrock.com/index.html

というわけで、バケット名はよく考えて命名しましょう！

第5回 JAWS-UG札幌勉強会に参加してきました

2012-02-15T10:25:00.001+09:00

第五回JAWS-UG札幌勉強会に参加してきました。今回は内容が濃くて、札幌はかなりレベルが高いなぁ、と思った次第です。 AWSエバンジェリスト玉川さん（@KenTamagawa）が東京からリモート参加になり、とうとうAWSはエバンジェリストまでクラウド化（笑）したのか！？という勉強会でしたw

AWSアップデート　2月14日JAWS札幌

View more presentations from 玉川憲 (Ken Tamagawa) - Amazon Web Services

Ustream録画アーカイブ

Video streaming by Ustream

みなさんの発表

cloudpack・AWSサムライの後藤さん（@kaz_goto）
第5回JAWS-UG札幌勉強会 cloudpack監視システムについて
View more presentations from Kazutaka Goto
サーバーワークスの千葉さん（@kachina_t）
ec2でivr on Prezi
アグレックスの古山さん
第5回 JAWS-UG 札幌 VPC新機能でECサイト
View more presentations from Hiroshi Koyama

ちなみに今回のLTは、女性によるLady's Talkということで盛り上がったわけであります。

アジェンダの早坂さんによる「ソーシャルゲームでのキャッシュの運用例」（発表スライドPDF：1.2MB）
コードヘッド鈴木さんによる「AndroidからAWSを使ってみた」（発表スライドPDF：460kB）
アフォーダンス新さんによる「AWSサービス」の解説
120214 JAWS-UG Sapporo5 LT
View more presentations from MachieAtarashi

自分が発表したスライドはこちら

というわけで、このスライドにもあるように、今後小ネタを少しずつアップしていこうと思いますww

AWS小ネタ集

View more presentations from Takehito Tanabe

リンク

EC2 on Asterisk-IVR « サーバーワークスエンジニアブログ

AWS MVP "AWS Samurai" award をいただきました！

2012-02-06T19:24:00.001+09:00

かなり遅ればせながらのご報告ですが… 昨年末のJAWS-UG東京勉強会にて、AWS MVP "AWS Samurai" awardの発表があり、このすばらしい賞を受賞いたしました！！！当日は札幌の自宅でしたので、お茶の間でUstreamで見ていたのですが、正直予想もしていなかったので大変驚きました〜！Twitterでコメントしたのですが、どうにも遅延があってリアルタイムとはいかなかったですww

私の他、JAWS-UG東京会長の竹下さん（@dynakou）、gumi CTOの堀内さん（@horiuchi）、cloudpackの後藤さん（@kaz_goto）と言う事で、この4人で2012年のAWSサムライという事になりますw

東京・札幌勉強会でのUstream中継やJAWS-UGの勉強会での発表、雑誌記事執筆、ブログその他での情報発信などを評価していただいたようです。ほんとうにありがたい事です。

自分はAWSの1ユーザーにすぎず、実務でもそれほど大規模に使っているわけではありません。ですが、印刷会社の開発者としてこうして北海道の地に戻って来てテレワーク出来るのも、AWSをはじめとしたクラウドがあったからです。これからも、この経験を皆さんにシェアできたらいいなぁ、と思っています。

本当にありがとうございました！！

Amazon SimpleDBのJava版データマッパーを作り始めました

2012-02-02T16:06:00.000+09:00

Amazon SimpleDBのJava版データマッパーを作り始めました。

dateofrock/simpledb-mapper - GitHub - https://github.com/dateofrock/simpledb-mapper

MavenのオレオレリポジトリをS3に作ってありますんで、ちょっと試してみたい方はpom.xmlに以下を追加してください。

なにそれ？

HibernateとかS2JDBCとか世の中に沢山あるORM的なもので、データストアをSimpleDBに特化させたものです。APIはJPAに準拠しているわけでも何でもなく、オレオレAPIです。たとえば、があったとして、こんなかんじです。

なぜそんなものを作ったのか？

Ruby版のSDKには、SimpleDBをデータストアにしたActiveRecordがあるんです。

Getting Started with the AWS SDK for Ruby

これは結構ステキですね〜。そして、最近発表になったDynamoDBでは、なんとJava版SDK内にデータマッパーを持っています。

Using the Object Persistence Model with Amazon DynamoDB

これもかなりステキですね〜。そんな中で、AWSの（把握しきれないくらい）数あるサービスの中でも、とりわけシンプルシリーズ（SimpleDB/S3/SQS/SNS/SES）大好き人間からみると、どうもSimpleDBのAPIが全然シンプルじゃないww かといって、JavaのSimpleDBラッパーが世の中にあるのかなぁ？と探してみると、確かにJDBCやJPAのインターフェースに乗せたすごいものがありますけど、ちょっとそれはオーバースペック（というか、そういうインターフェースに無理矢理マッチさせている感が苦手…）なので、恥を忍んで書いた次第です。APIはDynamoDBのデータマッパーを~~パクって~~参考にしました。

追伸

ちなみにJavaを書いたのは結構久しぶりだったので、アノテーションってどうやって定義するの？とか、そういうレベルでした（←JavaSE5から取り残されている人）
でも、リフレクションAPIをいじりだしたら異常にメンドクサイのは確かなんだけど、何だろう？この開放感はww 基本的に自分のために作っているライブラリで、まだまだ機能不足やら不具合があります。正直テストもマトモに書いていませんので、ご利用はAt your own riskでおねげーします。

さらに追伸

すでにこういうスバラシイものがありました。もっと早く気がつけば良かったよ…

tyano/simplequery - GitHub - https://github.com/tyano/simplequery

ちょっとだけテレワークしてみてわかったこと

2011-11-25T17:39:00.001+09:00

テレワーク／在宅勤務を開始してから1ヶ月半が経過し、少しずつリズムが出てきました。ちょっとだけ見えてきたこともあるので、ここにメモしておきます。

通勤からの解放

一日が4時間増えましたw

都内に通勤していた頃は、片道2時間弱かかっていました。往復4時間。これが一気に5秒まで短縮されました。著しいRTTの改善です。そして、朝昼晩の三食すべて家族で食卓を共にするという、今まであり得なかったシチュエーションに最近ようやく慣れてきたところです（笑）でも、これができることは大変にありがたいことです。
平日父親不在の核家族でしんどい思いをしてきた妻と、毎朝出勤時に玄関先で「またあしたねー」と言っていた息子に少しずつ借りを返せればいいかな？と思う今日この頃だったりします… それにしても、仕事が終わった直後に「あそんでモード」全開のテンション高い息子とつきあうのは、まだまだ修行が足りないようです（笑）

読書について

通勤時間は読書タイムという方は多いと思います。私自身も例外ではなく、電車の中で技術書を読んで勉強していたクチです。通勤がなくなると、いままで自然にあった読書タイムがなくなります。これはあえて作らないといけません。また、会社帰りに書店によって書籍を物色、という行為が出来ません。これも今になってみたらすごく大きかったなぁ、と思います。自宅の近くには使える書店がないので、あえて街中まで出ないといけません。図書館も近所にないし、ここはやり方を少し考えないとなぁ、と思っています。

地方で東京の仕事をするということ

SkypeとGoogle Docsの存在

会社とのコミュニケーションは基本的にEメールとSkypeです。本社で仕事をしているときも隣に座っているのに連絡はEメール、なんていう事も多かったですから（ゴメンネその1）、感覚的には悲しいかな？はっきり言って違和感ありません。
そんなことよりもやはり、Skypeの存在はすごく大きいですね。先日も3時間、延々と本社と会議しましたが、感覚的にはその場にいるのと違いがありませんでした。良くも悪くも（笑）。ただ、当然の事ながら紙の資料をその場で配布、という訳には行きませんから、Google Docsでドキュメントを共有しました。これも非常に便利です。

東京本社との時差？？

こちらは自然と勤務時間が9時-5時になります。まぁ、5時はちょっと言い過ぎですけど、要するに東京本社が本格的に動き出すまで数時間のズレが出てきます。人より朝早く出勤して早く帰る感覚ですかね？

業務の効率

「在宅勤務で生産性が向上することが科学的に証明されました」という記事が話題になってましたけど、これは人それぞれだと思います。自分は幸運にも仕事に集中できる部屋をキープできて、かつ家族の協力が得られたので明らかに効率がアップしてます。会社に出るまで通勤と戦わなくて良いというのはとても大きいです。あと重要なのが椅子ですね。IT仕事だとPCにへばりついている事が多い訳ですが、コーディングに夢中になると気がつけば辺りは真っ暗だったりします。引越した当初はマトモな椅子がなくて腰痛がひどくなりましたが、ここはきっちり投資すべきと考えて思い切ってレビーノチェアを買っちゃいました。アーロンチェアみたいな流行のメッシュは寒いので却下（ここは北海道）、肘掛けとヘッドレスト、ランバーサポートは必須という条件であれこれ調べてコレに決めました。会社の椅子もひどかったので（ゴメンネその2）、椅子が違うとこんなにも違うものか！と驚いている次第です。ほんと、椅子は重要！！

在宅勤務

運動不足

都内に通勤していた頃は少なくとも合計1時間は歩いていましたが、それすらなくなりますw でもここは雪の多い札幌。冬場は毎朝の雪かきが良い運動です。マジで有酸素運動ですww

あえて外に出る

在宅勤務はへたすりゃ引きこもりまっしぐらです。ここも意識して外に出る事をやらないといけません。最近はTwitterやFacebookなどのソーシャルメディア、またUstreamやWebinarなんかもしょっちゅうあるので実に良いのですが、やはりリアルな世界に出て人と会わないと人間ダメになります（笑）
先日JavaFestaというイベントが開催されたので、無理を言ってスタッフをやらせてもらいました。もちろんUst係ですw 翌日はJAWS-UGの札幌支部勉強会があったので、こちらにも参加しました。これから徐々に札幌近郊で行われている勉強会やイベントには顔を出そうと思っています。

Amazonでの買い物

札幌だとAmazonで「お急ぎ便」にしても翌日には着きません。したがって、Amazonプライムの意味が殆どありません。実際に津軽海峡をわたってみて、あらためて北海道の遠さを実感したので理解できますが、ここは一つ地産地消という事で？なるべく地元でお買い物をしようと思っています。

北海道に移住しました！

2011-11-25T17:21:00.001+09:00

遅ればせながらご報告です

前回のエントリで宣言した通り、東日本を車で縦断し、はるばる北海道までやってきました。

荷物満載状態で神奈川県逗子市を出発して山梨、長野を経由。新潟、山形、秋田、青森と日本海側をまわって津軽海峡を渡り、紅葉真っ只中の北海道を走って札幌に無事到着しました。移動距離1564km。7泊8日の旅でした。

道中はこんな感じでした

長野県の青木湖

長野県北安曇郡小谷村道の駅小谷
http://otarimura.co.jp/

新潟県長岡市和島オートキャンプ場の展望台からの日本海
http://www.kizuna-camp.com/umi.html

山形県温海の道の駅からみた日本海

秋田県男鹿半島なまはげオートキャンプ場（シーズンオフで貸し切り状態だったw）
http://www.namahage.co.jp/camp/

あきた白神駅に止まる五能線、リゾート白神を激写w

青森県白神山地にある十二湖
http://ja.wikipedia.org/wiki/十二湖

青森県つがる市のリンゴ畑

青函フェリーから見た青森港

津軽半島に沈む夕陽

ようやく函館フェリーターミナルに到着

北海道洞爺湖

真狩村の国道から羊蹄山を激写w

まずは、このような大移動に楽しんでついてきてくれた妻と息子に感謝！
秋から冬にかけての移動という事で、子連れキャンプ＆長距離移動は無謀だったか？と一瞬思いましたが、まぁなんとかなりましたw

飛行機を使えば羽田ー新千歳が1時間半。やっぱり遠かった…でも、もうこんな事は一生できないだろうな。良い経験させてもらいました！

中山峠より羊蹄山を望む

道中に立ち寄らせていただいた農家さん

山梨県北杜市の畑山農場さん、山形県遊佐町の尾形さん、秋田県大潟村のみすず農場さんには大変お世話になりました。家族一同感謝申し上げます！

山梨の畑山農場さんの味のある玄関を激写。
ご主人はなんと同じ大学出身。奥様は以前逗子にすんでいたということで、話題がミョーにローカルに（笑）
畑を見学させてもらいつつ、一晩泊めてもらいました。
ブログはこちら。http://blog.livedoor.jp/hatayamaorganicfarm/

山形の尾形さん宅の裏。
川は鳥海山から流れ出てくる澄み切った水。
やっぱりうまい米は水なんだなぁ、と思いました。
こちらにも一泊させてもらい、うまうまな食事を頂きました。ホント感動した…

秋田県大潟村のみすず農場さんの田んぼ。すでに稲刈り終了で寒いw
八郎潟で有名な広大な干拓地に圧倒。
これだけの農地を管理するってものすごい労力だな、と思う。

とてもおいしいとれたて野菜＆お米をごちそうしてもらい、大変ありがたかったです。通販もやっているので、ぜひみなさん注文してみてね！

北海道に移住します

2011-10-10T22:11:00.000+09:00

色々な方にすでにお伝えしているのですが、ここで改めてご報告いたします。

この度、北海道に移住する事となりました。

お仕事は現在のままで印刷会社のエンジニアとして続行します。いわゆるテレワークというスタイルになります。

北海道に帰るべきか否か？

自分は大学入学を機に故郷を離れ、卒業（っていうか大学院中退）後、都内で働いておりました。いわゆるWindows95あたりの「ご家庭に一台パソコンを」という時代からお仕事をやり始めて、最終的に落ち着いたのが欧文印刷株式会社でのエンジニアのお仕事です。結局11年ほど勤務しております。そして気がつけば来年不惑の歳でございます。（プログラマーとしてはとっくに定年ですがなにか？）

いつかは北海道に帰ろうと思っていました。道産子なら結構そういう意識が強いんじゃないかな？自分もそういう思いを抱えつつ、気がつけば日頃の忙しさにかまけてついつい忘れがちになっておりました。そうした中クラウドと出会った訳ですが、これで本当にどこでも仕事ができるな、と考え、昨年からJAWS-UGの縁もあって札幌の勉強会に遊びにいったりもしておりました。ただ、その時もまだ、踏ん切りがつかない感じで、チャンスがあればいいなぁ、という「受け身」の姿勢であった事は間違いないです。そもそも北海道に行くべき理由が見当たらなかった。当時はそんな感じでした。

移住を決断した理由

しかし、直接的な契機となったのは3.11の東日本大震災と、同時期に起きた身内の問題でした。後者の方は公にするのもアレなんで控えますが、もう少し近くに、少なくとも陸続きの所に（？）住んでいた方良い事情が出来てしまいました。これには代替手段も考えられたのですが、なんせ「不惑」ですからここは決断しろよ、と思し召しを頂いたのだと解釈しました（笑）
まぁ、それも大きな理由なのですが、家族全員にとっての3.11の経験がもう完全に移住フラグを立てたと言っても過言ではありません。こちらに当時の様子をメモってありますが、要するに

今動かずにいつ動くのだ！

という思いでいっぱいになったからです。いとも簡単に津波に蹂躙されてしまった東北の地、電気がなくなって改めて分かる現代生活の不合理さ、問題が収束しない原発と、その周辺にわき上がってくる洪水のような不確定情報、放射能問題… これらの混乱をどう自分の中で消化するべきか、そして父親としてどういう決断をすれば最良なのか？社会人としてどのような仕事をしていけば今後に繋げられるのか… もう待ったなしというか、今までおざなりに考えてきた事に大して、「不惑よ決断せよ」と言われているような気がしたんです（笑）

ライフスタイルを変えるのだ！

半年間いろいろ考えつつ、妻とも色々と話した（時には激論した）結果、ライフスタイルを少しずつ変えていかない事には、子供たちが生きる未来につなげる事が出来ないのではないか？という結論に至りました。

クラウドでワークスタイルを見直す

このプレゼンテーションは、JAWS-UG宮崎の勉強会でお話ししたものです

もう、受け身な生き方ではより良い人生を送れない時代だと思います。これは社会人としてより良い仕事をする、という意味もありますが、我々は社会人の前に一人の人間であり、その人間は服を着たり食べたり寝たりするわけです。そういった一番ベーシックな部分を「他人任せにしすぎていやしないか？」という素朴な疑問がどうしても頭をよぎって離れなかったんです。もちろん、そうはいっても極端な行動はとれません。いきなり自給自足的に農業に従事するのはあまりに非現実的ですし、そもそもそういうマイナス面からの動機で動いた所でうまくいかないのは当然です。それよりも、自分たちの手の届く範囲で、1%で良いから、人間が行きて行く為の最もベーシックな部分を少しでも生み出す事が出来る生活がしたい、という考えがベースにあります。理想は自分のプロフィールにもあるとおり半農半ITです。とは言うものの現実的に言って半農とは言うものの家庭菜園レベルで、自分達家族分位が当面の目標です。それでも良いと思っています。自分達の食べ物を自分達で作る事が出来ればそれだけもかなり違います。

仕事について

そのような結論が出たところで、そのようなライフスタイルを実現出来そうな場所、ということで、自然と自分の生まれ故郷である北海道が浮かびました。それには冬の生活という独特の問題がありますが、私自身道産子でありますし、妻もその点は不安要素はあるものの、これまでに様々な出逢いもあり、最終的には合意してくれました。
あとは仕事をどうするかという大問題があります。普通逆だろ？仕事を決めてからだろ？とおじさんたちから諭される事もままありますが、そこは「そうですよねー」と合図地を打って華麗にスルーしておきますw

仕事が大事か？家庭が大事か？などという三文芝居的な何かはそもそも問題ではなく、両方大事なのです。要は自分達はどう生きたいのか？と言う極めて自然な問題に対して素直に考える事が大事で、仕事か、家庭か、なんて言う切り口は意味が無いと考えています。

ちょっと話が呑み屋の説教オヤジくさくなってしまったので軌道修正しますねw

実際問題、弊社には「テレワーク」なんていうイマドキな制度はありませんでした。ましてや「印刷会社」なので、出社しないなんて事はハナから頭にないです。ですが、幸いにも会社には事情を勘案していただいて、テレワークを認めてくれました。決め手となったのは以下の二つの事実です。

自分の仕事はITシステムの開発と運用業務なので、ネットワークさえあれば基本的に場所は問わない
震災後に実行した、BCPのためのディザスタリカバリー対策で既にクラウド上に開発リソースが集約されている

あとは、打ち合わせは基本的にSkypeです。これも社内でSkypeを使う習慣のある人間がいなかった事もあり、夏の間に一週間ほど「在宅勤務」をやってみて試してみました。会議にもSkypeで出席しましたが、コミュニケーションを取るうえでも問題もなく、日常の細かい打ち合わせなどもSkypeの画面共有等を駆使して行えば問題なく進められるという実感をお互いに持つことができました。

とはいえ、実際にやってみたら色々問題も出てくるかもしれません。それでも地方でクラウドを中心としたワークスタイルを実現する事を念頭において、仕事もこれまで以上に張り切ってやっていきたいと思っています！

というわけで、今までいろんな方々に大変お世話になりました。そしてこれからも末永くどうぞよろしくお願いいたします。北海道にいらした際はお気軽にお声がけください。タイミングが合えば空港までお迎えにあがりますのでwww

ちなみに

家族全員が「北の大地の遠さ」を実感する為に、あえて「車」で移動いたします。子供がまだ小さいので、一日の移動距離は少なめで7泊8日の予定です。そして、もう寒くなりつつありますが、基本キャンプしながらです。でも、途中で堪え兼ねてコテージなどに変更するかもw

AWS SDK for Ruby

2011-07-20T20:55:00.000+09:00

「七夕記念企画／雲(AWS)に願いを！」という事で、お願いしたらあっという間に願いがかなったわけでして。

【AWS発表】 AWS SDK for Rubyを提供開始 - Amazon Web Services ブログ

大変喜ばしい！というわけで、ちょっとだけ試してみたメモです。

AWS::SNSを試してみる

一年以上前に、Amazon SNSのRubyライブラリをRightAwsを元に作ったんですが、もう不要になりました。万歳！

code.rock: Amazon SNSのRubyライブラリを（適当に）つくりました

SDKの導入方法はこの辺を見ていただくとして、例えばTopicを全て総ざらいして、その中のSubscriptionを取得するにはこんな感じになります。

# -*- coding: utf-8 -*-
require 'rubygems'
require 'aws-sdk'

AWS.config(:access_key_id => 'アクセスキー', 
  :secret_access_key => 'シークレットキー')
  
sns = AWS::SNS.new
sns.topics.each do |topic|
  puts topic.name
  topic.subscriptions.each do |sub|
    puts sub.arn
  end
end

実にいい感じですね。

Messageをpublishするには、Topicオブジェクトにpublishしてあげるだけです。

topic.publish('デフォルトメッセージ',
  :subject => 'Test',
  :email => 'ほげほげ')

送信先がメールの場合、:subject に日本語をそのまま与えるとエラーになりますんで、例のごとくJISエンコードしてあげます。

subject = '=?ISO-2022-JP?B?' + Kconv.tojis('日本語サブジェクト')
  .split(//,1).pack('m').chomp + '?='
topic.publish('デフォルトメッセージ',
  :subject => subject,
  :email => 'ほげほげ')

~を含むとpublishに失敗するぞ！

まだちゃんと検証していないのですが、問題を発見しましたので報告しておきますw
先のpublishですが、メッセージの本文に~（0x007E）があると、AWS::SNS::Errors::SignatureDoesNotMatchになってしまいます。
※ちなみに \(~0~)/ を試して気がつきましたw

topic.publish('デフォルトメッセージ',
  :subject => 'Test',
  :email => '~')

以下、エラーメッセージ

E, [2011-07-20T20:45:38.321580 #3504] ERROR -- : [AWS SNS 403 0.870669] publish {:message_structure=>"json", :topic_arn=>"arn:aws:sns:us-east-1:XXXXXXXXXXXX:XXXXXXXX", :message=>"{\"default\":\"デフォルトメッセージ\",\"email\":\"~\"}", :subject=>"Test"} AWS::SNS::Errors::SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

これってAWS SDKの問題って言うよりはRubyの問題なのかな？それともJSONエンコード？ちなみに試した環境は以下です。

$ ruby --version
ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0]

第9回 AWS User Group - Japan 東京勉強会で、ひさびさにLTしてきました

2011-07-15T15:41:00.018+09:00

CloudWatch Custom Metrics

View more presentations from Takehito Tanabe

↑自分は12:00位からです

こんにちは。フォロアー泥棒の@dateofrockです。

思い起こせば、第一回でSQSネタを、第二回でSNS自爆ネタを発表してからはや一年が経ちました。その間に、QCon Tokyo 2010とか、女子会とか、札幌支部の勉強会でしゃべったりと、結構いろんなところでお話しさせていただく機会をもらい、大変ありがたく思います。（沖縄行きてー）

AndroidでTwitter follower数をCustom Metricsに突っ込む

お約束の「続きはWebで」の件ですが、まずJMXを使ったCustom Metricsはこちらをご覧ください。
で、これをAndroidからやるためには、cron的な動作をさせる事が出来るAlarmManagerを使うのが便利です。

Main.java

package com.dateofrock.android.test;

import android.app.Activity;
import android.app.AlarmManager;
import android.app.PendingIntent;
import android.content.Intent;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
import android.widget.Toast;

public class Main extends Activity {

	@Override
	public void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.main);

		// 監視開始ボタン
		Button startWatchButton = (Button) findViewById(R.id.startWatchButton);
		startWatchButton.setOnClickListener(new View.OnClickListener() {
			public void onClick(View v) {
				long interval = 60 * 1000;// 1分間隔

				// Intent作成
				PendingIntent pendingIntent = createPendingIntent();

				// AlarmManagerに登録
				AlarmManager am = (AlarmManager) Main.this
						.getSystemService(ALARM_SERVICE);
				am.setRepeating(AlarmManager.ELAPSED_REALTIME, 1000, interval,
						pendingIntent);
			}
		});

		// 監視終了ボタン
		Button stopWatchButton = (Button) findViewById(R.id.stopWatchButton);
		stopWatchButton.setOnClickListener(new View.OnClickListener() {
			public void onClick(View v) {
				PendingIntent pendingIntent = createPendingIntent();
				AlarmManager am = (AlarmManager) Main.this
						.getSystemService(ALARM_SERVICE);
				am.cancel(pendingIntent);
				Toast.makeText(getBaseContext(), "Twitterの監視をやめますた", 10).show();
			}

		});
	}

	private PendingIntent createPendingIntent() {
		Intent intent = new Intent(getBaseContext(),
				TwitterWatchBroadcastReceiver.class);
		PendingIntent pendingIntent = PendingIntent.getBroadcast(
				getBaseContext(), 0, intent, 0);
		return pendingIntent;
	}
}

res/layout/Main.xml

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
	android:layout_width="fill_parent" android:layout_height="fill_parent"
	android:orientation="horizontal">
	<Button android:id="@+id/startWatchButton"
		android:layout_height="wrap_content" android:layout_width="wrap_content"
		android:text="@string/start_watch_string"></Button>
	<Button android:layout_height="wrap_content"
		android:layout_width="wrap_content" android:id="@+id/stopWatchButton"
		android:text="@string/stop_watch_string"></Button>
</LinearLayout>

極限まで研ぎすまされた無駄のないユーザーインターフェース

Main.javaは、アプリケーションを起動した時に最初に表示されるActivityです。スタートボタンが押されるとAlarmManager#setRepeating()するのですが、ここで渡されるPendingIntentはBroadcastReceiverを継承したTwitterWatchBroadcastReceiverを起動させるものになります。この中で、Twitter APIに現在のフォロワー数を聞きに行って、それをCloudWatchにputMetricDataするだけです。
上記のコードでは1分間隔で監視していますが、これは結構電池を消耗するのでおススメしません。今回はどれだけ短時間でフォロワーが増えるかみたかったので、あえて1分にしています。

TwitterWatchBroadcastReceiver.java

package com.dateofrock.android.test;

import android.app.Notification;
import android.app.NotificationManager;
import android.app.PendingIntent;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.text.format.DateUtils;

import com.dateofrock.android.test.TwitterClient.APIResult;

public class TwitterWatchBroadcastReceiver extends BroadcastReceiver {

	@Override
	public void onReceive(Context context, Intent intent) {
		// Twitterにお伺い
		TwitterClient twitter = new TwitterClient();
		APIResult result = twitter.getResult("dateofrock");

		// 結果をCloudWatchに送信
		CloudWatchClient cloudWatch = new CloudWatchClient();
		cloudWatch.sendMetrics("dateofrock", result);

		// Notify
		doNotification(context);
	}

	private void doNotification(Context context) {
		NotificationManager notificationManager = (NotificationManager) context
				.getSystemService(Context.NOTIFICATION_SERVICE);

		String text = "CloudWatchにTwitter情報を登録しました("
				+ DateUtils.formatDateTime(context, System.currentTimeMillis(),
						DateUtils.FORMAT_SHOW_TIME) + ")";
		Notification notification = new Notification(
				android.R.drawable.btn_star, text, System.currentTimeMillis());
		notification.flags = Notification.FLAG_AUTO_CANCEL;

		Intent intent = new Intent(context, Main.class);
		PendingIntent contentIntent = PendingIntent.getActivity(
				context.getApplicationContext(), 0, intent, 0);
		notification.setLatestEventInfo(context, "TwitterWatch", text,
				contentIntent);
		notificationManager.notify(R.string.app_name, notification);
	}

}

CloudWatchClient.java

package com.dateofrock.android.test;

import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.cloudwatch.AmazonCloudWatchClient;
import com.amazonaws.services.cloudwatch.model.Dimension;
import com.amazonaws.services.cloudwatch.model.MetricDatum;
import com.amazonaws.services.cloudwatch.model.PutMetricDataRequest;
import com.amazonaws.services.cloudwatch.model.StandardUnit;
import com.dateofrock.android.test.TwitterClient.APIResult;

public class CloudWatchClient {

	public void sendMetrics(String twitterUser, APIResult result) {
		if (result.isError()) {
			return;
		}

		Dimension dimension = new Dimension().withValue(twitterUser).withName(
				"User");

		// リクエストの組み立て
		PutMetricDataRequest request = new PutMetricDataRequest()
				.withNamespace("Twitter").withMetricData(

						new MetricDatum().withMetricName("Follower")
								.withDimensions(dimension)
								.withUnit(StandardUnit.Count.toString())
								.withValue((double) result.followersCount),

						new MetricDatum().withDimensions(dimension)
								.withMetricName("Friends")
								.withUnit(StandardUnit.Count.toString())
								.withValue((double) result.friendsCount),

						new MetricDatum().withDimensions(dimension)
								.withMetricName("Status")
								.withUnit(StandardUnit.Count.toString())
								.withValue((double) result.statusCount)

				);

		// CloudWatchにデータ送信
		AWSCredentials cred = new BasicAWSCredentials("アクセスキー", "シークレットキー");
		AmazonCloudWatchClient client = new AmazonCloudWatchClient(cred);
		client.setEndpoint(CloudWatchEndPoint.US_EAST);
		client.putMetricData(request);
	}

}

CloudWatchEndPoint.java

package com.dateofrock.android.test;

public class CloudWatchEndPoint {

	public static final String US_EAST = "monitoring.us-east-1.amazonaws.com";
	public static final String US_WEST = "monitoring.us-west-1.amazonaws.com";
	public static final String EU_WEST = "monitoring.eu-west-1.amazonaws.com";
	public static final String AP_SOUTHEAST = "monitoring.ap-southeast-1.amazonaws.com";
	public static final String AP_NORTHEAST = "monitoring.ap-northeast-1.amazonaws.com";

}

TwitterClient.java

package com.dateofrock.android.test;

import twitter4j.Twitter;
import twitter4j.TwitterException;
import twitter4j.TwitterFactory;
import twitter4j.User;

public class TwitterClient {

	public APIResult getResult(String twitterUser) {
		APIResult result = new APIResult();
		Twitter twitter = new TwitterFactory().getInstance();
		User user;
		try {
			user = twitter.showUser(twitterUser);
			result.followersCount = user.getFollowersCount();
			result.friendsCount = user.getFriendsCount();
			result.statusCount = user.getStatusesCount();
		} catch (TwitterException e) {
			result.error = true;
		} finally {
			return result;
		}

	}

	public class APIResult {
		int followersCount, friendsCount, statusCount;
		private boolean error = false;

		public boolean isError() {
			return this.error;
		}
	}
}

TwitterWatchBroadcastReceiver#onReceive()で起動されるTwitterClientですが、Twitter APIのGET users/showが幸い認証が不要なので、非常に簡素に書く事ができます。ただし、Twitterの状況によっては取得に失敗する事もありますし、ましてやケータイは圏外になる事もよくありますので、例外はキャッチして取得に失敗したという状況が分かるようにして（APIResult.error=true）値を返すようにしています。というわけで、エラー処理は適当ですw

結果発表

で、どのくらいTwitterのフォロワーが増えたかを貼っておきますとこんな感じでした。わずか3分で純増70弱です。協力していただいた皆様、本当にありがとうございます！
あれから半日以上経過しましたが、若干の増減はあるものの、今のところキープですww

ちなみに、所々グラフが切れている部分がありますが、これはTwitterAPIやCloudWatchAPIの呼び出しに失敗したからだと思います。原因はほぼ間違いなくAndroid端末の通信状況です。移動中でトンネルの中に入っていたりすると圏外になってしまい、失敗します。

ちなみに、CloudWatchではあるしきい値を超えるとAmazon SNS経由でメールを飛ばす事が出来るのですが、それもしゃべっている間に来ておりましたw

実際に来たメール（クリックで拡大）

Alarmの設定画面（クリックで拡大）

CloudWatch Custom Metricsの注意点

5分という制限時間ではお伝えしきれなかった事ををここにメモしておきます。※2番目、3番目はCustom Metricsに限った話ではありません。

消す手段が無いw
時刻表記がUTCのみ
これは、Management Consoleで見た場合に非常に分かりにくいのでなんとかして欲しいところです < AWS様
グラフデータを画像として取得できない
ただし、APIのGetMetricStatisticsを叩けば、DataPointがドバドバっと取得できますので、自力でグラフを描く事は可能です。ただ、どうせなら絵にして欲しいところです < AWS様

まとめ

今回はネタとしてわざとAndroidとかTwitterなどを出してみましたが、これはCloudWatchのCustom Metricsって使い勝手があるよ、という事を強調したかったからです。（というか、フォロワーを増やしてみたかっただけ？）
通常OSやアプリケーションレベルのメトリクスをとりたい場合、Nagios、Zabbix、Muininあたりが出てくるのでしょうけれども、クラウド環境でそれらを動かすってのもある意味芸が無いというか、そもそも監視サーバのお守りもなんだかなぁ、と思うので、CloudWatchに全て統合できれば嬉しいな、という個人的見解です。

もう、ここまで来るとIaaSとかPaaSっていうレイヤー分けが意味が無い気がする今日この頃でした・・

right_awsのマルチバイトでの謎挙動に関して

2011-05-23T20:52:00.012+09:00

最近、EC2やEBSなどに「日本語」のタグをつけられる事が解りまして（笑）、マネジメントコンソールからポチポチNameタグをつけ直していたのですが、最近リージョンの引っ越し等を行っている関係で、プログラムから制御させようと思い立ちました。

この手の管理プログラムは、いちいちJavaを立ち上げるのも気が重いので、Rubyのright_awsを利用してボチボチ作り始めました。right_awsのバージョンは2.1.0です。

require 'rubygems'
require 'right_aws'

AWS_ACCESS_KEY = 'アクセスキー'
AWS_SECRET_KEY = 'シークレットキー'

client = RightAws::Ec2.new(AWS_ACCESS_KEY, AWS_SECRET_KEY, :server => 'ap-northeast-1.ec2.amazonaws.com')
client.create_tags('vol-12345678', {'Name' => '日本語！'})

で、実行するとSignatureが合わないというエラーでコケます。

/Library/Ruby/Gems/1.8/gems/right_aws-2.1.0/lib/awsbase/right_awsbase.rb:545:in `request_info_impl': SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details. (RightAws::AwsError)
 from /Library/Ruby/Gems/1.8/gems/right_aws-2.1.0/lib/ec2/right_ec2.rb:140:in `request_info'
 from /Library/Ruby/Gems/1.8/gems/right_aws-2.1.0/lib/ec2/right_ec2_tags.rb:79:in `create_tags'
 .....

ところが、{'Name' => 'HogeHoge!!'}のようにシングルバイトの文字列を与えた場合はうまく行きます。

おっかしい…マルチバイト関連の問題だろう…めんどくさー、とか思いつつ、自分を奮い立たせる為にツイートしていたら（笑）なんと@junyaさんも同様の現象にあったとの事で、サポートフォーラムにも投稿したとの事。

CreateTags Query API でマルチバイト文字を使用するとSignatureDoesNotMatchエラーが発生します

Java SDKではうまく行くとの事で、これはRubyそのものの問題か、もしくはright_aws側の問題だろうなーと思いつつ、Java SDKで同じ事をやったら確かに問題なく行きます。

package test1;

import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.ec2.AmazonEC2Client;
import com.amazonaws.services.ec2.model.CreateTagsRequest;
import com.amazonaws.services.ec2.model.Tag;

public class CreateTagsTest {

    public static void main(String[] args) {
 final String AWS_ACCESS_KEY = "アクセスキー";
 final String AWS_SECRET_KEY = "シークレットキー";

 AWSCredentials cred = new BasicAWSCredentials(AWS_ACCESS_KEY, AWS_SECRET_KEY);
 AmazonEC2Client client = new AmazonEC2Client(cred);
 client.setEndpoint("https://ec2.ap-northeast-1.amazonaws.com");
 client.createTags(new CreateTagsRequest().withResources("vol-12345678")
  .withTags(new Tag().withKey("Name").withValue("日本語！")));
    }

}

仕方が無いので、Java SDKとright_awsの両方のソースを掘ってみたところ、やはりSignatureの生成のところで違いがありました。

Java側のクラスはcom.amazonaws.auth.QueryStringSignerです。下記、一部抜粋。

private String calculateStringToSignV2(URI endpoint,
            Map parameters) throws AmazonClientException {
        StringBuilder data = new StringBuilder();
        data.append("POST").append("\n");
        data.append(getCanonicalizedEndpoint(endpoint)).append("\n");
        data.append(getCanonicalizedResourcePath(endpoint)).append("\n");
        data.append(getCanonicalizedQueryString(parameters));
        return data.toString();
    }

「POST」という文字がハードコーディングされていますねw

では、Ruby側はどうなっているかというと、create_tagsメソッドがright_ec2_tags.rbに定義されています。※構造がJavaと異なるので単純比較が出来ないのです。

module RightAws
  class Ec2

    (中略)

    def create_tags(resources, tags, options={})
      default = options[:default].nil? ? '' : options[:default]
      params = amazonize_list("ResourceId", resources)
      params.merge! amazonize_list(['Tag.?.Key', 'Tag.?.Value'], tags, :default => default)
      link = generate_request("CreateTags", params)
      request_info(link, RightBoolResponseParser.new(:logger => @logger))
    rescue Exception
      on_exception
    end

    (中略)

  end
end

問題は、このメソッドの中でgenerate_request("CreateTags", params)しているところです。これはright_ec2.rbに定義されおりまして、びっくりする事が書いてありました。

module RightAws
  class Ec2 < RightAwsBase
    include RightAwsBaseInterface

    (中略)

    def generate_request(action, params={}) #:nodoc:
      generate_request_impl(:get, action, params )
    end

    (中略)

  end
end

get決め打ちキタコレ！というわけで、うまく動作するJavaに習って、right_aws側をこのようにしてみました。

require 'rubygems'
require 'right_aws'

AWS_ACCESS_KEY = 'アクセスキー'
AWS_SECRET_KEY = 'シークレットキー'

client = RightAws::Ec2.new(AWS_ACCESS_KEY, AWS_SECRET_KEY, :server => 'ap-northeast-1.ec2.amazonaws.com')
def client.generate_request(action, params)
  verb = :get
  if action.start_with? 'Create' then
    verb = :post
  end  
  generate_request_impl(verb, action, params)
end
client.create_tags('vol-12345678', {'Name' => '日本語！'})

generate_requestの挙動をCreateなんちゃらの時にPOSTに置き換えるという付け焼き刃対応ですw
結果的にこれでうまく行きました。

シングルバイトの時はgetでうまく行くのがどうにも納得いかないのですが…一応、ご報告です。

追記

Ruby 1.8.7で試した結果です。Ruby 1.9.2ではうまく行かないとの報告がありました。

JavaのJXMをCloudWatchのカスタムメトリクスに突っ込んでみた件（四番煎じ）

2011-05-19T15:40:00.009+09:00

CloudWatchのカスタムメトリクス

AWSのリソース監視、アラート発信が出来るCloudWatchですが、EC2に関しては正直今ひとつ使いにくいなーと思っておりました。理由は、OSより内側の情報が取れないので、ディスクの空きスペースを監視したり、Tomcatのメモリ状況等の情報を取得する事が出来なかったからです。

お仕事では状況のモニタリングにMuninを使っていますが、その為にインスタンスを1台立てたりして結構メンドイ…っていうか、クラウドっぽくない（笑）訳で、おもわず

とつぶやいた訳ですが、ソリューションアーキテクトの荒木さんに

と教えていただき、なるほどと思いつつ、やりたい事は逆なんだよなーとか思っていたら、じつは一週間ほど前にそのようなリリースがあったんですね…完全に見逃しておりました。

【AWS発表】クラウド監視サービスAmazon CloudWatchでカスタムのメトリクスが使用可能に - Amazon Web Services ブログ

また、すでに試されている方々もおられます。

これはイケル！と思いつつ、一番やりたいのはJavaアプリのモニタリングなんだよなー、という訳で、

とつぶやいたら、これまたソリューションアーキテクトの大谷さんに

と突っ込まれましたので、簡単に作ってみましたw
実行には、AWS SDK for Javaの最新版が必要になります。公式サイトからダウンロードしても良いですし、Mavenのリポジトリより適時落としてください。

使用例

JXMを使ってヒープメモリの状況を取り出し、それを一分間隔でCloudWatchに投げる例です。

import java.lang.management.ManagementFactory;
import java.lang.management.MemoryMXBean;
import java.lang.management.MemoryUsage;

import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.cloudwatch.AmazonCloudWatchClient;
import com.amazonaws.services.cloudwatch.model.Dimension;
import com.amazonaws.services.cloudwatch.model.MetricDatum;
import com.amazonaws.services.cloudwatch.model.PutMetricDataRequest;
import com.amazonaws.services.cloudwatch.model.StandardUnit;

public class JMXTest1 {

    public static void main(String[] args) throws Exception {
 while (true) {
     MemoryMXBean mBean = ManagementFactory.getMemoryMXBean();
     // ヒープメモリ状況取得
     MemoryUsage heapUsage = mBean.getHeapMemoryUsage();

     // Dimension
     Dimension dimension = new Dimension().withName("Server").withValue("001");

     // カスタムメトリクスデータのリクエストを生成
     PutMetricDataRequest request = new PutMetricDataRequest()
      .withNamespace("MyJVMTest01")
      .withMetricData(
       // Used
       new MetricDatum().withDimensions(dimension)
        .withMetricName("Used")
        .withUnit(StandardUnit.Bytes.toString())
        .withValue((double) heapUsage.getUsed()),
       // Max
       new MetricDatum().withDimensions(dimension)
        .withMetricName("Max")
        .withUnit(StandardUnit.Bytes.toString())
        .withValue((double) heapUsage.getMax()),
       // Committed
       new MetricDatum()
        .withDimensions(dimension)
        .withMetricName("Committed")
        .withUnit(StandardUnit.Bytes.toString())
        .withValue((double) heapUsage.getCommitted())

      );

     AWSCredentials cred = new BasicAWSCredentials("アクセスキー", "シークレットキー");
     AmazonCloudWatchClient client = new AmazonCloudWatchClient(cred);

     // CloudWatchにデータ送信
     client.putMetricData(request);

     Thread.sleep(60 * 1000);
 }
    }
}

で、結果がこれ。（画像クリックで拡大）

というわけで、めでたしめでたし！

ついでに要望など

カスタムメトリクスはとても嬉しい機能なのですが、グラフの時間を自分のロケールで表示できればパーフェクトですね… という訳で顧客というのはトコトンわがままな訳ですが（笑）とても良いサービスなのでついつい言ってしまいます！

「サーバ／インフラエンジニア養成読本」に記事が再録されました

2011-05-16T16:19:00.002+09:00

サーバ／インフラエンジニア養成読本 [現場で役立つ知恵と知識が満載！] (Software Design plus)
2011年4月9日発売
Software Design編集部　編
B5判／228ページ
定価1,974円（本体1,880円）
ISBN 978-4-7741-4600-3
Amazon.co.jpで見る

発売されてからちょっと時間がたってしまいましたが、ご報告いたします。インフラエンジニア向けのムックに弊社のAWS事例を載せていただきました！これは、昨年のSoftware Design 2010年11月号に書いた記事に加筆修正したものです。

インフラエンジニアでもなんでもない自分が、この手の本に寄稿できるなんて今まで考えもしませんでしたが、まさに空からサーバーが降ってくるクラウドのおかげでこのような事になりました（笑）

特に資本の少ない中小企業やベンチャーには、クラウド環境は既に必要不可欠な存在だと思います。これはIT企業は当然として、その他の業種でも少なからずITの力を使う必要がある場合、クラウドをうまく使いこなす事で様々なメリットが得られるはずです。

また、クラウドはAmazonだけ、という訳でもなく（笑）、適材適所でGoogleやSalesForce、Azureなどがマッチする場合もあると思います。とにかく、どのクラウドも「タダで始められる」所がほとんどですから、まずは自分で試してみることが何よりも大事です！！

運用環境構築に障壁がなくなった現在、極端に言えばソースコード一本で飯が食える（かもしれないw）時代になってまいりました。楽しい時代ですねw

S3とIAMを組み合わせたお手軽ファイル共有

2011-04-20T21:07:00.122+09:00

AWSを使ったお手軽ディザスタリカバリ対策を社内で構築したお話を書きましたが、その続きです。

ファイル共有としてS3を使おうとした経緯

ファイルをやり取りする時など、イントラにあるファイルサーバー（SambaやAFP、NFSなど）を経由させるのが一番お手軽な方法だと思います。実際、最近のNASは安いですし、RAIDも簡単に組めてそこそこ信頼性もあります。ちなみに弊社ではBuffaloのTera Stationを利用しています。

ですが、このファイルサーバーをクラウドに持って行くとなると結構大変です。弊社の場合ですと、エンジニアと印刷オペレーターとでファイルをやり取りする機会も多いので、エンジニア以外の人たちでも簡単に扱える仕組みが必要となります。AWSでこの手の「ファイル共有」プロトコルを喋らせるにはEC2を仕立ててあげなければなりませんが、今回はそのような時間もお金もかける事が出来ません。

AWS最強のサービスS3

AWSにはS3という容量無制限のストレージサービスがあります。CloudBerry ExplorerやCyberduckを使えば、FTPライクに扱う事が出来ますし、AWS純正のAWS Management Consoleはブラウザで利用出来るので、基本的なPCリテラシーがある人であれば扱えるものです。
※ただし、UIの日本語化が行われていませんので、場合によっては問題になるかもです。

そこで、ファイル共有の代わりにこの辺のツールを使う事にして、あとはファイルの書き込み、読み込みなどの権限管理をIAM（Identity and Access Management）を利用して設定してみました。

IAMに関しては、サーバーワークス小倉さんがJAWS-UGの勉強会で発表してくださった超わかりやすいスライドがありますので、そちらをご覧ください。

IAMのはじめかた

View more presentations from Junya Ogura

IAMまわりのツール

今の所IAMの設定は、AWS Management Consoleから扱えません。しかし、日本にはCloudworksという神サービス（笑）があり、こちらでIAMをサポートしています。また、FirefoxエクステンションのIAM Foxもあるので、コマンド叩くの嫌だ！という人でもだいぶ敷居が低くなっています。ただ、細かい所をいじるには、やはりコマンド、もしくはSDKを使ってAPIを叩かなければなりません。

また、設定自体はAccess Policy Languageと呼ばれる形式（中身はJSON）で書く必要があるので、それなりに大変です。ですが、JSONを生成してくれるAWS Policy Generatorが用意されているので、イチから手書きするよりも、こちらを使う方が良いかもしれません。

この記事では Policy GeneratorでJSONを作成 → 少々手直し → Cloudworksにて設定
いうやり方で行いました。その他、GUIのツールでサポートしていない部分はコマンドラインを利用しました。

概要

考え方としてはこのような感じです。

ファイルサーバーとして利用するバケットを一つ作ります。リージョンはもちろん東京です。このバケットを仮に「共有バケット」と呼ぶ事にします。バケット名は「s3-shared」とします。
印刷部門の人間には、この共有バケットに対してのみ、自由に読み書きが出来ます。
その他バケットは、管理者以外は読み書き出来ない事とします。

IAMで「admin」と「s3-user」という二つのグループを作ります。adminは管理者権限、s3-userはS3の共有バケットの読み書きのみ出来るという意味です。adminグループにはadminというユーザー、s3-userグループにはkenとsachikoというユーザーがいるとします。（名前に他意はありませんよw）

CloudworksでIAMを設定する

まずはユーザーを作らないと何も出来ません。コマンドでのやり方はググれば沢山出てくるので、Cloudworksでのやり方を説明してみます。

Cloudworksにログインし、左のIAMユーザーを選択、右上の「IAMユーザーの追加」をクリックします。admin、ken、sachikoというユーザーを作成します。

次にadminグループとs3-userグループを作成します。

adminグループ配下にユーザーadminを、s3-userグループ配下にkenとsachikoを入れます。グループを選択して、「IAMユーザーをグループに追加」をクリックします。以下の画面は、s3-userを選択した場合です。

s3-userグループにkenを追加します。追加するユーザーは、ちゃんとプルダウンで選択出来るようになっているので便利ですね！

同様にsachikoも追加して、s3-userグループの設定が完了しました。

ポリシーの記述

さて、ここからJSONでポリシーの記述を行います。ここではAWS Policy Generatorを使ってみます。

AWS Policy Generator

まずは、adminからやってみます。

adminはS3だけではなく、その他のサービスも全て利用出来るものとしますので、All Servicesにチェックを入れるだけです。

「Add Statement」をクリック、「Generate Policy」をクリックすると、このようにJSONが生成されます

このJSONをCloudworksにコピペするという訳です。

Cloudworksに戻ります。adminグループのIAMグループポリシーの追加をクリックします。ポリシー名は何でも良いのですが、判りやすくadmin-policyとでもしておきましょう。

次に、s3-userのポリシーを作成します。Policy Generatorに戻って、以下の事をやります。

Type of PolicyはIAM Policyを選択
EffectはAllow、AWS ServiceはAmazon S3を選択。以下の操作も同じ。
ActionsでListAllMyBucketsを選択。Amazon Resource Name（ARN）には、 arn:aws:s3:::* と記入。「Add Statement」をクリック。
ActionsでListBucketとGetBucketLocationを選択。ARNは arn:aws:s3:::s3-shared と記入。「Add Statement」をクリック。
ActionsでAll Actionsをチェック。ARNは arn:aws:s3:::s3-shared/* と記入。「Add Statement」をクリック。

結果、このような感じになります。

出来上がったポリシーはこんな感じです。

{
  "Statement": [
    {
      "Sid": "Stmt1303292722962",
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Sid": "Stmt1303292848143",
      "Action": [
        "s3:GetBucketLocation",
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::s3-shared"
    },
    {
      "Sid": "Stmt1303292879145",
      "Action": "s3:*",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::s3-shared/*"
    }
  ]
}

まず、IAMのデフォルトポリシーは全てDenyです。Allowを付け加えて行くやり方で考えています。

ListAllMyBucketsとは、S3バケットの一覧を表示するかどうかです。これはDenyしても良さそうですが、Management Consoleでは左側にバケット一覧が表示される為、Allowしておく必要があるみたいです。（情報求む）

共有バケット名は「s3-shared」です。これをARNで書くと arn:aws:s3:::s3-shared となります。ここに対してGetBucketLocationとListBucketをAllowしてやると、このバケット内のオブジェクト一覧を取得する事が出来ます。

さらに、このバケット内部を読み書きする為には、arn:aws:s3:::s3-shared/* に対して全てのActionをAllowしてやります。これは文字通り全てのアクションを許可してしまうので、例えばファイルのパーミッションにあたるACL（Access Control List）の変更もs3-userグループの人が出来てしまいます。この辺はどこまで制限するかによるでしょう。

このJSONをCloudworksにコピペします。

これでIAMの設定は終わりました。

s3-userでAWS Management Consoleを使う場合

通常、Management Consoleにアクセスするには、

https://console.aws.amazon.com/s3/home

に行くと思いますが、ここで入力するのはAWSアカウントのEメールとパスワードです。せっかくIAMを設定したのに、これではログイン出来ません（笑）

IAMでManagement Consoleにログインする為には、特別なURLが用意されています。（参考：AWSドキュメント）

https://your_AWS_Account_ID.signin.aws.amazon.com/console/s3

your_AWS_Account_IDは、AWSアカウントに設定されている12桁の数字です。ただ、この数字を覚えている人は極めてまれだと思いますので、AWSアカウントIDのエイリアスを作って覚えやすいURLに変更してしまいましょう。下記のコマンドを打ちます。

$ iam-accountaliascreate -a hogehoge
Alias: hogehoge
Direct Signin Link: hogehoge.signin.aws.amazon.com

これでめでたく、https://hogehoge.signin.aws.amazon.com/console/s3でログインする事が出来るようになりました。

さて、ユーザー名とパスワードを入力してログインしてみましょう…って、パスワードってどこかで設定しましたっけ？（笑）

実は、このパスワードの設定はCloudworksでは出来ません。しかたがないので、コマンドを打ちましょう。

$ iam-useraddloginprofile -u ken -p PASSWORD

これでようやくログインする事が可能になります。

ログインするとおなじみのコンソール画面が出て、バケット一覧が表示されます。試しに共有していないバケットをクリックしてみるとこんな感じでアクセス出来ません。うまく設定出来ているようです。

共有バケットは、自由にフォルダを作ったり、ファイルをアップロード／ダウンロードが出来ます。sachikoユーザーでも全く同じ事が出来ます。

s3-userグループは、S3の共有バケットの操作のみ許可されていますので、もちろんEC2は触れません。

もちろん、Elastic Beanstalkも無理です。

こんな感じで、共有バケットの操作のみに権限を絞ったIAMユーザーに対して、AWS Management Consoleを使ってもらう準備ができました。めでたしめでたし。

CyberduckやCloudBerry Explorerの場合

これらのツールを使う場合は、先ほど作ったIDとパスワードでは出来ません。従来通りアクセスキーとシークレットアクセスキーを使う必要があります。これはユーザーごとに発行します。

Cloudworksではこのようにやります。
アクセスキーを発行したいユーザーを選択し、アクセスキーの追加ボタンをクリックします。

そうすると、このようにキーが発行されますので、メモっておきます。シークレットアクセスキーは、この画面でしか表示されません。あとで確認する手段がないので、もし忘れてしまったらキーの再発行となります。（これはAWS側の仕様です。コマンドラインでやっても同じ事です。）

Cyberduckでは、ユーザー名にアクセスキーを、パスワードにシークレットアクセスキーを入力します。

共有バケットへはアクセス出来ますし、それ以外はアクセスが拒否される事が判ります。

まとめ

なんか、思いがけず長文エントリになってしまいましたが、ここで紹介している事は非常に単純なものです。ポリシーは時間帯でIP制限をかけるなど、きめ細かく記述出来ますし、そもそもS3だけでなく、EC2などのサービスにも適用出来ます。（私は全然使いこなしていませんがw）
また、Cloudworksのように周辺のツールを組み合わせれば、色々と作業が楽になります。

手軽でセキュアな無制限ストレージが格安で手に入る時代になりました。
いやー、S3って、ほんといいもんですね！

Twitterアイコンの衣替え！

2011-04-19T00:25:00.003+09:00

最近@crown_sugarこと南暁子さんに描いていただいたアイコンをシールにして名刺に貼ってますが、おかげさまで
「あっ！このアイコン見た事ある！」
と絶叫（？）される事が多い今日この頃ですw

Twitterアイコンの母である南さんは、なんとすでに100人を超える人たちの似顔絵を描いてらっしゃいます。しかもこれだけのクオリティが無料ですよ。すごい創作意欲です。

それで、100人描いてもまだ飽き足らず（？）なんと、過去に描いていただいたイラストを「衣替え」してくれるという、とても嬉しい企画があるんです。応募はハッシュタグ #koromogae を付けてツイート先着順、しかも事前予告なくゲリラ的に告知があるので、運がよいか、24時間TLに張り付くかどちらかしかありません（笑）

自分は、たまたまTLに見かけて、「ktkr!」と思いツイートしたのですが、いざ当選してみて、「はて、何に衣替えするか？」と悩むハメになってしまいました（←ひどい）

で、ふと思ったのが、シール好きな息子。ひょっとして、息子との2shotもアリなのか！？と思いつつ、衣替えの域をはみ出しており、いくら何でも厚かましいんじゃ…などと一巡りした挙げ句、偉大なる母、南さんにお頼み申した結果、無理を聞いてくださいまして描いていただきました！
A4の紙にでかでかと印刷してみせたら息子は大喜び。冷蔵庫に貼って悦に入っておりました（笑）

もちろん PRINTAIL さんでシールを発注。今回は常識的な枚数におさめましたw
ただ、前回と違うのは、シールの台紙が名刺サイズという事です。

この台紙のサイズ、実にいいんですよ！シールの予備を名刺入れに入れておく事が出来るので、意外に便利です。

ちなみに、このようなシャレオツな台紙がセットされてきました。

よーく見ると、透かしの様な印刷がされています。地味に凝ってますね。

という訳で、今度私と名刺交換する方は、このシールがついてくる予定です。（今貼っているソロバージョンの在庫がはけたらですがw）

いやー、アイコンって、ほんとにいいもんですね！

AWSを使ったお手軽ディザスタリカバリ対策〜Subversion編

2011-04-14T14:50:00.020+09:00

http://eitar0.pecori.jp/

東日本大震災のあった3月11日は、たまたま有休を取っていて自宅におりました。家族で外出しようとしていた矢先に「グラッ」と来て、結構大きいな、と思いつつ、なかなか揺れが収まらない長い横揺れに「こりゃ尋常じゃないな」と思いました。

会社が心配になり連絡をしようと試みたのですが、もちろん携帯はつながらず、こういう時こそアナログ電話だ！と思いつつも、通電していないと使えない電話機であることが発覚…30分後位に3Gが復活したので、唯一社内でTwitterをやっている方と連絡が取れ、皆はひとまず無事らしい、という事が確認出来ました。

自宅にはテレビがないのですが、そもそも停電しているので見る事が出来ません。幸いにも、iPod touch用ワンセグチューナーがあったので、これでNHKを見ると津波に襲われる東北の光景が…

自宅近くの川も津波の影響で逆流していたり、コンビニが非常用電源でレジを稼働させてがんばって営業していたりと、これは相当大きい災害だ、という事がじわじわ分かってきました。その日は停電もさっぱり解消せず、暗闇の中、キャンプ用のランタンをつけて夕食をとりました。

週明けはJRが動かなくて出勤出来ず。でも息子は大喜びで一日遊んで攻撃に出会い、別の意味でヘトヘトに。でも、父親的にはじっくり遊べた事がいろんな事を考えさせられる良いきっかけにもなりました。

次の日はなんとか出勤出来ましたが、社内のサーバー達が心配でした。それらには、ソースコードを保管しているSubversionのリポジトリやRedmine、Wikiなどの開発プロジェクト管理、他部署とデータをやり取りする為のファイルサーバーなどなど、壊れるととてつもなく困る重要なものばかりです。

もちろん、バックアップの体制は作ってありましたが、（過去にCVS、Subversionのリポジトリをぶっ飛ばした経験ありw）恥ずかしながら弊社は最小限の設備でやっておりますので、結構不安でした。中でも重要なソースコードは二重にバックアップをしていましたが、その二次バックアップ先である市販のRAID付きNASが華麗にラックから落下しており、こりゃマジでディザスタリカバリだな、と心に誓いました。（幸い中身は無事でしたが、外装には左写真のような傷が。）

この手のインフラ仕事だと、通常はある程度社内的な根回しをしてから実務の合間を縫って作業を行うのですが、今回ばかりは余震も続き、停電の問題もあったので時間が勿体なく、とにかくすぐにやる事を心がけ、問題ない所から順次クラウドに逃がしました。使ったクラウドはもちろんAWS（Amazon Web Services）です。

やった事

まず、EC2インスタンスを一つ立てました。リージョンは少し考えましたが、ここはあえて東京を選びました。それじゃ意味ないかも？とも思いましたけど、国内からアクセスしやすいシンガポールも米国西海岸もよく地震の起きる地域ですので、ここはAWSを信頼しました。そのかわり、バックアップを米国東海岸のS3に置いています。

また、外部に出してはならない重要なデータですので、セキュリティグループは慎重に設定します。ひとまず現段階では社内からのみSSHとSSLが通信出来る状態にしておきました。インスタンスはsmallインスタンスが1つです。（節電のため、と言っておきますw）
AMIはこの際Amazon Linuxを、とも思いましたが、時間の節約の為にも使い慣れているUbuntuをチョイスしました。

以下、かいつまんでやった事を書いておきます。結局は普通の物理サーバーと同じ手順です。

Subversionの移行作業

【社内】svndumpでダンプデータを取り、EC2へコピーします。

svnadmin dump /path/to/repos | gzip > svndump.all.gz
scp -i hoge.pem svndump.all.gz ubuntu@ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com:/tmp

【EC2】svnリポジトリを新規作成し、そこにダンプデータを読み込み直します。
```
sudo svnadmin --fs-type fsfs create /data/svn
zcat /tmp/svndump.all.gz | sudo svnadmin load /data/svn
```
【EC2】Apacheにdav_svnを入れて、httpsでアクセス出来るように設定します。詳細は割愛。
```
sudo apt-get install libapache2-svn
```
【社内】開発マシンに入っているチェックアウト済みのプロジェクトは、svn switch --relocateしておきます。
```
svn switch --relocate OLD_REPO NEW_REPO
```

※ここで失敗したのが、古いSVNクライアント（1.4）から新しいSVNリポジトリにrelocateしようとした時に、"UUID mismatch" のエラーが出てしまった事です。これを回避するには、リポジトリにダンプデータをロードする際、"--force-uuid" オプションをつけると良いみたいです。現行のバージョン（1.6系）ではこの問題は発生しません。

SubversionのバックアップをS3へ

社内の体制では、svnsyncで別サーバーのリポジトリへ同期をかけるという事をやっていました。今回はやり方を変えて、svn-backup-dumpsを使ってローカルにダンプデータを累積しておきつつ、米国東海岸のS3に作った同期させる、という体制にしておきました。

ダンプデータをためるディレクトリを作成し、svn-backup-dumpsを一日一回、夜中に実行します。S3にはバックアップ専用のバケットを一つ用意し、s3cmdでローカルバックアップディレクトリの中身をsyncをするという単純なやり方です。

#ダンプデータのバックアップディレクトリ作成
mkdir /data/svn-backup

#このスクリプトを一日一回実行する
svn-backup-dumps -z -c 50 /data/svn /data/svn-backup/
s3cmd -c /path/to/s3cfg sync /data/svn-backup/ s3://US_EAST_BACKUP_BUCKET/svn-backup/

これで、めでたく米国東海岸のAWSにソースコードをバックアップする事ができます。もっと心配な方は、同時にEUにもシンガポールにも置けます。

また、データを置いてあるボリューム自身も定期的にスナップショットを取っています。こちらにそのスクリプトを置いてありますので、よろしければご覧ください。

EBS snapshotとS3を使い分ける

EBSのスナップショットは取るのも簡単、復帰するのも簡単なので非常に使い勝手が良いのですが、ボリューム丸ごとをバックアップするものなので、仮にファイルシステムそのものが壊れてしまった場合に復旧が難しくなる可能性があります。したがって、

EBSのスナップショットはある程度履歴を取っておく
DBやSubversionなど、「ダンプデータ」を取得できるようなものはS3にコピーしておく

という体制を取りました。

弊社の規模感では、このくらいで十分です。そもそもディザスタリカバリなんてクラウド以前ではちょっとした夢物語でした。今ではこんなに簡単に実現する事が出来ます。

さらにS3を使う

開発に直接的に関わる部分はこんな感じでOKなのですが、その他の重要な、しかも頭の痛い問題ととして、「ファイルサーバー」があります。弊社のケースで言うと、例えば印刷担当部署とのファイルのやり取りに使うようなもので、専門のエンジニア以外が扱えるようなツールじゃないと厳しい事になります。VPCの中にSambaのサーバーを立てて…とか、そんな余力はありません。そこでやはり出てくるのがS3です。SambaやAFPのような「ファイル共有」的な使い勝手からは少し離れてしまいますが、FTPソフトは普段使っている方たちなので、CyberduckやCloudBerryであれば使えるだろうと判断しました。

その経緯は、また後日別エントリを起こします。

AWS東京リージョンを使ってみて気がついた事

2011-03-10T20:36:00.008+09:00

http://photozou.jp/photo/show/200613/52796789

今、お仕事で使っているAWSですが、二年以上前から稼働させている関係上、ずっとUS-EASTにおります。ですので、レイテンシーなどの問題がある訳ですが、日経SYSTEMSさんにお話しした通り、なんとかがんばって工夫したのでそこそこ満足出来る結果が出ました。（こちらでも同内容が読めるみたいです。要会員登録。）

後にシンガポールリージョンが出て、皆「早い！」と大騒ぎしているのを横目に、「いつか日本に来るからそれまでじっとガマン…」しておりましたw
そもそもデータの移行なんかはインフラエンジニアがいない我々にとって結構な大仕事なので、できればやりたくない訳ですけど、待ちに待った東京リージョンが出たので引っ越しせざるを得ません（笑）

残念ながら今の所Avaliability Zoneが1つしかないのでアレですけど、Multi-AZになったら即引越したい！という訳で絶賛「引越のお見積もり中」です。

それをやっていく中でいくつか気がついた事があったのでツイートしてみたら、結構反響があったのでブログにも残しておきます。

その1

静的ファイルをCloudFrontに乗っけたり、キャッシュを効かせて頑張っていたけど、やっぱり近さにはかなわない。アプリのスピードアップが体感出来た。わかってはいたけど、この差は大きい。

http://twitter.com/dateofrock/status/45476737299128320
悲しいかな（嬉しいかな？）これが現実です。試しにMicro Instanceでちょろっと試してみたりしましたが、本番環境と大して変わらないどころか、動的画像の転送が圧倒的に早いのでむしろ体感的には早い…これって、全部Microでいい(ry

その2

アプリのデプロイが早い。特に単一ファイルの.warは一瞬。メンテが楽になる予感。

http://twitter.com/dateofrock/status/45477146998743040
これは実際に作業してみるまで気がつきませんでしたが、快適そのものです。まるでサーバーが隣にあるみたい。

その3

国内で大きく報道されたので、東京に引っ越したいと言うだけで会社のエライ人に話が通じるなどw

http://twitter.com/dateofrock/status/45480356937338881
やはりこれが一番反響が大きかったです。ひょっとしたら（というか確実に）一番重要な要素かも知れませんね。最終的には自分の母親に認知されるのが最終ゴールのようですw

第一回 JAWS-UG全国理事会とJAWS-UGサミット2011春

2011-03-08T02:24:00.007+09:00

濃密な一日だった訳で

2011年3月4日は13時から23時位まで、まさにAWS一色な一日となりました（笑）その記録です。

第一回JAWS-UG全国理事会

13時よりAmazonジャパン会議室にて、東京支部のコアメンバー、全国のJAWS-UG支部の代表、副代表、女子会会長、副会長の方々が集結しました。当日Amazonの受け付けに行ったら未だかつてない人数が待っていて、「さすがAmazon。訪問客もすごい数だなー」とか思っていたら、実はその大半がJAWS-UG関係者だったというオチがw。

会の中では各自の自己紹介タイムも含めつつ、コアメンバー向けの発表も行われました。Ustreamで配信OK、という事で、例によってビデオ担いで行ってきました。
事前にネットワークを使う事を連絡していなかった為に、忍者の方に急遽光ポータブルを借りましたがネットワークが安定せず、結局JAWS-UG会長私物のWiMAXで行いました。したがって、映像の品質は多少落ちています。ごめんなさい。

ServerWorksの紹介 - 大石様
ERPパッケージベンダーにおけるAWSの活用法 - ワークスアプリケーションズ様
CloudPack - 後藤様
ActionScript API For AWS - 横田様
Amazon EMR - 津久井様
RightScale紹介 - 小室様荒井様
CloudFormation - AWS大谷様

このようなセッションの後は、今後のユーザーグループの方向性等についてのディスカッションが行われました。（リアルタイムで配信しました）結構活発な意見が皆さんから出されてとてもいい感じでした。（私は「やりましょう」と何か言った気がしますけど…）

JAWS-UGサミット2011春

その後はいつもの富士ソフトさんの会議室に移動してサミットの準備を行いました。今回は早めに会場に入れたのでカメラの位置調整やセッティング等を余裕でこなせたので良かったです。初めて安心してUstreamに取り組む事が出来ました（笑）

今回はもちろん、待望の東京リージョン開設直後ですし、地方支部の方々の参加もあっていつもの勉強会と違い雰囲気がお祭りムードに。まさに今のAWSの空気感そのままのムードで始まりました。

JAWS-UGサミット開会の辞 AWS玉川様

この開会の辞は意表をつかれましたね。すでにJAWSのベストセッション候補とも言われています（？）
ムービー制作はLT常連の@tottokugさんの力作。思えば去年JAWS-UGでSQSネタで初めてLTしてからもうすぐ一年経つ訳ですが、それまでに起きた事が走馬灯のように駆け巡りました（笑）

AWS小島様より

AWSを日本に持ってきた一番の功労者である小島さん。思えば、こうしてUStreamerとして活動出来るのも小島さんのおかげだと思っております…というのは冗談で、小島さんにコアメンバーに誘われ、JAWS-UGの活動を通して色々と見聞をふかめつつ、地元札幌に講師の手伝いに行ったり執筆の機会を頂いたりするなど、印刷業界では経験出来ないようなアクティブな空気感を感じる事が出来ました。ここ一年くらい急速に視界が開けてきた気がします。IT業界…もとい、クラウドをキーワードに積極的に集まってくる前向きな人たちに囲まれる事は自分にとっても非常に刺激になりますし、コアメンバーとしてそういう集まりを微力ながらサポート出来る立場にいるのは非常に良い経験になっています。
東京リージョンがオープンする直前にお母様を亡くされたという事で、超多忙を極める中とてつもなく大変だったと思いますが、本当にご苦労様でした。というか、これで終わりじゃなくて、これからが本番ですので今後ともよろしくお願いします（笑）

ソリューションアーキテクトからのメッセージ AWS荒木様 AWS大谷様
ソリューションアーキテクト、カッコいいですね！荒木さん、大谷さんのような優秀なエンジニアがいれば東京リージョンも安心です。そのような方々がおもわず転職したくなってしまうのがAWS、という事ですね。わかりますw

「PrimeCloud Controller」を用いたハイブリッドクラウドの可能性」CSK 瀧澤様
私個人の仕事としてはプライベートクラウドとか全く用がないんですが、パブリック／プライベート問わず、IaaSを複数操るとなるとこの手の管理コンソールが必要になってきますよね。今後はそういったプロダクトも増えてくるのではないでしょうか。自分の立場はアプリケーションを開発する側なので、インフラの管理は誰かにお任せしたいですし、今後はそのような流れ（PaaS）が加速して行くと思いますが…ちなみに、途中画面がグレーアウトしちゃってます。オートフォーカスが変な所に行ってしまったせいです。ごめんなさい！

「AWSによるソーシャルアプリ運用事例」gumi 堀内様
堀内さんのプレゼンはZENPREという画期的なツールを使って配信しました。スライドは別画面でクリアに表示されますので、Ustream側は話者だけを狙って撮影出来ます。本当はスライド用、話者用と二台のカメラで配信したいのですけれど、ZENPREがあれば問題ないですね。すばらしいです。プレゼンが始まる前に多少の仕込みが必要なのとスライドのアニメーションが再現されないのがちょっと残念ですが、それは今後に期待です！ZENPREいいよ!！
ちなみに私、以前堀内さんのLTを聞いてRDSを使ってみようと思った人間ですが、それ以来RDSラブです（笑）

ライトニングトーク Livlis 関様「Livlis on AWS 」 RX7(並河)様「AWS振り返り」小室様「クラウドの女達」 Adobe様
LivlisがAWSだったとは。オープン当初、シェアを地でいくこのサービスに共感していくつか出品しましたが、どーにもサイトが重くて途中でヤメてしまいました。今アクセスしてみたらサイトはさくさく動きますね。もう一度トライしてみようかな？という気にさせられました。
並河さんのLTがこれまた良かった！情報はアウトプットする所に集まってくるというのは本当です。並河さんのブログはAWSを触り始めた頃にさんざん助けられましたが、未だに助けられている自分がおります（笑）
女子会会長小室さんのプレゼンは、全国のインフラ女子、ひいてはIT系女子は必見だと思います。クラウドは万人に平等なプラットフォームです。そこには男女の区別はありませんし、アイディアと実行力とそれを実現する技術的スキルがあれば、だれでもPlayerになれます。さらにブログでこんなご指摘が…

その中でコアメンバーの方にお願いしたのが、懇親会での身の振る舞い方です。コアメンバーとなれば知り合いも多く、話したい人も沢山いると思うのですが、懇親会こそ、初めて参加された方に声をかけるべきだと思うのです。

ごもっともです（;´Д｀）
AdobeさんはFlash Media ServerのAMIがある！というお話でしたが、これも関係者にとっては朗報ですよね。個人的にはACS4のAMIを作っていただきたい気もしますがw

パネルディスカッション「Amazon日本上陸により何がかわるか？」
モデレータ: PublicKey 新野様パネリスト：CloudPack後藤様、Ripplex太田様、サーバーワークス大石様、Gumi堀内様、エビイ米林様、キャピタルアセットプランニング片山様

PublicKeyの新野さんにモデレータを務めていただいたパネルディスカッション。エビィの米林さんが実に上手いことを言っておりましたが、私もそう思います。ちなみに昔から使っているユーザーは未だにUS東海岸リージョンを使っている事が多い様な気がします。自分たちがまさにそうなんですが、そもそもDCの引っ越しというのは大仕事ですし、レイテンシーの問題はキャッシュを使ったり静的コンテンツはCloudFrontで配信したり、と色々工夫して「まぁ何とかなっている」…というのが実情です。US東海岸に未だにいる方々は、US西海岸やシンガポールが出来ても引っ越しの苦労とリスクを考えると今ひとつモチベーションがわかなかったのではないでしょうか？でも東京となれば話は別ですね。うちでも本格的に引っ越しの準備に入りたいと思います。

懇親会は歩くのが困難なくらい満員でした（87名という事です！）。最後にはAWSの小島さん、玉川さんが胴上げされて、ついでに（？）会長と肝付さんも胴上げされておりました（笑）いやぁ、とても良い週末でした。次回のJAWS-UGも楽しみです！

地方支部の方々も、ぜひこの空気を持ち帰っていただいてもらえればと思います。そして、各支部の勉強会でもUstream配信してください！（お問い合わせは @dateofrock までw）

Amazon Web Services ガイドブック

2011-02-25T16:07:00.004+09:00

Amazon Web Services ガイドブッククラウドでWebサービスを作ろう！
出版社: インプレスジャパン (2011/2/18)
発売日： 2011/2/18

AWSのシニアエバンジェリスト、Jeff Barr氏の著作です。（ジェフさんのブログ）監訳は日本のエバンジェリスト玉川氏（@KenTamagawa）によるもので、本家本元から出てきたAWSガイドとなっています。

自分のブログでもさんざん触れているSQSやSimpleDBなど、EC2やS3以外のサービスについてサンプルコードと共に載っているのが嬉しい点です。（言語はPHPで記述されています）

個人的になんと言っても一番のオススメは第10章です。すでにAWSを使いこなしているエキスパートな方々もこれだけの為に買う価値はあるかも！？結構コユイ内容ですよ。

10.1　アカウント管理と追跡

Account ActivityからAWSの利用状況をCSVで落とし、それをSimpleDBに格納して利用状況を解析する！

10.2　Elastic Block Storage

EBSのsnapshotをSimpleDBで管理したり、EBSでRAIDを作る！

10.3　EC2インスタンスのメタデータ

意外に知られていないEC2のメタデータについての解説。

10.4　動的なダイアグラムの作成

EC2インスタンスにアタッチされているEBSやsnapshotを絵にする！（これはイイ！）

余談ですが、先日のJAWS-UG勉強会でサイン本を頂いちゃいました！がんばってUstreamやって良かったw
※ちなみにここにもいらっしゃいましたねw

玉川さんのあとがきの一番最後のセンテンスはかなりビビっときますねー。個人的にはもっと言ってー、という感じです（笑）。

EC2インスタンスの停止通知に関して、本日出くわしたパターン

2011-02-09T11:09:00.008+09:00

記事タイトルを
「EC2の計画停止に関して、本日出くわしたパターン」
から
「EC2インスタンスの停止通知に関して、本日出くわしたパターン」
に変更しました。

計画停止という言葉はサービス全体が止まるイメージがあるとのご指摘がありました。この記事では特定の機器メンテナンスの為にどうしても影響が出てしまうEC2インスタンスにのみ、こういった事が起きる事がある、という事です。

EC2インスタンスの停止通知に関して、本日出くわしたパターンをメモっておきます。

2011年2月5日に以下のようなメールが来ました。

Subject: Maintenance Affecting your Amazon EC2 Instance

Hello,

Some of your instances in the us-east-1 region are on hardware that requires maintenance. Your other instances that are not listed here will not be affected.

i-12345678

For the above instances, we recommend migrating to replacement instances to avoid any downtime. Your replacement instances would not be subject to this maintenance.

If you leave your instances running, you will lose network connectivity for up to one hour. The maintenance will start at 1:00pm GMT (5:00am PST) on Friday, February 11, 2011. After the maintenance is complete, network connectivity will be restored to your instances.

As always, we recommend keeping current backups of data stored on your instance.

Sincerely,

The Amazon EC2 Team

「あなたの使っている i-12345678 というEC2インスタンスは、ハードウェアのメンテをします。メンテ中は小一時間ネットワークが使えなくなりますよ。」というものです。
今回は作業する時間もなくてしばらく放置しておりました。

すると、4日後にまたしてもメールがっ！（赤字は私が強調した部分です）

Subject: UPDATE: Maintenance Affecting your Amazon EC2 Instance

Hello,

We are following up on a maintenance notification we sent previously regarding Amazon EC2 instances listed below to clarify the impact of this maintenance. Only the instances listed here will be affected by this maintenance.

i-12345678

The maintenance will occur during a 4-hour window starting at 1:00pm GMT (5:00am PST) on Friday, February 11, 2011. During the maintenance, your instance will be powered off. After the maintenance is complete, power will be restored and your instance will reboot.

To avoid any downtime for the above instance, we recommend migrating to a replacement instance. Your replacement instance would not be subject to this maintenance.

As always, we recommend keeping current backups of data stored on your instance.

Sincerely,

The Amazon EC2 Team

「EC2はシャットダウンされます」になっておりました（汗）

という訳で、Amazon EC2 Teamからのメールはよく読みましょうね！

【関連】

Amazon EC2は、まれに「計画停止」されます

G-CLOUD Magazine 2011にAmazon SQSの記事を書きました

2011-02-08T19:38:00.000+09:00

G-CLOUD Magazine 2011
2011年2月11日発売
B5判／156ページ
定価1,659円（本体1,580円）
Amazon.co.jpで見る

「AWSガイド2011-進化を遂げるAmazon Web Servicesをフォローせよ」という特集の中で、Amazon SQSに関しての解説と、実際にAPIを使って簡単なサンプルアプリを作ってみる記事を書きました。技術評論社様、およびJAWS-UGの皆様ありがとうございました。

Software Design 2010年11月号に書いたMyBooks.jpでの事例にて、ちらっとSQSに関して触れていますが、紙幅の都合上詳細を書く事が出来なくて少々残念な思いをしておりました。しかし、大変ありがたい事に今回このムックへの執筆依頼を頂戴しまして、がんばって書いた次第でございます。

Amazon SQSに関しては、このブログでも再三取り上げていますので今更何をか言わんやなのですが、知名度が今ひとつだなぁ・・との実感がありました。この記事では、SQSそのものの解説もやっておりますが、実際にサンプルアプリケーションをRails3で構築するところまで踏み込んでみました。ソースコードも用意してありますので、お手元で試す事が出来るようになっています。（要AWSアカウントですがw）
SQSは用途が限られているとはいえ、ツボにはまったら非常に強力でしかも激安です。少しでも皆様に知っていただけたら・・と思います。

その他、この特集では

MySQL5.1/5.5をサポートするRDSの解説（Oracle Database 11gのサポート予定も先日発表になっています。）
EMR（Elastic MapReduce。Hadoopがすぐさま使えます。）の使い方と運用ノウハウ
ELB（Elastic Load Balancing）+EC2+RDSの組み合わせで、gumiさんが実際に運用している例
AWS ADK For PHPに関する解説

が収録されています。最近ではAWSの入門書籍もかなり出てきましたけど、一歩踏み込みたい方におススメの一冊です。

【関連】

※片山さんは一番厳しいパートを担当されましたねw

クラウド女子会になぜか参加してきた

2011-01-28T21:01:00.008+09:00

2011年1月27日に、Amazonさんの本社にて、「Japan AWS User Group (JAWS-UG) クラウド女子会」が開催されました。

そして、そこで私が男子にも関わらず、しかも中の人でもないのに発表する事になった経緯を以下にまとめましたので、よろしくご査証くださいw

まぁ、一言で言えば墓穴を掘った事になりますがなw
しかも、自らUstreamで配信している訳で、自作自演で玉砕という最悪のシーンも思い浮かぶ訳です((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
さらに後日、コアメンバーの集まりで「すべる」「どん引き」などの様々な心ない言葉をかけていただき、最終的にクラウドお兄さんとしてデビューする事になりまして大変ありがたき幸せに存じます。

数々の講演をこなしてきているAWSエバンジェリストの玉川（@KenTamagawa）さんですら「こんな経験はない」と言わしめた、超アウェー感満載のプレゼン、実に良い経験をさせていただきました（汗）

まぁ、そんなこんなでしたけど、会自体は皆さん初対面同士、という事で、少し固い感じで始まりましたが、宅麺さんのラーメンスープの香りが漂ってきた頃にはだんだんと雰囲気もほぐれ、良い感じになってきました。自分はというと、Ustreamの機材が普段と違っていたので、途中でアプリを落っことしてしまったり、Recordするのを忘れたりと明らかに舞い上がっていた訳ですが（笑）、普段あまり聞く事の出来ないJavariの中の人のお話や、人事の方のお話など興味深く聞きながら、音を立てないようにラーメンをすすっておりました。（音を立てると配信音声に思いっきり入ってしまう為）

Ustreamの視聴者は平均50名位だったでしょうか？おそらくほとんどが男子だった思われます（笑）
「客席うつせー」とか言われるかなと思いましたけど、みなさん紳士な方ばかりだったようで、そのようなお下品な反応はなかったようですね！

発表の方ですが、@mikiT_TさんのRoute53というリリースされたばかりの、しかもDNSを知らないとそもそもこのサービス自体が理解出来ないwというコユイ内容から始まり、私としてはちょっと安心。（なんでだろw）

@AyaKomuroさんはなんと着物姿。着物を着てAWSとかRackSpaceとか言っている人初めて見ましたw それはともかく、クラウドを使いたい場合に一番難しい所はまさにプレゼンにあった「関係者を納得させる」事だと思いますので、ふんふん頷きながらラーメンすすってました。（またラーメンかよ）

そして自分の発表ですが、さすがにSQSと女子力を絡めるのは無理だったので（トライはしたんだよ、トライはw）、ブログ製本サービス（MyBooks.jp）のお客様が7割女性だという事実を絡めて、danboを大幅フィーチャーして話を組み立ててみました。思いっきりキャラに頼ったプレゼンテーションです。

女子たちに明日はない～AWSを使い倒して女子力アップ!?

View more presentations from Takehito Tanabe.

ちなみに壇上から見た客席の光景は未だに忘れることができませ(ry

その後の玉川さんのおはなしは、正直TwitterのMentionの処理に追われてあまり聞いてませんでしたw
しかし、忙しいスケジュールの中で、あの女子力を絡めた話に持っていくのはさすがです・・。さすがエバンジェリスト！

ちなみに、今回の自分のスライドですが、凝ってますね、と言われましたど、実質Keynoteの作業は2〜3時間です。話す内容を一週間くらい心の隅に暖めておきつつ、三日くらい前に紙にぐちゃぐちゃ書き出して、それをテキストに起こして整理してシナリオを作りました。本当はもっと余裕を持ちたかったのですけど、なんせ絶賛引っ越し中＆仕事も立て込んでいるという状況でしたので、ここは一気にやっつけました。

danboに登場願うことを思いつき、Flickrでひたすら（必死の形相で）danboを検索、シナリオに合う画像を片っ端からダウンロードしました。（著作権の問題があるので、Creative Commonsライセンスの制限をかけます）
また、写真素材足成という実にナイスなサイトがあるので、こちらの画像も使わせていただきました。さらに一部のオブジェクトはJumsoftに非常に質の高い素材が置いてありますんで、こちらも利用させていただきました。

というわけで、スライドはいつもよりも手抜きです（すまん）。思いっきりdanboとjawsちゃんwとKeynoteの力に助けられました（困ったときのキャラ頼み）。
訴えたかった事はスライドにある通りです。せっかくの機会なので、本当はもっと話したい事がありましたけど、詰め込みすぎてもあれなので自重しました。

なにはともあれ、日本初？ひょっとしたら世界初？クラウド女子会の無事成功、おめでとうございます。くのいちの方々、玉川さん、Amazonの方々、皆様お疲れさまでした。参加されたクラウド女子の方々も、今後ともJAWS-UGをよろしくお願い致します！

日経SYSTEMS 2011年1月号で紹介されました！

2010-12-27T15:46:00.002+09:00

日経SYSTEMS 2011年1月号の「クラウド利用のシステム構築」という特集にて、ブログ製本サービス「MyBooks.jp」での事例を取り上げていただきました。
取材当日はいろいろとお話しさせていただきましたが、一番大きく扱ってもらったのが「画像のキャッシュ」に関する事です。AWSの米国東海岸にあるデータセンターと日本国内との距離の問題について解説されています。また、自前運用のデータベースからAWSのRDSに乗り換えた事も触れていただきました。

この特集記事ではたくさんの現場の人たちの声が聞こえてきます。「クラウド」の本格運用はまだ始まったばかりかもしれませんが、徐々に普通な事として浸透してきているなぁ、という印象を持ちました。それと同時に、みなさんそれなりに苦労されているな、とも（苦笑）

でも、クラウドに限らず何でもそうだと思いますけど、良いところを的確につかんで信頼性やコストでメリットが出るのであれば、悪いところは工夫すりゃ何とかなると。その為のエンジニアリングな訳ですし。色々難しいところはあるかと思いますが、情報インフラを「シェア」していくクラウドコンピューティングは今の潮流にも合っていると思います。

Twitterアイコンのシールを作りました

2010-11-09T00:52:00.005+09:00

前回のエントリで、@crown_sugarさんにTwitterアイコンを描いてもらった訳ですが、記念にPRINTAILさんにお願いしてTwitterアイコンをシールにしてもらいました。

こんな感じで、自分が40人いる訳ですが（笑）、勢い余って10枚発注した結果がこちら。

ちょっとやりすぎましたかね（汗）おそらく息子は大喜びして部屋中にシールを貼りまくる事でしょう（違）

ちなみにこれだけ作っても、送料込みで¥1,540でした。（実際は3シートからで¥980）

印刷品質も良いですし、これは大変お買い得です！

全然関係ないですけど、PRINTAILさんのお仕事はオンデマンド印刷を駆使して一般コンシューマー向けのサービスを展開されてらっしゃいます。印刷屋目線で見るとちょっと興味深いですね・・

Twitterアイコンを@crown_sugarさんに描いていただきました

2010-11-05T01:22:00.003+09:00

Twitterで有名なイラストレーター、@crown_sugarさんにイラストを描いていただきました！
ご存じない方は、Togetterに経緯がまとめられておりますので、ぜひご覧ください。

Twitterのアイコンですけど、初めて人と会って名刺交換する際に、TwitterのIDが併記されていると、実はフォローしていたり、フォロワーだったりと、意外に繋がっている事も多くびっくりします。（ちょっと前まではそれがブログでしたが・・）
その時に名刺にTwitterのアイコンがプリントされていたり、シールになって貼ってあったりすると一発で解ります。（ちなみに、早速PRINTAILさんにシールを発注しましたw）

@crown_sugarさん本当にありがとうございました。ソーシャルメディアを生かしてすばらしいお仕事されていると思います。今後のご活躍も期待しております！

Software Design 2010年11月号に寄稿いたしました

2010-10-19T08:00:00.005+09:00

Software Design (ソフトウェアデザイン) 2010年 11月号
2010年10月18日発売
B5判／216ページ
定価1,280円（本体1,219円）

「第1特集 Amazon事例国内新サービスから学ぶクラウド時代のシステム管理［実践］基礎知識」という特集で、自分が手がけているブログ製本サービス「MyBooks.jp」とその編集ツールである「MyBooks Editor」において、Amazon Web Serviceをどう活用しているのか？という事例を6ページ程でご紹介させていただきました。

思い起こせば、個人的にクラウドの衝撃（笑）を受けてから、かれこれ一年半以上が経過しました。最近になって「クラウド」という言葉がよく聞こえる様になってきましたが、よく解らない使われ方をしているケースも見受けられますし、単なるマーケティング用語、バズワードと捉える向きもあるようです。

しかし、国内のいわゆるユーザー企業は、自分たちでクラウドを使い始めています。そして、その潜在的なパワーを身を以て体験しています。今年の始めに「中小企業こそクラウドコンピューティングの波に乗れ」という記事を書いた時には、中小企業やSOHO/ベンチャーにこそ、クラウドは効く、という思いがありました。それは今でも変わっていません。（とはいえ、まだ一年経っていない訳ですが・・思えば遠くへ来たもんだw）

なお、この特集前半では、今をときめく株式会社gumiさんの事例が載っております。1-2章はインフラご担当石川さんの執筆で、とてつもないトラフィックをAWSでさばくノウハウが掲載されておりますし、CTO堀内さんのAWSに取り組んだきっかけなど、貴重なお話が満載です。特に、今後AWSに取り組もうかな？と考えている/取り組む予定がある方は必見の内容です。

ちなみに、弊社の事例ですと、gumiさんに比べれば断然スケールが小さいですが、導入したきっかけが似ているので勝手に親近感を覚えております（笑）

なお、さりげなくAWSWatchに言及しているのは秘密です。