JAWS DAYS 2015でスタッフ＆LT発表してきました

2015年3月22日(日)、JAWS-UG日本最大のイベント「JAWS DAYS 2015 | クラウドへダイブ 〜 Dive Deep into the Cloud!」が開催されました。今年は単なる参加者ではなく、スタッフ＆LT発表と、人見知りな上に緊張しいな自分にとっては結構なハードルを設けてみました。

スタッフー♪

JAWS-UG京王線を立ち上げた直後だということもあり、少しでもUGの役に立てたらと思って、スタッフとしてお手伝いさせていただきました。

当日はスタッフTシャツに着替えて気が引き締まったと思ったら、某氏に「登壇者は青の方ですよ」と言われてやっちまった感を味わいつつも、LTだしスタッフ色出てた方がいいでしょと思い、平静を装ってみたり。

参加者の方の受付が始まって徐々に会場が埋まっていく感じを普段とは別の視点で見ていられたのは、なんだか新鮮な感じでした。(Hack Dayのスタッフの方はそんな余裕はなかったかもしれませんが。)

いざセッションが始まってみると、(自分も聞きたいから担当になった)スマートニュースさんの発表はいきなり満席で、空いている席を教えて座ってもらったり、通路にはみ出していた立ち見の人たちになるべく詰めてもらったりと、発表を聞いている余裕がなくてスタッフの仕事をなめてたなと少し反省しました。ただ、参加者の方々も協力的で、ちゃんと少しずつ前に出てくれたりしたので非常にやりやすかったです。

(途中、ハッシュタグを追ってる人が気づいて自主的に詰めてくれることを期待するという横着っぷりを発揮しつつｗ)

自分はセッション会場の整理的な役割だったので、特に動きまわることはなかったですが、カメラマンのお二人は一日中カメラを担いで全体をずっと動き回っていたので、本当に頭が下がります。などなど、月次な感想ですが、ただの参加者だった時にはそれほど気にしていなかった、いろいろなスタッフや関係者の協力でこれだけ大きなイベントが大きな問題もなく成り立っているんだなあと実感しました。

私のような人間でも何とかなったので、他にもスタッフに興味がある方はぜひ来年のDAYSではスタッフとして協力してみると違った楽しみ方ができていいと思います。

空気を読まずクソ真面目に

JAWS DAYSのLTといえばおもしろネタが満載なことで有名で、それをわかっていながらクソ真面目なネタでLT発表もしてきましたｗ

資料はこちら。

終盤に向かうに連れて芸人枠度合いが高まっていく感じの順番でちょうど中間の7番目。だがしかし、なんと直前の発表者はあの「玉川、AWSやめるってよ！」でおなじみ(!?)の玉川さん(と大谷さん)。。。ダメやん、これ。

やりづらさを感じつつ、ド緊張な状態で始まったLT。大量の聴衆を前に更に緊張が高まり、喋りたいことを飛ばすしたり、どんどん早口になったりと5分間の予定が4分にも満たないというｗ
予定通りパイを顔面に受けて、なんだかスッキリした気分で発表を終えられましたｗ

(発表が終わるまでビール飲まないように我慢してたら、終わった時にはもうなかったというショックな出来事も、、、ｗ)

中井さん、加賀さん、写真使わせてもらっちゃいました。
f:id:matetsu:20150326150637j:plain
f:id:matetsu:20150326150807j:plain

言わせた感もありましたが、会場の皆さんに祝福の言葉をいただけたのもすごく嬉しかったです！
というわけで、その流れに乗って、例のアレ を置いておいてみる

毎度おなじみ、まとまらないまとめ

  • 興味がある人は一度スタッフをやってみると良い
  • セッションの発表は敷居が高いイメージがあるけど、LTはそうでもない(違う意味での敷居の高さがあるが気にしないことも大事)
  • PubCrawlは来年もやって欲しい(本文で触れてないけど)

JAWS-UG京王線 第1回勉強会を開催しました

