Lilaを読む：リアルタイム対局を支えるlichess.orgの公開サーバー

Lilaが扱うチェスサービスの範囲

Lilaは、lichess.orgの無料オンラインチェスサーバーとして、リアルタイム対局と使いやすさを中心に設計されています。READMEが挙げる機能は、対局検索、Fishnetを通じた分散コンピューター解析、トーナメント、同時対局、フォーラム、チーム、戦術トレーナー、モバイルアプリ、共有解析盤です。UIはコミュニティの協力で140以上の言語に対応すると説明されています。

ここで区別したいのは、サービスの機能説明と、リポジトリを自分で動かすことです。lichess.orgで利用できる画面と、lilaの開発環境を起動できることは同じではありません。READMEは公開ソースの一覧、Discord、GitHub Issuesへの入口を示していますが、個別機能の運用手順や本番用の構成値をすべて掲載してはいません。公開サービスの代替をすぐ作る材料ではなく、リアルタイムチェスサーバーがどの境界で分解されているかを読む対象として評価するのが適切です。

Scala 3と非同期サーバーの境界

LichessはScala 3で書かれ、変更されたPlay 2.8を利用します。テンプレートにはscalatags、純粋なチェスのロジックにはscalachessサブモジュールを使うとREADMEにあります。サーバーは完全な非同期構成で、Scala FuturesとPekko Streamsを多用します。ゲームのルール計算、HTTPリクエスト、ストリーム処理を一つの巨大な処理として扱わず、役割ごとに分けていることが読み取れます。

この説明から性能値を推測してはいけません。非同期という言葉だけでは、同時対局数、待ち時間、障害時の再接続、計算資源の上限は分かりません。コードを読む際は、対局状態の更新がどこで確定し、クライアントへどの経路で通知され、切断時にどの状態を復元するかを確認します。scalachessのルール計算とWeb側の表示を分けて検証すれば、対局の正しさと画面の同期問題を切り分けやすくなります。

WebSocket、Redis、対局状態の配信

WebSocket接続は別サーバーが担当し、Redisを通じて通信するとREADMEは説明しています。HTTPリクエストとWebSocket接続はnginxでプロキシできます。ブラウザが送る対局操作と、サーバーが参加者へ返す状態更新を同じHTTP処理に閉じず、リアルタイム通知の経路を独立させる構成です。

対局サービスで検証すべき点は、合法手の判定だけではありません。二人の操作が同時に届いた場合の順序、接続が一時的に切れた場合の再同期、観戦者への通知、Redisの一時的な遅延、プロキシ越しの接続維持を確認します。READMEはRedisと別サーバーの役割を記載していますが、再接続の閾値、メッセージ保持期間、障害復旧の手順までは示していません。実際の運用設計では、対局の確定データと一時的な通知を別に記録し、切断した利用者がどの状態へ戻れるかを定義する必要があります。

解析クラスタと大量の棋譜保存

コンピューター解析はStockfishを寄付サーバーによるAIクラスタへ配置し、fishnetを介して分散すると説明されています。ゲームデータはMongoDBへ保存し、12 billionを超えるゲームを保持し、Elasticsearchで索引化するとREADMEにあります。対局サービスと解析計算を同じ場所で処理せず、寄付された計算資源と検索用インデックスを組み合わせる構造です。

この構成では、解析要求の受付、計算の割り当て、結果の取り込み、棋譜検索を分けて評価します。解析の深さや待ち時間、寄付ノードの可用性、計算結果の再現性は、READMEの機能説明からは確定できません。大量の棋譜を扱う場合は、MongoDBのバックアップ、Elasticsearchの再構築、公開する棋譜の範囲、個人情報が記録される場合の削除方針も運用項目になります。READMEは評価基準や復旧時間を示していないため、12 billionという記述をそのまま自分の環境で再現できる容量の見積もりに使うべきではありません。

TypeScriptクライアントと多言語UI

WebクライアントはTypeScriptとsnabbdomで書かれ、SassからCSSを生成します。対局盤、解析盤、検索、フォーラムなどの画面をブラウザへ提供し、サーバー側の対局状態やWebSocket通知を利用者の操作へ反映する役割です。140以上の言語をコミュニティが支えているという説明は、翻訳の管理を実装の一部として扱っていることも示しています。

UIの動作を確認する場合は、対応ブラウザの表を基準にします。Firefoxは115以上、ChromiumまたはChromeは112以上、Edgeは111以上、Operaは97以上、Safariは16.2以上が記載され、Firefoxが推奨されています。古いブラウザは動作しないとREADMEに明記されています。バージョン表は現在の自分の端末での完全な互換性を保証するものではないため、WebSocket、音声や盤面操作、解析画面、レスポンシブ表示を対象ブラウザごとに確認する必要があります。

開発環境の入口と公開API

READMEのインストール欄は、./lila.shを実行し、sbtの薄いラッパーを通じてrunする手順を示しています。開発環境のセットアップはGitHub WikiのLichess Development Onboardingへ誘導されています。依存サービス、設定ファイル、データベース、Redis、解析ノードの準備は、READMEの短い起動例だけでは判断できません。wikiの手順を対象ブランチと照合し、開発用のデータと認証情報を分離してから起動するべきです。

Lichess APIは、アプリケーションやWebサイトで利用できるとREADMEにあります。APIの利用可能性は、自分のサービスが対局データや利用者情報をどのように取得し、保存し、表示するかを設計する必要がないという意味ではありません。呼び出し制限、利用規約、キャッシュ、利用者の同意、障害時の扱いはAPIの公式文書で確認します。自前のlilaを起動する場合も、公開サービスのAPI利用とリポジトリ内部の開発環境を混同しないことが重要です。

AGPL-3.0と採用前の検証順序

LilaはGNU Affero General Public License 3または利用者が選ぶそれ以降の版で提供され、詳細はCOPYING.mdを参照するとREADMEにあります。改変版をネットワーク経由のサービスとして提供する場合を含め、利用、改変、配布の形がライセンス条件にどう関係するかをLICENSE相当の本文で確認してください。AGPL-3.0は、対局者のアカウント情報、棋譜の権利、寄付計算資源、外部APIの規約を代わりに決めるものではありません。

自分の環境で試すなら、第一段階はブラウザとローカル起動の互換性、第二段階は合法手と対局状態の同期、第三段階はWebSocketとRedisの切断復旧、第四段階はMongoDBと検索インデックスのバックアップ、第五段階は解析ノードと公開範囲です。READMEの「Production architecture」は2022年7月時点の見出しだけで、現行の本番構成を説明する資料としては不足しています。したがって、Lilaは大規模なリアルタイムサービスの分割を学ぶ価値がある一方、READMEだけで本番移行を完了できるプロジェクトとは評価しません。

編集部の結論

Lilaは、リアルタイムのオンラインチェスを中心に、検索、コンピューター解析、トーナメント、同時対局、フォーラム、チーム、戦術トレーナー、モバイルアプリ、共有解析盤を組み合わせたlichess.orgのサーバー実装です。Scala 3、Play 2.8、Pekko Streams、Redis、MongoDB、Elasticsearchなどの役割がREADMEに明記され、公開APIと開発環境の入口もあります。自分の環境で試す場合は、wikiのセットアップ手順、対応ブラウザ、外部サービスの構成、AGPL-3.0の条件を先に確認してください。READMEの説明だけで本番性能や完全な運用手順まで判断せず、対局データと解析計算資源の範囲を明確にするのが先です。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes