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

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

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

4. P話すところ 4
Proxy originDNS
GSLB

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

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

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性能不足
システム入れ替え

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

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

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なツールで
ヘッダーが小文字になったことへの問い合わせ

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

19. P 19完了！！

20. P 20AOSSL対応・・・

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

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

23. P地震 9月8日 22時23分ごろ 23

24. P北朝鮮ミサイル 9月15日 06時57分ごろ 24

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

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

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

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を解消

32. PHTTP/2の現実：速くなった？
大きめのファイルのダウンロードは確かに速くなっている。
プロトコルの影響(slow start)？
OSやクライアント環境によるもの？
32
(ある日のピーク1時間のリクエスト数ベース集計)

33. PHTTP/2の現実：速くなった？
よくわからない…
33
(ある日のピーク1時間のリクエスト数ベース集計)

34. PHTTP/2の現実：ブラウザーから見る 34
HTTP/1.1

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

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

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

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

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

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実装

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

49. PQUICのメリット(高速接続) 49
さらに！ 0-RTTでもっと高速に

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

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

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