JAWS FESTA Kansai 2013 で一番長いセッションをやってきた
JAWS Festa Kansa 2013?
先日の9月28日にJAWS FESTA Kansai 2013に運営として参加してきました。
JAWS(日本AWSユーザーグループ)の全国規模のイベントを開催しました。今までJAWSのイベントは、いくつも開催してきたのですが本当の意味でのユーザーグループ主催のイベントはこれが初めてとなります。これまでは、良い意味でも悪い意味でもAWSの中の人の影響が大きい所があったのですが、ユーザーグループ自身のイベントを開こうとなって、開催しました。(ユーザーグループにはADSJの中の人が多数いらっしゃるのですが、運営主体はADSJ外の方が多数でした)
何を運営した?
私は「設計・移行ワークショップ(仮想RFPから提案書の作成)」という、仮想RFPを元に、参加者がグループで提案書を作ろうというセッションをやっていました。これは、JAWS横浜支部で2回実施した内容を全国イベントでもやってみよう、と言う事でやってみました。
このワークショップは、@maroon1st、@satotech さん、@ijin さん、@hashiva さん、あとリーダー(@iara)にも参加者のフォローをして頂きました。
どんな内容?
今回は、ECサイトに「WB〇」からの取材があり、1か月後に放映されるんだけど、どうやったら対応できるの?みんなで提案して、という仮想RFPをお題にしました。
内容はこんな感じです。
今回は、参加者が合計9名だったので、3人3チームとして提案書を策して頂きました。
提案書をみんな作成!
RFPの説明をして、参加者の方々に提案書を作成して頂きました。
提案書の内容は、テンプレートを提供していて、このテンプレートの内容に沿って作成頂きました。本来の提案書からするとまったく項目が足らないのですが、時間が限られているため、この内容でも多すぎるくらいです。
RFPの説明の時に、「実際に構築は行わないので、尖がった提案をして下さい!」と訴えたので、期待しながら皆さんの提案書作りを見回っていました。
横浜支部でやっている時より1チームの人数が少ないからなのか、全参加者が活発にディスカッションしている事が印象的でした。AWS未経験の方をベテランの方がうまくサポートしていたりしていました。
各チームのチームビルディングが良かったのかなあ、と思います。これは、「結果的に」なので、運営側はもっとファシリテーションをちゃんとやるべきでした。反省。
また、途中でRFPの最初の内容から要件追加をして見ました。内容は、ECサイトだから実は入会時とか購入時とかにメールをしているので、要件に追加をやりました。実は、やってみたら面白いんじゃないかと言ってその場で決めました。
各チームはどんな提案書を作成したの?
提案書の作成時間は2時間程度だったので、はっきり言って時間が足りません。そのため、最低限の
発表順は、速く提出したチームが最後とした結果、Cチーム→Bチーム→Aチームとなりました。
Cチームの発表
先ずはCチームです。こんな提案をして頂きました。
移行や監視をきっちり考えているところが、高ポイントですね!
Bチームの発表
続いてBチームの発表です。
移行時のアプリケーション変更の凍結まで言及して頂いてます。
Aチームの発表
最後はAチームの発表です。
AWS設計・移行のテンプレート - Google Drive
DBの負荷対策にDynamoDBを入れてきた意欲的な提案です。
「尖がった提案をして下さい!」と言ったので、それに応えて頂きました。「移行期間が短いけど大丈夫?」と聞いたら「我々に任せて頂ければ大丈夫です!」(笑)と言っていたので、まあ大丈夫でしょう!
各チームの発表に対して、お客に扮した運営者が質問をしていきます。
一番印象的な質問は@hashiva さんの
「AutoScalingを使うって本当に大丈夫ですか?」
でした。全チームがWebサーバをAutoScaling構成にしていたのですが、全チームに必ず聞いていました。
AutoScaling構成で運用を成り立たせるのは、難易度が高いんですよね~
結果は?
各チームのシステム構成、プレゼンテーション、チームワークに対して様々な項目に点数をつけて、採点を行いました。
チームワークに関しては、各チーム文句なしで差が付きませんでした。
システム構成はAチームとCチームがリードし、プレゼンテーションはBチームがリードしていました。
注目の優勝は
Cチーム!
でした。
運営側の回答例は?
こんな感じで回答例を作成しました。
これは、参加者と違って時間制限無しで作成したので、チートです。
ポイントは、以下の通りです。
・テレビを見てアクセスする人だから、ほとんどが参照処理で更新処理(商品の購入とか)が比較的少ないはず。
・多数のアクセスを裁くため、リクエストを別のサービス(CDNとかDNS)に分散させる。
・準備期間が短いので、簡略化のためAutoScalingはあえて使用しない。
・AWS以外の外部サービスもどんどん使っていく。
・DBアクセスの負荷低減のため、セッションストレージをElastiCacheのRedis Engineを使用し、RDBの負荷を下げる。
・RDSのMulti-AZ、RDSのRead Replicaの冗長化、セッションストレージのElastiCache Redis Engineの冗長化により、SPOFを排除。
・NATも冗長化する。
こんなところでしょうか。
このレベルの内容は、とても2時間では不可能ですね、、、
ちなみに、回答例についても質問を受け付けたら、参加者の質問より運営者のキッツい質問が飛びまくりました。@ijinさん@satotechさんとかガチのマサカリ怖い!
運営してみた感想/反省
このワークショップは、JAWS横浜で2回開催済みなので、大体の準備や当日の動きを把握していたので、準備不足でしたがなんとか運営は回りました。
しかし、このワークショップは4時間30分かかっているので、午後のセッションは他に全く参加できません。にも拘らず参加頂いた方々には感謝しています。ワークショップ後に「実際にAWSの仕事をやることになったので、このワークショップに参加しに来た」という方までいらっしゃいました。参加者の方も勉強になったと思いますが、運営側もとっても勉強になりました。
懇親会で、ワークショップの内容でLTをやったら、他の支部でもやりたいという声を頂きましたので、提供できるネタは提供致します。全国の支部で開催して頂けると良いですね。
最初、京セラドームでイベントをやろう!となった時は、本当に参加者が来るのかと不安になっていましたが、申込みで850人程度、実際の参加者で600人以上と大盛況でした。JAWSの関西メンバーの活躍のおかげですね。
最後に
翌日に大阪の新世界で串揚げをJAWSメンバーと食べたけど、これだけは忘れません。
串揚げは サソリ より コオロギ が旨い!