pixivのHTTP/2有効化の軌跡

@catatsuyです。普段はpixivの技術的な改善や広告周りを見ています。今回はHTTP/2の話を紹介します。

HTTPS化とHTTP/2について

以前紹介したようにpixivは2017/4/18にHTTPS化を完了していました。

昨今ブラウザで使える新しい技術はHTTPSが必須要件とされることが多くなりました。その中の代表格がHTTP/2です。HTTP/2自体はHTTPSを要求していませんが、実際にはHTTPSでなければブラウザ側で有効にならないため必須です。 HTTP/2に対応するメリットは他の詳しい記事を参照して欲しいですが、ざっくり以下のメリットがあります。

HPACKという仕様でハフマン符号を使ったHTTPヘッダーの圧縮ができる
1コネクションで複数のリクエストとレスポンスを並列に扱うことができる
リクエストされる前にレスポンスを返すサーバプッシュという仕様があり、うまく使うとユーザーの待ち時間を短くできる

これらのメリットがあり、しかも最近はWebサーバー側の実装も進んだため、新しいバージョンにして設定で有効にするだけでHTTP/2が使えるようになるケースがほとんどです。HTTPS化したらとりあえず有効にしたいと考える人がほとんどでしょう。

しかしpixivの場合は1年以上HTTP/2を有効にしてきませんでした。今回は今まで有効にできなかった事情と有効にした話を紹介します。

HTTP/2のコネクション再利用の仕様について

これからドンドン使われていくSNIについて – catatsuy – Medium

個人のブログでも紹介しましたが、ここでも紹介します。

HTTP/2 のコネクション再利用について確認してみる - ブログのしゅーくりーむ

この記事で紹介されているように、HTTP/2ではコネクションを極力再利用して、高速に通信を行おうとします。その証明書を使用して通信できるか次第で、コネクションが再利用できるかどうかの判断を行い、コネクションを再利用する実装をしてもよい(MAY)ということになっています。

RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)

RFC 7540の9.1.1節によると、TLSを使わず、名前解決の結果同じIPアドレスだった場合はコネクションを使い回していいと書かれています。TLSを使っている場合には、同じ証明書で通信が行えるならコネクションを使い回していいと書かれていて、名前解決については触れられていません。 TLSなしのHTTP/2通信を実装している主要ブラウザは存在しないため、このTLSを使わない場合の話は無視してよいです。そうなると同じ証明書で通信が行えるなら名前解決の結果を確認せずに通信を行ってもよいということになります。実際に2017年の時点で確認した限り、Firefoxは同じ証明書で通信が行えるならDNSに登録されているかどうかを確認せずに通信を開始することが分かっています。

例えばnginxの場合、設定がないホスト名でリクエストが来た場合default_serverの設定が動きます。正しく設定していれば呼ばれないはずなので、あまり気にすることがない設定かもしれませんが、もし設定が存在しないホスト名でリクエストが来た場合はここの設定が動くためユーザーの期待しない挙動をしてしまいます。

これを防ぎたい場合は、RFC 7540の9.1.2節に書かれているステータスコード421を返すと解決できます。nginxならばdefault_serverの設定でステータスコード421を返すようにすればよいです。しかしこの対応にも問題はあります。折角HTTP/2にしたのにコネクションを使い回せず、コネクションを張り直すようになるので、パフォーマンスが悪化する恐れがあります。そのため私は421が大量に発生しうる構成ならば、そもそもHTTP/2は有効にしない方がよいと考えています。

pixivでのHTTP/2有効化への障壁

pixivは*.pixiv.netのワイルドカード証明書を保有しており、その証明書を使って様々なサービスを提供しています。pixivではサービスだけでなく画像や静的ファイルの配信にもこれまで使用していました。

画像サーバーの場合は、オリジナルサーバーにリクエストが極力行かないように前段でキャッシュを入れたくなります。そうなるとメモリーも必要ですし、キャッシュヒット率を考えれば投入も慎重にならざるを得ません。以上の理由から、画像サーバーのフロントサーバーは普通のアプリケーションサーバーのフロントサーバーとは性質が異なります。同じサーバーでレスポンスを返すようにするのは現実的ではありません。

またpixivの場合、現在は新宿・白河データセンターの2拠点で運用されています。新宿・白河間の通信を大量に発生させるわけにはいかないので、アプリケーションサーバーと同じ拠点にフロントサーバーを置く構成が社内では一般的です。そのため新宿にも白河にもアプリケーションのフロントサーバーが存在しています。例えば新宿のサーバーへのコネクションを使い回して、白河のサーバーから配信したいドメインのリクエストが来てしまうと当然正しく動きません。

これらの事情によりpixivではHTTP/2をこれまで有効にしてきませんでした。

有効化のためにやったこと

HTTP/2を有効にするために、静的ファイル・画像ファイルの配信で.pixiv.netのドメインを使用している箇所をなくしました。嬉しい副作用として、ユーザーが無駄なCookieをリクエストに付与する問題も解決することができました。

有効にして

今のところ特にトラブルは起こっていません。サーバーグラフでは以下の変化が現れました。

CPU使用率が低下
- SSLハンドシェイクの回数が減ったことが大きいと考えています
メモリ使用量が増加
- 保持する必要があるコネクションが増加したことが大きいと考えています
帯域使用量（特にin）が減少
- HPACKによるもの

このようにサーバーのグラフからは基本的にユーザー側に嬉しい変化が見て取れます。

CPU使用率

メモリ使用率

帯域使用量

しかしパケットロスが多い環境ではHTTP/2の方が遅いことがあるそうです。日本国内ではほとんど問題ないと思いますが、中国や東南アジアのようにパケットロスが日常的に発生している環境もあります。そのため環境によってはHTTP/2有効化は必ずしも嬉しくないかもしれませんが、pixivのように多くのURLにリクエストするサービスでは、コネクション再利用の恩恵が大きくユーザー体験向上に繋がると考えています。

HTTP/2の真の効果を得るにはまだ遠い

上記の通りHTTP/2化による効果が現れましたが、HTTP/2の本当の効果を享受するためにはまだまだやることは山積みです。

別サービスである https://comic.pixiv.net/ や https://sketch.pixiv.net/ に対してCORSなリクエストをpixiv内から飛ばすと421が返る恐れがある
- 将来的には共通のフロントサーバーから返すようにしたいが、今回は許容
静的ファイルの配信を別ドメインにしたのでHTTP/2の機能であるプッシュが使えない
- 将来的には静的ファイルの配信はプッシュできるように同じドメイン上で配信したいが、HTTP/2有効化のために完全に別のドメインで提供
- 今回の構成はHTTP/2有効化のための一時的な構成

引き続きの課題として取り組んでいきます。