第17回 AWS User Group – Japan 東京勉強会に参加してきた #jawsug

しんや

2013.08.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

『今回はGeek向け』と言う位置付けで告知及び開催がされた2013/08/02(金)の『第17回 AWS User Group - Japan 東京勉強会』。講演20分×2本、LT×7本というてんこ盛りなボリュームで行われた勉強会をざっくりレポートして行きたいと思います。

開催場所はフューチャーアーキテクト株式会社＠大崎。こちらの会場に訪れるのは今回が初めてだったのですが、入り口とか超綺麗！会場内部も同様に綺麗で整備されていてUstreamばかりかDJブース(！)も用意されていると言う充実振りでした。

こちらがそのDJブース。めっちゃ本格的！

DJブース撮らせてもらいました！ #jawsug http://t.co/aVMeEhhiWt

— mist (@mist_dev) August 2, 2013

そしてこちらがセットリスト(のURLを含むつぶやき)。世代的には懐かし〜曲目がチョイスされており、素晴らしいセットリストになっていたと思います！

#jawsug 本日流していた曲リストです。人が集まり始めた 18:15 くらいから。 SONG - ARTIST 1. New Sensation (Samuel Sartini Mix) - Sam (cont) http://t.co/4XUkx2zx15

— TOM HKM aka はっかー (@c_5) August 2, 2013

私自身は会場までの到着時間を若干見積もり誤ってしまい、開会挨拶の途中に到着する形となってしまいました。参加メモについては挨拶終了後の得上さん講演からとなります。

このエントリでは、当日のつぶやきを各所で引用させて頂いております。
(※もし何か不都合等あるようでしたらコメント等でお知らせください。適宜対応致します。)

当日のタイムテーブル

(講演)「SQS vs SWF 〜なぜSWFに乗り換えるのか〜」
(LT)JAWS FESTA Kansai 2013もGeekです！
(LT)AWSあるある。こんなとこにもCDP！
(LT)ラピュタで学ぶAWS
- (補足)バルスについて
(講演)DevOps のいまと AWS
(LT)スケーラブルWordPress＆簡単デプロイサービス作ってみた
(LT)AWSゲームサイトを解析したよ！
(LT)ギーク〇人に聞きました～そして、東京の人へ～
(LT)AWSバッドノウハウカンファレンス(仮)の開催埋もれたAWSアイデアとノウハウを晒しませんか？
懇親会

(講演)「SQS vs SWF 〜なぜSWFに乗り換えるのか〜」

発表：得上竜一さん(TwitterID:@tottokug)(JAWSUG東京代表)

自己紹介：好きなAWSサービスはSimpleDB/DynamoDB/CloudSearchなど。

まずSQSとは？
- [参考]Amazon Simple Queue Service ( キュー管理サービス Amazon SQS) | アマゾンウェブサービス（AWS 日本語）
- [参考]Amazon SQS による分散キュー｜ Developers.IO
- SQSのQはQueueの"キュー"。送る側も受け取る側も、オンプレだろうが何だろうが利用出来る。AWS内最古参サービス。

SQSの詳しい話
- Visibility Timeoutに絡んだアーキテクチャの解説をされていました。

SWFとは？
- [参考]Amazon Simple Workflow Service (ワークフローサービス Amazon SWF) | アマゾンウェブサービス（AWS 日本語）
- [参考][AWSマイスターシリーズ]Amazon Simple Workflow Service (SWF)
- [参考]Amazon Simple Workflow Service (SWF) 入門｜ Developers.IO
- 会場に挙手アンケート...まだそこまでは浸透していない？でも便利なサービスです。
- starterやdeciderにを踏まえたアーキテクチャを解説。

SWFの動作説明や違いの解説

なぜSQSを辞めるのか？
- Visibility Timeoutまでの時間が積もり積もってしまうと、タイムラグが発生、同じ内容のメッセージを復数受け取ってしまう可能性が出て来てしまう。
- 問題点は他にも、実行の制御、ログの管理、QueueとWorkerの対応(キューのパーティショニング時)等など。

SWFにした理由
- 実行の制御(リトライ、失敗の管理)
- ログ管理(実行：エラーログの集約)
- 重複なし(これは超大事！)
- ワークフローで並列処理可能、cron的な使い方も可。

SWFよりSQSの方が良かった点
- 開発がシンプルに出来た
- LongPollingでスロットリングに関する例外(Throttle?Throttling?Exception：綴りに自信が無いです...^^;)を回避
- レイテンシ(Latency)が少し小さい(気がする)
- 利用料金が安い。(SQS：0.000000ドル、SWF：0.00012ドル。)

アーキテクチャ：
- SQS時代...EC2がたくさん。EC2がどのキューを見に行くかの制御をしていた。
- SWF時代...DynamoDBを使い、アクティブなタスクリストを管理。スケールはAutoScalingGroupで対応。

スケーリング：
- SQS時代...EC2がそれぞれのCloudWatchにメッセージを送り、制御。
- SWF時代...自分が担当するタスクリストのExecutionと残りメッセージの状況で計算を行い、割り出した値を元に制御。
  また、スポットインスタンスを利用(その時々で安いものを活用)。

