大規模運用で見えるWebプロトコルの理想と現実、そして今後 #html5j #html5j_b

P ⼤規模運⽤で⾒えるWebプロトコルの 理想と現実、そして今後 ヤフー株式会社 大津繁樹、新部長則 2017年9月24日

アジェンダ(前半: 新部) • ヤフーのhttps通信を⽀える共通Proxyの紹介 AOSSL対応、ハードウェアについて • 運⽤について monitor、deploy、HTTP/2 P 2

アジェンダ(後半: ⼤津) ⼤規模共通プロキシーから⾒えるWebプロトコルの 理想と現実 • HTTP/2の理想・現実 • TLSの現実 Webプロトコルは今後どうなる？ • TLS1.3とQUIC P 3

話すところ P 4 DNS GSLB Proxy origin

⾃⼰紹介 名前： 新部 ⻑則 所属： システム統括本部サイトオペレーション本部 インフラ技術4部 CDN運⽤ 担当： 共通Proxyのキャパシティ管理 構築、増設、監視、障害対応など P 5

システム構成 2015年6⽉26⽇ ヤフーの画像配信システム（CDN）の紹介 http://techblog.yahoo.co.jp/operation/2015-6-yahoojapan-cdn/ P 6

• http://techblog.yahoo.co.jp/operation/2015-6-yahoojapan-cdn/

ヤフーのProxyの歴史 2010年頃 Disk I/O不⾜ HDD -> SSD 時代 2011年頃 帯域不⾜ NW増強、DC追加 2013年頃 pushスパイク問題 Proxy、origin共に増設 2015年頃〜 SSL CPU性能不⾜ システム⼊れ替え P 7

ヤフーのProxyの歴史 2010年頃 Disk I/O不⾜ HDD -> SSD 時代 2011年頃 帯域不⾜ NW増強、DC追加 2013年頃 pushスパイク問題 Proxy、origin共に増設 2015年頃〜 SSL CPU性能不⾜ システム⼊れ替え P 8

ヤフーのProxyの歴史 2010年頃 Disk I/O不⾜ HDD -> SSD 時代 2011年頃 帯域不⾜ NW増強、DC追加 2013年頃 pushスパイク問題 Proxy、origin共に増設 2015年頃〜 SSL CPU性能不⾜ システム⼊れ替え P 9

ヤフーのProxyの歴史 2010年頃 Disk I/O不⾜ HDD -> SSD 時代 2011年頃 帯域不⾜ NW増強、DC追加 2013年頃 pushスパイク問題 Proxy、origin共に増設 2015年頃〜 SSL CPU性能不⾜ システム⼊れ替え P 10

AOSSL対応 2015年10⽉：全社横断プロジェクトチームを発⾜ 2016年4⽉：社外に向けても告知 サービスごとのHTTPS対応⇒共通Proxyによるセントライズ メンテナンスコストの削減、証明書運⽤の煩雑さを解消 P 11

AOSSL対応 P 12 サービス数 100 以上 ドメイン数 1000 ■証明書の制限に収まるように全社で調整 SEOと将来的なHTTP/2の展望を鑑みて、 可能な限りドメインを統合する⽅針を決定。 以上

共通Proxy 要件 • 4,000,000req/secのhttps • 400Gbps • 上記を冗⻑構成 P 13

共通Proxy 要件 • ⾼クロック、多コア、バランス型などの CPUで効果測定し、筐体を選定 • CPU使⽤率からの処理性能 • 処理性能と電⼒消費量のバランス • 帯域をどこまで出せるか P 14

共通Proxy Hardware • CPU: 2x Intel Xeon 28cores, 56threads • Memory: 128 GB • Storage: NVMe SSD • Server: 約500以上 ※導⼊時期によりスペックは多少違いあり P 15

共通Proxy 現状 • Request：200万rps • Traffic：300Gbps • Cache：2PByte • Software：Apache P 16

HTTP/2化 共通リバースプロキシーに移⾏している途中で開始 2016年4⽉ 25%程度をHTTP/2 有効 2016年5⽉ 100% HTTP/2 有効 サービス影響はcase-sensitiveなツールで ヘッダーが⼩⽂字になったことへの問い合わせ P 17

