読者です 読者をやめる 読者になる 読者になる

YAPC::Asia 2015 2日目

データ分析基盤を支える技術

  • @repeatedly

    • Masahiro Nakagawa
    • Perlの話は全く出てきません
    • TreasureDataでソースコード読んだり、tdメンテしたり
    • 小規模なイベントをぽつぽつやってる
      • 「ソース読むぞ」ってイベント作ってほんとに読むイベントやると人が集まらないのでオススメです
  • http://www.slideshare.net/repeatedly/technologies-for-data-analytics-platform Technologies for Data Analytics Platform

  • 入門寄り、実装まで踏み込むことはしません

  • #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
  • そう甘くは行かない、1台で行ければみんなハッピーだった
    • 更新に対して強いが、時系列に従ってデータ量が増えるクエリには強くない

もっと早い(並列分散)RDBMS

  • 実際そうしてきました
  • PRDBMS
    • Netezza, Teradata, Vertica...
    • Web系はあまり馴染みないが、大きい会社だと使ってたりする
  • OLAP
    • ある1行のカラムの更新に強い
    • shared-nothingで分散しているノードごとに計算が閉じるように実行できる構造
    • PRDBMSはほぼほぼこのモデルを踏襲
      • 1個使ったことがあるとわりとつぶしが効く

列指向ストレージ

  • int型の列をint型だけでまとめて保存
  • codeカラムを集計、みたいなケースに行指向よりI/Oが少ない
  • 圧縮効率も非常に良い
  • 解析に特化したデータフォーマット、現行の解析DBのほとんどが採用

  • 「1行更新したい」みたいなケースには、すべて更新書けないといけないので遅い

    • INSERTをサポートしてなかったり、非推奨だったり

解析基盤そのものはフツーに回せるようになりました

  • 2000年代後半まではこんなかんじでした

  • 「どうデータを配置するか」というユーザのノウハウがないとうまく回らなかった

  • 分散キーを指定できる

    • どの値をどのノードに分散させていくか
    • 下手な分散方式だと裏でNWがゴリゴリ動いてパフォーマンスが出ない
  • 銀の弾丸ではない

    • 再配置中はライトができない
    • メタデータのロックで1秒くらい待たされたりする
  • ずっと同じスキーマを使いますか?

    • 今までのRDBMSスキーマを変えなければならない時、すべてのデータの再構築・再圧縮が走ってしまう
    • それが何度も起きると、人は疲弊してしまう
    • 「じゃあスキーマ変えるんで、1日待って下さい」
    • 個々に対する異論がふつふつと出てきた
    • ↑がHadoopが流行る一因に
  • データの保存だけ何も考えずにガーッとやって、使うとき・解析するときに定義すれば良いのでは

    • RDBMS: Schema-on-Write
    • データソース・データウェアハウスの分離の発想
    • ライトはちょっと重いけど、リードが軽くなる
  • Hadoopでは読むときに型を作り出す
    • Schema-on-Read

Data Lake

  • ベンダー臭がして使っていいのか微妙なんですが
  • Hadoop、あるいはより広大なもの
  • 型を変換せずに、生のまま保存して、Data Lakeがその差異を吸収する
    • 実はいろんな人が提唱して人によって中身がバラバラ
  • 共通項は「デカいストレージ」

Data Lake Patterns

  • Web業界ではHDFSをデータレイクの代わりに使う
  • HDFSのデータをHadoopで処理する、というアプローチ
  • 生のjsoncsvなら、Hadoopが適当にやってくれる

Apache Hadoop

  • いろんなものが乗っかりすぎて、どこからどこまでを指すのかわからなくなりつつある
  • 一昔前はMapReduceでしたが、今では膨大な選択肢の一つ
  • 間にHadoopみたいな何でも置けるものを置いておくと楽ちん
    • ETLではなく、EL/Tのアプローチ
    • 今でも現役

