うえきのブログ

妙高市に住んでいるサーバエンジニアのブログです

AWS Game Day 2013 Tokyoに参加してきたよ

6月8日にAWS Game Day 2013 Tokyoに参加してきました。以下は備忘録を兼ねた日記です。

開催前

6月6日のAWS Summitの夕方に開かれたJAWS東京勉強会でルール説明があるというので参加したのですが、英語がサッパリ分からないので結局当日何をするのか、何を準備したらいいのか分からないまま臨みました。

一応開催案内メールで紹介されていたLearning from First Responders: When Your Systems Have to Workはダウンロードして読んではみましたが、サッパリサッパリです。

当日開始前

目黒のAmazonビルに集合。受付をすませ待合室で待機。ボッチな自分にも話しかけてくれる方がいたおかげでお互いのAWS歴などを話していました。

先日のJAWS東京にはたぶん300人以上来てたと思うので、今回の50人枠にはどれだけマッチョな人たちがくるのかと内心ビクビクしていました。ところが、意外に「AWS1ヶ月くらいです」とか「AWS未経験ですが見学枠がなかったので応募しました」な方が結構いたようです。もちろんTokyoリージョン開設前からAWSをバリバリ使ってましたよ〜みたいな人達も多くいたようです。（全18チームのリーダが熟練者だとしても全体の3分の1くらい?）

環境構築

ルール説明があった後、51名の参加者は3つの部屋に分かれ、さらに2〜3人のチームを作って環境を構築しました。自分はティターンズに配属されました。構築は手順書だけで10ページｘ4冊くらいあって、ハンズオンなら余裕で一日コースじゃね？ってくらいのボリュームです。しかもスクリプトがVirginiaリージョンでしか動かないとか、サンプルで用意されていた画像URLがいまは404 Not Found状態というワナがあり、原因調査してどうにか動くようになりました（Pythonコードを初めて触ったよ）。

今回の画像サムネイル生成バッチ処理の全体構成がどうなっているのかも把握できていないまま、いつの間にやらお昼の時間になってしまいました。環境構築は途中にして、間に合わなかったときのために用意された救済用CloudFormationだけ実行しておいて昼食を食べに出たのですが、帰ってきたらスタック作成に失敗してて泣きそうになりました（たしかリージョンが違っててTokyoリージョンで作ったKeyPairが見つからなかったため）。

攻撃

環境構築でバタバタしてたので攻撃手段を考える余裕もなく。でも存在しないURLをキューに渡すと404エラーでおかしな挙動をするようだったので、変なURLを送りつけてバッチ処理が困っているあいだに何か攻撃手段を考えようとしていました。


PowerUser権限のIAMユーザは渡されていたので、SQSやS3の読み込み・書き込み権限を剥奪すればバッチ処理は動かなくなることは明らかなのですが「それじゃ芸がないよね」ってことでしませんでした。夕方の懇親会で「サムネイル画像生成バッチ処理自体は動いているんだけど、なんだか挙動がおかしいってのがいい攻撃じゃない？」って話をしたら「いやいや、処理がちゃんと動いてて見た目にも問題ないように見えるけど実はやられてるってのがいいでしょ」という答えが返ってきて、まだまだエグさの精進が足りないなって思いました。


で、結局まともな(?)攻撃手段も浮かばないままタイムアップ。ふがいない。

復旧

攻撃中にも自分たちのEC2インスタンスの様子をCloudWatchでチェックしてたのですが、なにも攻撃されている様子がなく安心してました。ところがいざ様子をみてみるとS3やSQSへのアクセスはDENYされているは、S3にあるはずの作成された画像はすべて削除されているわ酷い状況でした。


1つ1つおかしなところを見つけながら直していったところ、無事インプットキューから元画像のURLを読み込んでサムネイル画像を作成しS3にファイルが作成されることが確認できました。「やれやれ、これで復旧完了か」と安心していたのですが、アウトプットキューに結果通知がたまるはずなのにいつ迄たってもゼロ件のままなのです。どうしてか分からず調べまわっているうちに、SQSの設定が変えられていていることが分かりました。"Delivery Delay"が最長の"15分"に設定されていて、"MessageRetentionPeriod"が"1分"になっていたためにキューにメッセージがたまらないように見えていました。


正直この復旧の時間が一番楽しかったです。自分で触っていると「ふつーそんな設定しないよ」ってことがされているので、たとえば前例のキューのように「こう設定すると、こういう挙動になるのか〜」となんだか感心しながら復旧していました。

ディスカッション

復旧が終わったら、参加者全員がひとつの部屋に集まって攻撃と復旧手段についてのディスカッションを行いました。

Google Docsで各チームの攻撃方法と復旧内容をリアルタイムに書き込み・共有しながら進めていったのですが、他のチームの攻撃方法は自分では思いつかないようなものばかりで、その資料をみてるだけでもすごく面白かったです。あまりネタバレすると第2回以降がつまらなくなってしまうかもしれないので簡単にご紹介すると、

  • SQSのキュー（本来サムネイル化する元画像のURLを送る）に無限リダイレクトするURLを流す
  • SQSのURLを処理するPythonコードの入力チェックの脆弱性を利用してOSをshutdownさせるコードを送りつける
  • CloudWatchのALARM設定でCPU使用率が高い状況が続いたらインスタンスを止める

などなど。表彰された方は「EC2のScheduled Eventsを使って毎分AutoScalingの台数をゼロにする」という攻撃をした方でした。Scheduled Eventsでそんな設定できること知らなかったよ（AWSからのreboot/shutdownのお知らせ欄かと思ってた）。

講評

OFA(Obama for America)のマイルスから今回の感想と堅牢なシステムを作る上で重要な事の説明がありました。


堅牢なシステムを作る上で重要なのは「システムがあるべき姿を定義し、そこから外れたら自動復旧する仕組みにしておくこと」。これは今までのような「壊れた環境を早く・正しくリストアする」という技能よりも一つ上のレイヤーにある、ということでした。個人的にはCloudFormationでリソースを作成し、Chefでサーバをあるべき姿に「収束」させるって考え方に繋がる内容ですごく同感でした。



ハードウェア的な考え方であれば「調子の悪いサーバは捨てて新しいのを買ってくる」という復旧方法はなかなか選択できませんが、クラウドの場合はそれがいとも簡単にできるわけで。AMIを用意しておけば、おかしな環境を捨ててCloudFormationで一発元通りってことも可能です。その辺の「いままでの常識ではできなかった復旧方法」を受け入れるってのも今後大切なことなのかもしれませんね。



まとめ

本当に楽しい一日でした。たくさん考えて、たくさん笑った一日でした。


冒頭にも書いたけど、集まった方達全員が「できる人」ばかりじゃなく、NoviceからExpertまでいろんな経験値の人達が集まってたと思います。AWSあんまり触ったことないからちょっと自信ないなって人でもチームを組んだ人の（エグい）攻撃や復旧の手際を横でみてるだけでもすごい勉強になると思いますよ！


興味がある人は次回の告知がでたら、すぐに参加申し込みしよう！！（次回もすぐに席埋まっちゃいそう）