HTTP/2割合 (ある⽇のピーク1時間のリクエスト数ベース集計) P 18

完了！！ P 19

AOSSL対応・・・ P 20

EV SSL対応 ワイルドカード証明書が使えない SNIによる証明書の出しわけ 今後も増え続けるドメインとの戦い中 P 21

共通Proxy サービス死活監視 monitor GSLB P 22 mackerel nagios LB経由死活監視 管制塔 プロセス死活監視 リソース監視 (cpu/mem/disk bps) log集計

地震 9⽉8⽇ 22時23分ごろ P 23

北朝鮮ミサイル 9⽉15⽇ 06時57分ごろ P 24

稼働実績 •2017年は今のところ稼働率100% キャパシティ不⾜や障害、オペミスもゼロ •全断は無し P 25

deploy •chef enterprise + screwdriver •速さより、安⼼を重視 •普段は、1台 -> 20%程度 -> 残り様⼦をみながら •特別影響が⼤きい変更時は、1週間程度50%で稼働させる 時もあります P 26

P 27 Webプロトコルの理想 と現実

⾃⼰紹介 名前： ⼤津 繁樹 所属： システム統括本部サイトオペレーション本部 インフラ技術4部 CTO室スタンダード⾔語サポート 担当： IETF標準化 Node.js サポートチーム P 28

P 29 HTTP/2の現実

おさらい: HTTP/1.1の⽋点 HTTP Head of Line Blocking P 30

HTTP/2の理想：HoLの解消 HTTP/2はHTTP Head of Line Blockingを解消 P 31

HTTP/2の現実：速くなった？ (1.5MB) 100 90 80 CDF [%] 70 60 50 40 30 20 10 0 0 50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950 [msec] http/1.1 http/2 大きめのファイルのダウンロードは確かに速くなっている。 プロトコルの影響(slow start)？ OSやクライアント環境によるもの？ (ある⽇のピーク1時間のリクエスト数ベース集計) P 32

HTTP/2の現実：速くなった？ P 33 (11KB) 100 90 80 CDF [%] 70 60 50 40 30 20 10 0 0 50 100 150 200 250 300 350 400 450 500 550 [msec] http/1.1 よくわからない… (ある⽇のピーク1時間のリクエスト数ベース集計) http2 600 650 700 750 800 850 900 950

HTTP/2の現実：ブラウザーから⾒る HTTP/1.1 P 34

HTTP/2の現実：ブラウザーから⾒る あれっ！？ 全然速くなっていない HTTP/2 P 35

HTTP/2の現実：HTTP/2 vs HTTP/1.1 このスプライト画像の表 ⽰までのタイムライン P 36

HTTP/2の現実：サーバから⾒る TCP TLSハンドシェイク ( ) HTTP/2によ る接続集約 6.4% 18.4% http/2 reused connection 49.8% Domain sharding の影響 P 37 http/1.1 reused connection http/1.1 new connection http/2 new connection 25.3% CPU 負荷低減？ HTTP/2でTCP新規接続、TLSハンドシェイクの割合が減っている。 http/2 新規接続 : 再接続 = 11 : 89 http/1.1 新規接続 : 再接続 = 42 : 58 (ある⽇のピーク1時間のリクエスト数ベース集計)

