AWS GameDay Tokyo 2013 プレイレポート 1

http://gameday2013.doorkeeper.jp/events/3960
に参加してきました。とても楽しかったのでプレイレポートをかいてみました。

ゲームの概要
以下のフェーズからなります。

自チームが相手チームのシステムを攻撃している時間、相手チームはこちらのシステムを攻撃します。その後、修復を行ない、振り返りの時間で、どんな攻撃をしたのか、どう回復させたのかという議論をしました。

システムの概要
イメージ変換のシステムで、以下のような処理を行なえます。
f:id:nginks:20130608225937p:image:w360:right

  1. InputキューにURLのリストがはいります。
  2. EC2上のImageProcesssorがInputキューにあるURLを取得します。
  3. ImageProcesssorは画像を変換します。
  4. ImageProcesssorは変換画像をS3に保存します。
  5. ImageProcesssorは変換画像のURLをOutputキューに送ります

URLをInputキューに入れるのは手動でおこないます。イメージプロセッサはauto scalingの機能で負荷に従い4台まで増えます。図にはかいていませんが、この他にauto scaling用のサーバも存在します。

攻撃の概要

攻撃側はAWSのPowerUser権限を持つユーザを利用して攻撃を行ないます。PowerUser権限が出来ないことは、

ということで、AWSコンソール上からインスタンスやイメージを削除したりは簡単できます。ただ、単に全部消すのは芸がないということで、高度で笑える攻撃方法を編み出す必要があります。

プレイレポ

10時会場到着。誰も知っている人がいないのでぼっち。他の人は楽しく歓談しているようにみえます。仕方ないので、iphoneいじって時間つぶし。さみしい。

10時半、ミーティングルームに集合してゲームの説明とグループ分け。エゥーゴグループになりました。グループ毎に別のミーティングルームに別れます。エゥーゴグループで6チームを作ります。最初にAWSにくわしい方をリーダーにして、その後詳しくない人をチームにわりふり。@takipone さんと二人チームになりました。チーム名はジムスナイパー(笑)

早速手順にしたがって、システムを構築します。AWSになれている@takiponeさんが作業、自分はマニュアルの表示と確認、ペアプログラミングの要領です。手順書は細かく書かれており、ImageProcessor用EC2インスタンスの作成、AMIの作成(AutoScaling用)、SQSの作成、S3バケットの作成とほぼ間違えるとこなく、スムーズに進みました。

基本のシステムが出来たということで、早速動作確認。動かない。。。インプットキューにいれたURL情報がいつまでたっても読みこまれない。。。システム作成ではよくあること、ということでデバッグ開始です。ImageProcessorはスクリプトなので、これを手動で実行してエラーを確認します。キューが見えていません。キューの名前を間違えたのかもしれないということで、ARNを渡したり、URLを渡したりと試しても駄目です。

他のチームも同じ問題にひっかかってることも判明してきました。しばらくの試行錯誤の後、結局botoはデフォルトでvirginiaリージョンを使っているため、Tokyoリージョンのキューは見えないという原因が判明。ImageProcessorのコードを書き換えて対処。無事URLメッセージが処理されることを確認しました。

満足感に浸っていると、AutoScalingの設定を忘れていたことが判明しました。AutoScalingはGUIが存在しないということで、コマンドライン上での設定が必要です。だが、そこはAWSマスター @takipone、さくさくとコマンドを入力して作成します。CloudWatchでalertに連動させてAutoScalingも完了します。キューにメッセージを沢山いれるとスケールすることも確認します。これでおしまいってAWSすごいと感動しました。GUIもそのうち出来るのでしょう。

ここでお昼の時間です。外に食べてもいいということでしたが、リージョン問題で時間がおしており、コンビニで弁当を買ってすぐに戻ります。弁当をたべながら、システムの攻撃と防御をどうするという話をグループでしました。

いろいろアイデアがでてきます。壊しても構わない他人のシステムというのはなかなか無いので、話が盛り上がります(笑)。また、攻撃を考えると、防御をどうすべきかも見えるのでためになります。グループで方法を共有するためのGoogleドキュメントを作成しました。後から見るとおもしろいです。

後知恵としては、今回の場合、守るべきデータはなかったので、システム再構築用のCloudFormationのスタックを作り、スタック自体をAWS外にバックアップするというというのが最善だったとおもいます。(時間的に厳しいですが....)
チームによっては残念ながらシステム作成がまにあわず、運営のつくったCloudFormationスタックを使ったところもあるようでした。ですが、折角のチャンスだから自分達で作りたいという人が多かったです。みんなこういうの好きなんだなぁと感じます。
相手チームが攻撃に利用するIAMユーザーを作り、攻撃開始時間まで待機です。

長くなったので、今日はここまでです。次回は「攻撃開始」。

コメント
0件
トラックバック
1件
ブックマーク
0 users
nginks
nginks

OpenStack、AWSの細かい話など