Skip to content

Latest commit

 

History

History
77 lines (58 loc) · 6.96 KB

02_Regulation.md

File metadata and controls

77 lines (58 loc) · 6.96 KB

レギュレーション

禁止事項

以下の行為は禁止されています。違反した場合、減点、0点、または失格となる場合があります。

  • 極端な最適化: API 動作テストは通るが、実際の業務アプリケーションとして機能しなくなるような最適化は NG です。
    • 例: 無意味にデータを削除して高速化するなど。
  • 初期データの欠損: 顧客データを消して高速化することは禁止です。顧客データは API を通して引き続き利用可能でなければなりません。
    • 画像については、アプリケーション内で様々なリサイズをされて利用されることを考慮してください。
  • UI の大幅な変更: ユーザインターフェースが明らかに変わるような仕様変更は禁止です。
  • 環境の制約事項の悪用: 以下の「環境の制約事項」を利用して不当にスコアを上げる行為は禁止です。
  • 他リソースの利用: 提供された環境以外のリソースを利用して処理能力を上げることは禁止です。
    • 例: 個人 PC でリクエスト処理を代替するなど。
  • 採点モジュールの改ざん: 採点モジュールを改ざんしたり、不具合を悪用して不当にスコアを上げる行為は禁止です。
  • 他チームの妨害: 他チームの環境にログインしたり、コードを変更したり、DOS 攻撃を行うことは禁止です。
  • 他チームとの結託: 他チームの環境にログインする、リポジトリを見るなどのカンニング行為は禁止です。
  • 主催者が不適切と判断した行為: その他、主催者側が不適切と判断した行為は禁止です。

競技中及び競技環境に関する注意

  • 競技環境の HDD 容量は潤沢ではありません。不要なリソースは削除してください。
  • リポジトリのディレクトリ構成を変えないでください。スクリプトが動作しなくなる場合があります。
    • 個別のサービス(backend 配下など)の構成については自由に変更可能です。
  • /.da領域は変更しないでください。動作しなくなる場合があります。また、中身の持ち出しも禁止です。
  • OS をシャットダウンすると、SSH ログインができなくなります。復旧には時間がかかりますので注意してください。
  • Azure 障害により競技環境が一時的に使用できなくなった場合でも、課題提出締め切りの延長はありません。
  • OS を書き換えるなどして競技環境が破損し、環境再構築が必要になった場合も、課題提出締め切りの延長はありません。

環境の制約事項

競技主催者側の都合上、やむを得ず現実的なシナリオと乖離している箇所があります。これを利用しても業務アプリケーションの改善とは言い難いため、あらかじめ共有します。

  • アプリケーションユーザのプロフィール画像に使用している添付ファイルは同じ内容を使い回しています。
    • HDD 容量制限のため、同じファイルが参照されることがありますが、同一ユーザのプロフィール画像を除いて全て別の添付ファイルであるものとして扱ってください。
  • API テストは、一部のテスト用のユーザ情報を利用して実施されます。
    • ユーザの識別はアクセス状況から容易にわかりますが、この情報を使って API テストだけ PASS する最適化はレギュレーション違反とします。

レギュレーション・制限

チューニングについて

  • チューニング対象になるのは、webapp ディレクトリに配置してあるアプリケーションになります。
    • frontend 配下のコードはチューニングの対象外となります
  • 負荷試験のシナリオをローカルで変更したい場合などは、benchmarker 配下に実装します。ローカルの負荷試験を変更しても、実際の採点に用いられる負荷試験には影響しません。

業務背景によるレギュレーション

  • グラフは複数のエリアに分けられ、それらの頂点数・辺数は異なっています。
  • ディスパッチャーは自身の対応エリアの依頼にしか対応できません。
  • 対応する依頼の優先度は、以下の通りとします。
    1. ステータスが対応待ち(statuspending)であること
    2. 依頼日時が最も古いこと
    3. 依頼の ID が最も小さいこと
  • 依頼に対しては、その依頼の頂点から(その時点で)最短距離にいる対応可能(statusavailable)なレッカー車を割り当ててください。
    • 条件を満たすレッカー車が複数存在する場合には、レッカー車の ID が最も小さいものを割り当ててください。
  • アプリケーションの稼働中にも、レッカー車の現在位置(頂点)が変わる可能性があります。
  • アプリケーションの稼働中にも、辺の重みが変わる可能性があります。
  • 一台のレッカー車は一度に一件の依頼しか担当できません。
    • つまり、同じタイミングで同一のレッカー車への依頼が発生した場合、そのレッカー車は一件の依頼にしか対応できず、その他のリクエストは失敗に終わります。

アプリケーションに関するレギュレーション

  • /register, /login, /logout, /user_image 以外のエンドポイントへは、セッショントークンによる認証が必要となります。
    • HTTP リクエストの Authorization ヘッダに、ログイン時に取得したセッショントークンを付与してください。
      • 例:"Authorization": "xxxxxx"
  • ユーザの認証に用いられるパスワードは、セキュリティの観点からハッシュ化を行っています。ハッシュ化のアルゴリズムは様々な方法が存在しますが、今回は参考として OWASP の公開している推奨のハッシュアルゴリズム のうちのひとつを利用するものとします。デフォルトでは、Argon2 によるハッシュ化を行っています。 (参考:OWASP Cheat Sheet Series https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
    • パスワードを平文(やそれに近い形)で、メモリ上に保存することは禁止とします。

制限事項・注意

  • APIのエンドポイントやペイロード・レスポンスの型を変更してはいけません。

トップ