余談

  • MapReduceというのがありましたが
  • Apache Tez
    • MapとReduceのタイムベースからDAGベースのより最適化された分界に
    • M/Rの段数が減る
    • MapReduceの記事を探すときはTez以降か以前か、で大きく変わります
    • Sparkがよく比較してるけど、旧MapReduceと比較してたりするので要チェック
  • いくつか迷信がある
    • HDFSとYARNはSPOF持ち」
      • Resource Managerが落ちると困る問題はもう治りましたよ
      • まだ言ってたら「ポジショントークだな」と思って下さい
    • Hadoopってソースからビルドできないからクソだ」
      • TDではCircleCIから毎回ビルドしてるんで、何を言ってるんだという感じ
      • HortonworksやCrouderaもしかり
  • Hadoopを自社で持ちたい!」
    • 「やめろ!」と言いたいですが...
    • 使うならパッケージをおすすめします
      • Hortonworks HDP, CDH, MapRとか
    • 最新を追うならJIRAとかでバグトラッキングをちゃんと追ってあげて
    • TDはHadoopにパッチを送っている会社で、パッチが当たったものを使いたい
      • それには数ヶ月ラグがあるので、コミュニティ版にモンキーパッチしたりするような時があります

Ingestion Tools

  • ログの保存手法

    • バルクロード
      • RDBMS->Hadoop、みたいなケース
      • Embulk
        • ちょっと宣伝込み
        • TDのOSS
      • Sqoop
        • Hadoop界隈ではよく使われている
      • 用途によってリサーチして下さい
    • ストリーミング保存
  • 1TBのデータを変換するのにまた1TBのストレージが必要だったりする、インポートはなかなか大変

    • ためたデータに直接クエリを投げたい!

MPP query Engine

presto

  • FaceBook
  • プラガブルなバックエンド

    • Hadoop上でなくてもできる
    • prestoそのものがMySQLを読んだりできる
      • FB社はめちゃくちゃDBの種類を持ってるので、いちいち置いていられない
  • つらいケース

    • 「速報値がほしい」
    • HDFSからデイリーや1時間おきにRDBMSへ持って行って、インタラクティブクエリを受けられるようにしてダッシュボードへ
      • データがでかくてクエリが帰ってこない、サマらないとダメ
      • サマってなおデカイともっとつらい
    • HDFSからpresto
  • 「もっと速報値がほしい!」

Apache Storm

  • 世の中の解析基盤はほとんどApacheに支配されています
  • 出てきたレコードをダイレクトに解析にかける
  • 1レコード単位に解析
    • マイクロバッチ
  • Twitterが利用したことで有名、がTwitterはもう使ってない
    • 代替ツールOSSでないので、みなさんはStormを使いましょう

Norikra

  • @tagomoris開発、日本製
  • StormはGradleでクエリを書く必要があった
  • SQLで書ける!
  • しかし分散しない!
    • モリスさんの努力が足りない
    • MerkariやFreakoutでは使っている

Apache Kafka

  • Apache Que
  • pullがあるまでpushされてきたデータを貯めこむ
  • データ分岐の粒度が違ったり、間隔が違うときに挟ませる
    • push側(fluentd, Flumeなど)は受け側のリソースを考慮せずに送りつけ続けてしまうので、そこを吸収するのが主なMotivation
  • ない会社もあるので、なくても動くことはあります
  • Push型とPull型が入り乱れ出したら、挟むとよさげ

めっちゃたくさんある、つらい

  • みなさんは解析がしたいのであって、運用はしたくないハズ
    • Amazon RedShiftやBigQueryみたいな便利なのがあります

Amazon RedShift

  • EMRは構築までで、Hadoop自体の面倒は見ないですが
  • Kafkaの代わりにKinesis、などでAWSソリューションだけで分散機構が

Google BigQuery

  • 数秒〜数十秒で返ってきて欲しい
  • 構造はほとんど同じなんだけど、最下層のColossusがスゴいらしい
    • しかし論文未発表で謎技術です

Treasure Data

  • 僕らもやってます
  • クラウドベンダではないので、OSSを組み合わせてデータレイクソリューションをクラウドの上に構築している
  • ストリーミングは未実装なので、機械学習みたいなのに

