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

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

1. 1. P 大規模運用で見えるWebプロトコルの 理想と現実、そして今後 ヤフー株式会社 大津繁樹、新部長則 2017年9月24日
2. 2. Pアジェンダ(前半: 新部) 2 • ヤフーのhttps通信を支える共通Proxyの紹介 AOSSL対応、ハードウェアについて • 運用について monitor、deploy、HTTP/2
3. 3. Pアジェンダ(後半: 大津) 3 大規模共通プロキシーから見えるWebプロトコルの 理想と現実 • HTTP/2の理想・現実 • TLSの現実 Webプロトコルは今後どうなる？ • TLS1.3とQUIC
4. 4. P話すところ 4 Proxy originDNS GSLB
5. 5. P自己紹介 5 名前： 新部 長則 所属： システム統括本部サイトオペレーション本部 インフラ技術4部 CDN運用 担当： 共通Proxyのキャパシティ管理 構築、増設、監視、障害対応など
6. 6. Pシステム構成 6 2015年6月26日 ヤフーの画像配信システム（CDN）の紹介 http://techblog.yahoo.co.jp/operation/2015-6-yahoojapan-cdn/
7. 7. PヤフーのProxyの歴史 7 2010年頃 Disk I/O不足 HDD -> SSD 時代 2011年頃 帯域不足 NW増強、DC追加 2013年頃 pushスパイク問題 Proxy、origin共に増設 2015年頃〜 SSL CPU性能不足 システム入れ替え
8. 8. PヤフーのProxyの歴史 8 2010年頃 Disk I/O不足 HDD -> SSD 時代 2011年頃 帯域不足 NW増強、DC追加 2013年頃 pushスパイク問題 Proxy、origin共に増設 2015年頃〜 SSL CPU性能不足 システム入れ替え
9. 9. PヤフーのProxyの歴史 9 2010年頃 Disk I/O不足 HDD -> SSD 時代 2011年頃 帯域不足 NW増強、DC追加 2013年頃 pushスパイク問題 Proxy、origin共に増設 2015年頃〜 SSL CPU性能不足 システム入れ替え
10. 10. PヤフーのProxyの歴史 10 2010年頃 Disk I/O不足 HDD -> SSD 時代 2011年頃 帯域不足 NW増強、DC追加 2013年頃 pushスパイク問題 Proxy、origin共に増設 2015年頃〜 SSL CPU性能不足 システム入れ替え
11. 11. PAOSSL対応 11 2015年10月：全社横断プロジェクトチームを発足 2016年4月：社外に向けても告知 サービスごとのHTTPS対応⇒共通Proxyによるセントライズ メンテナンスコストの削減、証明書運用の煩雑さを解消
12. 12. P 12AOSSL対応 サービス数 100以上 ドメイン数 1000 以上 ■証明書の制限に収まるように全社で調整 SEOと将来的なHTTP/2の展望を鑑みて、 可能な限りドメインを統合する方針を決定。
13. 13. P 13 • 4,000,000req/secのhttps • 400Gbps • 上記を冗長構成 共通Proxy 要件
14. 14. P 14 • 高クロック、多コア、バランス型などの CPUで効果測定し、筐体を選定 • CPU使用率からの処理性能 • 処理性能と電力消費量のバランス • 帯域をどこまで出せるか 共通Proxy 要件
15. 15. P 15 • CPU: 2x Intel Xeon 28cores, 56threads • Memory: 128 GB • Storage: NVMe SSD • Server: 約500以上 ※導入時期によりスペックは多少違いあり 共通Proxy Hardware
16. 16. P 16 • Request：200万rps • Traffic：300Gbps • Cache：2PByte • Software：Apache 共通Proxy 現状
17. 17. PHTTP/2化 17 共通リバースプロキシーに移行している途中で開始 2016年4月 25%程度をHTTP/2 有効 2016年5月 100% HTTP/2 有効 サービス影響はcase-sensitiveなツールで ヘッダーが小文字になったことへの問い合わせ
18. 18. PHTTP/2割合 18 (ある日のピーク1時間のリクエスト数ベース集計)
19. 19. P 19完了！！
20. 20. P 20AOSSL対応・・・
21. 21. P 21EV SSL対応 ワイルドカード証明書が使えない SNIによる証明書の出しわけ 今後も増え続けるドメインとの戦い中
22. 22. P共通Proxy monitor 22 GSLB mackerel nagios 管制塔 log集計 サービス死活監視 LB経由死活監視 プロセス死活監視 リソース監視 (cpu/mem/disk bps)
23. 23. P地震 9月8日 22時23分ごろ 23
24. 24. P北朝鮮ミサイル 9月15日 06時57分ごろ 24
25. 25. P稼働実績 25 •2017年は今のところ稼働率100% キャパシティ不足や障害、オペミスもゼロ •全断は無し
26. 26. Pdeploy 26 •chef enterprise + screwdriver •速さより、安心を重視 •普段は、1台 -> 20%程度 -> 残り様子をみながら •特別影響が大きい変更時は、1週間程度50%で稼働させる 時もあります
27. 27. PP Webプロトコルの理想 と現実 27
28. 28. P自己紹介 28 名前： 大津 繁樹 所属： システム統括本部サイトオペレーション本部 インフラ技術4部 CTO室スタンダード言語サポート 担当： IETF標準化 Node.js サポートチーム
29. 29. PP HTTP/2の現実 29
30. 30. Pおさらい: HTTP/1.1の欠点 30 HTTP Head of Line Blocking
31. 31. PHTTP/2の理想：HoLの解消 31 HTTP/2はHTTP Head of Line Blockingを解消
32. 32. PHTTP/2の現実：速くなった？ 大きめのファイルのダウンロードは確かに速くなっている。 プロトコルの影響(slow start)？ OSやクライアント環境によるもの？ 32 (ある日のピーク1時間のリクエスト数ベース集計)
33. 33. PHTTP/2の現実：速くなった？ よくわからない… 33 (ある日のピーク1時間のリクエスト数ベース集計)
34. 34. PHTTP/2の現実：ブラウザーから見る 34 HTTP/1.1
35. 35. PHTTP/2の現実：ブラウザーから見る 35 あれっ！？ 全然速くなっていない HTTP/2
36. 36. PHTTP/2の現実：HTTP/2 vs HTTP/1.1 36 このスプライト画像の表 示までのタイムライン
37. 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. 38. PHTTP/2の現実：結局どうなの？ 導入：No Trouble  枯れたTLS1.2上で導入できたので中間経路の問題を回避できた。 効果：実は、まだよくわかりません。  A/Bテスト、性能測定(クライアント・サーバのデータ突き合わせ）  ボトルネック調査、パフォーマンスチューニング これからです。 38
39. 39. PP TLSの現実 39
40. 40. PTLSの現実：オワコンプロトコル問題 40 (ある日のピーク1時間のリクエスト数ベース集計) TLS1.0はオワコン間近 でも5%弱は無視でき ない数字 SSL3.0を完全に殺した POODLEのような脆弱性 が公表されるか？ TLSバージョンの統計値
41. 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. 42. PTLSの現実：導入後の落とし穴  証明書の更新、ドメインの追加削除  漏れ、抜け、typo、オペミス  クライアントOSのアップデート  いきなりの挙動変化  認証局システムの事件・事故  お手上げ ＼(^_^)／ 42
43. 43. PP Webプロトコルは今後 どうなる？ TLS1.3とQUIC 43
44. 44. PTLS1.3が求められる背景 1. 常時TLS時代を迎えるにあたって、しっかりしたプロトコルが必要 2. TLS 1.2の限界。様々な技術負債の蓄積されている 3. 安全だけでなくモバイル環境の普及に応じた性能面の向上を 長期に使える、より安全で高性能なTLSプロトコルを作る。 44
45. 45. PTLS1.3の特徴 1. 様々な機能、項目の見直し・廃止 時代に合わなくなったもの、より効率的に変更修正できるものを TLS1.2から機能・項目を数多く廃止 2. よりセキュアに 平文通信が必要な部分を極力少なくして情報を秘匿 これまで攻撃対象となった機能を極力排除し将来的な攻撃に備える 3. 性能向上 初期接続の短縮による性能向上 (0-RTT接続) 45
46. 46. PTLS 1.3使えるの？  仕様はほぼ完了  次のOpenSSL-1.1.1でサポート  後方互換の透過性の問題を調査中 46
47. 47. PQUICとは  UDP上でTCP, TLS, HTTP/2の一部を実 現するプロトコル。  Googleが開発、2016年からIETF標準 化が始まる。  現在Googleから出るトラフィックの 30%以上がQUIC。これはインター ネット全体のおよそ7%相当。 47 ユーザーランド実装 vs kernel実装
48. 48. PQUICのメリット(パケットロスに強い) 48 回線輻輳
49. 49. PQUICのメリット(高速接続) 49 さらに！ 0-RTTでもっと高速に
50. 50. PGoogleによるQUIC性能評価  検索レスポンスの改善割合(検索文字を入力してから結果が表示されるまでの時間) 50 出典：http://dl.acm.org/citation.cfm?id=3098842 UDP Proxy導入 Googleは90%以上透過していると言うがQUIC切ったら Chromeが軽くなったという声もチラホラ
51. 51. P理想と現実のまとめ  HTTP/2は枯れたTLS1.2上で導入できたので中間経路での透過性の問題は 少なかった。エンドとエンドの問題に集中できた。  効果はまだわかりません。  TLS 1.3 や QUIC ではそういかないだろう。枯れるまで待つと技術的優位 性を失う。  今後の新しいWebプロトコルに対応するには、しっかりとした測定がで きるモニターの仕組みとエイヤじゃなくてもいける柔軟なシステム構成 が必要 51
52. 52. Pサービス・プラットフォーム開発エンジニア募集中！ ◆プラットフォーム開発とは Yahoo! JAPANにおける各サービスのフ ロントエンド・バックエンド部分と各 サービスを支える基盤システムの開発 ◆望ましい経験/スキル UNIX系OS上での開発経験 PHP、Node.js、C/C++、Javaなどを利 用した開発経験 ◆エンジニアオリエンテッドな開発環境 ・フリーアドレスの最先端オフィス ・外部との交流を目的としたコワーキングスペース ・開発マシン（Mac、Windows）は自分で選択 ・オープンソースへの貢献（コミッターも在籍） ・社員の約半分がエンジニア＋デザイナー（2500人以上） ・働く場所が選べる「どこでもオフィス」制度 日本最大級のユーザー数、トラフィック量を誇るヤフーの各サービス。 それらを支える基盤システムの開発を通じて、世の中からのフィードバックを日々体感しながら、 専門的な技術スキルを持った精鋭社員が切磋琢磨し、大きく成長できるチャレンジングな環境で す。 ◆申込はこちら