YAPC::Asia 2015 2日目
データ分析基盤を支える技術
@repeatedly
入門寄り、実装まで踏み込むことはしません
#yapcasiaD繋がりで、D言語コミッタもやってますので興味あれば
必要なコンポーネント、それをどう組み合わせるかという話
データ解析基盤に必要なもの
- Reporting
- Monitoring
- Exploratory data analysis
- 探索的な解析
- どういうものが効果的かわからない時に、いろんな断面から可視化する
- 相関を見つけ出す
- 探索的な解析
- Confirmatory data analysis
- 仮説ありきの解析
- Need data, data, data!
- 勘でやってハズしてるのはままある
Data Analytics Flow
- 一般的なデータ解析の流れ
- アプリからアクセスログ・アプリログをどっかに保存(象さん)→処理して解析
- テーブル一気に出しても人間解析できないので、整理しなければ
- 整理した上でビジュアライズする
Let's Launch Platform!
RDBMS
- とりあえずデータベースに放り込めばOK、スタートアップでもコレのままのところは多い
- 枯れててナレッジがたまってる
- シングルサーバなので分散ほにゃららを考えなくて良い
- RDBMSはスキーマに合うようにログのをETLしてクエリに変換、INSERT
- そう甘くは行かない、１台で行ければみんなハッピーだった
- 更新に対して強いが、時系列に従ってデータ量が増えるクエリには強くない
もっと早い(並列分散)RDBMS
- 実際そうしてきました
- PRDBMS
- Netezza, Teradata, Vertica...
- Web系はあまり馴染みないが、大きい会社だと使ってたりする
- OLAP
- ある１行のカラムの更新に強い
- shared-nothingで分散しているノードごとに計算が閉じるように実行できる構造
- PRDBMSはほぼほぼこのモデルを踏襲
- １個使ったことがあるとわりとつぶしが効く
列指向ストレージ
- int型の列をint型だけでまとめて保存
- codeカラムを集計、みたいなケースに行指向よりI/Oが少ない
- 圧縮効率も非常に良い
解析に特化したデータフォーマット、現行の解析DBのほとんどが採用
「１行更新したい」みたいなケースには、すべて更新書けないといけないので遅い
- INSERTをサポートしてなかったり、非推奨だったり
解析基盤そのものはフツーに回せるようになりました
2000年代後半まではこんなかんじでした
「どうデータを配置するか」というユーザのノウハウがないとうまく回らなかった
分散キーを指定できる
- どの値をどのノードに分散させていくか
- 下手な分散方式だと裏でNWがゴリゴリ動いてパフォーマンスが出ない
銀の弾丸ではない
- 再配置中はライトができない
- メタデータのロックで１秒くらい待たされたりする
ずっと同じスキーマを使いますか？
データの保存だけ何も考えずにガーッとやって、使うとき・解析するときに定義すれば良いのでは
- RDBMS: Schema-on-Write
- データソース・データウェアハウスの分離の発想
- ライトはちょっと重いけど、リードが軽くなる
- Hadoopでは読むときに型を作り出す
- Schema-on-Read
Data Lake
- ベンダー臭がして使っていいのか微妙なんですが
- Hadoop、あるいはより広大なもの
- 型を変換せずに、生のまま保存して、Data Lakeがその差異を吸収する
- 実はいろんな人が提唱して人によって中身がバラバラ
- 共通項は「デカいストレージ」
Data Lake Patterns
Apache Hadoop
- いろんなものが乗っかりすぎて、どこからどこまでを指すのかわからなくなりつつある
- 一昔前はMapReduceでしたが、今では膨大な選択肢の一つ
- 間にHadoopみたいな何でも置けるものを置いておくと楽ちん
- ETLではなく、EL/Tのアプローチ
- 今でも現役
余談
Ingestion Tools
ログの保存手法
- バルクロード
- ストリーミング保存
- fluentd
- Flume
- いろんなベンダのディストリビューションに入ってる
- Logstash, Heka, Splunk...
- 同上
1TBのデータを変換するのにまた1TBのストレージが必要だったりする、インポートはなかなか大変
- ためたデータに直接クエリを投げたい！
MPP query Engine
- さっきのPRDBMSからストレージを引いたみたいな
- データはなんでもOK
- Schema-on-Read
- データはなんでもOK
- RDBMSならRDBMSのスキーマ、HadoopならHadoopのスキーマを読んで結果を返せる
- 界隈では「SQL on Hadoop」
- presto, Impara, Drill
presto
- FaceBook社
プラガブルなバックエンド
つらいケース
「もっと速報値がほしい！」
Apache Storm
- 世の中の解析基盤はほとんどApacheに支配されています
- 出てきたレコードをダイレクトに解析にかける
- １レコード単位に解析
- マイクロバッチ
- Twitterが利用したことで有名、がTwitterはもう使ってない
Norikra
- @tagomoris開発、日本製
- StormはGradleでクエリを書く必要があった
- SQLで書ける！
- しかし分散しない！
- モリスさんの努力が足りない
- MerkariやFreakoutでは使っている
Apache Kafka
- Apache Que
- pullがあるまでpushされてきたデータを貯めこむ
- データ分岐の粒度が違ったり、間隔が違うときに挟ませる
- push側(fluentd, Flumeなど)は受け側のリソースを考慮せずに送りつけ続けてしまうので、そこを吸収するのが主なMotivation
- ない会社もあるので、なくても動くことはあります
- Push型とPull型が入り乱れ出したら、挟むとよさげ
めっちゃたくさんある、つらい
- みなさんは解析がしたいのであって、運用はしたくないハズ
- Amazon RedShiftやBigQueryみたいな便利なのがあります
Amazon RedShift
Google BigQuery
- 数秒〜数十秒で返ってきて欲しい
- 構造はほとんど同じなんだけど、最下層のColossusがスゴいらしい
- しかし論文未発表で謎技術です
Treasure Data
Resource Model Trade-off
- フルギャランティード
- 急激なスケールには自力でスケールアウトする必要がある
- フルマネージド
- BigQueryとか
- たまにレスポンスが遅くなったり、アンコントローラブルな要因が挟まる
- TDはその中間くらいです
- MS Azureもこういうことが出来ます、スライドに盛り込みたかったけど時間がありませんでした
「解析したい！」
- やりましょう！！！
- しかし運用コストが超高い
- クラウドベンダがそうさせないように努力しているので、その波に乗っかるべき
- エッジな機能を使いたい場合に限り、一緒に運用をしていきましょう
まとめ
Q&A
- PrestoのコーディネーターのHA構成ってやりようがありますか？
- 人間が分析するときの可視化、ダッシュボードを作るときのトレンドってありますか？
- セキュリティ的に全く外にデータを出せない時のパッケージってある？
- 実はあんまりないけど、MSのAzure Service FabricやOpenStackくらいなのでは
- バックエンドのスケーラビリティを担保できないと、実用的な基盤が作れない
- S3相当のオブジェクトストレージを自前で持つ、みたいな努力が要ります
- 実はあんまりないけど、MSのAzure Service FabricやOpenStackくらいなのでは
YAPCあるある
歴代実行委員長的な人たち
- miyagawa
- takesako
- 941
- lestrrat
- yusukebee
牧さん、941さん、miyagawaさんいらっしゃってますが、呼び込みをしたいので一旦出てもらってます
- 拍手のコツ
- 細かく早く
- 大きく
- 声も
- 拍手のコツ
基本情報から振り返るYAPC::Asia Tokyo
いつ・どこで
入場者数の推移
- '09にドロップがあったのは秘密にしたかった
- 推移についてはクロージングで話します
スポンサー数の推移
- 6社→47社
- メディア協賛とか含めると60越え
出来事から振り返る
'06
- '05に台北であった、そこで話した時に「来年東京でやってくれ」と言われたので
- 次の日のトークで「来年やります」と書いて
- 竹迫さんやnaoyaさんとキックオフをした
- ミーティングはそれっきりだったような
- 当日朝に集まって「あとよろしく」
- (牧)僕の受けた引き継ぎは↑でした
- ミーティングはそれっきりだったような
- 無線も家庭用無線LAN並べただけで、ほとんどつながらなかった
- 当時WiMAXも試験してたくらいの時期
- 「ワイエーピーシーアジア」かなと思ってたらmiyagawaさん「ヤプシーエイジア」
- 売上を来年に持ち越したくなかったので、20万くらい黒字になったけどperl Foundationに15万くらい寄付した
'07
- 津田ホール
- '07の懇親会でDanKogaiさんと邂逅
'08
- 東工大
- ３棟で移動が大変でした
- 大ホールの階段がコケやすい
- 以降'11まで
- ActivePerlのカナダactive state社からスポンサー協賛
- 芝生で餃子
- Y!がカップラーメンを配ってお湯で行列が出来る
- 食べると眠くなる
- 最後余って学生に押し付けてた
- miyagawaさんの紫色のやつ(Yahoo!知恵袋あごまくら)
'09
- 運営がJPAに
- '08のスタッフ打ち上げまで何もなかったが、各々ちょっと思っていたようで
- ちょっとやってもいいかなー、と思っていたら決定事項になっていた
- 階段でコケた事案をうけて保険を契約する際に、法人じゃないとダメでした
- 牧さんは当日38度の熱を出しました
- カメラマンの八木さん
- ACTがフランス
'10
- 941さんコミット
- JFXに初ドタキャン食らった気がする
- (牧)「引き継ぎ資料なんてものはない」
- (宮川)「'08までのMLはbasecampに全部残してある」
- (941/牧)「それ引き継ぎの時に聞きたかった」
'11
- ランチタイムrejectしたら大不評
- 「おなかすいた」言いながらみんなみっちりトーク聞いてた
- 941「トーク見るのは素人ですよ」
- 前夜祭で廊下で談笑してたら「静かにして下さい！」って言われた
- みねまつさんのマイクが壊れて大声でしゃべってもらった
'12
- 東大、一つの建物
- LTソンがすごかった年
- 人数が増えだして
- ぼっちランチ解消対策
- くじ引きして、お金あげてみんなでランチに行ってもらう制度
- RubyKaigiからパクった
- 個人スポンサーも
'13
- 慶応
- 941さんが会期中ずっとマークされてた
- CONBU
- 個人スポンサーの単価増
- おまもりを作った
- バグ封じのお守り
- 中には"Shut the fuck up and write some code"
- おまもりを作った
'14
- ゆーすけべーさん
- HUB貸切
- 宮川「今年はないのでちょっと不満ですね」
'15
- 会場がビッグサイト
- 5トラック、2000人超え
- 懇親会はキャパ700に600人
- 慶応では満員電車でご飯を食べるみたいな教訓があったので
Q&A
- お世話になった人リスト
- 勉強になったこと
- YAPCの人の集まる求心力の秘訣
- (941)負けを知りたい
- 嘘です
- 新しい人をどんどんいれること
- (牧)法人化して、投資できるようにしたこと
- 写真をとってもらうように
- ビジュアルで残して、想像できるようにできたのは大きい
- (941)負けを知りたい
YAPCに捧げたもの、得られたもの
- yusukebee
- 「LTは笑いを取るものなんだよ！」と言われたり
- あったかいなあと
- 一旦の区切り、ということで
- 941
- クロージング30分、長いなと思った
- 果たして最後なのかどうか
- 小さな飲み会みたいなのからイベントのノウハウを蓄積して、YAPCみたいな大きいイベントができるようになった
- みなさんも勉強会の主催・幹事を率先してやってみて頂ければ
- クロージング30分、長いなと思った
- 牧
- クロージングあるのでパスで！
- 竹迫
- 宮川
- yusukebee
HTTP/2時代のWeb
@Jxck
- Goでhttp2サーバ、クライアントを書いている
- mosaicfm
- http2study
- 今は正式名称がHTTP/2、HTTP/2.0と書いている記事があれば「古いんだな」と思ってくれれば
#http2study
日本人にすごいひとがたくさんいる
- nghttp2
- 「事実上のリファレンス実装」と言わしめた
- h2o
- kazuhoさんの発表とダダかぶりなんじゃないかと思って昨日の発表は全く見てません
- nghttp2
RFC 7540
- RFCになってしまいました
- みなさん既にお読みかと思いますが
策定のフェーズは終わった、使うフェーズに入った
今回は「理解した、導入する」を目指すつもりはありません
- 「気がついたらHTTP/2使ってたは」という世界も無くはない、実はそれはそんなに否定しなくてもいいのかもしれない
現状把握
- １ページ中のリクエスト数とコンテンツサイズは増える一方
- サイズも１こにつき2MB近くまできている
帯域 vs レイテンシ
- 帯域が増えたからWebが早くなる、というわけではないらしい
- やりとり自体のレイテンシが占める割合、それを削減する努力の方がクリティカルだということがわかってきた
速くするために
- RTT(ラウンドトリップタイム)を減らす
- 物理的に近くする
- レスポンスを早くする
- 光は案外遅い
- 光が早くなればいいが、どうやらそういう兆しはない
- RT(ラウンドトリップ)回数を減らす
- アクセス回数を減らす
- RTT(ラウンドトリップタイム)を減らす
HTTP/1.1
- テキストベース
- Header
- Body
- なんでもOK、バイナリでも圧縮でも可能
- TCPを毎回確立している
- 毎回3-Way-Handshake
- 毎回initial cwnd(輻輳制御)
- Head of line Blocking
- レスポンスが返るまで次のを返さない
- ひとつ詰まると後続が全部止まってしまう
- コレを受けて、ブラウザはこっそり6本張っている
- 2本推奨だったので6本張るようになりました
シンプルな一方高速化に限界が
- わりといろんな回避策を編み出してきました
- TCP
- TCP Fast Open
- 3-W-Hを
- InitCWND 10
- 昔ほど問題にならないので上げる
- TLS Session Ticket
- TLS False Start
↑Kernel level
それを待てない会社が独自プロトコルを作ってしまう
- これを標準化してみたのがHTTP/2です
HTTP/2
- バイナリフレーム
- パースしやすい
- サイズ効率が良い
- データ分割しやすい
語彙はそのまま(セマンティクス維持)
- GETはGETのまま
- 互換性をもたせる
ヘッダ何度も送る問題へのアプローチ
- HPACK
- ハフマン圧縮
- 頻出ヘッダ(200とか)を最初からIDにして共有
- 送信済みデータを再利用
- 圧縮の仕様だけ決めて、アルゴリズムは実装次第です
- http2studyでやってみて、高いものは8割方圧縮できたりしてます
- HPACK
1コネクションにストリームを多重化
- 全部同時に送る
- 全部一緒に送って全部遅くなるのは困るので、リソースに優先度をつける
- 画像より3倍cssにリソースを割り振る(ソケットに書き込む)
- コネクションを使い切る
- これまで6本がバラバラに走り出して、コネクションの割に帯域を使い切れてない
- １本にすればハンドシェイクも１回、帯域の限界までデータを送れる
- ベンチマーク
- https://jxck.io/labs/hol/
- 数字でも速く、それ以上に画像がの出る順番から体感で速く感じる
Server Push
- 1リクエスト1RTだった壁を超える
- Cache-Controlでブラウザキャッシュさせてると思いますが
- 熾烈なキャッシュの奪い合い
- 75%の人は48時間で領域を使い切っている
- 2日経てばクライアントキャッシュが無条件に空になっているかも
- Pushで積極的なCache管理していく案
- Service Worker
- フェッチとプッシュを全部jsで操作できる可能性がある
- アプリとしての側面が強くなる
Pushが入ることの意味
- FetchとPushの両方をカバー
- コンテンツ配信だけじゃもったいないですねコレ
- WebSocket over http2
- gRPC
- アプリケーション、ミドルウェアレベルで積極的に使える可能性が
では、採用しますか？
Response Timeの後の世界
- フロントエンドの画像１枚、がバックエンドのニューニングを台無しにする可能性は往々にしてある
- Res.Timeは世界の半分しか測れてない
- Speed Index
- Real User Monitoring
- 数値化しにくいものも多く、過渡期ではあるがレスポンスタイムだけで速度を測れる時代はもう終わった
最適化
- ものすごく素直に作っても遅くならないかもしれない世界が近づいている
実装
- まだ追いついてません
インフラ
- ロードバランスどうするの？
- HTTPS終端は？
- need more 知見
- まだ弱いです、議論が欲しい
HTTPS
- Pervasive Surveillance
HTTPS前提？
HTTP/2は巨人のものか？
- 戦ってるレベルが違う
- 毎日がDOSみたいな世界
- 我々のアプリが複雑でない、というわけでもない
- HTTP/2は使っても使わなくてもいい、というのがいいところ
- クライアントは標準化のおかげでいつのまにか導入されています
- リバプロ挟むだけで高速化した事例もある
- 今足りないのはノウハウ、ただそれだけ
これからどうなるのか
- priority 最適化
- HTTP/3の話ももう出てきています
- TCPの限界
「理解した、導入しない」
- 戦略としてはあり、ただしとどまり続けるリスクに注意
- まずは触ってみれば良いと思います、どうせまだ実装は足りていない
「能く知らないけど導入する」
- エコシステムの成熟次第ではあり得る
まとめ
- RFCが出てしまった
- HTTP1.1はなくなることはないので安心してください
HTTPS化はした方がいい、まともな新しい機能もだんだん試せなくなっていく
nginxが2015年末に実装を宣言
- ここが一つのチェックポイントになるのではないか
次のIETFが横浜に11月で
- Twitterに愚痴っても世界は良くならないので、ココに投げ込むことを検討して下さい
- 日本のガチ勢も集まります
Q&A
- ブラウザキャッシュの中身を知る方法は？
- 実は無いんです
- h2oが出しているのはサーバがキャッシュしているかどうかのシグナルを持っておこう、という提案
- 二重にpushを送っても問題はないので、あまり深刻な問題ではないかも
- 普及にどれくらい時間がかると考えていますか？
- 思いつくのはメジャーなサーバが正しく実装している状態、それなら来年か再来年くらい
- では、みんながそれを使うかどうかはわからない、来ないかもしれない
- したいひとはする、という程度のものだと思う
- 来るとしても近い未来ではなさそう
- エコシステムが揃うのは？
- Webはエコシステムで作るものだと思っている
- エコシステムが、使う側から見て成熟すると感じられるのはサーバ側のミドルウェアが暗黙的にサポート・支援をしてくれる状態
- そして、みんなが勉強会やブログで知見を共有できる状態
- 知見は少しずつ出てきつつあるが、サーバ実装は全然なので2,3年かかるだろう
- プライオリティの指定は明示できる？
- 今はブラウザの実装に依存しているが、
Resource HintsというのでProbabilityを指定することはできる - まだ実装の議論の段階
- 今はブラウザの実装に依存しているが、
- 昔からIPv6という問題があるんだけど、どっちからやんなきゃいけないんですかね
LT
MySQL 5.7の罠があなたを狙っている
- @yoku0825
- 5.7
- 今年中にはGAが出るでしょう
- 余計なお世話なパラメータが多い
- パスワード変更から360日後にロックされる
- UTCで出る、誰得
- binlogへの書き込みはDiskFullでは開放してくれないのでスタックする
- (めっちゃ多いのでスライド参照)
吉祥寺.pmというイベントを作った話
- Magnolia
- 悩み
- 聞きたいテーマの勉強会が都合よく解決されない
- →自分でイベント作ればいいのか！
- 聞きたい人の話が聞ける
- 自分の家の近くで開催できる
- 自分が聞きたいトークがあれば自分で開催すれば良い！
a good naming makes a good design
- Satoshi SUZUKI
- ・「いい名前が決まると設計が決まって勝手に実装が出来上がる」
- ちょっと意味がわからない
- 名前以上の機能を持たせない
- buildというメソッドでbuild以外にいろいろやっちゃうと
- テストも書きにくい
- 全部説明するのは最悪
- 日本語で説明して、割れそうなのを分けるという順番がよさげ
- 適切に役割を分割
botになる技術
モダンなクライアントサイドJSに追い付くための小さな(しかし大変な)一歩
- @zoncoen
- モダンなクライアント
- React, brownerify, BABEL, webpack, ngJS...
- ウチではjQuery1系とCoffeでした
- グローバル直叩き
- DOMは変数じゃない
- 「糞コードじゃないすか」「そう思うし、直して」
- 直した
- npm
- ファイルに分けつつ、WebPackでまとめる
- Marionette.js
- 圧倒的につらい状況からは脱した
Evaluating your stylesheets
- @t32k
Kaizen Platform
- Naoyaさん、5社で技術顧問してて「技術顧問ビッチじゃないか！」と言ってしまったのが今週のハイライトです
CSSのヘルスチェックしていますか？
Perlの$encoding変数
- @yappo
- 5.22からdeprecatedです
- いろんなバグ
THE REAL LOCK
- 本当のロックの話をします
- @moznion
- 分散排他ロック
- 何を使うのが正しいのか？
- ...電話だ！
- 電話を使うことで本当のロックに到達することができました
- 1876年からの伝統
- 「相手と通話できる」「相手と通話できぬ」
- Twilioでこれが実現できます
- 無料アカウントでデバッグしまくってたらexpireされてしまってDemoはできません
コミュ力あげてこ
- WebAudioを応用してコミュ力を鍛えるツールを作りました
- 世界的 <- コミュ力高い
- 伝統的 <- コミュ力高い
- 通信手段 <- コミュ力高い
- モールスは黒電話以上の伝統
- モールスでのコミュニケーション
- 情報量がめっちゃ少ない
- 「伝わってめっちゃ嬉しい」というプリミティブな感情が得られます
- 村上春樹「理解とは誤解の総体である」
- ＝わかった感
- 積極的に劣った手段でコミュニケーションをしていきましょう
COMBU
- 総延長1.6km、AP/SW90個、1時間でやりました
- ホントにやったのか？ということで、今から設営します
- 1分で設営、撤収できました
Vim script静的解析の光と闇
- Kuniwak
- 嘘、光はない
- 変数が闇
- リリースしてissueが速攻で5個立つ
- 謎構文
- Vim「甘えるな」
- 宣言と参照を追跡する
- Lv.1
redir - Lv.2 スコープ
- Lv.3
map- 文字列で渡されてしまう
- 無視するように甘えたら誤検知の嵐
- 再帰展開する
- 文字列で渡されてしまう
- 解析しやすいコードを書いて欲しいです
- そんなこんなでできたのが
vim-vint pip install vim-vint
