こんにちは、編集長の白石です。

この記事は、9月24日に開催されるHTML5 Conference 2017に登壇するエキスパートに、予定しているセッションのトピックを中心に、様々な技術的なお話を伺おうというものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、ヤフー株式会社にお勤めの大津繁樹さんと新部長則さんです。

▲左から、ヤフー株式会社 大津繁樹さん、新部長則さん

お二人のセッションは「大規模運用で見えるWebプロトコルの理想と現実、そして今後」（ルームB 13:20-14:00）です。 （現在HTML5 Conferenceは定員オーバーの状態ですが、無料イベントということもあってキャンセルも多めに出るらしいので、諦めずにキャンセル待ちすることをお勧めします！）

日本最大級のHTTPS & HTTP/2化案件の実際

白石: まず簡単な自己紹介からお願いできますでしょうか？

新部: 私は2005年の7月に入社し、Yahoo!メールや広告の画像配信を行うCDNの運用などを経て、現在は全社で利用しているリバースプロキシの運用を行っています。 現在、社内でプラットフォームと呼ばれる部分にはだいたい関わっている感じですね。

大津: まさに、新部さんのチームは、ヤフーのトラフィックをほとんど全て受け止めていると言って間違いありません。国内最大級のトラフィックを支えているんです、半端ないですよ。

白石: では大津さんも自己紹介をお願いできますか？

大津: 私は昨年の10月に入社したばかりです。大きく2つの仕事をしていまして、Node.jsのコミッターとして社内のサポートを行っているのと、IETFでネットワークプロトコルの標準化活動に関わっています。

白石: ありがとうございます。では、ヤフーのサービスをHTTPS + HTTP/2化した際のことを伺ってもいいですか？

新部: まずはヤフーのサービスをHTTPSに移行するところから始めたんです。HTTPS化に伴うコストや影響の試算を踏まえて、2015年10月に、全社横断でHTTPS化するプロジェクトが発足したんです。

HTTPS化するにあたっては大きな問題が2つありました。1つは、TLSの暗号化・復号化の処理が重たいということ。もう1つは、証明書の管理が煩雑にならないようにしなくてはならないということでした。なにせドメインでいうと1,000以上、サービスも100以上ありますので。

白石: 規模感が普通の会社とは桁違いだ…。

新部: なので、全社共通のリバースプロキシを作って対応することになったんです。そのリバースプロキシでTLSを一旦終端させて、そこから先は通常のHTTP/1.1に変換し、各サービスにリクエストを転送する。

白石: そのリバースプロキシって、だいたいサーバ何台分くらいになるんでしょう…？

新部: 500台以上ですね。

大津: 「以上」と言っても幅があると思いますが、そのかなり上の方ですよ、実際の数字は(笑)。

白石: す、すごい…！

新部: そして、2016年3月、最初にリバースプロキシに乗ったのはヤフオク！です。

白石: なんでヤフオク!を最初のサービスに選んだんですか？

新部: 検証の意味も強かったので、ある程度以上の規模感のあるサービスをデプロイしたかったんです。あと、下手すると人命を左右するような「何があっても絶対に止められない」サービスは避けたかった。

白石: なるほど。

新部: ヤフオク！も、いきなり全部をHTTPS化したわけじゃなくて、最初は一部だけ、その後範囲を広げていったという感じです。 幸いにもそれほど大きな事故も起こることなく進んでいき、2017年の3月末には、特定のクライアントに提供しているところを除いたすべてのサービスがHTTPSで動作するようになりました。

HTTP/2化は正直、「エイヤ」でやった

白石: なるほど、HTTPS化は、様々なご苦労はあったことと思いますが、比較的順調に推移したということですね。そして今では多くのサービスがHTTP/2を利用しているんですよね。HTTP/2化はどういう流れで進んでいったんですか？

新部: これはちょっと言いにくいし、言っていいのかもわからないんですが…正直、「エイヤ」でやってしまったところもありますね(笑)。

全社共通のリバースプロキシを構築できたし、ここをHTTP/2化してしまえば、全部HTTP/2にできるじゃん、と。弊社のエンジニアもHTTP/2サーバの実装に携わっていたりもしたので、自分たちで作った成果を自分たちで使いたいという要望もありまして…。

白石: で、「エイヤ」でやっちゃったと(笑)。

新部: まあ、全部をいきなり切り替えたわけじゃないですけどね。こちらも一部のサーバだけを切り替えて、問題がないことを確認しつつ、だんだんと。

