マイクロサービスアーキテクチャについて
発表者は小野 大器（クックパッド株式会社）さん。
会社が今度様々なサービスを今後生み出していくためには以下の大きな問題がありました。
- monolithicなアプリのままではテストが遅い
- monolithicなアプリのままでは軽微な修正を簡単に実施して deploy しにくい
この問題を解決するために、Microservices を採用することになった。Microservices については、Martin Fowler さんが書いた記事で紹介されています。
Cookpad は Rails アプリとして開発されているため、grage という各サービスに分割して Restfull APIで各サービスが通信しあうようなアーキテクチャに変更しました。
これによって他に利点もありました。各チームごとに開発言語を切り替えられたり、RDBMSを選択したりできるようになり、採用を効率的に進めることもできました。
デメリットとしては、各サービスごとに独立して動作しないモジュールなどを作り直したり、チーム構築の
各サービスとは、OAuth Services, Video Backend, などがあります。
Dev が AWS と出会って DevOps を目指した話
発表者は梅田 昌太（Retty 株式会社）さん。
rettyはみんなfavarite なメニューを持っている。梅田さんは炒飯だそうです。
400万人ユーザに近くなってきたときに問題発生。
- RDSに書き込んでたロギングの限界
- ミドルウェア（rettyの場合、php)をアップデートしていかないとAWSの便利なツールが利用できない
- 秘伝のたれがいっぱいで中身のわからないAMI
AWSを利用してDevOpsを利用する一番の目的。コードを書く時間がほしい。
そのため、Elastic Beanstalk：オートスケール
AWS状にherokuのようなサービスを作ってくれるサーボス。
git aws.push のAWSのコマンドで deploy 簡単。
EBのCLIも最近更新されて便利になりました。
s3fsは突然接続が切れるため怖い。
chat ops も導入。hubotからSQSになえて EBがキューから取得してくれる。これほんと便利！
スポットインスタンスは 1/10 にコストがなるが、負荷が上がると勝手に落とされる。でも、コストを見ていると楽しい！！
ec2を自分で負けたら負けだと思っている！結論：AWSを活用してどんどんサービスを開発していきましょう。
プッシュ通知大戦争
発表者は今村 雅幸（株式会社 VASILY）さん。
我々の会社はここの１階下にいます。
大戦争といいたかっただけなのですが！
iQON：アイコンというファッションアプリを開発している会社です。
プッシュ通知は、リテンションに効きます！ただ、インフラ屋にはたまったことじゃないが、ビジネス的には重要。
プッシュ通知への要件。(1)効果的な配信の仕組み。これは決められた時間内に全ユーザに配信したり、エラー対応、リトライ、アンインストールユーザの処理など。(2)分析の仕組み。これは曜日、時間、セグメント、文言を分析して、どんなユーザーがどんなプッシュに反応しているかを次に生かす。
プッシュ通知の課題。(1)２００万以上に一気に送りたいが、全員には時間がかかる。
(2)どのデバイスが有効かわからない
(3)エラーのリトライ処理のライブラリ実装が雑。
(4)さまざまな条件でプッシュしたい。
数時間かかっていた配信が１０秒程度に。プッシュの文言にハートを入れるとCTRがあがる！！女の子すごい！CTRはt%～n%ぐらい。
NewsPicks を支える技術と怖い話
発表者は文字 拓郎（株式会社ユーザベース）さん。
あのnaoya.ito-sanもほめているアプリ！！
NewsPicks のコメント欄がウゼーとか放言したところ昨日中の人に会ってしまい、ばれてないか非常にドキドキしたのですが案の定ばれてました。NewsPicks 最高ッス
— Naoya Ito (@naoya_ito) 2014, 12月 16
news picks はいま３０万人ぐらいのサービス。
キュレーションだけでなく、編集部があり、そこでコンテンツを作っていく。３年後に１００人態勢にすることが目標。
NewsPicksを支える技術
LINEで社長と議論できる会社
レガシー環境、コードを戦いながらなんとか運用
QA セッション
みんなで4択の質問に対して、以下の写真のようにリアルタイムに回答しながら、ビール頂きながら、ピザ食べながらの楽しいQAセッションでした。
