まめ畑

ゆるゆると書いていきます

JAWS DAYS 2014で「これで最強のAWSに」のセッションをやりました

AWS

JAWS DAYS 2014のセッションとして、これで最強のAWSにというセッションをやりました。 Twitterなどの反応はこちらに2014/03/15 JAWS DAYS 2014 - 『これで最強のAWSに』セッション #jawsdays #最強のAWS - Togetterまとめ まとめて頂いています。各セッションの発表資料はタイムテーブルからリンクがあります。


このセッションは、普段AWSを使っている方々をお呼びして、使っているからこそわかるAWSのイマイチなところ、イケてるところ、バッドノウハウ、こうしたら・こうなったらもっと良くなるのにという話をして頂きました。当日はOFAのMilesさんと、AWS SAの大谷さんにもご参加頂き、直接要望や実際のところどうやったらいいのさ？という事を直接伝える場があったらなと思い企画しました。(企画の大本は実はre:Invent2013開催中のラスベガスの会場にて生まれました。その時、堀内さんが撮った写真がこちら)


AWSのイベントでざっくざっく切り込んで行くスタイルをやるのは3回目くらいですが、いつ突っ込まれるか毎回ヒヤヒヤものです。

また、120分ぶっ通しのセッションかつ、裏ではImmutable Infrastructureのパネルが行われており、セッションにどのくらい人が入ってくるか不安でしたが、実際始まってみると、常時立ち見が出る状態で、終了後やTwitterなどの反応・会場での人気投票でもかなり良い評価をいただけていたようでした。
これは本当に発表していただいた3名とMilesさん・大谷さんのおかげと思っています。(自由に話していただこうと、かなりふわっとざっくりとしたお願いしかしておらず申し訳なかったです…)

発表資料

ぜんぶ AWS でやらないワケ by DeNA 坂本 卓巳 さん

発表で印象だったのは、オンプレとAWSを透過的に扱えるツールがあること。オンプレ・AWSを同じように扱えるというのはとても大事なことだと思っていて、AWSを使うとなっても運用方法が大きく変わってしまうと、それだけでも結構なコストになってしまうと思います。また、MHAに比べるとRDSのフェイルオーバーはまだまだ時間がかかるというのは自分も同じ悩みを持っていて、Milesさんが言うには今はもっと時間短縮されているとのことですが、それでも数分のオーダー。。 re:InventでもRDSチームとMTGする機会があったのですが、そこでも切実にお願いしておいた案件です。
AutoScalingやRDS、CloudWatchなどオンプレと同じ構成で自前で運用しなくてもフルマネージドサービスとしてAWSには存在しますが、ブラックボックなため障害時の切り分けやAWSならではの制約・制限に引っかかり実はすんなり移行できない併用しにくい部分というのが存在します。コストにしても。
既存の環境でツールなどが作りこまれてると、AWSに移行したとしても、自前でコントロールしたほうが案外運用しやすかったりするものです。
発表を通して、同じ悩みを抱えてる…と思っていました。

What makes AWS invincible by フリークアウト 岩尾 はるか さん

50ms or dieのフリークアウトさんの発表。EC2インスタンス同士で低遅延で通信するというオプションが無いのは確かにそうで、Placement Groupが要件を満たせそうな感じがしますが、HPC向けインスタンスなどのハイスペックインスタンスしか使えないです。AWS内部のlatencyのゆらぎもここまでシビアな要件になるとかなり影響がでるのだろうなと聞いていました。
後は、AWSの管理周りの話。Management Consoleでポチポチやることもあるけれど、UIが絶妙な感じで、Stopの上にTerminateがあったり、CLIでもRoute tableやRoute53などいじる場合やEC2インスタンスを起動するだけでもわかりにくいオプションを使わないといけない。そして、AWSはインフラをコードで管理できるが、Sandboxなどのテスト環境が無いのが辛いという話は会場やTwitterでも共感の声が多かったように思います。(オプション指定が難しすぎる…ラッパーなどを書けばいいのでしょぅが…)
Mileさんが一番食いついたのは、Record & Play機能が欲しいというもので、Management Consoleの操作を記録して、コードなどにしてくれる機能。これは確かに欲しい…
Sandboxに関しては、Eucalyptusが使えるとMilesさんからの回答がありました。CLIならdru runがあると。IAMも少し前にポリシーをテスト出来る様になったのですが、EC2もクリティカルな場所はdry runだけでなく、テストしやすい方法があると良いなと思っています。