1/27日にJAWS-UG京王線の第1回勉強会を電気通信大学で開催しました。
最初は開催できるのか、人が集まるのか不安だらけでしたが、蓋を開けてみたら出席率19/20という高出席率（しかもその一人も直前の繰り上がりだったのでやむなしな感じ）でした。
これも全て、参加者の皆様、協力してくれたスタッフの皆さんのお陰です。

JAWS-UG京王線の紹介

私自身がJAWS-UG京王線が生まれたきっかけや、京王線や電通大でやる理由のようなものを発表させていただきました。

大学時代からずっと京王線沿線に住んでいて、こののどかな沿線に熱いAWSユーザがどれくらいいるのかということが気になってTwitterにつぶやいたことが事の始まり。会場として電通大を選んだのは、自分の母校であることも大きいですが、国立大学の中では知名度的にイマイチな感じがあるので多くの人に知ってもらいたかったこと、電通大にいる優秀な学生さんたちといずれコラボレーションというかコミュニティを通じて楽しいことができたらいいなと思ったというのもあります。

会場として電通大を使うことができたのは、なによりもハートビーツの藤崎さんの協力があったからこそです。ハートビーツさんが大学内にオフィスを持っていて、大学と協力してイベントをしたりしていたことがあったおかげで会議室を貸していただけました。本当に感謝してます。

他にも肉会メンバーという理由でスタッフとして協力してくれた中井さんとぎょりさん、京王線沿線在住でロゴの作成などをしてくださった品田さん、中央線のスタッフでありながら京王線も通っている駅ということで中央線ロゴデータの提供などしてくださった内田さん、京王線の立ち上げでわーっと盛り上げてサーッと消えていった（消えてない？）吉田さん、この6人のお陰で勉強会を開催することができました。ありがとうございます！

これからも継続していけるよう、ぜひぜひご協力ください。

資料の骨組みを家で作って、GoogleDriveにあげて、会社で肉付けをして保存したはずが同期できていなくて、発表時には中途半端な資料を使うことになってしまい、集まっていただいた方には本当に申し訳なかったです。これが、使いたかった資料です。（大して違わないとか言わないで＞＜）

本編

本編の内容は以下の様な感じでした。発表していただいた皆さん、お疲れ様でした＆ありがとうございました。

ハンズラボ今井さん awscliで自動化 業務で使うAWSCLI

（すみません、正確なタイトルを忘れてしまいまいした。。。）

マル秘ゲストとして登場した今井さん、当日まで私もマル秘ゲストが誰か知りませんでしたｗ

短時間しかメンテ時間のない場合に、awscliを使ってうまいこと自動化（とそのための検証）をしてあげることで、作業の確実性を高めて楽をしましょうといったお話。今井さんも紹介してましたが、awscliのwaitサブコマンドは、ec2インスタンスの起動などのstateが変わるのを待つときに便利でいいですよね。

ハンズラボさんは自前でシステムを作っているので、こういった運用周りのネタも豊富で、まだまだいろいろなお話が聞けそうですね。いつかは長谷川さんにハンズラボシステムの野望を語っていただきつつ、実装する今井さんとの掛け合いみたいなことをしていただけたら面白いんじゃないかと思っています。

SendGridエヴァンジェリスト中井さん メール配信サービスを比較してみた

Amazon SESがあるAWSの勉強会でSendGridの紹介をしてもらうという画期的な試み。というわけではなく、SESとSendGridとMandrillというメール配信系のサービスを比較してそれぞれのメリット・デメリットを紹介していただきました。

SendGridは見た目の金額だけ見ると他のサービスよりも高くなってしまうこともあるけど、運用していく上で面倒なところに対して気が利いているので、（人的な）運用コストを下げるのにはすごく良いと思います（使いたいけどまだ会社に許可をもらえていなくて使っていないお前が言うなと突っ込まれそうですがｗ）。


Walti藤崎さん Walti.ioの紹介

「サーバサイドのセキュリティスキャンをもっと身近に」するためのサービスWalti.ioの紹介をWaltiの藤崎さん（ハートビーツの藤崎さんと同一人物です）にしていただきました。