白石: なるほどー。ちなみにその、最も重要なリバースプロキシですが、具体的にはどのソフトを利用しているんですか？nginxとか？

新部: いや、Apache Traffic Serverというプロダクトです。元々これは米国のYahoo! Inc.が開発していたものをApache Software Foundationに寄贈したものです。

白石: では、Apache HTTP Serverとは関連がないんですね。

新部: そうです。このサーバをHTTP/2対応させるパッチの開発に、弊社のエンジニアもコミットしているんです。

「HTTP/2化で速くなったかは…正直わかりません(笑)」

白石: では、HTTP/2への切り替えは、それほど大きな問題もなくうまく行ったと。そうした環境で運用を行ってみて、実際にわかったことや問題などはありますか？例えばHTTP/2化することで、パフォーマンスが向上するんじゃないかという期待はあったと思うのですが。

大津: そうですね…正直に言ってしまうと、HTTP/2でパフォーマンスが上がったかどうかはよくわからないんです。

白石: ああ、それ先日インタビューしたあほむさん も同じこと言ってました(笑)。

大津: 個別に見れば、速度が上がっている部分は確実にあるんです。ただ、トータルで向上したかどうかは結局よくわからないんですよね。

例えば、window.onload が速くなったかというと、そうでもないんです。ただ、onloadについてはあまりにも様々な要因が絡むんで、測定の指標としてあまり有効でないという問題もありますけどね。なにせ、ずっと昔から運営しているサービスなので、 document.write にブロックされているページも残っていたりしますし。

白石: 確かに、「トータルで向上したか」と言っても「トータル」ってそもそも何なんだという定義が難しそうです。

大津: そういうところも含めて、測定が十分に行えていないというのも課題ですね。サーバ側のログを見ると、リクエスト数ベースでHTTP/1.1とHTTP/2の割合は現在4:6くらいです。

白石: 1.1がまだいるっていうのは…ああそうか、(HTTP/2に対応していない)古いブラウザを使っているクライアントですね。クライアントの環境も様々だから、余計測定が難しいですね…。

大津: そうなんです。一気に切り替えてしまったことで、A/Bテストなども行えていないですしね。A/Bテストを行うために、一部を一旦HTTP/1.1に戻すというのもありかもしれません(笑)。

HTTP/2がサーバの処理負荷を下げる？

白石: HTTP/2に移行する前の、HTTPSへの切り替えではいかがでしたか？先程、「TLSの処理が重たい」という懸念が事前にあったとのことでしたが。

新部: 一度それで問題になったことはありますね。

弊社のサービスからプッシュ通知を送った時とかは、ユーザーが一斉に接続するので負荷が一時的に高まるんですが、それでCPUがパツパツになってしまったことがありまして。ただ、HTTPS化する前はCPUがボトルネックになるようなことはなかったので、やはりTLSの処理が影響していたんだろうなあと思います。

大津: ただ、その後そういう問題は起きていないのは、HTTP/2が一役買っているのかもしれません。

HTTP/2はTCPセッション数が減るので、TLSの暗号化・復号化に伴う処理負荷も減ります。単純に言えば、HTTP/1.1の時に6セッションだったものがHTTP/2で1セッションになったら、TLSのコストは1/6になるわけで。

白石: なるほど！HTTP/2がサーバの処理負荷を下げるという可能性は、今まで思い至りませんでした。

HTTP/2のさらに先へ。新しいプロトコルを知る – TLS 1.3とは？

白石: HTML5 Conferenceでは、さらに新しいプロトコルについてもご紹介があるとのことですね。

大津: はい、TLS 1.3やQUICについて紹介しようかと思います。

TLS 1.3というのは、1.2までの技術的負債を精算しつつ、ハンドシェイクを速くすることを目的とした仕様です。仕様はだいたい固まっていて、現在Googleをはじめとした企業が、実験的に使用して調査中です。

白石: 技術的負債を精算して、さらに速く…って、いいことづくめですね。

大津: ただ、TLS 1.3にはまだ大きな問題が残っています。後方互換性に関わる透過性の問題があって、通信できない場合があることが報告されているのです。

TLS 1.3に対応していない中間機器が、接続を無断で切断しちゃうことがあるんですよね。そういうファイアウォール、IDS（Intrusion Detection System:不正侵入検知システム）、IDP（Intrusion Prevention System:不正侵入予防システム）などが中間経路にあると、ネットワーク全体がダウンしてしまうこともあります。本来は、TLS 1.2にフォールバックしてほしいのですが…現在Googleなどが後方互換の問題を最小にするために透過性の調査を行っているところです。