Resource Model Trade-off

  • フルギャランティード
    • 急激なスケールには自力でスケールアウトする必要がある
  • フルマネージド
    • BigQueryとか
    • たまにレスポンスが遅くなったり、アンコントローラブルな要因が挟まる
  • TDはその中間くらいです
  • MS Azureもこういうことが出来ます、スライドに盛り込みたかったけど時間がありませんでした

「解析したい!」

  • やりましょう!!!
  • しかし運用コストが超高い
    • クラウドベンダがそうさせないように努力しているので、その波に乗っかるべき
  • エッジな機能を使いたい場合に限り、一緒に運用をしていきましょう

まとめ

  • SQLちゃんと使って下さい
    • RDBMS以外でさえも、SQLで記述するような世界になってきている
    • あと10年は、SQLだけは覚えとかないとダメだと思います

Q&A

  • PrestoのコーディネーターのHA構成ってやりようがありますか?
    • TDではPrestoのHA構成はよっぽどデカいクエリがない限りやっていない
    • コーディネーターはステートレスなので、複数のPrestoをラウンドロビンして落ちたら別のに投げる、という感じです
  • 人間が分析するときの可視化、ダッシュボードを作るときのトレンドってありますか?
    • 作らないほうがいいと思ってます
    • Tableau、MetricWizard?など、探せばいっぱいあります
      • 要望に合わない時に作らないといけないけど、js/cssバリバリの世界
      • OSSではあんまり良いのがない、みんなよさ気なのは有償になっちゃっている
      • キャッシュしないと毎回投げちゃって課金がかさむことがあり、Tableauは内部にキャッシュDBを持ってたりする
      • このへんまで考慮して作らないと難しいのでは
  • セキュリティ的に全く外にデータを出せない時のパッケージってある?
    • 実はあんまりないけど、MSのAzure Service FabricやOpenStackくらいなのでは
      • バックエンドのスケーラビリティを担保できないと、実用的な基盤が作れない
      • S3相当のオブジェクトストレージを自前で持つ、みたいな努力が要ります

YAPCあるある

  • 歴代実行委員長的な人たち

    • miyagawa
    • takesako
    • 941
    • lestrrat
    • yusukebee
  • 牧さん、941さん、miyagawaさんいらっしゃってますが、呼び込みをしたいので一旦出てもらってます

    • 拍手のコツ
      • 細かく早く
      • 大きく
      • 声も

基本情報から振り返るYAPC::Asia Tokyo

  • '06~'08は有志、'09〜JPA

  • 歴代ロゴと運営

  • '06のラクダはオライリーから許可をもらいました

    • perl関連でラクダを使うときはオライリーが権利を持っている
    • Tシャツでの使用のみ、なので来年以降のロゴは変えるようにしてました
  • '06来た人は10人いないくらい

いつ・どこで

  • '06は大田区民プラザ
  • '09に東工大が秋にしか開かなかったので10月に、それ以降は詰められずずっと秋
  • 民間施設は津田ホールとビッグサイトのみ

入場者数の推移

  • '09にドロップがあったのは秘密にしたかった
  • 推移についてはクロージングで話します

スポンサー数の推移

  • 6社→47社
    • メディア協賛とか含めると60越え

出来事から振り返る

'06

  • '05に台北であった、そこで話した時に「来年東京でやってくれ」と言われたので
    • 次の日のトークで「来年やります」と書いて
    • 竹迫さんやnaoyaさんとキックオフをした
      • ミーティングはそれっきりだったような
        • 当日朝に集まって「あとよろしく」
      • (牧)僕の受けた引き継ぎは↑でした
  • 無線も家庭用無線LAN並べただけで、ほとんどつながらなかった
    • 当時WiMAXも試験してたくらいの時期
  • 「ワイエーピーシーアジア」かなと思ってたらmiyagawaさん「ヤプシーエイジア」
    • 当時はCPANもクパンと呼ばれてたりした
    • YAPCをやっぷくと呼んでる人も
  • 売上を来年に持ち越したくなかったので、20万くらい黒字になったけどperl Foundationに15万くらい寄付した