複数VPCでのベストプラクティス by クルートテクノロジーズ 宮崎 幸恵 さん

サイト毎に1アカウント1VPCという使い方。これはお金周りなどなどの事情によるものだそうで。。そして、今70VPCを管理しているという構成図を見てかなり驚きました…そして、それぞれのVPCがオンプレや監視を行ってるVPCと通信していて、通信にはVyattaにてVPN、ルーティングやNATが行われているという、そしてVPCも頻繁に増えたり消えたりと頭蕩けそうな感じでした…
AWS公式にVPCのIGWがVPC間ルーティングをサポートしてくれるとスッキリとした感じになると思うのは凄く同意です。後、事前アンケートでも多かった、サブネットのリサイズ。最初スモールスタートやオンプレとNW周りを合わせるために小さくサブネットを切ってしまうと、インスタンスが増えてきたり、ELBが増えると(ELBは5-6個IPアドレスを消費します)IPアドレスが足りなくなってしまい、リサイズが出来ないので、VPCなりサブネット作りなおして引っ越しとなってしまします。技術的に難しいのはわかるのですが、欲しい機能の1つです。
最初からどかんと大きくサブネットを切るというのも手なのですが、そうするとサブネット数が少なくなるのでこちらも中々悩ましいところです。

まとめ

今回、登壇をお願いした方々は、ソーシャルゲーム・アドテク・エンタープライズ系と三者三様で、AWSに求める部分もそれぞれの事業形態の観点で違っていて、聞いていて非常に参考になったと同時に、JAWS DAYSを通して、AWSは本当に様々な業界や形態で使われているというのを改めて実感しました。
それぞれの要求に答えていくことは非常に難しいことだとは思いますが、その中でも共通して共感できる部分というのも少なくは無く、その部分に関して直接中の人にフィードバックしてお伝え出来てよかったかなと思っています。
Milesさんも、発表を聞きながらgood b っていう場面が何回もあったり、それいいね！ということもありました。それぞれの質問にも丁寧に答えて頂き、セッション終了後も色々話して頂きました。

AWSを使い始めよう・使い始めたばかりという方には、こういうこともあるのか、とか、普段バリバリ使ってる方には、それやっぱありますよねーみたいな感じ思っていただければ嬉しいところです。

事前に行った、バッドノウハウアンケートでも予想以上の回答があり、いくつかは直接答えていただけました。こちらもアンケートにご協力いただいた方々ありがとうございます！
ちなみに、事前アンケートで一番多かったのは、EBSの性能周りで、容量を大きく(500GB以上)そして、IOPSも高く設定して、事前に全領域にddなどで書き込んでおかないと性能が…とかもう少し1本でIOPS出したいというものでした。
他にも、CloudFormationのテンプレートの仕様やInfini bandやRDMA使いたいなどもありました。意外とバッドノウハウ集まってます…
監視についても色々ありましたが、Milesさん的にはNagiosやzabbixなどと組み合わせて、CloudWatchを使って、CloudWatchはAWS内部で取得しているメトリクスを見るのに使うのに適してるとのこと。(最小監視間隔が1分で2週間しかログを保持しないためその辺の要望が多かったです)　監視も適材適所ですね。
AutoScalingに関しては、CloudWatchに頼らず、自前のスクリプトでMax/Minのキャパシティを調整するのがいいんじゃないかなぁとのことでした。


次に突っ込んだ話は、 AWS Casual Talks#2　で！
そして、こういうバッドノウハウなどのあまり外には出してない・出しにくいノウハウ共有は別の機会にまたガツンとやりたいと思っています！

ありがとうございました！

f:id:con_mame:20140317163527j:plain