設計・実装する段階でしっかりと意識していたつもりのセキュリティ周りの設定や実装が、いざ確認してみたら漏れていたなんてことがないとはいえないこんな世の中で、そういった部分をちゃんと確認して対策を行うきっかけを与えてくれるためのサービス。サーバサイドセキュリティの基本的な部分が抑えられているので、サービスインする前のチェックや、大きめのアプリケーション改修、ミドルウェアやネットワーク周りの設定変更を行ったあとに、本当に意図したとおりになっているかを確認できて、しかもお安いのもいいですね。

ISID品田さん リンゴの保管方法

りんごの保管の話をたとえに、エンタープライズでのクラウドの導入時に障壁となりやすいセキュリティ基準の解釈おける「目的と手段の取り違え」などをわかりやすく紹介していただきました。FISCなんかも最近ではクラウドの利用を想定したものに変わってきていますし、金融系やエンタプライズ系でのクラウド利用が広がっているのは、ISIDの渥美さんたちの活動が大きいですね。

リンゴの話からいきなりFISCの真面目な話が出てきたと思ったら、接続不良でMacからの投影が切れてしまうというトラブルがありつつも、Appleのリンゴマークが表示された状態という奇跡を起こしながら走りきったのは見事でした。さすがSP、肝が座ってます。

詳しい話が知りたい場合はこちらの本を読むといいそうです。

Amazon Web Services入門 ― 企業システムへの導入障壁を徹底解消
Amazon Web Services入門 ― 企業システムへの導入障壁を徹底解消
posted with amazlet at 15.01.30
加藤 章
インプレス
売り上げランキング: 8,050
Amazon.co.jpで詳細を見る

ヴァル研究所内田さん JAWS-UG中央線の紹介

中央線と京王線の両方が乗り入れるところにおすまいということで、力を貸していただけることになったヴァル研究所の内田さんに沿線支部の先輩である中央線支部の紹介をしていただきました。

JAWS-UGの東京勉強会の規模が大きくなりすぎて、気軽に参加しづらい人や、恵比寿や目黒みたいなオシャンティな場所での開催ではないけどアットホームな感じで開催したいといった部分は、京王線でも真似したいコンセプトです。

高尾山のビアマウントを貸切って行った勉強会は是非、共同同時開催か共同別途開催で2度楽しむかということをしたいですねという話を内田さんとはさせていただいてます。

LTs

大喜多さんによるZabbixでのWISAを監視する話、鈴木さんによるIntel Edison+Cognito+Kinesis+Lambda+S3+RedshiftでIoTな環境を構築する話、田中さんによるEC2Configの話、どれも楽しく聞かせていただきました。

まとまらないまとめ

今回の発表者は第1回ということもありほぼスタッフで構成しましたが、次回以降はそうもいかないので、発表してくださる方いましたら、是非よろしくお願いします！ADSJの方にも是非発表していただきたいですし、ハンズラボさんのようなユーザ企業の方で、事例を交えつつ発表してくださる方がいるといいなと思っています。

初めてイベントの開催側をやってみて、イベントを開催することの大変さを実感するとともに、本当にスタッフの皆さんの協力がなければこの勉強会は実現できなかったなあという思いでいっぱいです。もちろん参加していただいた皆さんがいなくてはイベントが成立しなかったので、参加者の皆さんにも感謝しています！こんなに人に感謝したのはいつぶりだろうかっていうくらい、いろいろな人に感謝しています（伝わっていなかったら、このブログで伝わったら幸い）。

今後もぼちぼち開催していきますので、あたたかく見守っていただけたらなと思います。こんなネタが聞きたいという要望があるかた、発表したい方などは、 ハッシュタグ #jawsug_keioline をつけつつ、@matetsu を始めとしたスタッフにご連絡ください。

桶Tさんによるとぅげったはこちら。（まとめありがとうございます！！！！！！）


P.S. ブログが遅くなってしまってすみません。

京王線でも上手にJAWSと付き合って行こう

JAWS-UG Advent Calendar 2014の10日目です。最近寒さが厳しくなってきている中、すべり気味なタイトルで更に寒さを増してしまっていること、反省しています。技術ネタではないです。

はじめから結論、「JAWS-UG京王線」やります！

