おはようございます。エンジニアの japlj です。作曲 (DTM) をしています。

去る 2019 年 1 月に、新人エンジニア主催でISUCONに機械学習の要素を取り入れた新しいタイプのコンテスト “PIGICON” を開催したことはみなさまご存じだと思います (つい先程まで PIGICON の存在を知らなかったという方もたった今リンク先の記事によって PIGICON を知ったことになり、認知度は 100% であることが明らかになっています)。

PIGICON 紹介記事にもあるように、PIGICON では短期間に多数の採点を行ったにもかかわらず運営の実装起因でのエラーは一度もなく、採点ごとのスコアも非常に安定していました。本記事では、PIGICON の安定性を支えたコンテストシステムの構成と、その一翼を担ったベンチマークツールについて紹介します。

コンテストシステムの特徴

まず最初に、コンテストシステムの特徴的な点を挙げると:

• 参加者にはチームごとに AWS EC2 インスタンスが一台与えられ、そこに API サーバを実装する
• ポータルサイト (Web アプリ) は AWS ECS 上で稼働させる
• ベンチマークツールは AWS Batch 上で稼働させる

特に、ポータルサイトとベンチマークツールを完全に切り離したことがコンテストシステムの安定性と利便性に大きく寄与しました。

採点ジョブの管理・実行を Batch に一任することでポータル側でのジョブ管理の負担を軽減し、かつ複数回の採点でスコアのぶれが出にくい安定したベンチマークを行うことができました。

また、参加者が「どうもうまくサーバが応答できていないな」と感じた場合など、自由なタイミングで採点を中断できるようになっています。こういった便利な機能も Batch のジョブをキャンセルするだけで実現できるので、Batch の採用は非常に良かったと感じています。

これらのインフラ (EC2, ECR, ECS, Batch など) の構成を Terraform で、参加者に与える EC2 インスタンスに参考実装や ssh の公開鍵を設置するセットアップ方法を Ansible で、それぞれコード化することで保守性や再利用性を高めています。その上で、実際の AWS 環境への適用は CI ツールである drone に行わせるようにすることで、インフラ周辺まで含めて高速に開発を進めることができました。

コンテストシステムの構成

コンテストシステムの全体構成は上図のようになっており、矢印で示された順にしたがって採点が行われます:

1. 参加者が与えられたインスタンス上に API サーバを立ち上げる
2. ポータル上で採点開始ボタンを押す
3. DB に採点ジョブの情報を登録
4. Batch ジョブを投入する。このとき Docker コンテナに環境変数で各種情報 (ジョブ固有のトークンや、ベンチマーク対象のサーバの IP アドレス、評価に用いるデータセットの指定など) を渡す
5. ベンチマークツールが立ち上がり、環境変数で指定されたデータセットを S3 からダウンロード
6. 同じく環境変数で指定された IP アドレスに対してベンチマークを実行しながら、採点状況 (途中経過など) を随時ポータル側に通知する
7. ベンチマークが終了するとポータル側にベンチ結果を通知
8. DB 上の採点ジョブの情報を更新
9. ポータルに採点結果を表示

ポータルとベンチマークツールが分離されているので、ベンチマークツールが必要な情報はすべて環境変数で受け取れるようになっています。

また、ベンチマークツール側からは指定された URL に対し HTTP で採点の進捗情報や結果などを通知します。これにより、採点の途中経過がリアルタイムにポータル側で表示されます。この機能は採点の進捗 (上手く動いているかどうか) が分かりやすく、また処理速度が目に見えて分かる点で非常に好評でした。ビジュアル面についての詳細は、実際の画面の様子を含めたポータルサイト編の解説記事 (同期の辣腕 Web エンジニアによる渾身の記事) で紹介される予定ですので、ご期待ください。

ベンチマークツールの特徴

ベンチマークツールは Scala で実装されており、Akka HTTP を使って実際のリクエスト/レスポンスのやりとりを行っています。

こちらもいくつかの特徴的な点を挙げると:

• Batch で動かすために Docker コンテナ化されており、種々の情報を環境変数で指定する
• データセットの変更に柔軟に対応できるよう、リクエスト/レスポンスの生成・処理部分が具体的なデータのスキーマに依存しない
• 高速かつ安定したベンチマークのため、ホストレベルの API でコネクションプールを用いることで常に一定数のやりとりが同時に行われるようにしている

多くの情報を環境変数で外部から指定できるようにしたことと、ベンチマーク処理をデータセットに出来るだけ依存しない形で設計したことで、データセットを差し替えて同様のコンテストがすぐに開催できるようになっています。(もちろん、実際にはスコア計算のバランス調整などが必要になりますが、ベンチマークツールやポータルなどのシステムにはほとんど手を加える必要がありません)

まとめ・感想

ポータル (Web アプリ) を ECS、ベンチマークツールを Batch で動かすことで、非常に安定したコンテストシステムを構築することができました。ポータルとベンチマークツールがうまく分離されていたことで、それぞれ別メンバーが中心となって効率よく開発を進めることができました。こういったシステムの設計は初めての経験でしたが、開発面でも成果物の面でも上手くいったと思います。

広告

RCO アドテク部では、何らかを募集しています。(続きは Web で)