🍃このブログは移転しました。
3秒後、自動的に移動します・・・。

次世代 Web カンファレンス に行ってきたメモ #nextwebconf

nextwebconf.connpass.com

聴いたやつは以下。

  • server_perf
  • server_arch
  • webrtc
  • http2
  • front_arch

フロントエンドエンジニアやってますがクライアントまわりは身の回りに聴いてる人いっぱいいそうなので、最後以外はサーバーサイドに寄ってみた。
資料があるわけじゃないので箇条書きまとめ。

server_perf

はじめに

  • ページ返してた時代からAPI時代へ
  • 処理は軽くなったが量が増えた
  • 3-4万リクエストを1台でさばけるように

パフォーマンスのあげかた

  • どーしてもパフォーマンスが上げられない処理は、仕様から変えるのもあり
  • キャッシュは効くけど運用がつらくなる
  • メモリ負荷も上がるので、表示頻度との兼ね合いで
  • ユーザー単位でキャッシュ作るのも一例として
  • ABテストはしづらくなる

言語

  • 1CPUあたりの性能は頭打ちしてるので、マルチコアで並立処理できる言語を使いたい
  • APIサーバーにRailsはやりすぎ

周辺技術

ネットワークの安定しない海外アクセス

これから

  • スマホアプリAPIをいかにさばくかが今後の課題
  • CDNを使わざるを得ない状況
  • ボトルネックもサーバーからフロントへ
  • CDNがアプリっぽい振る舞いをするようになる・・?

サーバーサイドのエンジニアの皆様は、いまはアプリからのAPIリクエストと戦ってるんですねー。

server_arch