初めましてな方もそうでない方も、出オチですみません。JAWS-UG京王線やります！年明け1月にでも第0回ができるよう準備を進めていますので、京王線・井の頭線沿線にお勤め/お住まいの皆様、沿線に縁のある方はぜひ参加していただければと思います。勉強会のテーマとしては、自分がインフラや運用を担当しているというのもあって、「AWSの運用・監視・トラブルシューティング」まわりのネタで構成できたらいいなと思っています。

現在、cloudpackの吉田さん、(一部で話題の)肉会メンバーであるSendGridエヴァンジェリストの中井さん＆サーバーワークスのぎょりの協力のもと話を進めています。さらに、ISIDの品田さんも協力してくださるとおっしゃってくれています。会場としては京王線ならではということで電通大が使えたらいいなと思って、ハートビーツの藤崎さんにお願いして電通大が使えないかを調整して頂いています。他にもご協力いただける方がいましたら、Facebookかtwitter経由でご連絡いただけると嬉しいです。

と、いってみたものの、どれくらい参加者・協力者が集まるのか不安な部分もありつつ、吉田さんと肉会メンバという謎の安心感のあるメンバがいるので、なんとかなるかなとも思っています。

事の発端

言いたいことは言ったので、ここからは流す感じで。

なぜに京王線勉強会をやろうと思ったか、学生時代からずっと住んでいる京王線をもっと盛り上げたいなと思ったのがきっかけです。その結果、肉会の帰りにした以下のツイートが吉田さんに捕捉され拡散されるに至り、退路を絶たれたわけです。

退路を絶たれたと言うとネガティブに聞こえますので、背中を押してもらったといったほうがいいですねｗ

そもそもJAWS-UGとの出会い

自分の所属についてプライベートな場で触れることは（マイナス面が大きすぎるので）ほとんどないのですが、ブログ上では発表資料を公開しているので今更隠す必要もないですよね。

EightをPrivate BetaからPublic Betaにするにあたって、もともと使っていたサービスから他のサービスに切り替えるかどうかという話があったわけです。その時に、(Eightがメインではなかったにもかかわらず)自分が使いたいという思いからAWSを猛プッシュしたまでは良かったんですが、設計のお作法がよくわからなかったんです。。途方に暮れそうになっている中で、すごくちょうどよくJAWS-UG東京勉強会(2011年12月のやつ)が開催されることを知って、藁をもつかむ思いで参加したのが最初でした（補欠だったけど）。そこで出会ったサーバーワークスさんには設計の協力をしてもらったことをきっかけに、プライベート含めて仲良くさせてもらってますｗ

今の自分とJAWS-UG

業務上必要にかられてのスタートでしたが、その後は自分の興味から積極的に東京勉強会には参加させて頂いています。人見知りの激しい自分にとっては、懇親会とかでぼっちになる確率が高く厳しいこともありますが、知り合いも増えてきて楽しく過ごしています。

1度だけJAWS Days 2013で発表をさせてもらったきり、発表をしていないのは心苦しいですが、最近では、AWSウルトラクイズで運良く優勝してしまって、ラスベガスで開催された最大のイベントであるre:Invent 2014に参加させていただくことができました。本当に貴重な体験をさせていただけて、すごくプラスになっただけでなく、本気で英語できないとダメだなとも実感させられました。はい、頑張ります。。ただ、re:Inventに参加できたことで、AWSを使うだけでなくJAWS-UGというコミュニティへの関わりを変えていけたらいいなと思うようになってきました。

そんな中で、12/2に開催されたCloud Roadshow 大阪には有給をとって完全プライベートで参加してきました。大阪という場もあるのでしょうが、JAWS-UG関西のLT大会は東京の勉強会とはまた違った感じでエンターテイメント感が強いもののように感じました。運営側がすごく楽しそうに進行していたこと、懇親会でADSJの小島さんが熱く語っていたJAWSというコミュニティの素晴らしさ、懇親会解散後に遅くまで飲みに付き合ってくれたサーバーワークスの小林さんと仕事について語ったことなどなど、すべてが京王線勉強会の実施を後押ししてくれている感じがして、すごくやる気をもらって東京に戻ることができました。

