code.rock: AWS

ラベル AWS の投稿を表示しています。すべての投稿を表示

2016/10/06

AWS Cloud Roadshow 2016 札幌登壇のお知らせ
Tweet

なんだかすっかり告知ブログになっちゃってますが、大きめのイベントに登壇させていただくので、お知らせいたします。

AWS Cloud Roadshow 2016 札幌

日時：
2016 年 10 月 12 日（水）ニューオータニイン札幌
10:00 ～ 20:30 （開場：9:30）

「スケーラブルな農業機械」の実現を目指す、農業情報設計社の取組について、というタイトルで、弊社代表の濱田とともにお話しさせていただきます。

自分が話す内容ですが・・一応技術の責任者ですし、AWSのイベントなので、ちゃんと技術の話をします！（笑）

スタートアップの分際でいきなり世界3拠点のマルチリージョンなシステムを構築しておりますが、そんなことを実現できるAWSのマニアックな利用方法？を含めてお話しするつもりです。とはいえ、時間がないので、めっちゃ駆け足になると思います。あらかじめご了承ください（笑）

そのうち落ち着いたら、少しずつ技術的な部分を公開していくつもりです。（と自分にプレッシャーをかけてみるw）

では、当日ニューオータニでお会いしましょう！

2014/04/17

AWS Elastic BeanstalkはImmutable Infrastructureそのものじゃないか
Tweet

ちょっと遅くなってしまいましたが、第13回 JAWS-UG札幌勉強会で発表してきましたので、ご報告いたします。なお、今回でこのシリーズは完結いたします（笑）

ブログ製本サービス MyBooks.jpのアーキテクチャ Part.3 AWS Elastic Beanstalkについて from Takehito Tanabe

ちなみに先月の JAWS DAYS 2014 では、Immutable Infrastructureのトラックが常に超満員でして、通路にまで人が溢れおりました。また、東京方面ではImmutable Infrastructure Conferenceが開催される位、ちょっとしたイミュータブル祭りになっているようです（笑）しかし、その中であまりAWS Elastic Beanstalkについて話題が出てこない気がしたので、今回あえて発表させてもらいました。

まだサーバーにSSHでログインしてるのかい？

AWS Elastic Beanstalkは、まさしくBlue Green Deploymentをするためのサービスですし、そもそもEC2起動時にkey pair指定をしなくても良い=サーバーにログインしなくてもいいんじゃね？という事実が、イミュータブルっぷりを発揮しております。
※ちなみにスライドにもある通り、個人的にはkey pairを指定していますw でも個別のサーバーにSSHでログインする機会は滅多にありません。

Elastic Beanstalkがリリースされた2010年当時は、このkey pair指定をしなくても良い、という意味が全く分かりませんでした。当時はconfigで環境を自動構成する機能（公式ドキュメント）もなく、カスタムAMIをあらかじめ準備する必要がありました。しかし、カスタムAMIを作るという事は、そのAMI自体を管理して行かなければならない、という別のタスクが発生します。例えば、先日のHeartbleed Bugのような重大なセキュリティの問題が発生した場合、そのソフトウェアを最新版に更新した上で、再度AMIに保存し直す、といった作業が発生します。管理すべきものを増やしたくないのに、これでは本末転倒です。Chefなどのプロビジョニングツールも良いのですが、そこまで大げさじゃないんだよなぁ、という場合、このconfigがちょうど良い感じなんです。

ちなみにconfigではスクリプトも実行出来ちゃいます。ということは、要するに何でも出来るのですが（笑）configでは書ききれずにスクリプトを書いてしまう場合は、無理してElastic Beanstalkを使わずに、別のソリューションを使った方が良いと思います。（【参考】EC2 インスタンス上のソフトウェアのカスタマイズ）

インフラの構成管理をある意味強制される

基本的にconfigはアプリケーションのソースコードの中に入ります。具体的には

