JAWS-UG 大阪の第3回勉強会で作ってたスライドの1枚（例によって時間オーバーなのでここまでたどり着かなかった）

データには様々な状態があり、「コモディティ」の重要性(＝コミュニティに任せられるものはすべて任せる)を認識するべき。そして「差分・Delta」をきっちりマネージメントする事。「ユニーク」は皆様お馴染みですね。

さて私は今回は LT ではなくUGの枠で、AWS 実演販売^h^hのコマを担当しました。

そのコマの資料は JAWS-UG 大阪支部の Web で公開することにして、「実演」でつかったアプリの紹介と CloudFormation、CLoudWatch custom metrics のスクリプトのリンクをここでかいておきます。

MacOSX用 S3 ツール

• Transmit
• Cyberduck
• Bucket Explorer
• (Windows なら CloudBerry が一押しらしい)

Route 53

• R53 Fox
• (Route 53)

CloudFormation Template

• Ubuntu + WordPress All-In-One Template
• (CloudFormation)

CloudWatch custom metrics + munin-node

• cloudwatch-munin-node
• (CloudWatch custom metrics)

# また時間たりなかった orz

今回は、初心者向け勉強会としてAWS入門編でハンズオンを企画しました。前々回前回と富士ソフトさんのご協力で会場を使わせていただいていたのですが、今回はテレビ大阪さんの支援をいただいて、大手前のテレビ大阪の会場を使わせていただける事になりました。ありがとうございました。

当日は生憎の雨でしたが、会場はほぼ満席の状態で、支部長の挨拶から始まり、玉川さんのプレゼン、メインメニューのハンズオン(S3のみならずEC2まで)(想定外のドラ息子?の登場)、恒例のLT(これは由緒正しいドラ娘)とつつがなく進み大成功でした。

さーて、私の第二回のLTは、今回は短時間でヤルというのを課題にしていて、なんと2分で終了という快挙を成し遂げたとおもったら、司会の赤井さんからの厳しいツッコミが入り後半はヘロヘロになってしまいました。申し訳なし。

今回は初心者向けということで、インフラ寄りに突っ込んでの話は準備してなかったのですが、時間が余ったので、もっと深い話をしたら良かったかなと反省しています。ではスライドをご笑納下さい。

t1.micro + WordPress + CloudFront この組み合わせはかなりイイ!    Cloud Formation の Template 作ったらウケますかね?

詳しくはwikiで : http://www.egrep.jp/wiki/index.php/CloudFront_custom_origin

さて、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 は究極のセルフサービスであると私は事あるごとに言っていましたが、このセルフサービスを使うコツ、これを意識する事が重要なのです。

さてさて、勉強勉強。