勉強会メモ - 第21回 AWS User Group - Japan 東京勉強会

f:id:yoshi0309:20140411201645p:plain

どうも！JAWS の勉強会に参加してきましたのでメモを公開します。

今回のテーマは「Startup CTO AWS Battle」。これだけの数のスタートアップの話を、５分とはいえ、一度に聞けるのはかなり貴重でした。登壇者のCTOの皆様、ありがとうございました。あと、かなり当たり前なのですが、AWS含むクラウドやサービスを使う目的は、インフラ運用を出来だけ省力化して、本来やるべきところにリソースを割くためであるという点については、いずれの方についても共通で、再度考えなおすきっかけとなりました。

また、やっぱりというかなんというか、Elasticsearch の人気はかなりのものでした。検索そのものももちろんですが、kibana でログ分析という用途でも使われているとのことです。ChatWork さんにいたっては、CloudSearch の大規模導入を控えているそうで、AWS Summit Tokyo の事例発表が楽しみです。

オープニング

アマゾンデータサービスの秦さん登場、スタートアップ担当。US からの担当者も来ている。お名前の漢字を間違えていたらすいません。
アマゾンはスタートアップに力を入れている。
「かんぴょう」ってなんだっけ？w

特別登壇伊藤直也さん

https://speakerdeck.com/naoya/sukerusurukai-fa-zu-zhi-falsezuo-rifang-number-jawsug

スケールする開発組織の作り方もしくは暗黙知を作らない組織運営の仕方
AWS でも手作業では昔と同じではないか？インフラをソフトウェア的に扱うことでコードで表現するという対策。暗黙知から形式知へ。
作業時間の効率化が重要ではないか
手作業でやっていては、クラウドの利点を無に返しているのでは
インフラ運用は、暗黙知がたまりやすい
単にコード化すれば良いわけではない。
開発の業務フローが変わることが最も大事。
github で pull request 開発をして、ちゃんとレビューができる。変更履歴の可視化も可能。また、情報共有にもなる。
自動化そのものはあまり重要ではない。 分からないから保守的になる。暗黙知が保守的な意思決定を促してしまう。
スタートアップは、暗黙知が少ないから機動力がある。動ける範囲を自律的に見定めることができる。暗黙知の圧力に負けて保守的になる。
The Twelve-Factor App http://twelve-factor-ja.herokuapp.com/
ひと通り回ってくると、チーム間の情報共有が必要になる。フロー情報の共有として、Quiita:Team を使っている。Twitter のようなゆるさで、気軽に書けるツールが必要。wiki はストック型なので、なかなか書かれない。
メンタルモデルのコードへの反映
コード化しても「なぜ」が暗黙知化する点については意識する必要がある。

Wantedly株式会社川崎禎紀さん

https://speakerdeck.com/kawasy/how-wantedly-in-directly-uses-aws

Wantedly ではどう AWS を使っているか？
Heroku をメインで使っている。裏では、AWS を使っている Elasticsearch も。
Heroku を使うと開発のアジリティーが高まる、平日１日５回。気軽にスケール。
github + wercker + heroku
流行っているテクノロジーを使うことを目的にしない!

Sansan株式会社宍倉功一さん

サービス開発に集中するために、AWSを使い倒す方針。
Eight KPI 、開発のPDCAサイクルの中で効果測定と検証で使う
事業で見ている指標、User Growth Team で見ている指標、施策ごとで見ている指標
分析結果を迅速に共有、関係者に共有、詳細な結果を簡単に共有
日時分析の速報はメールで共有、主要な指標は Dashbordで、柔軟な分析のできるツール
FlyData で Redshift に放り込む。バッチでデイリーで分析し、SES で通知
DUCKSBOARD でダッシュボードのUIを表示。掲示ディスプレイで常に見えるように。
slash-7 で柔軟な分析を実現。

株式会社スマートエデュケーション谷川裕之さん

世界向けの発信には、S3 + CloudFront は必須。
ピークタイム（土曜日の朝）がはっきりしている。CLI で EC2 のインスタンスを増やす、デプロイするなど、事前準備がやりやすい。CLI は使わないと AWS の恩恵はない。
インフラもアプリも手間を少なくし、本来やるべきところに時間を使う。

ChatWork株式会社山本正喜さん

ビジネス向けチャット + タスク管理 + ビデオ通話
検索には mroonga on EC2
アップロードしたドキュメントは直接 S3 に放り込んでいる。
平時と休日にはっきりトラフィックの差がある、Auto Scaling を導入して、コストが下がる
mroonga は 1億レコード突っ込むと壊れるので、Elasticsearch に移行したい。の、タイミングで Amazon CloudSearch が登場。CloudSearch に乗り換え、検証済み。未本番導入。AWS Summit Tokyo の事例で話す予定。
Scala に全置き換え

株式会社nanapi 和田修一さん

サービスごとに使用しているインフラが異なる。
アンサーは、読モやニコ生主が登場するとアクセスが急に増えることがある
chef でインフラ管理。オンプレも Vagrant も AWS の全部 chef の cookbook で
fluentd でログの集約。s3 に保管する他、elastic search + kibana でログ分析。
New Relic で SQL のパフォーなんす分析。

BASE株式会社渡邉涼一さん

ネタがなかったので、ネタ作りにセッション管理を Redis に移行してみた。
安くなった！

ランサーズ株式会社田邊賢司さん

ANSIBLE / docker / SEARVERSPEC も今後使いたい
プレ環境にスポットインスタンで24時間稼働している。２月に高騰することが多いようなので特に注意！
CLI で起動。余裕を持って入札価格を設定。
Appサーバーのスケールアップ。m3.large / c3.large を合わせて検討。c3.large に合わせてチューニング。メモリを増やさずに、CPU を活用することで節約。
新インスタンスの情報を watch していると得することがある。

株式会社アカツキ田中勇輔さん

cloudformation + chef + capislano
git のタグを元にデプロイ内容を決定している。デプロイ先は AWS のタグで決定。
AWS のタグは役割の分類に最適。
RDS 、CM を打つと CPU リソースが枯渇することが予想された。
Commit 時の REDO ログと binlog の fsync() をやめて節約。障害時は最大１秒のオフライン時間が発生するが、CPU使用率が 30% から 5% に低下。あまりおすすめはしない。
監視 cloudwatch-to-hipchat、cloudwatch のアラートをチャットに流す。

Kaizen platform Inc. 石橋利真さん

暗黙知の時代から、見える化の時代へ - 痛みがある。 ec2 keypair がなくなっていた・・ / RAILS_ENV はどこで設定されてんだ
chef / serverspec に以降
GitHub 時代のデプロイ戦略
開発プロセスの改善

株式会社ビズリーチ竹内真さん

ルクサのことを話します、高級なタイムセールサイト
メール配信数が、一億通/月 !!
大量メール配信システムは金額的に厳しいので使っていない。SES も高いので使っていない。自前で作っている。
SDK をキックして配信用のEC2サーバーを増減。配信する時間は決まっているので、時間単位でコントロール。EIP は予め確保 (Floating IP パターン)。
最大１５台までスケール。１時間よりちょっと短い時間になるように、台数を調整している。台数を多くし過ぎると、お金が勿体ない。