'07

  • 津田ホール
  • '07の懇親会でDanKogaiさんと邂逅

'08

  • 東工大
    • 3棟で移動が大変でした
    • 大ホールの階段がコケやすい
    • 以降'11まで
  • ActivePerlのカナダactive state社からスポンサー協賛
  • 芝生で餃子
  • Y!がカップラーメンを配ってお湯で行列が出来る
    • 食べると眠くなる
    • 最後余って学生に押し付けてた
  • miyagawaさんの紫色のやつ(Yahoo!知恵袋あごまくら)

'09

  • 運営がJPA
  • '08のスタッフ打ち上げまで何もなかったが、各々ちょっと思っていたようで
    • ちょっとやってもいいかなー、と思っていたら決定事項になっていた
    • 階段でコケた事案をうけて保険を契約する際に、法人じゃないとダメでした
  • 牧さんは当日38度の熱を出しました
  • カメラマンの八木さん
  • ACTがフランス
    • ACT...YAPCの管理CMS
    • 日本から使うためのPayPalゲートウェイシステムにバグがあり(ドットの位置がズレてるみたいな)、直さないといけなかった
      • 販売開始してから動かなくなった
      • miyagawaさんがお金もらってフランスの作者の家に泊まりこんで直した

'10

  • 941さんコミット
  • JFXに初ドタキャン食らった気がする
  • (牧)「引き継ぎ資料なんてものはない」
  • (宮川)「'08までのMLはbasecampに全部残してある」
    • (941/牧)「それ引き継ぎの時に聞きたかった」

'11

  • ランチタイムrejectしたら大不評
    • 「おなかすいた」言いながらみんなみっちりトーク聞いてた
    • 941「トーク見るのは素人ですよ」
      • 前夜祭で廊下で談笑してたら「静かにして下さい!」って言われた
  • みねまつさんのマイクが壊れて大声でしゃべってもらった

'12

  • 東大、一つの建物
  • LTソンがすごかった年
    • udzulla劇場
    • LTは(アメリカの)YAPC発祥です
  • 人数が増えだして
  • ぼっちランチ解消対策
    • くじ引きして、お金あげてみんなでランチに行ってもらう制度
    • RubyKaigiからパクった
      • 個人スポンサーも

'13

  • 慶応
    • 941さんが会期中ずっとマークされてた
  • CONBU
  • 個人スポンサーの単価増
    • おまもりを作った
      • バグ封じのお守り
      • 中には"Shut the fuck up and write some code"

'14

  • ゆーすけべーさん
    • '13に牧さん941さん引退宣言
    • つらかったので今年はまた牧さんに...
    • 「慶応とめっちゃモメるから」と言われ続けて教授からあたってちゃんとしたら何も怒られなくなった
      • 慶応では加藤教授、東工大は奥村教授
      • 大学を使いたければ教授から攻めましょう
  • HUB貸切
    • 宮川「今年はないのでちょっと不満ですね」

'15

  • 会場がビッグサイト
  • 5トラック、2000人超え
  • 懇親会はキャパ700に600人
    • 慶応では満員電車でご飯を食べるみたいな教訓があったので

