Lichess Tablebaseサーバーの最適化

テーブルベースサーバーの最適化

テールレイテンシの解消

• 7駒 Syzygy テーブルベースサーバーは、RAID の整合性検査を実行している間、リクエスト処理に苦戦していた
• 新しいアプローチとして、dm-integrity を LVM で使用し、データブロックを読むたびに手動で検査する方式に変更
• 17 TiB のテーブルベースをダウンタイムなしで移行するため、2台目のサーバーを用意してベンチマークテストを実施

新しいハードウェア構成

• 32 GiB RAM
• 2 x 201 GiB NVMe（以前のサーバーには SSD 領域がなかった）
• 6 x 5.46 TiB HDD（以前のサーバーはディスクが5台のみだった）
• オペレーティングシステム: Debian bookworm

モニタリングの重要性

• RAID 5 を使用することで、単一ディスク障害からの復旧が可能になり、すべてのディスクにランダム読み取りを分散
• 初期テストでは性能は良好だったが、モニタリングによってすべてのディスクが均等に使われていないことを発見

ベンチマーク結果

• サーバーは1秒あたり 10〜35 件のリクエストを受信
• 100万件のリクエストを記録してベンチマークテストを実施
• 平均応答時間は速いが、テールレイテンシは高い
• mmap より pread のほうが優れた性能を示した

mmap と pread の比較

• mmap: ファイルをメモリにマッピングしてディスク読み取りを透過的に処理するが、エラー処理が難しい
• pread: システムコールを通じて読み取りエラーを戻り値として報告する
• pread のほうが高性能だった理由は、メモリマップされたデータブロックがページ境界をまたぐ場合、2回のディスク読み取りが発生する可能性があるため

POSIX_FADV_RANDOM の逆効果

• POSIX_FADV_RANDOM を使うと、ページキャッシュの圧力を下げるためにファイルアクセスがランダムであると OS にヒントを与えるが、実際には逆効果だった
• テーブルベースのアクセスパターンはランダムではない可能性がある

限られた SSD 領域の活用

• SSD 領域を効率的に使うため、疎ブロック長リストとブロック長リストを SSD に保存し、最大でも1回の遅いディスク読み取りで済むようにした
• RAID 1 の代わりに RAID 0 を使い、冗長性を捨てて性能を最適化

読み取りの並列化

• ユーザーインターフェースですべての手の DTZ 値を表示するため、平均的なリクエストは 23 回の WDL プローブと 70 回の DTZ プローブを発生させる
• リクエスト処理を並列化することでテールレイテンシを低減

実環境での性能

• ベンチマークシナリオでの最適化が実環境でも有効であることを確認

# GN⁺のまとめ

• この記事は Lichess のテーブルベースサーバー最適化の過程を扱っている
• テールレイテンシを減らすためのさまざまなアプローチを試し、ベンチマークテストで性能を検証している
• mmap と pread の比較、POSIX_FADV_RANDOM の逆効果、SSD 領域の活用、読み取りの並列化といったテーマを扱う
• この記事はサーバー最適化に関心のある開発者にとって有用であり、似た機能を持つプロジェクトとしては Stockfish などがある