意外と長くなってきたので、そろそろ締め

JAWS-UG京王線勉強会が開催されたら、ぜひとも参加してください！京王線、京王線連呼しれますが、京王線・井の頭線沿線のJAWSな人たちを盛り上げていくことが目的ですので、沿線に関係ない方もよろしくお願いします！

中央線のコアメンバの方々、高尾山ビアマウントでのイベントの際は是非一緒に何かできたらと思ってます。（京王線も高尾山口駅があるのでｗ）

re:Inventの参加報告ブログは近いうちに書きます。。。

下手な文章を読んで下さりありがとうございました。

(追記) ロゴを募集してます

大事なことを忘れてました、誰かロゴを考えてくださる優しい方はいませんか？自分の中での京王線のイメージは馬車道なのでそのあたりのイメージとか、かっこいいのができたらいいなあと(他人任せ)。
(「馬車道」というと京王多摩川駅の飲食店を想像してしまうのが京王線ユーザの性だということをすっかり忘れてました。「馬車鉄道l」とか「馬車軌間」といったほうが良いようです。 )

※勝手に会社名や名前を出させていただいた方、NGだったらFBなどで凸ってください（先に許諾をとってなくてすみません）

SR-IOV対応版AMIでのカーネルアップデート時は注意 (自分用メモ)

AWSの(いろいろな意味で有名な)マッツォさんがSR-IOV版CentOS6.5のHVM AMI*1を公開してくれて、ありがたく試していました。最近になってそのインスタンスを気軽に yum update して、再起動したら eth0 と(つけてないけど) eth1 が up しなくてアカンヤツになってしまいました。

まあ、当然といえば当然ですね。SR-IOVのドライバはカーネルモジュールなので、カーネルのバージョンが変われば動作しなくなってしまいますよね。というわけで、カーネルをupdateするときには以下のようにしましょう。(注:アップデート後のカーネルが2.6.32-431.20.3.el6.x86_64の場合です。適宜読み替えてください。)

# yum update
# mkdir tmp
# cd tmp
# curl -O http://jaist.dl.sourceforge.net/project/e1000/ixgbevf%20stable/2.14.2/ixgbevf-2.14.2.tar.gz
# tar xf ixgbevf-2.14.2.tar.gz
# cd ixgbevf-2.14.2/src
# BUILD_KERNEL=2.6.32-431.20.3.el6.x86_64 make install
# reboot

これで大丈夫(だった)。

*1:http://understeer.hatenablog.com/entry/2014/04/08/203021

AWSウルトラクイズで優勝しちゃいました

土曜日に思い切り寝まくって、現実に戻ってきました。駄文ではありますが、記録には残しておこうと思い、1年半ぶりくらいのブログを書いております。

7月17日、18日の2日間で開催されたAWS Summit 2014。
なかなかセッションの内容が埋まらないなあと思ったまま申し込みを忘れていたため、7月の頭まで登録をしていなかったのは内緒です。

申し込みが遅かったので、一番聴きたかったTech Deep Dive by Amazonのセッションはひとつも取れておらず、事例系のセッションをひたすら聴講しておりました。各セッションでは、AWSは自分たちの売上が上がることよりも、ユーザのサービスやシステムが低コストで効率よく構築・運用できるかという視点でアドバイスやサポートをしてくれているということが語られていたと思います。自分が携わっているサービスで利用しているので、その点は結構感じます。
あと、ユーザの声が大きくなるほどその要望が実現されやすくなるということで、Amazonさん自身も積極的に聞くようにしていますし、発表者の皆さんも積極的に要望をあげているというのも面白いしなと思います。

Intelさんの発表の中では、最後にちらっとなんで現行インスタンスのほうが旧世代インスタンスよりも安いのかについて触れられていたのかも良かったです。現行世代のインスタンスはIvyBridgeのCPUを使っていて、旧世代のSandyBridgeよりも1ソケットあたりのコア数が多くなっています。そのため、少ないハードでより多くの仮想マシンを提供できるので、インスタンスの単価を下げることができるそうです。より多くのユーザが利用してハードウェアの購入単価が下がるということもあるのでしょうが、こういった部分も値下げに寄与しているんですね。


