後半話し聞いてばっかりでメモとってないっすｗ
自分でも考えることあるからこれにどうやって付け加えていこうか考え中
Server Pref
サーバーサイドパフォーマンスって話題は細分化されててシビア。
モニタリングの話がどうしても出てきてしまう…
Webの規律が下がっていると感じるがどうか？
@xcir
スマホにシフトしていったのでパフォーマンスの勘所は変わってきている
APIリクエストが増えている
@cubicdaiya
Webからのアクセスは1割
JSON APIになってやることは減ってるけど、求められるパフォーマンスは上がってきている
チューニングで気をつけてるか、どう言う改善をしているか
@xcir
Webのトラフィックの流れを見て、どこが詰まっているかを調べる
@cubicdaiya
CPUの使用率が上がっている
1台のサーバーで3，4万接続ある
非同期処理している部分とか
メッセージキューに入れて裏のJobWorkerが動いてる
高速化しにくいリクエストをどうしているか
@cubicdaiya
トランザクションが必要なところがネックになる。I/Oネック。
札束で殴る。
マスタをRedisにキャッシュさせたり
@xcir
キャッシュできない類のところは高速化しづらい
非常に辛い。仕様を変える。
キャッシュ戦略はどうしてるか
キャッシュは銀の弾丸？
運用しやすさとのトレードオフはどうする？
@xcir
キャッシュで重要なのはそのデータが再利用されるかどうか
シリアライズ/デシリアライズに時間がかかりすぎて逆にパフォーマンスが下がるパターンも。
どのレイヤーにキャッシュを使うかが大事
@cubicdaiya
全ユーザー共通で表示するようなデータに使う
ランキングみたいなデータ
ユーザー単位でキャッシュ→事故は怖くないのか？
@mirakui
文化の問題かもしれないが…
ログインして表示しているモノはキャッシュしないというポリシー
トラブルが怖い。
キャッシュのせいだろ？ちゃうで。このやりとりがヤダ。
言語の選択にも絡んでくるんじゃないか
Rubyは運用しやすいと思うようにしているｗ
メイン言語は？
@xcir
みんな大好きPHP
合ったものであればなんでもいい。
@cubicdaiya
GoとかC
ちょっと前からCPUの性能は頭打ちになってて、マルチコアが主流
それがやりやすい言語を選択する
マルチプロセスでやろうとするとオーバーヘッドがでかくてあんま早くない
フレームワークはすごく軽量なモノを使う
リクエスト数は多くなってくる。
1リクエストのオーバーヘッドが効いてくる。
Webサーバのミドルウェアについて
今回のメインはこの点
Varnishどれくらい使い倒してる？
Nginxは？
@xcir
一通り触ってる
ESI、ストレージ…
4.1が出ていじれることが増えた
レスポンスを加工とかできるようになった
開発環境でもVarnish立ててる
@cubicdaiya
HTTPSサーバー、LB等々…
検索サーバー10台くらいをNginxでLB
プッシュ通知のリクエストをHTTPでとばしてる
luaとかmrubyで拡張したりしてる
少ない処理で大量のリクエストをさばくアーキテクチャ
最近のVarnishの動き
HTTP/2も視野に入っている
VarnishのHTTPSへの姿勢はどんな感じ？
SSL/TLSが嫌い
ネットの接続の問題
海外だとつながらなくなることもよくあり、海外からの接続で工夫していることは？
@cubicdaiya
国毎の商習慣が違うからアプリが別になってしまう
アメリカだとレイテンシーが日本と違う
TLSハンドシェイクを抑えたりとかしてる
@xcir
CDNは重要だな、という印象
日本だとあんまりだけど。
@mirakui
パスによって言語が違ったりしている
US Eastに振り分けのサーバーを置いてる
→何故かというとどこからリクエスト来ても一律遅いからｗ
カジュアルに海底ケーブルが切れるｗ
Opera mini はすごいという話
画像とか勝手に小さくしたりしてくれる
AJAXとかサーバーサイドでレンダリングして返したりしてる
東南アジアで普及してる
エンジニアは消耗してるらしいｗ
CDNについて
CDN使わざるを得なくなっていくんじゃないか
小さな企業には各国にサーバーを設置するのはムリ
@xcir
使ってます
@cubicdaiya
CDNに求められてることが増えてる
WAFが乗ったり、画像管理機能が付いてるとか
APIリクエストでCDN通したりしている
フロントにボトルネックが移ってきている
アプリケーションのレイヤーが上がってきている感じ
Server Arch
gRPC Gatewayの話
プロトコルバッファでHTTP/2で転送するライブラリ
gRPCすげえいい。
よくないところ→そこを補うところはgRPC Gateway
JSONベースのAPIと互換性がない
外部システムと連携する場合サーバープッシュは必ずしも必要なもんでもない
システム内部とシステム外部の要件が違うので仲立ちになるモノ
内側での通信でgRPCみたいなSpecificな通信するのはどう思う？
エンジニアとしては使ってみたい
ライフサイクルが長いからなかなか冒険
トラディショナルなのはSOAPｗ
REST over HTTP1 はまだトラディショナルじゃない
ジャンプしすぎないためのgRPC Gatwayはいいんじゃないか
HTTP/2ってHTTP1の追加な仕様だから透過的には移行しないんじゃないか？
HTTPコネクションのプーリングってDBコネクションプーリングするような考え方とマッチするんじゃないか
HTTP2の基盤でカスタムなプロトコルの一例がgRPC
Thriftは芽がない…
Security
@nishimunea
サーバー側のセキュリティを勉強しよう
でもサーバー側は大体出そろってる感
新しい分野を研究しなくてもいい。
@kinugawamasato
XSSは面白い
Webの開発者がブラウザの問題に対応することはあんまないっぽい
W3Cは何の網羅性もない
各企業が各分野で得意なモノを持ち寄ってできている
仕様が曖昧…
もっと網羅性のある体系的なものになるべき
バグハントするときは？
仕様から入る
セキュリティのリリースノート見るとメモリリークとかはあるけど、仕様面でのバグはそんなに見ない。ブルーオーシャンでは。
ブラウザのバイナリ解析して機能を見つけている。
http2
HTTP/2の現状
5月 RFC7540 策定された
それまでに大体固まってた
主要ブラウザはHTTP/2対応した
H2O, Nginx, Apacheも対応した
JavaはJettyが対応
libcurlがHTTP/2に対応した
HTTP/2を使って1よりも早いWebを作れているかというとまだ怪しい
これから。
HTTP/2で早くなる？
遅くなるケース
HTTP1だと同時接続数が6だった。
HTTP/2になって同時に100本とかいけるようになった
けどこれだけで早くなるか？
従来は順番にダウンロードしてた
HTTP/2では、HTMLも画像もCSSも全部一緒にダウンロードする
→レンダリングできるようになるのに時間がかかる場合がある
Priorityの仕様はあるけど、クライアント（ブラウザ）がきちんとリクエストするようになってないから早くならない。
Firefoxくらい。
Priorityの仕様はOptional
HTTP/2だと1つのTCPに依存するので、TCPに問題が発生すると全てが破壊的に遅くなる。
PriorityはExperimentalな実装
どうすればいい？
H2Oではリクエストの内容で先に送るモノを決めてる
コンテンツの優先度はクライアントよりも作ってる側の方が知ってるはず
Safariは比較的早くなるかも
リクエストブロッキング（大きなリソース、非同期なリクエスト）
測定することが重要
Priority：H2Oは次のバージョンではMIME-TYPEじゃ足りないからクエリパラメータで対応するようにする
これをきちんと使わないと早くならない
Priority そこまで万能なモノではないと考えてる @jovi0608
送れる場合と送れない場合があるはず。
その時にコントロールできるかが大事
Googleみたいにモニタリングしてソケットバッファをダイナミックにやればいいんだけど、そこまでできないからPriorityは微妙。
Server pushについて
HTTP1に比べて優れているところ → 遅延の影響を受けにくい
使える？
早くなるケースもある。
劇的に効くパターン→飛行機内の通信
通常のWi-Fiではそこまで大きくない
1RTT削るためのモノ
キャッシュコントロールが難しい
クライアントとサーバーが持ってる状態を比べる術がない
いらないんじゃないか説
双方向リクエストは将来的に必要。
高速化の手法としては使われていかないかもしれない
Server Initiateに使われていきそう
H2Oの最新バージョンからクライアントサイドでキャッシュ状態をCookieに持ってServer Pushさせるような機能を搭載
早さ以外の価値はあるのか？
他に語るべきモノはあるのか
バイディレクション
いったん繋がればイーブン。
→これで何が変わる？
P2Pエクステンション。
サーバーからクライアントへGETできるようになる。
でも今のセマンティクスを変えてしまうからすぐになんかなるってことはない。
汎用プロトコルとしてのHTTP/2
次のHTTPへのリビジョンアップがやりやすくなった。
HTTP1まではほとんど拡張の余地はなかった
HTTPSでしかHTTP/2は使えないけど、逆にセキュアWebとしてはいい。
HTTP/2は基本的に早くなる！
ブラウザやらサーバーやらの対応でいずれ早くなる
サーバーの負荷が減る。
TLS前提の時代だと通信の負荷は上がるからこのメリットは際立つ。
Googleもセッションを束ねて余剰がでてメリットがある。
HTTP/2はハイパージャイアントのもの？
身の丈に合っているのかどうか
HTTP/2使わないと死ぬかと言えばまあそんなこたない。
導入の障害になるとすれば上げるための労力とかそういうところだけ
サーバー台数減らせる
1秒でも早くなれば数％の売上げアップ
→ 価値はあるはず
検証してみる価値はあるんじゃないか
HTTP/2にするとシャーディングとか結合とかいらなくなるけど、動的に切り替えるフレームワークがあった方がいい
コンテンツの最適化の問題がある
モバイルファーストなサイトなら、iOS9,10だけになればHTTP/2オンリーなサイトに切り替えていってもいいはず
HTTP/2に足りないものは何か
HTTP3はまだ
TLS1.3に集中してる
TLS1.3がまに合わなかった問題
プロトコル自体は双方向な仕様になってる
既存のHTTPに合わせるため、無理矢理サーバー・クライアントな制限がかかってる。
完全なP2Pになる
リクエスト・レスポンスなモデルが問題
双方向なやりとりができるようになりたい
今後ドンドン出てくる
WebSocketはHTTP/2では使えない
QUICってなに？
Googleが独自に開発しているUDP上の機能
なぜUDP?
TCPの問題を解消するために。
パケットロスが発生した場合のボトルネックを解消するため
0RTTはHTTP/2では越えられない壁
HTTP/2をさらに一歩進めたもん
TCPとか標準化してしまうと変化にすごく時間がかかる。
だからUDPで自分らでやっちゃおうぜ、という流れ
HTTP/2のプロトコル実装は1週間くらい、QUICは数倍作るだろうなあ。
TLS1.3のライブラリがあればだいぶ短縮できるけど。
MSがQUIC実装作った。
ゲーム作ってる人達に求められてる。
どこに向かっているんだろう
なんで大きく変わっちゃったんだろう
どういう事を意味しているのか
昔の技術的負債をすごく返している時期
それについて行けるのか？
ついて行けないとそれが負債になっちゃう可能性がある。
HTTP1は残り続ける…
そこにプロトコルがあるから、高みを見たい
だから実装する
ブラックボックスの中身が明かされただけでWebは最初から簡単じゃなかった
Monitoring
@songmu
@mikeda
@rrreeeyyy
@fujiwara
監視はなんでやるのか？
落ちたら困るモノを見つけるため
将来に対して手を打つための手段
キャパシティプランニング
システムを最適化するためのもの
インフラコストの最適化
最近の監視
チェック監視だけだったのがメトリック監視がだいぶ増えてる
昔はみんなどんな監視してるのか分からなかった
独自のcronでやってたんじゃないか。
ノウハウの共有ができてきた。
メトリクス監視とチェック監視を切り分けて考えない方がいい。
Zabbixで全部一緒にやった方がいいんじゃないか的な
分けない方がいいと思う。
どれくらいの間隔で取得するか
1分でやると数秒だけ劣化したのが見つけられない
1秒だと人間が知覚できる分解能だから取っときたい
そんな取ると死ぬから現状できない
監視が難しい問題
あるある。
ミドルウェアで何を監視すればいいかは運用している内に分かってくる。
取ってる値が多すぎたり、見る必要なかったり、必要なものがなかったりする。
一般化しづらい。
そして秘伝のたれになる。
あんまり新しいミドルウェア入れないように抑止してる
時系列データベース
DatadogはCassandra使ってる
Kafka使ってる
Fluentdの話
Fluentdが与えた影響はでかい
ほぼリアルタイムなログ処理はFluentdがもたらしたと思う