CROSS 2014メモ.org

当日の自分用メモ
気が向いたら感想や考察を書くかも
org-modeで書いたのを分割

機械学習CROSS

* 機械学習のユースケース
** ちょっとくらい間違えても大丈夫な分野
   -広告とか
** ビジネス側が「人にはできないだろう」と思っているところ
   -大規模なデータ
   -曖昧なクエリ
** マーケティング
   -手段の1つにすぎない
   -デジタルマーケティングでは利益を増やせる
   -リアルマーケティングでは在庫を減らしたりしてコストを減らせる
** 機械学習の補助を受けて、最終的には人間が判断する使い方
** 誤検知をどこまで許容できるか
   -日本の空気:ミスは許さない
   -欧米の空気:ミスしても速いなら良い
* 機械学習でどれだけ質の良い訓練データを得られるかの軸
** 利益に対して機械学習の結果が直接反映できる
   -例えば広告。webの収益源なので最適化は重要
** 機械学習の目的が明確になっている
   -男女予測: 男 or 女
   -スパムフィルタ: spam or not
** 機械学習の効果を意思決定者にどう伝えられるのか
   -広告主に因果関係を説明するのか、できるのか
* 機械学習導入の費用対効果や導入判断について
** フィルタをスルーすると社会的責任が果たせずサービスも廃れる場合
** 撤退ポイントを明確にしていて、許容できる範囲で機械学習にチャレンジ
* 機械学習一本で行くのか、人とかと組み合わせるのか
** 対策を打てないとどうしようもないので解釈性が無いと厳しい
   -モデルを変える
   -手作業で直す
** 人間ではできなかった領域に踏み込む事こそ機械学習の意義
** 人間側(専門家)が強いという考え方
   -機械が間違えた結果を人間が見れば正解が判断できるという前提
   -間違えた結果を理解した結果で説明できるか
* アカデミックと実用の関係
** 新しい技術はアカデミック分野からやってくる
** やってみたら実用できなかったとかもある
* 一番最初にKPIを決めるのが大事
** 機械学習で何をしたいのか
** データ項目と目標値
** 活用しながらKPIが上がっていくのを楽しむということが大事
* 失敗事例とか事例いろいろ
** 企業活動は戦略とオペレーションがあるが、機械学習は後者にのみ適用できる特性
   -変化が起こりやすい戦略的なレンジではモデルが壊れたりする
** 抽出したい・したくないパターンをはっきりさせておかないと良い判定器が作れない
   -トレーニングデータは良いのもを
** 機械学習結果を、人間によるドメイン知識のフィルタリングを行って活用すべき
   -購買サイトで冷蔵庫をカゴに入れたり買ったあとでも冷蔵庫をレコメンド
** 学習データがたくさんあってもノイズが高いと意味ない
   -急激な傾向の変化に鈍くなる
   -不動産データみたいに。データの収集に営業など人の手が介在する場合はデータ不足で失敗しやすい
* ソフトやクラウドサービスがあるのでアルゴリズムを深く知らなくても機械学習を使えるようになった
* あとは導入するのかしないのかとかそういう問題

次世代webセッション前半プロトコル

* 去年からプロトコル周りでどんなアップデートがあるのか
** QUIC本気になった
   -アプリケーションプログラマとしては待ち
   -TCPが持っていた部分をアプリケーションが持たなければならない
** PRISM
   -スノーデン事件が古いプロトコルを見直すきっかけになった
   -手のひら返しでE2E暗号
   -ディスカッションがTLS前提に一瞬で移った
** アップグレードの雰囲気
   -ALPNだるい
   -ブラウザベンダの抵抗が強い
   -TLS前提のプロトコルレイヤが見えている
** TLSも変わるよ
   -でかい仕様になっているので
   -TLS1.3、QUIC、HTTP2が一緒くたになって変わるのかも
** ALPN
   -次世代プロトコルを長い期間使うのならアップグレードは必須になる
   -GNU TLSに入った
   -NPNとALPNでAPIが違う→ALPNが普及したらNPN落とす?
   -Googleはどちらも話す
   -443いいよね