HTTP/2の現実：結局どうなの？ P 38 導入：No Trouble n 枯れたTLS1.2上で導入できたので中間経路の問題を回避できた。 効果：実は、まだよくわかりません。 n A/Bテスト、性能測定(クライアント・サーバのデータ突き合わせ） n ボトルネック調査、パフォーマンスチューニング これからです。

P 39 TLSの現実

TLSの現実：オワコンプロトコル問題 P 40 TLSバージョンの統計値 TLS1.0はオワコン間近 でも5%弱は無視でき ない数字 SSL3.0を完全に殺した POODLEのような脆弱 性が公表されるか？ (ある⽇のピーク1時間のリクエスト数ベース集計)

TLSの現実：暗号⽅式のSPOF n 99% 以上が Forward Secrecy で ECDHE鍵交換。統計は取れていな CipherSuites 統計 0.1% 0.2% NSAバックドアが公表されたら大混 0.2% TLS CipherSuite 0.0% 0.0% ECDHE-RSA-AES 4.2% いがほとんどが NIST-P256。 n ECDHE-RSA-AES128-GCM-SHA256 25.0% ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA 乱に。x25519の準備を始めないと。 n DES3はすぐ切れそう。AESもなん かあったらChaCha20使えるか？ P 41 DES-CBC3-SHA AES128-SHA AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA 70.3% ECDHE-RSA-AES256-SHA384

TLSの現実：導⼊後の落とし⽳ n 証明書の更新、ドメインの追加削除 u n クライアントOSのアップデート u n 漏れ、抜け、typo、オペミス いきなりの挙動変化 認証局システムの事件・事故 u お手上げ ＼(^_^)／ P 42

P 43 Webプロトコルは今後 どうなる？ TLS1.3とQUIC

TLS1.3が求められる背景 P 44 1. 常時TLS時代を迎えるにあたって、しっかりしたプロトコルが必要 2. TLS 1.2の限界。様々な技術負債の蓄積されている 3. 安全だけでなくモバイル環境の普及に応じた性能面の向上を 長期に使える、より安全で高性能なTLSプロトコルを作る。

TLS1.3の特徴 1. 様々な機能、項目の見直し・廃止 時代に合わなくなったもの、より効率的に変更修正できるものを TLS1.2から機能・項目を数多く廃止 2. よりセキュアに 平文通信が必要な部分を極力少なくして情報を秘匿 これまで攻撃対象となった機能を極力排除し将来的な攻撃に備える 3. 性能向上 初期接続の短縮による性能向上 (0-RTT接続) P 45

TLS 1.3使えるの？ n 仕様はほぼ完了 n 次のOpenSSL-1.1.1でサポート n 後方互換の透過性の問題を調査中 P 46

QUICとは n UDP上でTCP, TLS, HTTP/2の一 部を実現するプロトコル。 n Googleが開発、2016年からIETF 標準化が始まる。 n 現在Googleから出るトラフィック の30%以上がQUIC。これはイン ターネット全体のおよそ7%相当。 ユーザーランド実装 vs kernel実装 P 47

QUICのメリット(パケットロスに強い) 回線輻輳 P 48

QUICのメリット(⾼速接続) さらに！ 0-RTTでもっと⾼速に P 49

GoogleによるQUIC性能評価 n 検索レスポンスの改善割合(検索文字を入力してから結果が表示されるまでの時間) UDP Proxy導⼊ Googleは90%以上透過していると⾔うがQUIC切っ たらChromeが軽くなったという声もチラホラ 出典：http://dl.acm.org/citation.cfm?id=3098842 P 50

• http://dl.acm.org/citation.cfm?id=3098842

理想と現実のまとめ n P 51 HTTP/2は枯れたTLS1.2上で導入できたので中間経路での透過性の問 題は少なかった。エンドとエンドの問題に集中できた。 n 効果はまだわかりません。 n TLS 1.3 や QUIC ではそういかないだろう。枯れるまで待つと技術的優 位性を失う。 n 今後の新しいWebプロトコルに対応するには、しっかりとした測定がで きるモニターの仕組みとエイヤじゃなくてもいける柔軟なシステム構成 が必要

サービス・プラットフォーム開発エンジニア募集中！P ⽇本最⼤級のユーザー数、トラフィック量を誇るヤフーの各サービス。 それらを⽀える基盤システムの開発を通じて、世の中からのフィードバックを⽇々体感しながら、 専⾨的な技術スキルを持った精鋭社員が切磋琢磨し、⼤きく成⻑できるチャレンジングな環境で す。 ◆プラットフォーム開発とは ◆エンジニアオリエンテッドな開発環境 Yahoo! JAPANにおける各サービスのフ ロントエンド・バックエンド部分と各 サービスを⽀える基盤システムの開発 ・フリーアドレスの最先端オフィス ・外部との交流を⽬的としたコワーキングスペース ・開発マシン（Mac、Windows）は⾃分で選択 ・オープンソースへの貢献（コミッターも在籍） ・社員の約半分がエンジニア＋デザイナー（2500⼈以上） ・働く場所が選べる「どこでもオフィス」制度 ◆望ましい経験/スキル UNIX系OS上での開発経験 PHP、Node.js、C/C++、Javaなどを利 ⽤した開発経験 ◆申込はこちら