Summitのそれぞれのセッションも楽しみにしていましたが、一番楽しみにしていたナイトセッション、毎年恒例のJAWS-UG勉強会 in AWS Summit！事前にビア(だけじゃないよ)とおつまみが振る舞われて開始されました。人大杉で知り合いも来ているはずなのに、相変わらずのぼっちでスタート。。。いや、いいんです、勉強会のコンテンツさえ聞ければ。。。と思ったら、ぼっちの特等席である壁際を陣取ったために、後ろ過ぎて全く内容が聞こえてこませんでした。。。WernerとJAWS-UGメンバのパネルディスカッション聴きたかった。。。
※あとで知り合いの方が話に来てくれて、最後までぼっちだったわけではありません

そして、お待ちかねのAWSウルトラクイズ。前々回は全くダメで、前回は仕事で参加できなかったので、今年は壇上に上がるくらいにはなりたいなと意気込んで参加しました。危うさもありつつ、なんとか正解を重ねて壇上へ上がることができた時点で、ほぼほぼ満足してしまっていました。 見回してもても、壇上にいる人たちは猛者ばっかりですし、敗者復活によってCertificateを3つ持ってるマサカリ集団が上がってくるし、一旦全滅するし、全然わからない問題ばかり出るしで、運と勘に頼るしかなかったです。

そして運命の時が訪れました。

問題
Amazon WorkSpacesのユーザボリューム(Dドライブ)のスナップショット頻度は？
[グー]6時間
[チョキ]12時間
[パー]24時間

(WorkSpacesは発表された時の説明を少し聞いたくらいで、使ったこともないからマニュアルとかサービス説明よんでねーよー！！！まったくわかんねーーー！！！)

(6時間じゃちょっと早い気がするし、24時間だとちょっと自動でやるにしては長すぎるんじゃないか。間をとって12時間だな。)

デーデン♪(みんな一斉に回答の手を挙げる)

(あーーー、チョキ出してるの一人しかいない。。マサカリerが違うの出してるんだから終わったわ。。。)

「正解は12時間！」

(え、マジ？えっ？えっ？えっ？)
この時点で頭が真っ白になってました。というわけで、このへんの記憶が曖昧だったりしますｗ


2位と3位も決まり、表彰式でAmazon CTOのWernerから目録(?)を頂いて、もう笑うしかない状態。仕事中には出ることのない満面の笑みで写真撮影に応じていたかと思います。完全な浮かれポンチ(古)ですね。いや、でも本当に嬉しかったことは確かです！


壇上から降りて、「締めの言葉オナシャス！」と言われ、真っ白第二弾。。。
全く言葉が浮かぶはずもなく、ただただキョドって終わってしまいました。本当に申し訳ありません。。。いいおっさんなんですし、もっと度胸つけるようにします。

当日は全く何も言えなかったので、この場を借りて伝えたいと思います。
まさか自分が優勝できるなんて夢にも思っておらず、嬉しいと同時にもっと頑張らないといけないなと気を引き締めています。Twitterなどで皆様から温かい言葉をかけていただきまして、本当に感謝しております。re:inventではちゃんと吸収してこられるように、まずは英語を聞き取れるようにしたいと思います。そして、ベガスぼっちにならないように社交性も高められればと思っております。関係者の皆様、おめでとうと言ってくださった皆様、本当にありがとうございます！

と言った感じで、AWS Summitは無事終了。複数の部隊に分かれて2次会(?)へ向かいました。私は脱藩先の仕事やプライベートでもお世話になっているサーバーワークス組に混じって、天狗で飲んでました。翌日は二日酔いでした。。。

長々と駄文を失礼しました。

(実はブログを書くよりも他にやることあるだろうというツッコミを受けそうでビクビクしています。そちらもちゃんとやりますので、お手柔らかに。。ｗ)

JAWS DAYS 2013 DAY2で「Eight meets AWS」という発表をして来ました #jawsdays #jawsug

ちょっと遅くなりましたが、3月16日のJAWS DYAS 2013のDAY2で発表して来ました。

