Skip to content

Latest commit

 

History

History
341 lines (208 loc) · 16 KB

MANUAL.md

File metadata and controls

341 lines (208 loc) · 16 KB
Raw

ISUCON9 本戦マニュアル

はじめに

スケジュール

  • 10:00 競技開始
  • 18:00 競技終了
  • 以後主催者により結果チェックと追試

ISUCON9 本戦 ポータルサイト

本戦進行は以下のポータルからベンチマーク走行のリクエスト・結果チェックを行って進行します。事前に登録したGitHubアカウントを用いてログインしてください。

ポータルは競技終了時間になると即座に閲覧不可能になります。ご注意ください。

https://portal.isucon.net/contest/

ポータルサイトでは、ベンチマーカーが負荷をかける対象となるサーバーを1台選ぶことができます。 後述する競技後の追試でもこの設定を利用します。

予選の時と同様にサーバの追加と削除ができますが、絶対に追加と削除の操作はしないでください。

追試が実行できない場合は失格になるので、競技終了までに正しいサーバが選択されていることを必ず確認してください。

ポータルサイトでは、ベンチマーク走行の処理状況も確認できます。 ベンチマーク走行が待機中もしくは実行中の間はリクエストは追加できません。

サーバー、ネットワーク構成について

セットアップ済みのAlibaba Cloud上のサーバーインスタンス(ECS)を提供します。インスタンスは3台提供されます。

［重要］競技終了後は、ベンチマーク走行成績の追試を行いますので、シャットダウンしないでくださ

［重要］競技に利用できる計算機資源は主催者側が用意した3台のインスタンスのみです。外部のメトリクス計測サービスの使用のみ特例として許可しますが、スコアを向上させるいかなる効果も持つものであってはいけません。

作業開始

以下の順序で作業を開始してください。

1. サーバへのログイン

ポータルに記載のチームIDとチームパスワードを利用しサーバにSSHでログインします。

ホスト名は teamチームID-[abc].isucon9.hinatan.net です。

ユーザー名は isucon、パスワードはチームパスワードです。

( ex: ssh [email protected] )

サーバーには本戦終了後の主催者による追試のため、 admin ユーザーのアカウントがあります。

［重要］admin ユーザーのアカウントに関して、アカウントの削除や既存の公開鍵の削除を行ったことにより主催者による追試をおこなうことができない場合は、失格とします。

2. アプリケーションの動作確認

初期状態ではWebサーバーのグローバルIPアドレスに、ブラウザからアクセスするとアプリが表示されます。

