- 10:00: 競技開始
- 17:00: リーダーボードの更新停止
- 18:00: 競技終了
- 20:00: 結果発表(予定)
ISURIDEの仕様についてはISURIDE アプリケーションマニュアルを参照してください。
ISUCON14の競技では下記のウェブサイトを利用します。事前に登録した情報を用いてログインしてください。 なお、このページは競技開始時刻までアクセスすることはできません。
https://portal.isucon.net/contestant
ポータルでは、負荷走行(ベンチマーク)の実行/結果確認、質問/サポート依頼の送信、リーダーボードの確認ができます。
ポータル上のリーダーボードは、競技終了1時間前に他チームの情報が更新されなくなり、自チームの情報のみ更新されるようになります。
ISUCON14のDiscordサーバーは競技中ならびにその前後の時間はすべてのチャンネルが発言不可となります。競技時間中はポータルを通して質問/サポート依頼を送信することができますので、そちらを利用してください。
ただし、競技参加者(以下「選手」といいます)は競技時間中もDiscordの確認が可能な状態、通知が受け取れる状態を維持してください。 これは主催者が選手とリアルタイムでのチャットが必要だと判断した場合、主催者がDiscord上でプライベートチャンネルを作成しメンションの上、呼びかけを行う場合があるためです。呼びかけに応じない場合、競技に支障をきたす可能性があるため、必ず応答可能な状態を維持してください。
また、主催者からのアナウンス等もDiscordで実施されます。
選手は主催者へ質問を送信することができます。質問は競技内容・マニュアル・レギュレーション等に対する疑問点の確認や、サーバー障害などのトラブル報告・サポート依頼に利用することができますが、これに限りません。
競技時間中の質問について、主催者からの回答は全選手へ公開、あるいは個別に回答されます。 全選手へ公開される場合、質問内容の原文、あるいは主催者による内容の要約が公開されます。 未回答の質問・未公開の回答については質問した選手およびそのチームメンバー、主催者のみが確認できます。 質問への回答・更新はポータル上にて選手およびそのチームへ通知されます。
主催者は競技時間中の質問への回答を、原則として全選手へ公開します。 ただし、重複する質問や、選手およびチーム個別の問題に対する対応の場合、この限りではありません。
送信された質問に対する回答が、競技性に影響を与えるものと主催者が判断する場合、回答できない旨を返答することがあります。
下記はサポート対象外となります。
- AWS及びAWSクーポンに関する質問/サポート依頼
競技に参加するにあたり、各チームが用意したAWSアカウントで競技環境を下記の手順に従って構築してください。
まず、環境構築にはAWS CloudFormationを利用するため、チームはポータルのサーバーリストからAWS CloudFormationのテンプレートをダウンロードします。 テンプレートはチームごとに固有のものとなっているため共有厳禁です。
このテンプレートでは以下のリソースを作成します。
- EC2サーバー(c5.large)x 3
- EBS(gp3 20GB)x 3
- EIP x 3
- VPC x 1
- VPCサブネットx 1
- VPCルートテーブルx 1
- インターネットゲートウェイx 1
- セキュリティグループx 1
- Availability Zone情報取得に利用するLambda関数x 1
- IAMロールx 2
- EC2インスタンスプロファイルx 1
テンプレートから作成されるIAMロールは、EC2サーバーおよびLambda関数で上記リソースの情報取得を行うために利用します。 許可されているアクションはAWSの仕様上、アカウントに存在する他のリソースの情報も閲覧できる設定になっていますが、主催者は不要な情報の取得は行いません。
- AWSマネジメントコンソールのCloudFormationを開き、ページ右上に表示されている リージョン名がアジアパシフィック(東京)(ap-northeast-1) になっていることを確認します。
- 「スタックの作成」をクリックします。 既存のスタックがある場合は「スタックの作成」から「新しいリソースを使用(標準)」を選択します。
- 「ステップ1 - スタックの作成」では、「前提条件 - テンプレートの準備」で「既存のテンプレートを選択」、「テンプレートの指定」で「テンプレートファイルのアップロード」を選択し、上記でダウンロードしたテンプレートファイルのアップロードを行い「次へ」をクリックします。
- 「ステップ2 - スタックの詳細を指定」では、任意のスタック名 (例:
isucon14
) を設定し、「次へ」をクリックします。 - 「ステップ3 - スタックオプションの設定」では、変更を行わず「次へ」をクリックします。
- 「ステップ4 - 確認して作成」では、ページ最下部「スタックの作成」ボタンの上に表示されている「AWS CloudFormationによってIAMリソースが作成される場合があることを承認します」にチェックを入れた上で、「スタックの作成」をクリックします。
- 作成したスタックの状態が
CREATE_COMPLETE
(作成完了)になるまで待機します。(数分かかります)
上記はAWSマネジメントコンソールが「日本語」の場合の手順です。他の言語の場合も同様の手順に従ってください。
スタックの作成完了後、数分程度でSSH接続できるようになります。サーバーには選手がGitHubに登録しているSSH鍵を利用して、ユーザー名isucon
でSSH接続ができます。
サーバーのIPアドレスはポータルか、AWSマネジメントコンソールのEC2サーバーページから確認できます。
また、AWSマネジメントコンソールからEC2 Instance Connectを使用して接続することもできます。
EC2 Instance Connectを使用する場合、ユーザー名は isucon
としてください。
サーバー起動後にポータルのサーバーリストに表示されない場合は、EC2 Instance Connectでログインして競技環境の確認を実行し、問題が無いか確認してください。
ISURIDEには、WebブラウザからHTTPSでアクセスできます。 初期状態では、アクセス時のホスト名を元にルーティングする設定となっているため、下記の通りhostsファイルを編集しhttps://isuride.xiv.isucon.netにアクセスしてください。
MacやLinuxは /etc/hosts
に、 Windowsは C:\Windows\System32\drivers\etc\hosts
に以下の行を追記します。
${サーバーのIPアドレス}
は、ポータルのサーバーリストから確認できるパブリックIPアドレスに読み替えてください。
${サーバーのIPアドレス} isuride.xiv.isucon.net
上記変更の反映にはブラウザの再起動が必要な場合があります。
- 競技終了後は主催者からアナウンスがあるまで競技環境のシャットダウンや停止などは行わず、3台とも起動した状態を維持してください。
- 競技時間中の再起動や一時的な停止に関しては問題ありません。ただし、競技終了時に全てのサーバーが起動した状態でないと、追試が実施できず失格となりますので十分ご注意ください。
- 競技に利用できる計算機資源は主催者が公開したCloudFormationテンプレートの内容に沿って起動されたEC2インスタンスのみです。
- 例えば、テンプレートで作成されたリソースを、その内容に沿わなくなる変更(例:インスタンスタイプの変更)を行った状態で、競技に利用すると失格となります。
- 競技終了時点で競技環境の確認に失敗する状態の場合、失格となります。
- 競技終了時点でポータルのサーバーリストに複数環境(スタック)が混在している場合、失格となります。
- レギュレーションに記載した通り、モニタリングやテスト、開発において外部の資源を用いても構いませんが(例:メトリクス計測サービス)、スコアを向上させる効果を持つものは認められません。これは前述している複数環境の利用も含みます。
- 競技終了後は、主催者が追試を行います。Discordサーバーおよびhttps://isucon.netにて主催者がアナウンスをするまで、競技環境への接続や操作はしないでください。
- 競技終了後、別途アナウンスがあるまでの作業や操作(削除を含む)は失格となります。なお、アナウンスは結果発表後の予定です。
- 競技環境の削除は、各チームで行う必要があります。削除を行わなかったために発生した不利益について、主催者は一切の責任を負いません。削除を行ってよいタイミングについても、結果発表後にアナウンスを行う予定です。
選手が競技を進めるにあたって新たなポート解放が必要な場合、セキュリティグループの変更を行なっても構いません。
ただし、SSH(TCP/22)、HTTPS(TCP/443)については競技に影響があるため変更しないでください。
上記セキュリティグループの変更により、追試が実施できない場合は失格となりますのでご注意ください。
下記は追試に利用するため、変更した場合は失格となります。
envcheck.service
に関わるファイル/etc/systemd/system/envcheck.service
/etc/systemd/system/multi-user.target.wants/envcheck.service
/opt/isucon-env-checker
内のファイル、バイナリファイル
isuadmin
ユーザーに関わるファイル・権限およびログイン情報- その他、主催者による追試を妨げる変更(例: サーバー上の
isucon
以外のユーザーに関する、ユーザー削除や既存の公開鍵の削除、サーバーの再起動の妨害)
サーバー起動(再起動を含む)時に競技環境が主催者の指定した環境で構築されているかを確認(envcheck)し、サーバーのIPアドレスを含む競技環境の情報をポータルに送信する処理が実行されます。
送信された競技環境の情報を元に、ポータルのサーバーリストの情報(サーバーIPアドレス等)を更新します。なお、これはサーバー単位で更新されます。
この処理はサーバー起動時以外に、以下のコマンドで選手自ら行うことができます。
$ sudo /opt/isucon-env-checker/envcheck
競技環境に主催者の指定と異なる設定がある場合、エラーメッセージが表示されます(競技環境の確認の失敗)。 エラーメッセージを確認し、修正を行ってください。
なお、追試において競技環境の確認に失敗した場合、失格となります。 本項に記載の方法に従って、競技環境の確認を行うことをお勧めします。
選手自らが操作により競技環境への接続性を失った場合など、競技環境を初期状態に戻す必要がある場合は上記競技環境の構築と接続を参考に、AWS CloudFormationで新たに競技環境の構築を行ってください。 再構築以前の競技環境上で変更を加えたソースコードや設定ファイル等の移行は、各チームの責任で行ってください。
なお、サーバーインスタンスの起動・停止・再起動はAWSマネジメントコンソールやAPIから選手が行っても構いません。 ただし、競技終了時に全てのサーバーが起動した状態でないと、追試が実施できず失格となりますので十分ご注意ください。
複数スタックの問題を回避するため、再構築作業の完了後は以前のAWS CloudFormationスタックを削除することをおすすめします。
ポータルからダウンロードしたテンプレートを利用してAWS CloudFormationスタックを複数作成しても構いません。ただし、以下の点に留意してください。
競技環境の確認に記載の通り、サーバー情報の更新はサーバー単位、かつサーバーインスタンスが起動(再起動を含む)するたびに実施されます。 そのため、複数のスタックで作成されたサーバーが同時に存在している時、選手の操作によっては、ポータルのサーバーリストに複数のスタックのサーバー情報が混在してしまう可能性があります。 混在しているかの判断はポータルとスタックのリソースに表示されているIPアドレスを元に行ってください。
競技時間中は混在した状態になっていても問題ありませんが、競技終了時点でポータル上のサーバー情報が混在していた場合は失格となりますのでご注意ください。
主催者はポータルに登録された環境以外のサポートや、複数スタックが混在した状態でのサポートは行いません。
下記の言語での実装が提供されています。
- Go
- Node.js
- Perl
- PHP
- Python
- Ruby
- Rust
初期状態ではGoによる実装が起動しています。
各言語実装はsystemdで実行・管理されています。 リファレンス実装をGoから他の言語に切り替えるには以下の手順を実行します。
sudo systemctl stop isuride-go.service
sudo systemctl disable isuride-go.service
以下のコマンドでstopとdisableを同時に行うことができます。
sudo systemctl disable --now isuride-go.service
sudo systemctl start isuride-{言語名}.service
sudo systemctl enable isuride-{言語名}.service
{言語名}
には以下の言語名を指定してください。
言語 | {言語名} |
---|---|
Go | go |
Node.js | node |
Perl | perl |
PHP | php |
Python | python |
Ruby | ruby |
Rust | rust |
以下のコマンドでstartとenableを同時に行うことができます。
sudo systemctl enable --now isuride-{言語名}.service
ただし、PHPのリファレンス実装を使う場合のみ、systemdの設定変更の他に、次のようなnginxの設定変更が必要です。
sudo ln -s /etc/nginx/sites-available/isuride-php.conf /etc/nginx/sites-enabled/
sudo systemctl restart nginx.service
リファレンス実装ではデータベースとしてMySQLを利用しています。
リファレンス実装のMySQLに管理者権限で接続するには以下のようにします。
sudo mysql isuride
リファレンス実装では、初期化処理(POST /api/initialize
)においてデータベースのデータをベンチマーカーが想定している状態に戻します。
以下のコマンドでもデータベースのデータを初期化できます。
~/webapp/sql/init.sh
初期状態において、初期化処理はベンチマーカーが要求する範囲の整合性を担保します。 競技に伴って処理の変更やデータ構造の変更などを行う場合、初期化処理が行っている内容を漏れなく提供してください。
isuride
データベースのスキーマはリファレンス実装に含まれています。
SQLファイル | 内容 |
---|---|
webapp/sql/0-init.sql |
データベースおよびユーザーの作成 |
webapp/sql/1-schema.sql |
各種テーブルの作成 |
webapp/sql/2-master-data.sql |
マスターデータの作成 |
webapp/sql/3-initial-data.sql.gz |
初期データ |
isuride
データベースを初期化するにはデータベースをDROP DATABASE isuride
およびCREATE DATABASE isuride
で再作成し、以下のコマンドでテーブルの作成を行ったのち、データの初期化を行なってください。
cat webapp/sql/1-schema.sql | sudo mysql isuride
サーバーには *.xiv.isucon.net
のTLS証明書が設定されています。
このホスト名でHTTPS接続を行うとTLS証明書の検証エラーは発生しません。ベンチマーカーはこれを期待します。
ベンチマーカーによる負荷走行はポータル上からリクエストできます。
ポータルにアクセスし、「Job Enqueue Form」から負荷走行対象のサーバーを選択した後、「Enqueue」をクリックすることで、選択したサーバーに向けての負荷走行がリクエストされます。リクエストされた負荷走行は順次実行されます。
負荷走行が待機中(WAITING
)もしくは実行中(RUNNING
)の間は新しい負荷走行をリクエストできません。
ベンチマーカーによる負荷走行は以下のように実施されます。
- 初期化処理の実行
POST /api/initialize
(30秒でタイムアウト)POST /api/owner/owners
(複数回実行。各リクエストは10秒、処理全体は20秒でタイムアウト)POST /api/chair/chairs
(複数回実行。各リクエストは10秒、処理全体は20秒でタイムアウト)POST /api/user/users
(複数回実行。各リクエストは10秒、処理全体は20秒でタイムアウト)
- アプリケーション整合性チェック(数秒~数十秒)
- 負荷テスト(60秒)
- 最終チェック(数秒~数十秒)
初期化処理もしくはアプリケーション整合性チェックに失敗すると、負荷走行は即時失敗(FAIL)になります。
負荷テスト終了時点でHTTPレスポンスの処理を打ち切ります。未完了のリクエストなどは強制的に切断されます。負荷テスト終了以降に強制的に切断されたリクエストはスコア、検証には影響しません。
負荷テスト終了時点で行われていた決済処理は負荷テスト終了後5秒以内に完了する必要があります。5秒以内に完了しなかった場合、ベンチマーカーの期待する決済金額と一致せずFAILになります。
ベンチマーカーからのリクエストのタイムアウトはそれぞれ以下のように設定されています。
リクエスト | タイムアウト |
---|---|
POST /api/initialize |
30秒 |
GET /api/app/notification |
60秒 |
GET /api/chair/notification |
60秒 |
それ以外のリクエスト | 10秒 |
ベンチマーカーによる負荷走行は以下の状況で打ち切られます。 打ち切られた場合はその負荷走行はFAILとして記録されます。
- 初期化処理の実行中にエラーが発生する
- 負荷走行の実行中にクリティカルエラーが発生する
- 負荷走行の実行中に200件以上のワーニングが発生する
- アプリケーション整合性チェックの実行中にエラーが発生する
負荷走行中のクリティカルエラーは以下の種類があります。
- ユーザーが想定していない通知を受け取りました
- 椅子が想定していない通知を受け取りました
- ユーザーに想定していないライドの状態遷移の通知がありました
- 椅子に想定していないライドの状態遷移の通知がありました
- 椅子がライドの完了通知を受け取る前に、別の新しいライドの通知を受け取りました
- ライドが長時間マッチングされませんでした
- ユーザーのライド評価がタイムアウトしました
- 評価は完了しているが、支払いが行われていないライドが存在します
- 決済サーバーに誤った支払いがリクエストされました
POST /api/chair/coordinate
の反映GET /api/app/nearby-chairs
で返される椅子の座標は、過去3秒以内にPOST /api/chair/coordinate
で送信された座標に一致する必要があります。GET /api/owner/chairs
で返される椅子の移動距離合計に反映されるまでに3秒の猶予が許容されます。
- ライド
POST /api/app/rides
の反映- 要求されたライドが、椅子とマッチされた後、ユーザーと椅子に通知されるまでに30秒の猶予が許容されます。
以下に示す要素の合計がスコアとなります。
椅子がライドとマッチした位置から乗車位置までの移動距離の合計 * 0.1
椅子の乗車位置から目的地までの移動距離の合計
ライド完了数 * 5
競技中に最後に行った負荷走行の結果を、最終スコアとします。 最後に行った負荷走行がFAILしている場合や、追試において失格となったチームについては、最終スコアがないものとして、受賞の対象となりません。
最終スコアが上位の3チームに賞を授与します。
- 優勝(1位)
- 準優勝(2位)
- 3位
学生チームのうち最終スコアが上位の2チームに学生賞を授与します。
- 学生1位
- 学生2位
競技中にスコアが一番最初に32,767点を超えた1チームに特別賞を授与します。
各企業賞は、最終スコアが上位の30チームのうち、さらに下記条件を満たすチームに授与します。
- ポケットサインRSA賞
- 最終スコアが2つの素数の積で表されるチームのうち、最も大きいスコアの1チーム
- FORCIAらすと賞
- Rust以外の言語を使用し、最も最終スコアが低かった1チーム
- 未来につながる火を灯すで賞 by FLINTERS
- 最終スコアに7が一番多い1チーム
- はてな賞
- 最終スコアの末尾4桁の点数が8107(はてな)に最も近い1チーム
- Cygames賞
- 最後の1時間でランキングが隠れた後、スコアが最も上がった1チーム(「最終スコア」から「競技終了1時間前までの最大スコア」を減じた数字が一番大きいチーム)
- いい生活賞
- 最終スコアが11位の1チーム
- MIXI賞
- 最終スコアが25位の1チーム
- エブリー賞
- 最終スコアが9位の1チーム
- また会いま賞 by LINEヤフー
- 最終スコアが30位の1チーム
POST /api/initialize
のレスポンスで出力された言語情報を元に、Go/PHP/Python/Rubyで参加したチームのうち最終スコアが上位のチームに言語賞を授与します。
確認のため、該当チームにソースコードの提出を求める可能性があります。
- Go言語賞 by さくらインターネット
- Goで参加したチームのうち最終スコアが上位の3チーム
- PHP言語賞 by CySphere
- PHPで参加したチームのうち最終スコアが上位の1チーム
- Python言語賞 by mento
- Pythonで参加したチームのうち最終スコアが上位の3チーム
- Ruby言語賞 by エムスリー
- Rubyで参加したチームのうち最終スコアが上位の3チーム
受賞の対象となるためには、競技中に最後に行った負荷走行の POST /api/initialize
レスポンスのJSONの language
フィールドに実装に利用した言語が出力されている必要があります。
言語賞の対象言語と判定される language
の条件は下記の通りです。この設定は、リファレンス実装に含まれています。
言語 | language フィールド |
---|---|
Go | go |
PHP | php |
Python | python |
Ruby | ruby |
競技終了後、主催者による確認作業(追試)を行います。 追試は下記の手順で実施され、失格した場合は最終スコアがないものとして扱います。
- 競技サーバー3台全てを再起動します
- 何らかの理由で再起動できない場合、失格となります
- 競技中に選手の判断でサーバーを停止することは認められていますが、競技終了時点で停止したままのサーバーがある場合、再起動できず失格となるため、十分ご注意ください
- 何らかの理由で再起動できない場合、失格となります
- 再起動後、競技環境が主催者の指定した環境で構築されているかを確認(競技環境の確認)します
- 競技環境の確認に失敗した場合、失格となります
- 最終スコアが記録されたインスタンスをターゲットにして、負荷走行を行います
- 負荷走行の結果、結果がFAILもしくは最終スコアの75%以下の場合、負荷走行を再実行し、再度判定します
- 2回目の再実行(最初の負荷走行を含めて3回目)でFAILもしくは最終スコアの75%以下の場合、失格となります
- 競技サーバー3台全てを再起動します
- この時点においても、何らかの理由で再起動できない場合、失格となります
- 負荷走行実行時にアプリケーションに書き込まれたデータが、再起動後に取得できるかどうかを確認します
- データが取得できない場合、失格となります
- アプリフロントエンドにアクセスし、表示を確認します
- アクセスができない場合や、構造がリファレンス実装と異なる、意図しないデータが表示されている場合、失格となります
以下の行為を特に禁止とします。
- 競技終了時間までに、競技の内容に関するあらゆる事項(問題内容・計測ツールの計測方法など)を公開・共有すること(内容を推察できる発言も含みます)
- 不特定多数への公開はもちろん、他チームの選手と連絡を取り、問題内容等を共有する事(結託行為)も禁止とします
- ただし主催者がX(旧Twitter)、Webサイトにおいて公開している情報は除きます。ポータルでログインを要するページ(ISUCON14のDiscordサーバーを含みます)において記載されている内容は公開情報でない旨にご留意ください
- 競技時間中、チーム外の人物とISUCON14の問題にまつわる事項のやりとり(ISUCON14選手かどうかを問いません。SNSでの発言も含みます。)
- 主催者の指示以外で利用が認められたサーバー以外の外部リソースを使用する行為(他のサーバーに処理を委譲するなど)
- モニタリングやテスト、開発などにおいては、PCや外部のサーバーを利用しても構いません
- AIによるコード分析やコード生成を利用しても構いません
- デプロイのために外部のコンテナレジストリ(Amazon ECRなど)を利用することは構いません。ただし、競技終了まで他のチームに対して公開されないように注意してください
- 主催者からその選手が属するチームへ提供されていないサーバーに直接のアクセスを試みる行為や、外部への不正アクセスを試みる行為
- 具体的にはベンチマーカーへのログイン試行等が該当します。なお、左記は例示のため、これに限りません。
- 他チームと結託する行為(程度を問いません)
- 主催者が他チームへの妨害、競技への支障となるとみなす全ての行為
本マニュアルやレギュレーション、ポータルにおいて禁止とされた行為(禁止事項)への違反は、失格とします。
また、競技環境の確認に記載されている通り、追試において競技環境の確認に失敗した場合にも、失格となります。 記載の方法に従って、環境情報の確認を行うことをお勧めします。