Q&A

  • お世話になった人リスト
    • (941)永山さん
      • 懇親会を毎度セッティングしてくれる幹事マン
    • (宮川)竹迫さん
      • '07,08はほとんど日本に居なくて、すごいいろいろやってもらった
    • (竹迫)DanKogaiさん
      • 外国人スピーカー、ハッカソン
      • 日本でハッカソンをやったのは多分YAPC::Asiaから
    • (牧)並木さん
      • 多分自分の次に長くYAPCにいた人
      • 有名でないけど、こういう人に支えられて
  • 勉強になったこと
    • (竹迫)スライドの翻訳
      • ものすごく教養がないと翻訳できなかった
    • (宮川)最初に講演をお願いしたまつもとさんとラリー・ウォール
    • (牧)スタッフやってるとLTしか見れなかった
    • (941)同じくLTでdameningenさんのWerl
  • YAPCの人の集まる求心力の秘訣
    • (941)負けを知りたい
      • 嘘です
      • 新しい人をどんどんいれること
    • (牧)法人化して、投資できるようにしたこと
      • 写真をとってもらうように
      • ビジュアルで残して、想像できるようにできたのは大きい
  • YAPCが今、Perl以外の言語を許容している理由

    • (竹迫)'06にまつもとさん、高橋さんを招聘している
    • '08からの前夜祭のRejectConfが盛り上がった
      • Perl人口自体は減少の傾向があるので、他の言語を取り込んでも、という認識
      • RejectConfの方がお酒片手に読めて面白そうなのもあった
    • (牧)言語を1つに絞ると、あまり業務に即してなくて面白いのがなさげな感じがする
    • (宮川)他のYAPCではこの傾向はなくて、Perl自体の話が多い
      • 言語のレベルではない、上のレイヤーの話が増えてきたのはそういう流れなのかなと思う
  • YAPCに捧げたもの、得られたもの

    • yusukebee
      • 「LTは笑いを取るものなんだよ!」と言われたり
      • あったかいなあと
      • 一旦の区切り、ということで
    • 941
      • クロージング30分、長いなと思った
        • 果たして最後なのかどうか
      • 小さな飲み会みたいなのからイベントのノウハウを蓄積して、YAPCみたいな大きいイベントができるようになった
        • みなさんも勉強会の主催・幹事を率先してやってみて頂ければ
      • クロージングあるのでパスで!
    • 竹迫
      • YAPC::Asiaで初めてのイベント運営、国際カンファレンス運営
        • YAPCに育てられました
      • 東京以外でもやってもいいんでないか、その時にはやってもいいんじゃないかなと
      • (牧)YAPC自体は商標ないので、やりたい人いたらやっていいんですよ
    • 宮川
      • 自分のルーツはPerlコミュニティ、年3,4回の帰国のうち1回はかならずYAPC::Asia
      • 同窓会みたいな感じ、YAPC以外にもこういう帰ってこれる場所が残っていって欲しい
      • いろんな人に支えて頂いて感謝

HTTP/2時代のWeb

  • @Jxck

    • Goでhttp2サーバ、クライアントを書いている
    • mosaicfm
    • http2study
    • 今は正式名称がHTTP/2、HTTP/2.0と書いている記事があれば「古いんだな」と思ってくれれば
  • http://http2.info

  • #http2study

    • IETFに行ってきた人の報告を聞く会、とか
    • 実装についての議論
    • RFCが出る前からハッカソンやったりしてました
    • MLのissueにあわよくばコメントしてみよう、みたいなissueソン
  • 日本人にすごいひとがたくさんいる

    • nghttp2
      • 「事実上のリファレンス実装」と言わしめた
    • h2o
      • kazuhoさんの発表とダダかぶりなんじゃないかと思って昨日の発表は全く見てません

RFC 7540

  • RFCになってしまいました
    • みなさん既にお読みかと思いますが
  • 策定のフェーズは終わった、使うフェーズに入った

  • 今回は「理解した、導入する」を目指すつもりはありません

    • 「気がついたらHTTP/2使ってたは」という世界も無くはない、実はそれはそんなに否定しなくてもいいのかもしれない

現状把握

  • 1ページ中のリクエスト数とコンテンツサイズは増える一方
    • サイズも1こにつき2MB近くまできている
  • 帯域 vs レイテンシ

    • 帯域が増えたからWebが早くなる、というわけではないらしい
    • やりとり自体のレイテンシが占める割合、それを削減する努力の方がクリティカルだということがわかってきた
  • 速くするために

    • RTT(ラウンドトリップタイム)を減らす
      • 物理的に近くする
      • レスポンスを早くする
        • 光は案外遅い
        • 光が早くなればいいが、どうやらそういう兆しはない
    • RT(ラウンドトリップ)回数を減らす
      • アクセス回数を減らす

