大規模運用で見えるWebプロトコルの理想と現実、そして今後 #html5j #html5j_b
- 2. Pアジェンダ(前半: 新部) 2 • ヤフーのhttps通信を支える共通Proxyの紹介 AOSSL対応、ハードウェアについて • 運用について monitor、deploy、HTTP/2
- 3. Pアジェンダ(後半: 大津) 3 大規模共通プロキシーから見えるWebプロトコルの 理想と現実 • HTTP/2の理想・現実 • TLSの現実 Webプロトコルは今後どうなる？ • TLS1.3とQUIC
- 5. P自己紹介 5 名前： 新部 長則 所属： システム統括本部サイトオペレーション本部 インフラ技術4部 CDN運用 担当： 共通Proxyのキャパシティ管理 構築、増設、監視、障害対応など
- 7. PヤフーのProxyの歴史 7 2010年頃 Disk I/O不足 HDD -> SSD 時代 2011年頃 帯域不足 NW増強、DC追加 2013年頃 pushスパイク問題 Proxy、origin共に増設 2015年頃〜 SSL CPU性能不足 システム入れ替え
- 8. PヤフーのProxyの歴史 8 2010年頃 Disk I/O不足 HDD -> SSD 時代 2011年頃 帯域不足 NW増強、DC追加 2013年頃 pushスパイク問題 Proxy、origin共に増設 2015年頃〜 SSL CPU性能不足 システム入れ替え
- 9. PヤフーのProxyの歴史 9 2010年頃 Disk I/O不足 HDD -> SSD 時代 2011年頃 帯域不足 NW増強、DC追加 2013年頃 pushスパイク問題 Proxy、origin共に増設 2015年頃〜 SSL CPU性能不足 システム入れ替え
- 10. PヤフーのProxyの歴史 10 2010年頃 Disk I/O不足 HDD -> SSD 時代 2011年頃 帯域不足 NW増強、DC追加 2013年頃 pushスパイク問題 Proxy、origin共に増設 2015年頃〜 SSL CPU性能不足 システム入れ替え
- 13. P 13 • 4,000,000req/secのhttps • 400Gbps • 上記を冗長構成 共通Proxy 要件
- 14. P 14 • 高クロック、多コア、バランス型などの CPUで効果測定し、筐体を選定 • CPU使用率からの処理性能 • 処理性能と電力消費量のバランス • 帯域をどこまで出せるか 共通Proxy 要件
- 15. P 15 • CPU: 2x Intel Xeon 28cores, 56threads • Memory: 128 GB • Storage: NVMe SSD • Server: 約500以上 ※導入時期によりスペックは多少違いあり 共通Proxy Hardware
- 16. P 16 • Request：200万rps • Traffic：300Gbps • Cache：2PByte • Software：Apache 共通Proxy 現状
- 17. PHTTP/2化 17 共通リバースプロキシーに移行している途中で開始 2016年4月 25%程度をHTTP/2 有効 2016年5月 100% HTTP/2 有効 サービス影響はcase-sensitiveなツールで ヘッダーが小文字になったことへの問い合わせ
- 19. P 19完了！！
- 20. P 20AOSSL対応・・・
- 23. P地震 9月8日 22時23分ごろ 23
- 24. P北朝鮮ミサイル 9月15日 06時57分ごろ 24
- 26. Pdeploy 26 •chef enterprise + screwdriver •速さより、安心を重視 •普段は、1台 -> 20%程度 -> 残り様子をみながら •特別影響が大きい変更時は、1週間程度50%で稼働させる 時もあります
- 28. P自己紹介 28 名前： 大津 繁樹 所属： システム統括本部サイトオペレーション本部 インフラ技術4部 CTO室スタンダード言語サポート 担当： IETF標準化 Node.js サポートチーム
- 29. PP HTTP/2の現実 29
- 30. Pおさらい: HTTP/1.1の欠点 30 HTTP Head of Line Blocking
- 31. PHTTP/2の理想：HoLの解消 31 HTTP/2はHTTP Head of Line Blockingを解消
- 36. PHTTP/2の現実：HTTP/2 vs HTTP/1.1 36 このスプライト画像の表 示までのタイムライン
- 37. PHTTP/2の現実：サーバから見る http/2 新規接続 : 再接続 = 11 : 89 http/1.1 新規接続 : 再接続 = 42 : 58 37 49.8% 25.3% 18.4% 6.4% TCP ( ) http/2 reused connection http/1.1 reused connection http/1.1 new connection http/2 new connection (ある日のピーク1時間のリクエスト数ベース集計) HTTP/2でTCP新規接続、TLSハンドシェイクの割合が減っている。 TLSハンドシェイク CPU 負荷低減？ HTTP/2によ る接続集約 Domain shardingの 影響
- 38. PHTTP/2の現実：結局どうなの？ 導入：No Trouble 枯れたTLS1.2上で導入できたので中間経路の問題を回避できた。 効果：実は、まだよくわかりません。 A/Bテスト、性能測定(クライアント・サーバのデータ突き合わせ） ボトルネック調査、パフォーマンスチューニング これからです。 38
- 39. PP TLSの現実 39
- 41. PTLSの現実：暗号方式のSPOF 99% 以上が Forward Secrecy で ECDHE 鍵交換。統計は取れていないがほと んどが NIST-P256。 NSAバックドアが公表されたら大混 乱に。x25519の準備を始めないと。 DES3はすぐ切れそう。AESもなんか あったらChaCha20使えるか？ 41 70.3% 25.0% 4.2% 0.2% 0.2% 0.1% 0.0% 0.0% TLS CipherSuite ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA DES-CBC3-SHA AES128-SHA AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES256-SHA384 CipherSuites 統計 ECDHE-RSA-AES
- 42. PTLSの現実：導入後の落とし穴 証明書の更新、ドメインの追加削除 漏れ、抜け、typo、オペミス クライアントOSのアップデート いきなりの挙動変化 認証局システムの事件・事故 お手上げ ＼(^_^)／ 42
- 44. PTLS1.3が求められる背景 1. 常時TLS時代を迎えるにあたって、しっかりしたプロトコルが必要 2. TLS 1.2の限界。様々な技術負債の蓄積されている 3. 安全だけでなくモバイル環境の普及に応じた性能面の向上を 長期に使える、より安全で高性能なTLSプロトコルを作る。 44
- 45. PTLS1.3の特徴 1. 様々な機能、項目の見直し・廃止 時代に合わなくなったもの、より効率的に変更修正できるものを TLS1.2から機能・項目を数多く廃止 2. よりセキュアに 平文通信が必要な部分を極力少なくして情報を秘匿 これまで攻撃対象となった機能を極力排除し将来的な攻撃に備える 3. 性能向上 初期接続の短縮による性能向上 (0-RTT接続) 45
- 46. PTLS 1.3使えるの？ 仕様はほぼ完了 次のOpenSSL-1.1.1でサポート 後方互換の透過性の問題を調査中 46
- 47. PQUICとは UDP上でTCP, TLS, HTTP/2の一部を実 現するプロトコル。 Googleが開発、2016年からIETF標準 化が始まる。 現在Googleから出るトラフィックの 30%以上がQUIC。これはインター ネット全体のおよそ7%相当。 47 ユーザーランド実装 vs kernel実装
- 51. P理想と現実のまとめ HTTP/2は枯れたTLS1.2上で導入できたので中間経路での透過性の問題は 少なかった。エンドとエンドの問題に集中できた。 効果はまだわかりません。 TLS 1.3 や QUIC ではそういかないだろう。枯れるまで待つと技術的優位 性を失う。 今後の新しいWebプロトコルに対応するには、しっかりとした測定がで きるモニターの仕組みとエイヤじゃなくてもいける柔軟なシステム構成 が必要 51