実行環境を揃えたDocker Imageを言語ごとに用意して使い分ける
ここでスピーカーが小西氏に交代し、Trackの大まかなシステム構成の説明を始めた。Trackは、「Track Application」「Contents Server」「Command Execution Server」「Scoring Server」の4種類のモジュールで成り立っている。このうち、ユーザーが目にするにはTrack Application。「Editor」というモジュールを内蔵しており、それがほかのモジュールと連携して、コンテンツを表示している。さらに、Command Execution Serverと連携して、ユーザーが入力したコードの実行結果を表示する。
Contents Serverは、コンテンツの供給と登録、そしてバージョン管理を受け持っている。登録したコンテンツは一度作って終わりとはいかず、何度もバージョンアップを繰り返すことになる。「誤字脱字などはすぐに修正できるが、問題文を修正するときは、受講者に有利不利が発生することがあるので、すぐには修正できないことがある。そこがContents Serverの難しいところ」（小西氏）
Command Execution Serverは、受検者が作成したファイル・セットと受検者が指示した実行コマンドを受け取って、その標準出力と標準エラー出力をWebSocketで返している。Trackでは現在、20近いプログラミング言語に対応しているが、それぞれの言語のコンパイル、実行環境として、言語ごとにDocker Imageを用意して使い分けている。
アルゴリズム問題で計算量の多い問題を多くの受検者に出題すると、計算量の多いプログラムを受検者全員が実行する。その結果、Command Execution Serverの計算能力が追いつかず、スケール・アウトで対応しなければならないのだ。問題の計算量を見積もって、どれくらいのサーバーを配分するかを決めるときに悩むことが多いという。
Scoring Serverは、ユーザーが提出したコードを採点し、得点を決定する。テスト・コードの実行はCommand Execution Serverが担当するが、その結果の解釈、採点はScoring Serverが受け持つ。
ユーザーがコードを保存するたびに、Scoring Serverに採点依頼がやって来て、そのたびにScoring Serverはテストを複数回実行する。その理由は、成功するはずのテストが失敗することがあるからだ。これは実際の開発現場でも起こることだそうだ。
失敗する理由としては、「npm install」のような通信を伴うコマンドが失敗する、Command Execution Serverが何らかの理由で不調に陥ってテストが動かない、計算量が多い問題では実行を指示しても制限時間内に完了しないなどが挙げられる。