まとめると
- 開発はSQSの方が楽、実行はSWFの方が楽。
- 実行制御が入る場合は断然SWFの方が良い、等など。

コストについて
- 比較すると、SWFはSQSに比べてそんなに高くない。なぜ？
- SQSは送受信共に稼働しており、お金が掛かっている。ポーリングでも同様。(ロングポーリングが出て来て幾らか状況は変わったらしいが)
- この部分をSWFに置き換える事で安く上げる事が出来る。workflowの実行にも無駄が無くなる。

、というので、SQSからSWFに乗り換えしました、というお話でした。そして途中、マイクの調子が悪い事に対し、つぶやきでこういった指摘も。得上さんはアドバイス通りに真摯に対応しておられました。

あれだ、得上さん、マイク寝かせすぎなんだ。赤外線の指向性に対して90°違う。。。 #jawsug

— 人型提督「東雲」@呉鎮守府 (@H_Shinonome) August 2, 2013

(LT)JAWS FESTA Kansai 2013もGeekです！

発表：桶谷卓也さん(TwitterID:@okeee0315)

"大阪からの刺客"(by 得上さん)と言う事で、JAWS FESTA関西のお知らせを告知LTとして発表。

人生が変わるその日...2013/09/28、JAWS FESTA Kansai 2013開催！
GAME DAYがあったり、Coder Dojo、CDP道場等、AWSなGeekの皆さんが思う存分力を発揮出来る内容が一杯。
Geek同士が交流出来る内容が多い。AWS以外にもWordbench、HTML5キャラバン等も開催。
Geekなら行かない訳には行かない！関西のGeekも、皆さんと会える事を心待ちにしています。
そして謎の『Redshiftガール』とは？正体は当日乞うご期待と言う事らしいw
また、最後に出て来た『JAWSUG新世界』、関東で例えると『JAWSUG浅草』的な所らしいです。

(LT)AWSあるある。こんなとこにもCDP！

発表：小島英揮さん

自己紹介：
- JAWS-UG設計者、日本でのAWSマーケティングを統括。
- 長時間プレゼン専門、今回は『バッファ的時間(5分)』での挑戦です。
- 好きなサービスはEC2。インスタンスタイプが沢山ある、あの感じが良いとの事。
- 好きな言葉：『Work Hard / Have Fun / Make History』。(※Amazon.co.jpのスローガン。)

こんな事ありませんか？：日常の事象をAWSのサービス名で置き換えてしまうこと。

また、最近置き換えてしまった"癖"として、AWS Summit Tokyoでの出来事を挙げていました。これには自分も参加していたので劇的改善状況には本当に驚きました！

1日平均3500名の来場者、初日は受付が非常に混雑してしまう事態に。機会損失...
ここはCDP(Cloud Design Pattern:クラウドデザインパターン)を適用しよう！
受付人数を増やし、2日目は劇的な改善を図ることに成功！
でも、ロードバランサーの前にキュー？→実は、先のアメリカ大統領選でも同じ対応が行われていた。
サンキューCDP！最先端を学びたい人は、Re:Inventへ！

AWS re:Invent 2013

(LT)ラピュタで学ぶAWS

発表：舘岡さん(TwitterID:@iara)

今回のこの第17回JAWS-UG 東京が行われた日は2013/08/02(金)。奇しくもこの日は、スタジオジブリのアニメ映画「天空の城ラピュタ」がテレビ放映された日でもありました。近年、このアニメ映画が放映される時には決まって言及されるのが『バルス』に関する話題。

『バルス』について

ちなみに、『バルス』とは一体何なのでしょうか？飛行石#おまじない - Wikipediaには、以下の様に解説がなされています。

飛行石（ひこうせき、Levistoneまたは Levitation Stone）は、人や物体を重力に逆らって宙に浮かせるなどの力を持つ、架空の物質である。ここでは、スタジオジブリ制作のアニメ『天空の城ラピュタ』（監督・宮崎駿）に登場する透明感のある青色の結晶体について述べる。

バルス：滅びの言葉。ラピュタ語で「閉じよ」を意味する。ラピュタ城中枢に浮かぶ巨大飛行石に命令を伝え、中枢部の回路を自壊させ、城全体を崩壊に導く。

『バルス』が話題となるのは、この台詞を発するタイミングが物語の終盤である事、またその台詞の登場に合わせてWebメディア等で一斉に発言(ここでは主に台詞と同じく『バルス！』という風に書き込んだりつぶやいたり)する事でサーバがダウンしたりと言ったアクシデント・障害が放映の度に取り沙汰されると言った点が理由としてあったりします。瞬間的な負荷は想像を遥かに超えるものであり、ITシステムに関わる者にとっはて突発的なアクセス増・負荷対策という点で興味関心を引く部分であったりする訳です。今回も例に漏れず放送前から各所で話題となり、またこれまでの記録を遥かに上回る記録(Twitterに於ける瞬間のつぶやき数)を達成していました。

昨日の「バルス」の記録がでました。ツイート数のピークは主人公が「バルス」と発したのとほぼ同じタイミングで日本時間の午後11時21分50秒、ツイート数は143,199TPSで、これまでの最高である今年の「あけおめ」の33,388TPSを大幅に上回っています。

— TwitterJP (@TwitterJP) August 3, 2013

YouTubeを探してみたら、まさにその瞬間の状況を捉えている動画がありましたので貼り付けておきます。ちなみに、『バルス！』と合わせてその後に発される『目がぁ〜〜、目がぁぁぁ〜〜〜〜〜〜』辺りの一連のシーケンスまでが特に有名であり、各所でパロディ化されてたりしております。

[swf]http://www.youtube.com/watch?v=_gYMRKOp_yI,800,560[/swf]

舘岡さんのLTは、そんな前提・背景がありつつの内容でした。(以上、前説おしまいw)

LT内容

『今日は"バルスコマンド"を作って来ました』と舘岡さん。ざわめく会場。

仕込みが必要との事で、しばし調整待ち。

一体何が出てくるのかと思ったら、まさかのAA(笑) クオリティが高過ぎる！

台詞なども表示させ、周辺の状況を完全再現しております。

そして『バルス！』の瞬間。画像右上に比較画像を載せてみましたが、脅威の再現率ですね！(しろめ

『バルス！』からの『目がぁ〜〜、目がぁぁぁぁ〜〜〜〜〜』のシーン。良く見るとサーバが次々にシャットダウンされています(笑)

僕の作ったbalusコマンドはterminate protectionもauto scalingから起動したEC2インスタンスも問答無用で殺します。一番苦労したのはterminal.appでアスキーアートを表示する部分でした。 #jawsug

— あだ名がリーダー (@iara) August 2, 2013

このコマンドは以下の様なユースケースで使うのが良いです、との舘岡さんの解説。

LTの時間が終了したので詳しくは触れていませんでしたが、実は他にも色々機能があります...とディレクトリ一覧を表示。良く見ると『balus.sh』の他にも『pazu.sh』("天空の城ラピュタ"の主人公、先の『バルス』写真画像左側の男の子)や『muska.sh』(『目がぁ〜〜、目がぁぁぁぁ〜〜〜〜〜』の人。作品中設定年齢は28歳〜32歳)と言ったプログラムも。一体どんな挙動を見せるのでしょうか。興味津々です。

そして何とこのソース、近々GitHubに上がるとのこと。これは期待大です！楽しみに待ちましょう。

そのうちbalusコマンドはgithubにあげます #jawsug

— あだ名がリーダー (@iara) August 2, 2013

(講演)DevOps のいまと AWS

発表：伊藤直也さん(TwitterID:@naoya_ito)

堀内さんに今回登壇して欲しいと言われたのに、(当の堀内さんが)来ていないw
OpsWorksについて話して欲しいと言われてましたが、Amazonの回し者ではないのでその話はしませんw

AWS Management Console、便利ですよね。でも...

また、マウスでそういう操作をする人って...『切腹！』ものですよね〜。

#jawsug 東京切腹ネタがオリジナルを超えてる件

— tmae (@tmae) August 2, 2013

こういった作業は、やはり自動化したいところ。
最近では、Packerというものも出ている。これはAMIを統合的に管理出来るツール。

Packer

AMIが出来たらインスタンスを立ち上げましょう。この辺はVagrantが便利です。

Vagrant

そしていざ、プロビジョニング。その際はこの本を是非！1人10冊くらい買ってください。(ステマ)(※でも本当に素晴らしい本ですよねぇ...)
Chefは、コードを書いてサーバを構成するツールです。Rubyで設定ファイル(レシピ)を書きます。読みやすいです。

Amazonでチェックする

動作確認、ここも自動化したい。手作業でやるなんてのは(ry
テストも自動化。この辺りはserverspecが便利です。作者は日本人。デフォルトになりつつあると思います。
rspecでテストを書きます。Rubyで書くのですが、Rubyが分からなくても十分理解出来る内容です。
テストが書けたらrake specコマンドで実行。guardコマンドを使って、ファイル書き換えのタイミングでテスト自動実行も可能。
最後はvagrant destroyで終了。

serverspec - Home

これら一連の流れが、今時のDevOpsです。色々自動化出来ます。...という事は！

と言うことは、Jenkinsを使って自動化、CIが出来る訳です。さすがにAMI作成は手動でやらざるを得ないけど、以降は全て自動化可能。

Vagrant + Jenkins の CI を AWS でも回す - naoyaのはてなダイアリー

CIで1日1回でもいいし、インスタンスを破棄→立ち上げる、という作業を行なっておくと非常に安心して新しいサーバを追加出来る。
Autoscalingにも柔軟に対応出来る。
AWSの場合Snapshotの機能で同じような事が実現出来るのでは…？→Snapshot取得の間の差分を手動で埋めざるを得なくなる局面が訪れてくるので、なかなか難しい。
provisiongフレームワークの良いところは、最初から全部自動化しなくても、想定している状態に追いつかせる事が出来る点。
seerverspecでテストを行う事で自信を持てる。
そして、全部コードになっている、という点が大きい。