白石: 通信を遮るものをどう扱うか、は難しい問題ですね。正直、簡単に解決する問題には全く聞こえませんね…

大津: そうなんですよ。少し前に、GoogleがTLS 1.3を試験的に有効化していたところ、ある学校で問題が発生し、数万台のChromebookが通信もアップデートも行えなくなってしまうということがありました。 こうなるとGoogleですらお手上げなんですよね。TLSに完全に依存しているので。

そう考えると、HTTP/2って「幸運」だったと思うんですよね。

白石: 「幸運」ですか。

大津: はい、TLS 1.2という「枯れた」プロトコル上の動作を前提にできたのがラッキーでした。TLS1.2って、2008年に登場したプロトコルで、今は完全に普及しきっていますから。

そういう前提のないプロトコルや機能拡張だと、大変なんです。

例えば、TCPのデータ送受信開始を速める「TCP Fast Open」という仕様もあるのですが、うまく通じない現象がAppleのエンジニアによって報告されていて、最近Linuxで緩和策が講じられたにもかかわらず、Microsoft Edgeではついにデフォルトで無効化されてしまいました。

TCP Fast Openは2014年に標準化されており、Linux、 macOS、 WindowsなどOSの対応も進んでいるのですが、それでもまだこういう状況です。それほど、低レイヤーのプロトコルを普及させていくのは難しい。

だから、私たちがHTTP/2の移行にあまり苦労しなかったことも含め、HTTP/2のアップグレードがこれほどスムーズなのは大変幸運なことなのです。

QUICという「プラットフォーム」の可能性

白石: QUICについても教えていただけますか？

大津: QUICは、ざっくり言うとUDPの上でTCP、TLS 1.3、そしてHTTP/2の一部をごちゃっとやる感じのプロトコルです。

白石: ごちゃっと(笑)。

大津: IETFでの標準化も進められていて、今度の10月で1年になりますね。非常に有望なプロトコルで、今後のネットワークのプラットフォームになっていくポテンシャルを秘めていると期待しています。

白石: なぜそこまで期待していらっしゃるのでしょう？

大津: 「UDPなので疎通性が良い」というのと「ユーザーランドで動作するプロトコルなのでデプロイが容易」ということが挙げられます。

先程TLS 1.3の普及には苦労しそうだ、という話をしましたが、QUICはUDPなので比較的通りやすいんです。また、通じなかった場合はTCPにフォールバックする機能もある。通信を行うコンピューター同士が、エンドツーエンドでQUICに対応していればいいのです。

ユーザーランドで動作する…というのは、TCP BBR (※) と比較するとわかりやすいと思います。

※参考: 「Google、TCPのスループットとレイテンシを改善する輻輳制御アルゴリズム「TCP BBR」をGoogle Cloudで利用開始 (Publickey)」

TCP BBRは、Googleが開発した新しい輻輳制御のアルゴリズムです。モバイル環境のように、パケットロスが非常に多い環境でも速度を最大化できるという利点があります。

しかし欠点としては、TCPのスタックってOSのカーネルに実装されているので、使おうとするとカーネルのアップデートが必要になるということです。できれば通信を行うコンピューターがどちらもTCP BBRに対応したカーネルにアップグレードしていることが望ましいのですが、OSのアップグレードサイクルを考えると、どれほど少なく見積もっても普及には数年かかるでしょう。

その点QUICはUDPの上で構築されている。プロトコルの処理はユーザーランドで行われるので、デプロイするのにOSのアップグレードなどを伴いません。プロトコルのバージョンアップも、機能追加も比較的簡単だと考えられます。将来的にHTTPだけでなくDNSやWebRTCなどでQUICが利用されることも検討されています。

白石: それが、「QUICはプラットフォームになりうる」という先程の言葉の意味ですね。

大津: はい。ただ、QUICも実際には良いことばかりではありません。「QUICを無効にしたらChromeが軽くなった」などのノウハウが最近巷に広まってきています（※）。さきほどUDPの透過性の良さについて話しましたがやはり完全に透過ではなく、これも中間経路での問題が出てきている現象だと見られています。

※参考: 「最近 Chrome が「重くなった・ひっかかる」と感じたら試してみてほしいこと (Tanweb.net)」

白石: やはり、ネットワークプロトコルのデプロイって難しいんですね…。ただ、QUICが持つ素晴らしい可能性についても、よくわかりました。

本日は、実際の大規模なHTTPS & HTTP/2への移行経験から新しいWebプロトコルのお話まで聞けて、大変勉強になりました！ どうもありがとうございました。