今日(6月18日) JAWS-UG 大阪支部の第三回勉強会が行われました。前回と同様テレビ大阪さんのご厚意により会場を提供していただきました。満員御礼で大盛況でした。
さて私は今回は LT ではなくUGの枠で、AWS 実演販売^h^hのコマを担当しました。
そのコマの資料は JAWS-UG 大阪支部の Web で公開することにして、「実演」でつかったアプリの紹介と CloudFormation、CLoudWatch custom metrics のスクリプトのリンクをここでかいておきます。
MacOSX用 S3 ツール
Route 53
CloudFormation Template
CloudWatch custom metrics + munin-node
# また時間たりなかった orz
4月23日土曜日に JAWS-UG 大阪支部の第二回勉強会が開催されました。
今回は、初心者向け勉強会としてAWS入門編でハンズオンを企画しました。前々回前回と富士ソフトさんのご協力で会場を使わせていただいていたのですが、今回はテレビ大阪さんの支援をいただいて、大手前のテレビ大阪の会場を使わせていただける事になりました。ありがとうございました。
当日は生憎の雨でしたが、会場はほぼ満席の状態で、支部長の挨拶から始まり、玉川さんのプレゼン、メインメニューのハンズオン(S3のみならずEC2まで)(想定外のドラ息子?の登場)、恒例のLT(これは由緒正しいドラ娘)とつつがなく進み大成功でした。 :-)
さーて、私の第二回のLTは、今回は短時間でヤルというのを課題にしていて、なんと2分で終了という快挙を成し遂げたとおもったら、司会の赤井さんからの厳しいツッコミが入り後半はヘロヘロになってしまいました。申し訳なし。 :oops:
今回は初心者向けということで、インフラ寄りに突っ込んでの話は準備してなかったのですが、時間が余ったので、もっと深い話をしたら良かったかなと反省しています。ではスライドをご笑納下さい。
t1.micro + WordPress + CloudFront この組み合わせはかなりイイ! Cloud Formation の Template 作ったらウケますかね?
詳しくはwikiで : http://www.egrep.jp/wiki/index.php/CloudFront_custom_origin
先週の木曜日の午後に AWS で障害が発生しました。AWS EC2 では Region と Availability Zone という概念で区画されています。障害が発生した Region は us-east-1 (米国 東海岸) でした。この us-east-1 は一番古く、顧客も多いので、数の論理と古い資産という意味で、価格が他の Region より安価で、個人的に AWS を使っている私は、ネットワーク・レイテンシーよりもお値段という事で、この Region を愛用しています。
さて、AWS からの障害通知 (AWSWatch ありがとうございます) を受けて、us-east-1 で稼動している、私の instance 達を確認したところ、問題なく元気に動いていました。instance はそれぞれ別の AZ でバラけさせて稼働させています。EBS backed instance が便利なので、EBS backed instance に移行し、新規構築する場合も EBS backed にしていました。ただし一番古い 1 つの instance のみ instance store になっていました。この blog が稼動している(た)のが、この古い instance なのです。
この instance には MySQL 用に EBS Volume を attach しています。
障害が長引くにつれて、us-east-1 の EBS に障害が発生しているという事が報告され、つまり、私は障害が影響する可能性はあったのですが、稼働状況を確認しても不具合は無く幸運に恵まれたかもと、その日は就寝しました。
翌日、起床後すぐに稼働状況を確認したところ、金曜日の午前1時ごろから munin のグラフで異常があるのを見つけました。この blog の稼動しているサーバの iowait が高くなっていました。他の instance は異常はありませんでした。
サーバに login して、EBS の中身を見ると、アクセスは可能であり、この段階で backup を取るコマンドを投入したところ失敗しました。blog の閲覧はこの時点でも問題なくできており、varnish や memcache をつかった構成であったのが幸いして、cache からコンテンツは参照できてたようです。
この段階で、EBS の snapshot を取るという作戦はあったと思います。しかし、EBS 全体の障害であるという事と長期化しているという事を考えて、下手に動くと余計に悪くなるという経験上の判断があり、個人のサイトでもあり、Amazon の Ops の活躍を待っておこうと手は付けずにいました。
金曜日の午後になって、障害が1つの AZ のみになったとの報告が出た時点で、そろそろ対策をした方がいいかなと感じ始め、また該当 instance のOSがもう EOL 寸前なので、EBS backed でカレント・バージョンのOSで環境再構築する準備を始めました。他の AZ では EBS backed instance の起動は出来ていたので、古い instance から環境を移し、あとは、障害が発生している、MySQL の DB の移行のみという所まで構築しました。
障害報告によると、該当のAZで障害があるEBSは detach するな、reboot するなとの事
その日夜までは、cache からコンテンツの参照はできていましたが深夜には MySQL に引きずられて、apache が動かなくなりました。この為、AWSの障害時のノウハウを得るために冒険に出ました。EBS の snapshot を試みるも取れない、EBS の強制 detach もダメ。instance を reboot してもダメ。AWS からの報告を見るとdetach の API を殺しているとの事。がんばれー > AWS Ops という事でその日は就寝。
土曜日になりました。まだ復帰していない。なんと長い障害でしょう。AWSで初めての事かもしれません。
朝8時頃に snapshot が取れるようになっていました。もうこうなったら楽勝。健全な AZ で EBS Volume を作成し、昨日つくっておいた EBS backed instance に attach して、設定確認して、Elastic IP すげ替えて一件落着。このあたりが素晴らしく楽で、もう絶対に昔に戻れないとしみじみ思うところですね。
さて、障害を起こしたことはきちんと postmortem をしてもらう事は当然。今回の障害のイケテナイ所は、EBS の設計ですね。一旦障害がおこったら re-mirror の嵐になる。ちょうど銀行の取り付け騒ぎと同じですね。 このイケテナイ所よりもっとイケテナイ所は、1つの AZ に閉じていなかった所です。これはイカン。
さて、私たち Ops 側としても、今回は重要な経験を得たと思います。AWS は究極のセルフサービスであると私は事あるごとに言っていましたが、このセルフサービスを使うコツ、これを意識する事が重要なのです。
さてさて、勉強勉強。
Cloud Foundry が再起動。今度は、Spring だけではなく、Rails や、なんと Node (node.js) も。
注目すべきはここでも RightScale がいい仕事している事。
(図にある “Msg Services” って Zimbra だよね ;)
(追記)
ネットワーク・レイテンシーの問題を*仮に無視すれば*、request route、app execution engine、services が広域に分散・協調して動くようになるんでしょうね。
