色分けやグルーピング、検索、パーマリンク(permalink)を望むならば、ブラウザに長大なログを表示するのは難しい作業になる、とGitHubのエンジニアのAlberto Gimeno氏は言う。ReactとプレーンなJSライブラリをテストした後、同社が独自開発を決めたのは、このような理由からだった。
GitHubのエンジニアたちに求められた大きな設計判断のひとつは、仮想化の選択だった。仮想化がなければ、UIが遅くなったり、応答しなくなったりするリスクが高すぎるのだ、とGimeno氏は説明する。仮想化の可能なレベルは2つある。データの仮想化とUIの仮想化だ。
UIの仮想化では、ログに属する全エントリのサブセットのみを表示して、ユーザがページをスクロールするのに従ってビューを更新する、という構成を取る。データの仮想化は、ブラウザは常に有効なデータの一部のみを保持していて、他は必要に応じてフェッチするという、もっと複雑なアプローチだ。
最初の実装で、GitHubのエンジニアたちは、まずReactベースのライブラリを、次にプレーンなJavaScriptライブラリをテストしたが、どちらも結果は好ましくなかった。特にReactベースのライブラリは、GitHubにとって重要である、長いログ行を処理するために行の高さを可変にする機能がサポートされていなかった。一方のプレーンなJavaScriptによるソリューションは、必要な機能をすべて備えているという点では適切だったが、ユーザエクスペリエンスの面で十分なパフォーマンスを提供することができなかった。いくつかのHacker New上のコメントで述べられていたように、最初の実装でのログビューはほとんど非実用的なものだった。特にログページのスクロールと情報検索については、まともに動作していなかった。
これらの理由から、GitHubのエンジニアたちは、スクラッチからログエクスペリエンスを再実装した上で、使用状況のデータを活用してそれを改良していく方法を選択することにした。
当社のデータによると、既存ジョブの99.51パーセントが50,000行未満なのですが、これまでの経験から、20,000ログ行を越えるとブラウザに問題が生じすることは分かっていました。さらに、ログの行数が少なくても、非常に大きなメモリ空間を占有する可能性があることも分かりました。これらすべての情報に基いて、データ仮想化は不要だがUIの仮想化は必要である、という判断をしたのです。
ログ表示に関する要件には、最低でも50,000行の表示(モバイル環境を含む)、制限のないテキスト選択が可能であること、メモリ使用量の削減、そして当然ながら、ログリストの検索やジャンプにおいてもスムーズな動作が可能であること、などがあげられていた。
GitHubの新たな実装において重要なファクタのひとつは、レンダリングされるノード数を減らすようなDOM構造にすることで、スクロール中のDOMの変化量を少なくすることだった。スクロール中に変化するDOMが多すぎると、特にモバイル環境では負の影響を与えることになる、とGimeno氏は言う。
最終的にたどり着いたアイデアは、ログ行をクラスタにグループ化する、というものでした。ログを1行単位で削除したり追加するのではなく、N行をひとつのクラスタとして、クラスタ単位で削除や追加を行うのです。何度かテストした結果、クラスタの行数をいくつにすればよいかが分かりました — クラスタあたり50行です。
最初の実装をものにするまでに1週間、プロダクション品質に達するまでにさらに数週間を必要とした。このアプローチによってGitHubは、ログUIのパフォーマンスを完全にコントロールできるようになった、とGimeno氏は強調する。
本記事の執筆時点では、このライブラリはオープンソースとして公開されておらず、GitHubから将来的にオープンソース化される予定かどうかの発表もされていない。さらなる情報が入手できれば、この記事を更新する予定である。