* 証明書
** いずれwebでなにかやるには証明書の購入が必須になる
** 証明書発行局の事故もある CA
** CA局にすべての責任が行くのは、「信頼できるインターネット」を阻害しうる
* websocket
** over SPDY
** ドラフトには入っている程度
* これからどうなるのか
** 13年に打ち上げられた話題を進めていく
   -標準化活動
** コアのプロトコルはLast Callまでに、それ以外はおいおい
   -だらだらやってるとみんなが興味を無くす
   -LastCallがかかってからみんな読み始めて意見を言い出す(怒)
* webrct
** 仕様がでかい
** コーデック決まらない
** HTTP2に比べたら完成
* NAT
** 実世界デプロイ(サービス提供側)は意識せざる負えない
   -安心してユーザに使ってもらうため
** ユーザ側は意識しなくて良いあたりwebrctは進化している
* レイヤリング
** 教科書的には維持するようにあるけど
** いつか潰したくなる by google
* 俺の考える最強のプロトコル
** QUICに向かっているが障壁は多い
** 現状だってPOSIXとかの制約でTCP/IPに妥協しているに過ぎない
** 障壁を壊していいんだったらTCP自体を壊したい by lefさん
* 実際QUICどうなん
** Googleでも実験段階
** 人とか割いている
** まだ表に出すには早い
* 戻ってHTTP2
** アプリケーションの負担的にHTTP2のほうが普及する見込み
** 転送量削減とかではQUICのほうが良さそう
** 「プロトコルはできたけど運用どうするの」問題
   -DevOpsML誰も流していない
   -だからこそ読める
   -5年後にはみんな運用しているかもだし文句があるなら言っといたほうがいいよ
   -でも手が回っていないし仕様が決まってなかったから仕方なかった
   -今年は運用にも目が向くのでは
** LastCallを目指してこれから頑張っていく予定
   -終わりに向けて活動を始める3月
   -プロキシのユースケースでうまく行ってないし難しそう
** 日本は世界で群を抜いて実装が多い国
   -辻川さんパネェ
   -すごい人に母国語で質問できる幸せ

分散処理システムCROSS

* サーバから端末まですべて含めて分散システムだ!
* Presto, Raft Paxos
** Paxosが難しかったから簡単な実装にしよう→Raft
** BashoのRECON見ると勉強になる
** jepsen ネットワーク分散耐性のチェック clojure製
* サーバ自体がステートレスにしないとスケールアウトによる冗長性の実現が難しい
* workerとmasterの比率
* Hadoop
** 小さいアプリとかでは使わない
** 当たりだして急に需要が出る
** みんな社内で同じノウハウを独自に溜め込んでいて共有されていない
* DB SCR
** 運用の話をすると人があつまる
** マジでソースコード読みたい人は少ない
* 運用
** Hadoop
   -よくわからないエラーを吐く
   -勝手に落ちてる
   -落ちてもジョブが続くのがHadoopの嬉しいところ
   -メタ情報が少ないとplaningが難しかったりするので使い方重要
** AWS
   -障害が起き得る
   -Staticな環境ではないから、全障害のカバーは無理
   -オンプレからクラウドに移る流れのある昨今、最初からクラウド指向でアプリを書くことが必要
   -そういうノウハウを共有するべき
   -落ちることに対しては、インフラとユーザとMWベンダが一致団結しないと無理
** どういう故障モデルを想定してAWSのシステムを考えればよいのか
   -結果整合は避けられない
   -強整合では経済的合理性がなくなる
   -クラウドにプレッシャーをかけないアプリを書く(exponential back)
** 故障の定義
   -故障をハンドリングしてデータを使わない選択ができれば良い
   -つーかそれこそが難しいんじゃん?
** テスト
   -テスト書くのが大変(quickcheck)
   -再現環境を作るのも大変そう
   -fail側をどうやってシミュレートするのかが鍵
** インフラの人のこれから
   -MWの効果を発揮できるのはインフラが整備されている前提
   -インフラがおろそかだと分散システムが経済的合理性を欠く