$APP_ROOT/.ebextensions/*.config

という場所に入りますので、基本はgitやsvnなどのソースコード管理システムの中に一緒に放り込まれるでしょう。そうすると、インフラの構成もバージョン管理されてしまうという・・まさにDevOpsな世界が自動的に出来上がりますw AWSはこの点を意識しているのかどうか・・よく解りませんけども、個人的には良く出来ているなぁ、と思います。

運用のベストプラクティス？

Amazonの長年の経験で培ってきたものがAWSにあるとすれば、まさしくサイト運用のベストプラクティスが詰まったものがElastic Beanstalkなんじゃないか？と思います。他のサービスに比べれば地味でパッとしないかもしれませんけども（笑）使いどころを間違えなければ、Elastic Beanstalkは初期学習コストも異様に低いですし、サイトの運用負荷を劇的に下げられる強力なサービスだと思います。

2012/12/02

Amazon SWF Flow Frameworkのエラー処理について
Tweet

AWS Advent Calendar 2日目担当の@dateofrockです。初日は横浜支部の吉田さんが書いておられます。なんでもラスベガスで開催されたAWSのグローバルイベントに参加された後、シアトルのホテルから記事をアップしたとか。うらやましー。

こちらはすっかり冬景色の札幌からお送り致しますww

どうでも良い前フリ

http://www.flickr.com/photos/trasroid/3108074700/

えーと、全然関係ないですけど、サンタクロースってトナカイが引っ張るそりに乗って来ますよね。しかも、煙突から入ってきますよね。
クリスマスの季節には雪で真っ白な札幌に生まれ育った自分にとって、このサンタクロースはリアルに感じられておりました。
クリスマスが近づいても雪が少なかったりすると、そりが滑らないんじゃないか？とマジで心配したり、自宅の煙突はきちんと掃除されているか気になったり...（笑）

神奈川に住んで、東京で仕事を20年やってきましたけど、関東のクリスマスって雪も降らないし空っ風ピュ〜だから、子供達は皆どう思っているのか、長年の疑問でしたww

うちの息子もいったいどう思っていたのか・・？彼が大人になったら聞いてみたいと思います（笑）

ネタはSWFです

さて、このAWS Advent Calendarは執筆陣が豪華なので、このメンツの中でいったい何を書けば良いのやら、結構悩みました。JAWS-UG札幌支部から代表？として書くからには、あまり下手な事はかけないし、さらに日程をAWSの荒木さんに譲って頂いたので、これはガッツリ「ディープな話題」で行くしか無いとwww

先日のラスベガスで日本初のCDP（クラウドデザインパターン）を世界に対して発信されたAWSの片山さんが、すでにスベってるタイトルでSWFを取り上げるらしいのですが、楽しく正確な記事はそちらを見て頂くとして、私は以前書いたFlow Frameworkをさらに掘り下げることをやってみたいと思います。

なので、前回の記事を読んでいない方はそちらを先に読んでください！じゃないと、今から書く記事の意味が分からないと思いますwww

あと、コードはgithubに置いてありますので、そちらもどうぞ！

失敗を恐れるべからず

SWFで処理するワークフローはこのような感じでした。

だれかがS3へ画像をアップロードする
S3から画像をダウンロードする
モノクロに変換する
処理完了をメールでお知らせする

これを見ると、危険な場所が沢山ありますよね。例えば、ファイルをアップロード・ダウンロードする訳ですから、ネットワーク障害などで失敗する可能性もあります。また、画像変換処理も危険な香りがしますよね。

ワークフローの途中で処理に失敗した場合、その先の処理は当然出来ないのできちんとワークフローを中断させる必要があります。
また、処理が失敗した事をログに書いたり、管理者にお知らせしたくなってますよね？

こういう面倒な事をスッキリ実現出来るクラスがFlow Frameworkに用意されています。では実際のコードを書いてみましょう。

話を簡単にする為に、S3からのアップロード、ダウンロードに失敗する事を想定してみます。もとのActivityのコードはこんな感じでした。これらのメソッドに対して、きちんと例外をスローするように変更しましょう。

想定されるエラーを分析すべし！

もともとAWS SDKではAPIの呼び出しでエラーが発生した場合、AmazonClientExceptionのサブクラスが投げられます。これはRuntimeExceptionを継承したクラスなので、try/catch節を書かなくて済む、という利点がありますが、ついつい忘れがちなので注意が必要です。また、実装クラスの中ではローカルにテンポラリファイル作ったり、ストリームを読み書きしている部分があります。これもIOExceptionが投げられる可能性があります。

この二種類の例外は性質が全く異なるものですので、一緒くたにせずにきちんと分けて処理する事にします。その為に、オレオレExceptionを定義しておきます。（これが後で効いてきますよ！）

この例外をスローするように、アクティビティの実装を改良してみましょう。

エラーは謙虚に受け止めた上で、雲になげてしまえ！

さて、WorkflowImplの方ですが、普通に考えたらスローされる例外をJavaのtry/catch/finally節で処理するでしょう。そのようなコードは一見問題なさそうに見えますが、忘れちゃならないのが「非同期実行される」という事実です。各アクティビティをわざわざメソッドに切り出して、@Asynchronousアノテーションを付けている事を忘れないでくださいw

SDKではTryCatchFinallyクラスが用意されています。実装のやり方は簡単。Javaのtry/catch/finally節を書くのと同じ要領です。

doCatch()の中では、ログを書いて、管理者にメールを送って、例外を再スローしています。
doFinally()の中では今回は特に何もしていませんが、後始末などが必要であればここで行います。

ちなみに、スローされた例外を握りつぶしてしまう（再スローしない）と、SWFから見た場合そのアクティビティの実行がうまく行ったと判断されてしまいます。（タイムアウトなどを除いて）

例えば、アップロードに失敗したのに、ダウンロードがうまく行くはずがありませんが、前段のアクティビティがエラーになってしまった、という事実をSWFが把握出来れば、次のアクティビティの実行をきちんとキャンセルしてくれます。ですので、我々は例外に対して何も心配する必要はありません。

起きてしまったエラーはそれはそれとして心の中で事実として受け止め、大いに反省し、次のステップへの大いなる啓示として前向きにとらえた上で、えいやっ！とその例外をもう一度クラウドの中に放り投げましょう。

心広きSWFは、その邪悪なワークフローをしっかりと止める事が出来ます。

失敗したって、もう一度やってみればイイじゃないか。

さて、例外処理が出来て一安心ですが、実際に問題が起きた時に、そのリカバリーを誰がするのか？という事になります。SWFにはRe-Run（ワークフローの再実行）という機能があるので、それを手動（やそれに近い方法）で行う事も可能ですけど、今イチあか抜けないですよね。そういう貴方にFlow Frameworkが提供するのは、Exponential Retryです。つまり、自動リトライ機能です。早速これを実装してみましょう。

Exponential Retryでは、「何秒後にリトライを開始して、それを何回やるか」を設定します。例えば以下のような事が簡単に実現出来ます。

アクティビティが失敗したら、5秒後にリトライ
1回目のリトライに失敗したら、10秒後にリトライ
2回目のリトライも失敗したら、今度は20秒後にリトライ
3回リトライしてもダメだったら、そのワークフローは終了

リトライの間隔はExponential（指数的）に倍増します。実装は非常に簡単。@ExponentialRetryアノテーションを自動リトライさせたいメソッドに加えるだけです。ここでは例として、S3Activitiesのdownload()メソッドに自動リトライをかけてみましょう。

簡単すぎて、このスゴさが伝わらないんじゃないか？と若干心配ではありますが（笑）、ここで一旦立ち止まって、深呼吸をして、胸に手を当てて、本当にコレで良いのかよ〜く考えてみてください。

・・・
・・・
・・・

オレはこんなにもSWFに頼っていいのか・・・いくらクラウドが無限にスケールする、って言っても、何でもかんでもリトライさせるのは賢くないよね・・・

賢くリトライするべし

download()の実装で考えられる例外は、大きく分けて二つあります。

S3のAPIエラー
ローカルファイルシステムのI/Oエラー

2番目の原因がディスク障害だったりすると、これはどう考えてもリトライさせない方が良いですよね。その場合は、S3のAPI例外がスローされた時だけリトライする、という設定をしましょう。exceptionsToRetryという属性を追加します。

S3の例外は、先ほど作ったMyS3Exceptionです。オレオレExceptionをあえて作った理由はここにあります。「リトライするかしないか」と言う事を切り分けたかったからなんです。「あとで効いてきますよ！」というのは、ここの事です。

ちなみに、@ExponentialRetryアノテーションでは粒度が大きすぎる！なんて言う場合は、RetryDecoratorなんてのもあります。これはワークフローの実装の中で、Activityクライアントのリトライポリシーを動的制御したい、なんて時に有用そうです。さらには、AsyncRetryingExecutorなんていうExecutorもあるようです。

え〜、両方とも使った事無いので、「ある」という事実だけお伝えし、コメントは控えておきますwwww

と言う訳で、複雑になりがちで、かつ信頼性の高いリトライ機能を組み込むのは非常に大変ですが、Flow Frameworkはこのように非常に簡単に組み込む事が可能です。

まとめ

以上、簡単にまとめてみましたが、自前でコレと同じ事を実装するとえらい大変な事になる事は皆さんお分かりでしょう。Flow Frameworkはこのように非常に実践的で、しかも簡単に作れるようになっています。

でも、一点、言っておきたいのが、設計をきちんとしておかなければ、このような有用な機能が全然活かせない、という点です。ここはある意味非常に難しい（笑）インターフェースをきちんと定義しておかないと、あとで「なまらわやくちゃ」になるので頑張りどころです。

これに関しては、中の人の名言がありますので、最後に引用させていただいて、JAWS-UG仙台の小泉さんにバトンを渡したいと思います！

@dateofrock @ar1 Flowは設計しないやつはいらねえ！って感じの漢なフレームワークです
— Shinpei Ohtaniさん (@shot6) 9月 19, 2012

2012/10/10

コンフィグファイルを使ったElastic Beanstalkのカスタマイズをやってみた
Tweet

【AWS発表】コンフィグファイルを使ってさらに柔軟にElastic Beanstalkをカスタマイズ可能に - Amazon Web Services ブログ

すっぴん状態のBeanstalkを使えるのなら別ですが、普通は色々パッケージを入れたり、Tomcatをカスタマイズしたりといくつか作業が発生すると思います。今までだとカスタムAMIを事前に作って置くとか、cloud-initで自動構築するとか、要するに事前の仕込みが必要だった訳ですけど、ひょっとしたら設定を書いておけば全部済むかも？と喜び勇んで早速試してみましたw

ですが、やはり一筋縄では行かなかったので、いくつかハマりポイントをメモです。今日一日これを検証してますが、早速ハマったポイントをメモっておきます。

パッケージを自動インストール

きちんとバージョンまで書かないとうまく行かないっぽい。（yumでしか検証してないけど）

任意のコマンドを実行

アプリをdeployするたびにコマンドが走るので、それを念頭に置く必要がありそう。例えば以下の例では、二回目以降のdeployでFile existsのエラーになってしまう。

ソースアーカイブを自動解凍

モノによってはmakeしたり実行権つけたりシンボリックリンク張りたくなる。
これをやるには別途コマンドを追加しなければならない。

2012/06/20

Elastic BeanstalkでカスタムAMIのタイムゾーンを変更してハマった件
Tweet

Elastic Beanstalkが日本に来てから約2ヶ月経ちますが、つい出来心で本格的に使う事になりましたので色々と触っております。一般的にはどうなのかよくわかりませんが、自分のニーズでは標準のAMIそのままでは不足ですので、自ずとカスタムAMIを作成する事になります。

Beanstalk用のAMIの最新バージョンを探す
普通にEC2インスタンスとして立ち上げて、ログイン。ごにょごにょする。
AMIを保存して、AMI IDをメモっておく。
BeanstalkのEnvironmentで、自分で作ったカスタムAMIのIDの指定をする。

これでBeanstalkでアプリが起動してめでたしめでたし、のはずですが、しばらくすると勝手にEC2が落ちますw
BeanstalkのEventログを見てみると、あれ？BeanstalkがEC2インスタンスを落としてるじゃんw 自分で立ち上げておいて落とすなんてヒドい…

Beanstalkが立ち上げてくれたEC2にログインして、http://localhost:8080 を見てみるとちゃんと生きてる。と言う事は、Tomcatの死活監視をしてらっしゃるhostmanager様がたぶん勘違いしているはず…（Elastic Beanstalkの内部的な事は、こちらの資料に詳しく書かれています。: AWSマイスターシリーズReloaded(AWS Beanstalk) ）

というわけで、ログ（/opt/elasticbeanstalk/var/log/hostmanager.log）を見てみました。すると、というエラーが整然と並んで記録されておりますorz

EC2のタイムゾーンを弄ったから？

ちょっとググってみたら、AWSのフォーラムに同じような質問がありました。

AWS Developer Forums:multiple failures to retrieve status of instance - https://forums.aws.amazon.com/thread.jspa?threadID=63368

質問の回答には「EC2のタイムゾーンをGMT以外で使わない事をオススメする」と言う事で…あぁ、確かに思い当たる節があるw 確かにカスタムAMIを作ったとき、タイムゾーンをJSTにしたわ。と言う訳で、GMTに戻してみたら、hostmanagerのエラーは出なくなりました。ただ、そのままだとアプリ側の日付処理がずれるので、JVMのオプションに-Duser.timezone="Asia/Tokyo"を指定しました。かっこわるいけど仕方が無い…

これ、どうなんだろ？クラウド的（？）にはタイムゾーンはGMT！ってのも分かりますが、実際は変えちゃう事も多いのでは？

ちなみに問題のhostmanagerがtimestampをパースしている部分ですが、となってます。Time.iso8601(timestamp)をお好みのものに変更すればうまく行きそうな気もしましたが、ハマるといけないので自重しました（笑）

2012/02/21

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

この間の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

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

2011/07/20

AWS SDK for Ruby
Tweet

「七夕記念企画／雲(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]

2011/05/19

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

CloudWatchのカスタムメトリクス

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

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

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

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

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

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

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

JMXから直接CloudWatchのカスタムメトリクスに投げられるものなんてまだないよね…

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

と突っ込まれましたので、簡単に作ってみました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/16

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

サーバ／インフラエンジニア養成読本 [現場で役立つ知恵と知識が満載！] (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

2011/04/20

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

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って、ほんといいもんですね！

2011/04/14

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

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であれば使えるだろうと判断しました。

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

2011/03/10

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

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

2011/02/25

Amazon Web Services ガイドブック
Tweet

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

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

2011/02/09

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

記事タイトルを
「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は、まれに「計画停止」されます

2011/02/08

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

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

登録: 投稿 ( Atom )

MyCSS

リンクリスト