読者です 読者をやめる 読者になる 読者になる
本格SEもすなる、技術ブログといふものを、駄目SEもしてみむとて、するなり

JAWS FESTA Kansai 2013 で一番長いセッションをやってきた

AWS

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メンバーと食べたけど、これだけは忘れません。
https://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-prn2/1267997_370478359749476_1291928069_o.jpg串揚げは サソリ より コオロギ が旨い!