HTTP/1.1

  • テキストベース
  • Header
    • 圧縮負荷、変わらないものも毎回送る、重複が多い(UA)
    • UAは嘘をつかないといけないのでどんどん長くなっている
  • Body
    • なんでもOK、バイナリでも圧縮でも可能
  • TCPを毎回確立している
    • 毎回3-Way-Handshake
    • 毎回initial cwnd(輻輳制御)
    • Head of line Blocking
      • レスポンスが返るまで次のを返さない
      • ひとつ詰まると後続が全部止まってしまう
    • コレを受けて、ブラウザはこっそり6本張っている
      • 2本推奨だったので6本張るようになりました

シンプルな一方高速化に限界が

  • わりといろんな回避策を編み出してきました
    • HTTP
      • KeepAlive
      • CSS Sprite
      • File Concat
      • Domain Sharding
        • ドメイン変えればもう6本張れるじゃん」
      • Bad Hack
        • なんで画像一個にまとめる必要があるんだ
  • TCP
  • TCP Fast Open
    • 3-W-Hを
  • InitCWND 10
    • 昔ほど問題にならないので上げる
  • TLS Session Ticket
  • TLS False Start
  • Kernel level

    • おいそれと触れるレイヤーではない、Linux/iOS/Androidが対応してくれるのも待たなければならない
  • それを待てない会社が独自プロトコルを作ってしまう

    • これを標準化してみたのがHTTP/2です

HTTP/2

  • バイナリフレーム
    • パースしやすい
    • サイズ効率が良い
    • データ分割しやすい
  • 語彙はそのまま(セマンティクス維持)

    • GETはGETのまま
    • 互換性をもたせる
  • ヘッダ何度も送る問題へのアプローチ

    • HPACK
      • ハフマン圧縮
      • 頻出ヘッダ(200とか)を最初からIDにして共有
      • 送信済みデータを再利用
    • 圧縮の仕様だけ決めて、アルゴリズムは実装次第です
      • http2studyでやってみて、高いものは8割方圧縮できたりしてます
  • 1コネクションにストリームを多重化

    • 全部同時に送る
    • 全部一緒に送って全部遅くなるのは困るので、リソースに優先度をつける
    • 画像より3倍cssにリソースを割り振る(ソケットに書き込む)
  • コネクションを使い切る
    • これまで6本がバラバラに走り出して、コネクションの割に帯域を使い切れてない
    • 1本にすればハンドシェイクも1回、帯域の限界までデータを送れる
  • ベンチマーク

Server Push

  • 1リクエスト1RTだった壁を超える
  • Cache-Controlでブラウザキャッシュさせてると思いますが
    • 熾烈なキャッシュの奪い合い
    • 75%の人は48時間で領域を使い切っている
    • 2日経てばクライアントキャッシュが無条件に空になっているかも
    • Pushで積極的なCache管理していく案
  • Service Worker
    • フェッチとプッシュを全部jsで操作できる可能性がある
    • アプリとしての側面が強くなる

Pushが入ることの意味

  • FetchとPushの両方をカバー
  • コンテンツ配信だけじゃもったいないですねコレ
    • WebSocket over http2
    • gRPC
    • アプリケーション、ミドルウェアレベルで積極的に使える可能性が

では、採用しますか?

Response Timeの後の世界

  • フロントエンドの画像1枚、がバックエンドのニューニングを台無しにする可能性は往々にしてある
  • Res.Timeは世界の半分しか測れてない
    • Speed Index
    • Real User Monitoring
      • 数値化しにくいものも多く、過渡期ではあるがレスポンスタイムだけで速度を測れる時代はもう終わった

最適化

  • ものすごく素直に作っても遅くならないかもしれない世界が近づいている

実装

  • まだ追いついてません

インフラ

  • ロードバランスどうするの?
  • HTTPS終端は?
  • need more 知見
    • まだ弱いです、議論が欲しい

HTTPS

  • Pervasive Surveillance
    • NSAのPRISM(広域盗聴)
      • スノーデンが告発、この間のIETFSkypeで「スノーデンだけど質問ある?」みたいなことやってたみたいです
      • AT&Tがそれに協力していたとか
      • 牧歌的にできていた時代はもう終わったのではないか
    • 証明書高い問題、特に個人のレベルでは顕著

