AWS Game Day Tokyo 2013 開催報告 - Part 2

引き続き、Game Dayの報告です。AWSを用いたクラウド版、ほこxたて対決!前回下記のようにPart 1と書いてしまったのでPart 2を書かざるをえない感じですw 疲れMAXですが、なんとか書き上げます!

AWS Game Day Tokyo 2013 開催報告 - Part 1

 

準備

さて、前回の記事で、3人ずつのチームを作った後は(今回は18チームできました)、戦うことになるチームの組み合わせを決めて、まず戦う準備を行いました。

  • まず、指定した手順を参考に、AWSの幾つかのサービスを用いてバッチ処理を行うシステムを作りました。SQSのキューに画像のURLリストを貼付けるとワーカーであるEC2インスタンス群が合成して1枚の写真を作ってS3に吐き出してくれる画像処理バッチクラスターです。
  • 次に、Power User権限を持つIAMユーザー(つまり、AWSのインフラを好きなように設定変更、削除、追加できる)を作成し、対戦相手を攻撃できるようにしました。

攻撃と修復

準備が整うと、制限時間の範囲で、お互いに対戦相手のクラスターが機能しなくなるように攻撃します。前回の記事ではこの攻撃がはじまったところでした。現場では、「いつ攻撃するの? by 玉川」「いまでしょ! by マイルズ」のかけ声で攻撃開始となりましたw すべってませんよ。

 

相手のインフラを好きなように30分間攻撃します。しかし、単純に全てのリソースを消したって面白くありません。相手が気づかないような、それでいてシステムとしては致命的、かつ修復が難しいか時間がかかるような攻撃をしかけます。皆さん、相手に対して嫌らしい攻撃をするのが本当に楽しそうでした。Security Groupの設定をこっそりと変えてアクセスできなくする、サイズの大きい画像をキューに大量に放り込む、SQSのキューのVisivility Timeoutを変える、EC2のサーバーの名前を「アホ」と変えて精神的ダメージを与える、などクリエイティブかつ陰湿な攻撃が沢山見られました。

f:id:kentamagawa:20130608142135j:plain

 

攻撃が終わると、先ほど作ったIAMユーザーを使用できないようにします。そして、今度は30分間で修復を行います。システムへの攻撃を検知して、稼働状況に戻していきます。会場からは、こんな攻撃があったかと唸るような声がそこかしこから聞こえてきました。

下は、「あれおかしいな、どこも変わっていない、と唸る@sato_shi

f:id:kentamagawa:20130608143718j:plain

 

どのように修復していったかも全て記録が取られていきました。

f:id:kentamagawa:20130608151522j:plain

修復時間が終わると、どこからともなく拍手がわき起こりました。無事に修復を終えてシステムが再稼働したチームと、修復しきれなかったチーム、明暗が分かれました。修復を無事に終えたチームは、おもしろ画像を入れたネタの仕込みに必死でしたw

結果発表

3つの賞が下記のチームに送られました。入賞者の皆様、おめでとうございます!

Most EVIL break!賞

最も優れた攻撃を行ったチームzanbezi5 (@maroon1stさんとこ)に!もっとも意地悪な攻撃として評価されたものは、AutoScaling設定をスケジュールする仕組みを使い(put-scheduled-update-group-action)、毎分、サーバー台数が0台になる、という攻撃でした。

Most AWESOME fix!賞

最も優れた修復を行ったチームPRISM (@ijinさんとこ)に!SQSのキューの中に、無限ループして増殖していくメッセージが仕込まれていたのも難無くクリアし全て修復してシステムを稼働状態に見事に戻しました。

Funniest Imag賞

バッチ処理クラスターからの画像がが最も面白かったチーム Fujinomiyaに!

f:id:kentamagawa:20130608235047j:plain

 

Game Dayからのラーニング

マイルが言ったGame Dayからのラーニングのまとめが非常に良かったので、箇条書きで残しておきます。

  • システムは、作るよりも、壊す方が楽
  • 全てを修復可能だが、多くの場合、予測できない量の時間がかかる
  • CloudWatchなどの監視やアラーム、通知といった準備無しでは、攻撃に気づくのにどれくらい時間がかかるだろうか?
  • システムが複雑でなかったとしても、どう壊れているかを把握するのは複雑になりえる。修正したり置き換えたりするのはどれくらい時間がかかるか?もし、CloudFormationのスクリプトがある場合はどうくらい助けになるか?
  • じつは、最高のシステムとは、どう振る舞うべきか、どのような状態にあるべきか、という明確な定義を保存しているべき。そして、繰り返し現状を検査し、それを定義と比較することで、自動的にもとの定義に適合するように自己治癒し続ける。
  • こうなると攻撃は無意味なものになる。システムは自己治癒可能であるから。HA設計の定義がどれだけ強固であるか、定義された状態に戻るまでの時間がどれくらいかかるか、が重要なものとなる。
  • AWSでは、このようなデザインを達成するための沢山のツールがすでに用意されている。Autoscaling、CloudFormation、CloudWatchとAlarms、SWF、Elastic Beanstalk、Route 53。各サービスは、自己治癒可能で、定義可能で、高い可用性を持ったシステムである。
  • これらのAWSのサービスは、常にGame Dayのための準備が整っているのです。それは、AWSサービスにとっては、毎日がGame Dayだから!

さて、駆け足でお送りしたAWS Game Dayでしたがいかがでしょうか?ご参加頂いた皆さん、本当にありがとうございました。Game Dayを日本でやろうと言い出してくれたMiles Ward、開催に尽力したAWSソリューションアーキテクト陣営、ナイスワークでした!

AWS Game Day Tokyo 2013

 

また近いうちに、AWS Game Day Tokyo Vol.2を開催したいと目論んでいますので、乞うご期待を!

 

@KenTamagawa