LinkedInは、EspressoデータベースをHTTP/1.1からHTTP/2に移行することで、接続数、待ち時間、ガベージコレクション時間を削減し、性能と拡張性を劇的に向上させた。これらを改善するために、チームはNettyのデフォルトHTTP/2スタックを最適化し、ニーズに合わせる必要があった。
LinkedInは、MySQL上に構築されたドキュメントプラットフォームであるEspressoを使用して、多くのデータを保存・提供している。LinkedInのプラットフォームが有機的に成長するにつれてデータ量は増加しており、同社はEspressoクラスタのフットプリントを常に拡大し、Espressoに集中型キャッシュレイヤーを導入したり、サービス間通信にProtocol Buffersを採用するといった最適化に取り組まざるを得ない。
Espressoのハイレベルアーキテクチャ（出典：LinkedIn Engineering Blog）
Espressoのトランザクションスタックは、ルーターとストレージノードという2つの主要コンポーネントで構成されている。ルーターはリクエストを適切なストレージノードに転送する役割を担い、MySQLクラスタとのやり取りとデータフォーマットの適切な適合を担当する。これらのコンポーネント間の通信にはHTTPプロトコルと、より具体的にはNettyフレームワークが使用されている。チームは、Espressoクラスタが時間とともに大きくなるにつれて、拡張性が徐々に低下していくのを観察してきた。
最近では、ルーターノードを100台追加した結果、ストレージノードのメモリ使用量が増加し、ガベージコレクションの追加によりレイテンシが15%増加した。さらに、多数のHTTP/1.1コネクションにコネクション・プーリングが適用されるため、コネクション取得にかかる時間は数ミリ秒（95パーセンタイルで15ミリ秒）になることもある。最後に、スイッチのアップグレードのようなネットワーキングのイベント中に、何千ものコネクションを再確立すると、ストレージノードのコネクション制限に当たってエラーが生じる可能性がある。
LinkedInのソフトウェアエンジニアスタッフであるAbhishek Andhavarapu氏は、HTTP/1.1とHTTP/2の違いと、それらがEspressoプラットフォームの性能と拡張性にどのような影響を与えるかを説明している。
ルーターとストレージレイヤー間の通信において、私たちの以前のアプローチでは、ウェブサーバーとクライアント間のやり取りで広く採用されているプロトコルであるHTTP/1.1を利用していた。しかし、HTTP/1.1はリクエストごとの接続で動作する。大規模クラスタの場合、このアプローチではルーターとストレージノード間で数百万もの同時接続が発生する。その結果、拡張性、回復力、および性能に関連する数多くのハードルに制約が生じることになった。
チームはHTTP/2への移行中も、Nettyフレームワークを使い続けることに決めたが、すぐにそのままでは満足のいくパフォーマンスが得られないことがわかった（HTTP/1.1の実装よりもスループットが45%低く、レイテンシは約60%高い）ためエンジニアはHTTP/2スタックのボトルネックを調査し、対処する必要があった。調査の結果、コネクションの獲得とリクエストの処理、そしてリクエストのエンコード/デコードという2つの改善点を特定した。
開発者は、関連するクラスをフォークすることで、いくつかのNettyの内部実装の詳細を補強した。リクエストごとに新しい処理パイプラインを作成しないように、既存のチャンネルを再利用するハンドラの実装を作成した。また、カスタムEventLoopGroup実装を導入し、ワーカースレッド間の接続をより均等にバランスさせた。コネクション取得時のコンテキストスイッチングを減らすため、チームはコネクションプールの実装を見直し、高性能でスレッドセーフなキューを採用した。
さらに、JNIベースのネイティブSSLエンジンを使用することで、SSL処理が最適化され、カスタムSSL初期化ロジックにより、長いDNSルックアップ遅延を回避できるようになった。最後に、チームはHTTP/2リクエストをHTTP/1.1リクエストとしてカプセル化するカスタムコーデックを作成し、Espressoが使用する多くのカスタムHTTPヘッダーに対応できるようにするとともに、HPACKヘッダー圧縮を無効にすることで、エンコード/デコードのパフォーマンスを最適化した。
HTTP/2移行後の待ち時間の短縮（出典：LinkedIn Engineering Blog）
チームは、これらすべてのカスタマイズの後、HTTP/2への移行により、HTTP/1.1と比較して、TCP接続数を88％削減、待ち時間を65～75％削減、ガベージコレクション時間を75～81％削減、接続取得までの待ち時間を11msから0.02msに短縮（99％改善）するなど、大幅な改善が見られたと報告した。