HTTPS前提?

  • HTTP/2はHTTPS上にしか実装、しない流れ
    • Oppotunistic Encryption
      • 日和見暗号
      • HTTPなのに暗号化
      • Fxで脆弱性が見つかりoffになっている

HTTP/2は巨人のものか?

  • 戦ってるレベルが違う
    • 毎日がDOSみたいな世界
  • 我々のアプリが複雑でない、というわけでもない
    • HTTP/2は使っても使わなくてもいい、というのがいいところ
    • クライアントは標準化のおかげでいつのまにか導入されています
    • リバプロ挟むだけで高速化した事例もある
    • 今足りないのはノウハウ、ただそれだけ

これからどうなるのか

  • priority 最適化
  • HTTP/3の話ももう出てきています
  • TCPの限界
    • UDP、それは最後の希望
    • →QUIC
      • = TLS1.3, HTTP/2, UDP
      • Google検索結果で既に使っているはずです

「理解した、導入しない」

  • 戦略としてはあり、ただしとどまり続けるリスクに注意
  • まずは触ってみれば良いと思います、どうせまだ実装は足りていない

「能く知らないけど導入する」

  • エコシステムの成熟次第ではあり得る

まとめ

  • RFCが出てしまった
  • HTTP1.1はなくなることはないので安心してください
  • HTTPS化はした方がいい、まともな新しい機能もだんだん試せなくなっていく

  • nginxが2015年末に実装を宣言

    • ここが一つのチェックポイントになるのではないか
  • 次のIETFが横浜に11月で

    • Twitterに愚痴っても世界は良くならないので、ココに投げ込むことを検討して下さい
    • 日本のガチ勢も集まります

Q&A

  • ブラウザキャッシュの中身を知る方法は?
    • 実は無いんです
    • h2oが出しているのはサーバがキャッシュしているかどうかのシグナルを持っておこう、という提案
    • 二重にpushを送っても問題はないので、あまり深刻な問題ではないかも
  • 普及にどれくらい時間がかると考えていますか?
    • 思いつくのはメジャーなサーバが正しく実装している状態、それなら来年か再来年くらい
    • では、みんながそれを使うかどうかはわからない、来ないかもしれない
      • したいひとはする、という程度のものだと思う
      • 来るとしても近い未来ではなさそう
    • エコシステムが揃うのは?
      • Webはエコシステムで作るものだと思っている
      • エコシステムが、使う側から見て成熟すると感じられるのはサーバ側のミドルウェアが暗黙的にサポート・支援をしてくれる状態
      • そして、みんなが勉強会やブログで知見を共有できる状態
      • 知見は少しずつ出てきつつあるが、サーバ実装は全然なので2,3年かかるだろう
  • プライオリティの指定は明示できる?
    • 今はブラウザの実装に依存しているが、Resource HintsというのでProbabilityを指定することはできる
    • まだ実装の議論の段階
  • 昔からIPv6という問題があるんだけど、どっちからやんなきゃいけないんですかね
    • IPv6も昔からあるけど、IPv6は一人が頑張ってなんとかなる問題ではないと思う
    • HTTP/2はある意味ではサーバとクライアント間で完結している
      • 対応のスピードは圧倒的にHTTP/2の方が早く、低コストなハズ
    • 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になる技術

  • botの人います?
  • 平田哲
  • bot、便利で多様化していきます
  • 社員で発言をEvernoteに保存していて、100個超え
    • bot化されてしまう
    • PHPで49行
    • 「便利!本人要らない!」
  • 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

クロージング

  • 軽くYAPCの振り返り

  • 60スポンサー、90スタッフ、90のトーク

  • 平均100Mbps
  • 来場者数2130人

  • 3位 Kazuho Oku

  • 2位 Jxck
  • 1位 hitode909

  • "YAPC::Asia" is free

  • Please BLOG ABOUT YAPC!!!

  • One more thing

    • builderscon.io
      • (仮)
      • 2016年は絶対に何もやりません