( ex: https://team999-a.isucon9.hinatan.net )

GET / へアクセスすることで、トップページにアクセスすることができます。 画面の「ユーザー登録」から、ユーザを作成することができます。

3. 負荷走行

ベンチマーク走行を行う際はポータルサイト上からリクエストします。 リクエストの際には対象となるサーバーの設定が必要です。

ポータルサイト上のServersタブにアクセスして、ベンチマーク走行を実行したいサーバーをベンチマークの対象として設定を保存してください。

ポータルサイト上のDashboardタブにアクセスして、Enqueueをクリックすると、ベンチマーク走行リクエストがキューイングされ、主催者が用意したベンチマークサーバーにより順次処理されます。

詳細については後述します。

参照実装の切り替え方法

初期状態ではGoによる実装が起動している状態になります。

各言語実装は systemd で管理されています。 例えば、参照実装をGoからPythonに切り替えるには次のようにします。

$ sudo systemctl stop    isutrain-go
$ sudo systemctl disable isutrain-go
$ sudo systemctl start   isutrain-python
$ sudo systemctl enable  isutrain-python

リカバリ方法

DB(isutrain)を初期状態にもどすには、次のコマンドを実行します。

sudo systemctl stop isutrain-go
sudo docker rm webapp_mysql_1
sudo docker volume rm webapp_mysql
sudo systemctl start isutrain-go

決済代行サービスAPIの利用について

アプリケーションを開発・確認する際に、利用可能なPayment Serviceを用意しています。

ベンチマークと共用のため、ベンチマーク中にはアクセスしないようにしてください。

APIの仕様は 決済代行サービスAPI仕様書 を参照してください。

ISUXPRESS予約について

ストーリー

2020年に向けて日本を横断する超高速鉄道が建設されました。

  • 2020年1月1日開業
  • 乗車券購入を今日の18時から開始したい

アプリケーションの仕様について

詳しくは ウェブアプリケーション仕様書 も参照してください。

乗車券の予約について以下の機能を持っています

  • 乗車券の予約と購入
    • 指定した日時以降に出発する列車の検索
    • 座席指定をした指定席の予約
    • 座席指定をしない指定席の予約は仮予約時にアプリケーション側で指定される (あいまい予約)
    • 自由席チケットの購入
    • 決済は外部の決済代行サービスによるクレジットカード決済のみ
  • 予約一覧の確認と予約詳細の確認
  • 予約のキャンセル

ルール詳細

指定された競技用サーバーインスタンス上のアプリケーションのチューニングを行い、それに対するベンチマーク走行のスコアで競技を行います。 利用が認められた競技用サーバーのみでアプリケーションの動作が可能であれば、禁止事項に該当しない限り、どのような変更を加えても構いません。

各サーバにおけるソフトウェアの入れ替え、設定の変更、アプリケーションコードの変更および入れ替えなどは一切禁止しません。 ベンチマーク中に利用が認められたサーバー以外の外部リソースを使用する行為(他のインスタンスに処理を委譲するなど) は禁止します。 ただしモニタリングやテスト、開発などは、PCや外部のサーバーを利用しても構いません。

許可される事項には、例として以下のような作業が含まれます。

  • 複数台あるサーバーの役割の変更
  • DBスキーマの変更やインデックスの作成・削除
  • データベースに利用するミドルウェアの変更
  • キャッシュ機構の追加、ジョブキュー機構の追加による遅延書き込み
  • 他の言語による再実装

ただし以下の事項に留意してください。

  • コンテスト進行用のメンテナンスコマンドが正常に動作するよう互換性を保つこと
  • サーバ再起動後にすべてのアプリケーションコードが正常動作する状態を維持すること
  • ベンチマーク実行時にアプリケーションに書き込まれたデータは再起動後にも取得できること

また、初期実装は言語毎に若干の挙動の違いはありますが、ベンチマーカーに影響のない挙動に関しては仕様とします。 ベンチマーカーとブラウザの挙動に差異がある場合、ベンチマーカーの挙動を正とします。

座席の予約フロー

ISUXPRESS予約では以下の操作により座席の予約を行います。

  • 列車検索 ( /api/train/search )
  • 座席指定する場合は座席選択 ( /api/train/seats )
  • 仮予約 ( /api/train/reserve )
  • 支払い ( /api/train/reservation/commit )

座席は仮予約されたタイミングで確保されます。この時点から同じ列車・座席の予約はでき無くなります。

ベンチマーク走行

ベンチマーク走行は以下のように実施されます。

  1. 初期化処理の実行 POST /initialize（20秒以内）
  2. アプリケーション正常動作チェックの実行 （適宜: 数秒〜数十秒）
  3. 負荷走行（60秒）
  4. 負荷走行後の確認（適宜: 数秒〜数十秒）

各ステップで失敗が見付かった場合にはその時点で停止します。 アプリケーションに、本来想定される挙動と異なる挙動が見られた場合には、その負荷走行において失格判定とします ただし、負荷走行中のエラーについては、タイムアウトや500エラーを含む幾つかのエラーについては無視され、ベンチマーク走行が継続します。

また負荷走行が60秒行われた後、レスポンスが返ってきていないリクエストはすべて強制的に切断されます。 その際にnginxのアクセスログにステータスコード499が記録されることがありますが、これらのリクエストについては減点の対象外です。

60秒間の負荷走行ののちに、5秒以上待ってから、整合性チェックを行います。 このタイミングまでに、外部決済サービスのキャンセルなど処理の整合性をとってください。

スコア計算

スコア計算では、アプリケーションが提供する各エンドポイントから算出されるスコアと、アプリケーションとして評価できるチューニングポイントに付与されるボーナススコアが用いられます

スコアは レスポンスが正常であったリクエスト数 をベースに以下の計算式で計算されます。

エンドポイント毎の点数 * 成功リクエスト数 + ボーナス点 - 減点 = スコア

エンドポイント毎の点数

  • /api/auth/signup 1点
  • /api/auth/login 1点
  • /api/auth/logout 1点
  • /api/stations 1点
  • /api/train/search 3点
  • /api/train/seats 3点
  • /api/train/reserve 5点
  • /api/train/reservation/commit 1点
  • /api/user/reservations/:item_id/cancel 1点
  • /api/user/reservations 1点
  • /api/user/reservations/:item_id 1点

ボーナス点数

仮予約が成功すると10点が加算されます。

あいまい予約において、座席が隣り合わせになると以下の条件でさらに加算されます。

  • 2席隣り合う場合 10点
  • 3席隣り合う場合 15点
  • 4席隣り合う場合 20点
  • 5席隣り合う場合 25点

失格と減点

以下の条件のエラーが発生すると、失格・減点の対象となります。

  • 致命的なエラー
    • 1回以上で失格
    • メッセージの最後に (critical error) が付与されます
  • HTTPステータスコードやレスポンスの内容などに誤りがある
    • 1回で5点減点
    • 1000回で失格
  • 一定時間内にレスポンスが返却されない・タイムアウト
    • 1回毎に5点減点
    • 失格にはならない

HTTPステータスコードは、基本的に参照実装と同一のものを想定しています。またベンチマーカーのメッセージは同一のメッセージを1つにまとめます。表示されているメッセージの数とエラー数は一致しないことがあります。

制約事項

以下の事項に抵触すると失格(fail)となり、点数が0点になります。

  • 静的ファイルの内容の変更
  • POST /initialize へのレスポンスを20秒以内に返さない場合
  • アプリケーション互換性チェックに失敗した場合
    • 同一座席の二重発券などの重要なエラー
  • その他、ベンチマーカーのチェッカが失敗を検出したケース

最初に呼ばれる初期化処理 POST /initialize は用意された環境内で、チェッカツールが要求する範囲の整合性を担保します。 サーバーサイドで処理の変更・データ構造の変更などを行う場合、この処理が行っている内容を漏れなく提供してください。

本戦終了後に行われる主催者による確認作業（追試）において下記の点が満たされていることを確認できなかった場合は失格となります。

  • アプリケーションは全て保存データを永続化する必要があります
    • 処理実施後に再起動が行われた場合、再起動前に行われた処理内容が再起動後に保存されている必要があります
  • アプリケーションはブラウザ上での表示を初期状態と同様に保つ必要があります
    • 列車検索の結果件数が10件未満の場合も失格とします
  • パスワードの保存方法が変更されていないこと
  • OSのメモリサイズが提供時と同じ状態であること

予約可能期間の設定

POST /initialize のレスポンスにて、2020年1月1日からの「予約可能な日数」を返すことができます。 この期間を長くすることで多くのユーザーが予約に訪れます。

POST /initialize のレスポンスは JSON 形式で

{
    "available_days": 10,
    "language": "golang"
}

available_days が予約可能な日数になります。10日から366日までが指定できます。

予約可能な日数を広げるほど多くの予約リクエストが来るようになります。

また、ちなみに、languageの値は実装に利用した言語となります。languageが空の場合はベンチマーカーは失敗と見なされます。

リーダーボードの更新について

ポータルサイト上のリーダーボードのスコアは、競技終了前の1時間は表示は更新されなくなり、自チームのスコアのみ確認が可能になります。

特別賞

競技時間中のスコアが、最初に 15000 を超えた1チームを特別賞とします

最終スコア

最終スコアは、競技時間終了後、再起動後に主催者によって実行した最初のスコアを採用する。

本戦終了後に主催者によって行う作業手順

  1. 全チームのサーバーを再起動し、10分以上待つ
  2. 全チームのベンチマークを管理者用のポータルからエンキューし計測
  3. 2での結果がfailとなったチームのサーバーを再起動
  4. 3の対称となったチームのベンチマークを2同様にポータルからエンキューし計測
  5. 全チームのサーバーを再起動し、データ永続化チェック、画面表示の確認を行う
    ここで確認ができなかったチームは失格とする
  6. 5をパスしたチームの中からポータル上でのスコアを最終順位と決定する

本選終了後の注意事項

本選終了後は、サーバーに対して一切の操作を行わないでください。

禁止事項

  • 他チームの競技用サーバや、決済代行サービスAPIにアクセスすること
  • 競技時間中に出題内容に関するあらゆる事項(問題内容・計測ツールの計測方法など)を公開・共有すること
    • ただし主催者が公開している情報は除く
  • 主催者が他チームへの妨害とみなす全ての行為

既知の問題

  • 初期実装は遅すぎてスコアが出ません。
  • 初期実装ではロック機構がうまくなく、二重発券される場合がある可能性があります

その他

ベンチマークサーバやレギュレーションは、主催者は競技者に周知したうえで一時停止や変更を行うことがあります。

サポートは事前に連絡のあった discord のチャンネルにて行いますが、基本的に、本選環境の構成・操作方法やベンチマーカーの処理内容については返答しません。