Developers Summit 2013レポート(2)
デブサミ2/15分前半です。長くなったので2つに分けました。
2日目は同じ会場で続けてセッションを聞く場合、廊下に出ずにチェックインできるようになっていました。ラウンジの電源も1日目の終わりから使えるようになっていましたし、スタッフのみなさんも改善が早いですね! そしてGREEさんのミネラルウォーターをいただきました。お水は本当に助かります。いつもありがとうございます。
「爆速」を支えるテクノロジー
- 15-A-1
- 村上臣 Y! チーフモバイルオフィサー
- スライド
- 漢字でわかるのはいいですね「爆速」
村上さんについて
- Y!は基本的にPCの画面が想いうかぶでしょう。CMOを設置したのは…
- 自分はPCの経験がない。ずっとモバイル畑
- 最初は社内でも肩身のせまい部門だった。回りとPVもケタが違う。いつも携帯をたくさん並べてポチポチやってる人達、みたいなカンジ
- 転機は2006年、ソフトバンクがキャリアを売収してYモバがはじまった
- アマチュア無線
- 小学校のころは自転車に無線機を乗せていた
- 大学生のころ、電脳隊
Yahoo! Japanについて
- 2012年3月1日 Y!の経営体制変更
- 創立以外増収増益をした、伸び続けている会社の役員を全部交代した。これはすごいこと
- スマホの大陸が大きい、進化スピードも速い。それに合わせた体制にする
- 経営陣も10歳以上若返り
- 爆速
- 「迷ったらワイルドに行け」
- 新社長宮坂の新入社員への言葉: 4つの約束
- Focus。やるならフォーカスしろ、1個の得意技
- Fast。早く動け
- Fun。楽しんでやれ
- Be Wild。迷ったらワイルドに行け
- 新社長宮坂の新入社員への言葉: 4つの約束
- インド進出
- Y! Inc.は世界中にブランドを持っているので、日本国外で何かやるときにはY!の名前は使えない
- Bharti、エアテルとやっている
- 米Bashoと提携
爆速について
- 爆速
- エンジニアの才能を生かす
- 1. 承認プロセス数: 8 → 2
-
- 関所が8つくらいある。ウォーターフォール的な企画審議とか
-
- 3. 月1ペースで全社ハッカソン実施
- 4. Hack Day
- 5. MYM
- Hack Day生まれのプロダクト
- コミュニケーションツール
- Node.js/MongoDB
- HTML/CSS/JavaScript
- 社内採用をYammerと競って勝利
- 働き方が変わった。「メールよりMYM」
- 趣味の部屋、秘密の部屋もたくさんある
- 内製なのでフィードバック→即改善
- 6. GitHub Enterprise全社導入
- 2012年3月末、エンジニアがほしい → 上層部が「いいね、動いてみて」
- 7月、アカウント数160でスタート → 一瞬でなくなる
- 現在アカウント数500
- Gitのすごさはpull request
- 自律的な現場への変化、活性化
感想
小学生のころから自転車で移動体通信とはすごいですね! 爆速、そのスピード感はすごいものを感じました。「エンジニアの才能を生かす」というのにしびれます。「マインドを変える」ということに関してエンジニアは柔軟であるだろうと思います。エンジニアのマインドが変わることによって、回りの人達も巻き込んでいけるんじゃないかと思っています。
モバイルファースト再考
- AKQAの紹介ムービー
- The Biggest Revolution is Happening on the Smallest Screen We Have
モバイルファースト
- モバイルファーストの時代と言うが、モバイルファーストとは何?
- モバイルファーストの時代
- 元気あるサービスはモバイルオンリーのものが多い
- Path, Square, Flipboard, Instagram, LINE
- モバイル向けのデザイン原則
- Mobile First!
- Luke Wroblewski (Y!)
- Growth, Constrain, Capability (成長性、制約、可能性)
- モバイルの成長性: まあわかってますしいいですよね
- モバイルの制約
- 小さい画面/パフォーマンス/場所と時間(モバイルではむしろ自由)
- マイナスのデザイン
- ネイティブの機能を使ってどうやるか
- 必ずしもWebデザインの話ではないはず
- モバイルの可能性 ← ここが本来のmobile firstでは?
- Mobile First
- モバイルで出来ること、出来ないこと → 特性を活かしたサービス
- Contents First?
- モバイルでもPCでも同じコンテンツを
- まずはコンテンツありきであるべき
- → 本来はデバイスに依存しない情報提供という考え方
- Future Friendly
- Mofile Firstの利点
- 閲覧環境を選ばない
- ブラウザに依存しない
- 情報構造がシンプル
- データが小さく軽い ……はず
ユーザーを見る
- モバイルを使う人ってどんな人?
- デザイン思考
- まずはプロトタイプを作って、現場で実験と検証を行い、問題点を発見→改善、をくり返す
- エスノグラフィーは本質を見抜くためには上流の手法
- 小中学校を観察した例
- TVがまったく使われない
- 連絡ボード(コルクボード)があっても黒板が使われる
- 椅子の足にテニスボールをかぶせている
- キタナイ雑巾とキレイな雑巾を彼らなりに分けているが大人にはわからない
- 新しい発見があります。本物(本筋)の発見があります
- Action!
- 書を捨てよ、町へ出よう(寺山修司)
- デスクを捨てよ、モバイルを使おう
- 本当のユーザーを知ろう
- 実際にモバイル端末を使い倒そう
- 端末は自分で買おう
- 自分で買わないと使い倒しません
- モバイル端末を使う日を週4日、少なくとも3日設定しよう
- 書を捨てよ、町へ出よう(寺山修司)
Opsから挑むDevOps
- 15-D-4
- 千葉則行さん エクシード
- インフラエンジニアとして
- Dev - DevOps <= Ops
- Action!
- 人と艱難を共にすべく、人と安楽を共にすべからず
- お題
- エンジニアを解放する
- 深夜の仕事が多い。年とってきた
- DevOps
- 2009年か2010年?
- 私たちの取り組み
- 改めて考えてみる
- 再びAction!
- エンジニアを解放する
インフラエンジニア
- インフラエンジニアの苦悩
- 突然の…
- 明日までに…
- そんなこと言われても…
- 分業〜すべてのスキルを持つことができない時代
- Dev vs Ops
- エンジニア vs 営業
- 企画部門 vs 技術部門
草勢衛基味
- 対立なんて不毛
- 世界中でスーパーな人たちが切差たくましているのに
DevOps
- コラボレーションの仕組みをつくること
- Cluture, Lean, Automation, Measurement, Sharing
- DevOpscafe.org
Culture┳Lean ━Automation
┗Sharing━Measurement
- DevOpsと言って思いうかぶのは
- Chef, puppet, cfengine
- 例えばChef
- Chef: 無防備な状態でつっこんでいくと間違いなく返り撃ちにあう
- Chefの解説
- Mcollective
- Puppet labsのブロダクト
- 去年かおととし
- スケーラビリティーがある
- MQに入れ、ノードが取りに行く
- 実際のインフラ屋の仕事
- 設計、構築: とても静的な仕事〜設定したら変えたくない
- 障害対応: とんでもなく動的〜急いで対応しないといけない
- Automation?
- 自動化できるのは静的なコトだけ
| ←静的 | 動的→ |
| Chef | Mcollective |
| Puppet | Capistrano |
- ツールのまとめ
| Pull | Chef/Puppet | ○ | 状態の一貫性 |
| × | 動的な操作は難しい(順番を指定して実行) | ||
| Push | Capistrano | ○ | 任意のタイミングで操作 |
| × | なんでもアリになってしまう | ||
| × | スケールしない | ||
| async | Mcollective | ○ | 非同期型、スケールする |
| ○ | 任意のタイミングで操作可能 | ||
| × | 単なるメッセージトランスポーターである |
こんなのはじめました
- cloudrop
- 運用の静的な部分と動的な部分をあわせ持つような仕組みを作りたい
- アーキテクチャ
Portal ┃ Restful API => Mcollective Client ┃ ActiveMQ ┏━━┻━━┓ Mcollective Mcollective Servers Servers ┃ ┃ Chef-solo Chef-solo Script Script
- pullでもpushでもなく非同期なカンジで仕事を流していく
- オペレーションの標準化
- なんでもアリにすると荒れる
- 再利用するべき → 標準化
ボトムアップに
↑ システム構築の標準化
↑ 利用パッケ必ジの規格化
↑ 作業の細分化
-
- → 品質(Q)-コスト(C)-スピード(Agility)のバランス
- ボトムアップな標準化
- タスク → パッケージ → バインダー → ライブラリ
- パッケージ: MySQLなどミドルウエアのレベル
- バインダー: 最終調整してシステムにする
- 「フレームワーク」とは、流れは提供できるがノウハウ蓄積はお客様でやってね、ということ
- 仕事はできる人に集まってくる
- シニアなエンジニアはシニアな仕事をしてほしい。どんどんクックブックを生産してもらいたい
- 現場の人は手順として確立されたものを確実に実行してほしい
- cloudropの効能: 標準化してナレッジをためると何ができるか
- 手元の環境でテスト → 本番へ
- テスト、QA、本番環境を同一に
- configureの引数変えないでください! など
- public <=> private間の相互利用
- blue green deployment
- 本番と新しいバージョンを全一構成で用意しておいて切り換えるデプロイ手法
改めて考えてみる
再びAction!
- Shareできるコト、できないコトがある。
- 「人と艱難を共にすべく、人と安楽を共にすべからず」
- つらいこと、難しいことは共有しやすい
- 楽なことを共有しようとすると堕落してしまう
- つらいコト、大変なコトを共有することから始めましょう
感想
ボトムアップからの積み上げというのは、インフラ・オペレーションの仕事にはよく合うと思います。
NoSQLの野心的な使い方 〜Apache Cassandra編〜
- NoSQLのよくある誤解
- Cassandraを選んだ理由
- どういったものを使いたいかをよく考えて選んでほしい
- 一長一短あるので検討してほしい
- NoSQLとRDBMSとの本当の関係
- 実案件でのNoSQL
- 大規模ポイント管理サービス: 視聴率データの取り込み
- 秒5000回の書き込みの実績
- 1800万回/時、130億回/月
- スマートメーター系への展開
- 拡張性の担保
- サーバーを追加すればOK
- すでに秒間16000回を実証済
- サーバー障害もひと通り経験
- HDの大規模障害(半分落ちた)にも耐えた
- こんなシステムを1人で構築することもできるのがNoSQLの面白いところ
- 大規模ポイント管理サービス: 視聴率データの取り込み
- NoSQLあるある
- 社長「NoSQLって何?」 → 「さすがですね! これからのびる技術です」
- 人事「新人でもできる?」→「ちょうど良かったです。そういう人の方が向いてます」→人材確保
- 部長「お金になるワケ?」
- NoSQLが熱い領域
- M2M(広い意味で)
- センサーネットワーク
- 業界大手はHadoopによる可視化まで
- 既存領域でもまだまだいける
- M2M(広い意味で)
- Action!
- 合言葉
- NoSQLでうでを試そう
- 大切な考え方・キーワード
感想
NoSQLにはなんでも入れられるから、モデルを先に作るより画面を考えよう、というのは、SQLに慣れた頭だと逆に難しそうです。
その他
ランチは1日目に満席で入れなかったカレー屋さんに行きました。おいしかったです。イベント会場周辺のランチ事情をどこかにまとめておきたいですね。