概要はこちら。
Ustの録画はこちら。(動画マジ恥ずかしい。自分では冒頭だけ見て、まだ全部は見れていません。)

発表資料の方は、こちらからご覧いただけます。

内容としては、おおまかに言うと下の3点。

  • AWSのEC2以外のサービスをうまいこと使って運用コストを下げましょう
  • 使いづらい部分があったらSDKを使って使いやすいツールを作るといいよ
  • SWF使ったよ (#ヤマンさんへの感謝を込めて)

途中、Amazonさんの回し者なんじゃないかというくらいAWSのサービス押しを決めてましたが、Management ConsoleのVPC周りがちょっと使い勝手が良くないので、そのあたりをもう少し改善してくれると、ライトユーザも使いやすいんじゃないかなと思って発表にも織り交ぜておきました(ライトに使っていたら感じない不満かもｗ)。

資料を見て、何かお気づきの点などありましたら、ご指摘ください。

社会人になってから初めての発表ってこともあり、かなり緊張していたのですが、進行役(?)のAmazon 松尾さんが頷きながら聞いてくれているのを見て、結構救われました。

懇親会でもいろいろな方とお話させていただいて、特にChef関連の話をしている時に、Amazonの松井さんが「OpsWorksはまだまだおもちゃみたいなもん」(酒が入っていたので間違って覚えていたらごめんなさい)といっていたのは良い収穫だったと思う。もう少し待ってから触って見るくらいでもいいのかも。
JAWSUGのコミュニティの素晴らしさも改めて実感できたし、応援(冷やかし？)に来ていた後輩もああいう雰囲気の中に放り込むことができたし、大変充実した一日でした。

帰宅後に、恐る恐るTogetterで反応を見てみましたが、皆さん温かい目で見守ってくださっている感じがして嬉しかったです。

技術以外の部分で成長できるいい機会をくださった AWS&JAWSUG の方々、本当にありがとうございました！
(忙しすぎて発表の機会を譲ってくれた先輩にも感謝！)

Redis + Sentinel で自動フェイルオーバ in Amazon VPC を試してみた

AWS VPC redis

お久しぶりです。
最後にブログを更新したのがInternal ELBが登場して勢いで書いた6月11日。。。更新してなさすぎですね。

そこで今回試してみたのは、Redis + Sentinelの自動フェイルオーバをAWS VPC環境で実現するというものです。

元々は「 RedisをKeepalivedでフェイルオーバーする構成案 - 酒日記 はてな支店 」を参考にして構築しようと考えていたのですが、VPC(というかAWS)の環境ではbroadcastやmulticastが使用できないので、VRRPが使えず断念。そこで少し途方にくれつつ考えたのが、Sentinelを使う方法。

Redisについては特に説明は必要ないと思いますので、Sentinelについて簡単に。

  • 監視: masterやslaveが期待通り動いているかどうかを定期的に監視
  • 通知: 指定したログレベルのものが発生した時に、管理者やプログラムに通知を行う
  • 自動フェイルオーバ: master障害時にslaveをmasterへと昇格させる。redisを使っているアプリケーションに新しいmasterのIPアドレスを通知する

詳細はこちら( Redis Sentinel Documentation – Redis )を参照していただければと。

構成

構成としては、以下のような感じです。すべてCentOS6.3(ちょっとだけカスタムAMI)を使っています。

  • web(application)サーバ2台
  • Redis + Sentinelサーバ2台

f:id:matetsu:20121228110332p:plain
※ #ヤマン さんによる「 VPCでアベイラビリティゾーン越しにプライベートIPを共有する（Source/Descチェック外し） - c9日記 -カタヤマンがプログラマチックに今日もコードアシスト 」のような構成です。

webサーバは特に言及することはなく、Redisに接続するためのIPとしてVIPである 172.16.0.10 を使うようにするくらいです。
Redisサーバでは、以下のような設定をします。

  • 両機のループバックインターフェイスに予めIPエイリアスとして 172.16.0.10/32 を設定
  • インスタンスのSource/Dest Checkをdisableにしておく←これ重要(masterにするスクリプトでもdisableにするようにしてるけど)

VPCのroute tableの設定はmaster/slaveの設定をするときにスクリプトを使って一気にやってしまうので、先に設定しておく必要はない。

Redisの設定(初期設定)

master/slaveの関係を作る前のRedis初期設定は以下のようにしています。

slaveof no one
masterauth [pass]
requireauth [pass]

くらいしか変えていません。

Sentinelの設定はこちら。まだ特に関しの設定はせずに、起動するだけになっています。

この状態で、まずはサービスを起動します。

# service redis start
# service sentinel start

Master/Slaveの設定

続いて、redis01をmaster、redis02をslaveとして設定します。

基本的には単純にredis-cliからslaveofコマンドを実行するだけなのですが、requireauthを設定しているので、パスワードを入れるのが面倒だったので、以下の様なpythonスクリプトにしています。

また、masterノードのVIP(ループバックに設定したやつ)にwebサーバからのアクセスを向かせるために、VPCのroute tableを設定するためのスクリプトも準備しておきます。ACCESS_KEYやSECRET_ACCESS_KEY,routetable_idは自分の環境にあわせてください。

このスクリプトでは、自分自身のインスタンスIDにVIPへのアクセスをルーティングするようにしています。

このスクリプトと、実行ノードをmasterにするスクリプト(redis-to-master.sh)、指定したmasterノードのslaveにするスクリプト(redis-to-slave.sh)を組み合わせて、master/slave構成を取るようにする。


redis-to-master.shとredis-to-slave.shの中で、sentinelが監視するクラスタの情報を登録するためにsentinel.confを変更する処理も入っています。この処理は、以下のテンプレートのmasterノード情報をsedを使って置換しているだけです。

以下のように実行して少し待てば設定完了です。

[redis01]# redis-to-master.sh
[redis02]# redis-to-slave.sh redis01

フェイルオーバを試す

ここからが本題です。
フェイルオーバはSentinelが自動で行なってくれて、masterが切り替わったことをアプリケーションに伝えてくれるとのことですが、VIPを使ってVIPの向き先を変更することで対応しています。

sentinelの設定で指定している client-reconfig-script で指定しているスクリプト redis-failover.sh では failover endが渡された時に route-table を書き換えてVIPを自身のインスタンスIDに向けるようにしています。こうすることで、webサーバ側では特に接続先を変えなくてもそのままの設定で接続できます。もちろん、failover endが渡ってきているので、自動フェイルオーバが完了して、もともとslaveだったノードがmasterとして稼働します。

また、SentinelがWarning以上のステータスを検知した場合に通知するためには notification-script に通知スクリプトを指定する。

これで、フェイルオーバが起きたことを検知することもできる(もちろん監視も忘れずに)。
フェイルオーバが起きた時には、以下のようなログが出力される。上のnotification-scriptだと、5通のメールが来ることになる。。。これも「+hoge」となっているEvent Typeを見て分岐したりもできるので、もう少し改良の余地はあるかと思います。

[23304] 15 Jan 19:59:06.858 # +sdown master mymaster MASTER_IP 6379
[23304] 15 Jan 19:59:06.859 # +odown master mymaster MASTER_IP 6379 #quorum 1/1
[23304] 15 Jan 19:59:17.395 # +failover-detected master mymaster MASTER_IP 6379
[23304] 15 Jan 19:59:17.495 # +failover-end master mymaster MASTER_IP 6379
[23304] 15 Jan 19:59:17.495 # +switch-master mymaster MASTER_IP 6379 SLAVE_IP 6379

masterが切り替わったあとも、webサーバからはVIPでそのままアクセスできることも確認できた。まだまだ検証しないといけないこともあるけれど、それなりに簡単にフェイルオーバの仕組みを構築することができました。

Sentinelについては、簡単に動かしてみた程度なので、もう少し詳しく調べてみたいなと思っています。


年末に勢いで3分の2くらい書いたところで放置してしまっていましたが、このまま眠らせておくのもアレですし、とりあえずアウトプットしておこうとようやく書き上げました。不備などありましたらご指摘ください。gistも(ほぼ)初めて使って見ました。
今年はちゃんとブログにアウトプットしていきたい！