grpc-gateway

  • gRPCは良いもの / https://github.com/grpc/grpc
  • 従来型のRESTのAPIとgRPCを仲立ちするgateway
  • やってることは内部で効率よく処理することもできる内容だが、これは外部通信向けに作ったもの
  • 10年メンテしないといけないプロジェクトではgRPCには手を出せない(SIer視点
  • gRPCでもSOAPの用途の80%はカバーできると思う
  • ただトランザクション系はgRPCだとつらそう
  • コネクションをプールできる実装
  • DBとそれができるのは現在Javaしかない?
  • http2がベースになれば、その上でカスタムプロトコルを展開できる
  • Thriftとはなんだったのか
  • RMI(Remote Method Invocation)

Reactive Streams

  • http://takezoe.hatenablog.com/entry/20150217/p1
  • gRPCにはいわゆるBackpressureみたいな機能はない
  • Rubyは送られすぎると死んじゃう
  • ハードで解決できないくらいスケールしないといけない時代のReactive
  • ネットワークに限界を感じたらGCP
  • それでも厳しいと感じたら海底ケーブルを自前で・・
  • 並行処理プログラミングは簡単じゃない
  • Goはそのへん楽にしてくれる(けどやりすぎ注意
  • Scalaもそのへん頑張ってる
  • ErlangもElixirも隣の芝生は青い(と思う

Microservices

  • 内部通信と外部通信を分けたうえで、内部に使いたい
  • 非同期が必要なのもこれのため
  • なんちゃってなものは巷に多い(http叩いてるだけとか
  • 非機能要件(デプロイ・モニタリング)も互換性が必要
  • Docker用のDockerビルダーも欲しくなってくる
  • サービス間通信に比重がよる

まとめ

聞いたことあるけど詳しく知らん単語と、まったく知らん単語とをつなぐのに必死なセッションだったw

webrtc

はじめに

  • 現状は割とつらい
  • プラットフォーム(SkyWayとか)も頑張ってるけどつらい
  • ブラウザ別対応するのもつらいけど、ブラウザの自動アップデートもつらい
  • バージョンアップ後、自動的に動かなくなる事案が発生する
  • つらい

運用のつらい話

  • SDP / candidateがわからんと何もできない
  • UDPのパケロスで動画が汚い
  • コーデック対応してない環境とかある
  • Edgeのなんか独自なやつとか
  • 社内NWよりモバイルネットワークの方がまだつながる
  • UDPが抜けない環境も意外にある(社内NWだと)
  • SDP読む担当が運用で専任でいないときつい
  • しかもSDPの実装はChromeFireFoxでまったく違う
  • WebRTCやるならFireFoxのSDPがキレイで良い
  • サイマルキャストどうする問題
  • いまは画質を1つしか選べない
  • Chromeには独自の実装があったりする(Hangout向け?

MCU / SFU

  • P2Pの限界を感じるとこっちを模索する
  • いまはMultipoint Control Unit(MCU)が最適解
  • 動画の変換は重いのでそこがネック
  • Selective Forwarding Unit (SFU)だと暗号化が重い
  • もうこれRTCPからってなる
  • UDPはロストするものなのでそれをなんとかしないといけない
  • それに全員が全員にフルで送信すると負荷もやばい

組み込みRTC

  • クライアントは固定したい
  • Electronは固定できていい
  • RaspberryPIでも割と動く
  • ただ録画はやめとこ

ORTC

これからやるにも

  • つながらない問題はなくならない
  • LANケーブル抜けてる人ほんとにいるから!
  • P2Pのメリットはサーバーいらないところのみ
  • それ以上にやりたいことはあるはずなので、基本的にはMCU / SFUありき
  • PolycomのWebRTCはよくできてる
  • 最初はP2P、人増えたらMCU、モバイルがきてもMCUに移行する
  • SVC(Scalable Video Coding)はMCUでもやれんことはないが・・・SFU

まとめ

  • サイマルキャストの仕様がきっと固まる
  • それまではMCUで頑張る
  • サイマルキャストきたらSFU
  • その次はSVCをなんとかしたいが帯域推定つらい
  • 海外はEdgeが強いのでORTCもはじまってる
  • 海外ではWebRTCが実は流行ってる
  • いいSDKを選べば利用者としては幸せになれるもの
  • お金にはな・・る?

1:1通信程度なら数行で書けて夢あふれまくり!やけどその先は闇ですって。
私はまだ一握りくらいの闇しか見ておりません。

http2

はじめに

  • 無事に仕様としては固まった
  • 主要なブラウザはHTTP/2に対応完了!

ほんとに速いのか

  • 同期接続数6の制限はなくなった
  • が、あれこれあべこべに返ってくるようになってむしろファーストペイントが遅くなる環境もある
  • priorityをクライアントでもちゃんと実装しないとダメ
  • いまはFireFoxだけ実装されてる
  • h2oだとデフォルトでMIME-TYPEからそれを判別してたりする
  • asyncなものもあるので、src="~.js?priority=high"とかもありかも

サーバーPush

  • 1RTT削るだけ
  • 日本だとRTTがボトルネックにはならないので、そこまで恩恵がないかも
  • キャッシュ用途に使うとか?

速さ以外のメリットは

  • httpはブラウザ用のものではなく、プロトコルなのでその意味で拡張は歓迎
  • 複数TCPを1つにできるのはやはり大きい
  • 数%遅くなると売上が下がるとかそういうケースには効く

HTTP/3・・?

  • それよりTLS1.3をなんとか
  • HTTP/2はreq x resな形式
  • gRPCは複数本のコネクションを貼るものなので、HTTP/2が必要
  • WebSocketはHTTP/2では使えない
  • QUICならUDP上でTCP+TLS相当のことができる
  • UDPでやりとりできる = レイテンシが下がる = 幸せ

Webのプロトコル

  • HTTP/1.1はサポートしつつ、いつしかHTTP/5までサポートみたいな未来に?
  • FTPも使われてるし、HTTP/1.0もまだいる
  • jsのライブラリみたいな短ライフサイクルではないので、プロトコルのセマンティクスが変わったとしても追従コストはそこまで変わらない

こう聞いてるとまだまだどう使われるか、どう対応していくか想像がつかんなーという印象。
フロントエンドでどう活用するか戦略みたいなのは結構かわると思うので、要チェックですねー。

front_arch

はじめに

  • フロントエンドのjsの話
  • フレームワークの特徴とか
  • Reactは単純
  • 当時のAngularの双方向バインディングの画期的感ったら
  • 単方向だとシンプルになる
  • FireFoxOSでも使えるWebComponents

Router

  • Angularはng-routerよりはui-router
  • React-routerは宣言的!に書ける
  • 結局HistoryAPIのラッパなので、FWが用意する必然性はない

記法まわり

  • ReactはJSX x Babelで書いていく
  • AngularはTypeScriptやBabel
  • PolymerもES6で書ける

速さ

  • Angularは1.4時点でもReactと同じくらい速い
  • 速さを求めてReactは選ばない
  • DOMが遅い!ってなるのはゲームくらい

アーキテクチャ

  • 全て揃ってる = 足かせになることもある
  • Angular2はFluxっぽい
  • ReactはHot reloadとかできる
  • ComponentにStateをもたせるべきか
  • データはどこにあっても良いのでは

イベントの管理

  • Streamの概念はこれから
  • まずはPromise
  • ES-Observableとかも期待

これから

  • フロントエンドフロントエンドとフロントエンドバックエンド(二槽式!)
  • コンポーネント・リクエスト・イベントから成るのがフロントエンド
  • jsじゃなくても別にいいし、ServiceWorkerでやったりとか(二槽式!)
  • 仕様があるから比較ができ議論ができる

なんかいろいろあるみたいですけど、誰が喋ってもあの話の流れではああなると思います。

おわりに

書きました!