参考資料

[1] AWS CDK×AWS FISでミニGameDayをつくろう

GameDay 開催のためのリソースの紹介。

https://jawsug-cdk.connpass.com/event/287408/

https://speakerdeck.com/yoshimi0227/aws-cdkxaws-fisdeminigamedaywotukurou

[2] New AWS GameDay Benefits Help Partners Build Cloud Skills and Engage with AWS Experts

参考[1] で引用されている。パートナー向けに開放されている GameDay 開催のためのリソースがあるらしい

https://aws.amazon.com/jp/blogs/apn/new-aws-gameday-benefits-help-partners-build-cloud-skills-and-engage-with-aws-experts/

[3] ServerlessDaysでServerlessなパフォーマンスチューニングコンテストを開催しました #ServerlessDays (Serverworks engineer blog)

過去に Serverless Days で開催されたコンテスト。ベンチマーカーが瞬間風速の計測ではなく常時稼働によるスコア計算方式。どちらかというと可用性の観点が反映された採点スタイルで、その点では ISUCON よりは GameDay に似ている。

https://blog.serverworks.co.jp/tech/2019/10/23/serverlessdays-spec-contest/

[4] 社内 GameDay をやってみた (M3 Tech Blog)

https://www.m3tech.blog/entry/2021/10/22/123000

自分が想像していたよりももっとミニマムで良いと気づけた。ISUCON も GameDay も割と回答者の自由度が高いので、お題を1点で決め打ちしても良いのだと気付いたことがよかった。また、お題そのものも実務に近そうな印象があったのも Good

hassaku63

Must

必須方針として決めていること。

AWS を使う
Lambda がアーキテクチャの中心となる作問
ビジネスメトリック（＝サービス提供）がスコアに反映されるようにしたい
パフォーマンス向上がビジネスメトリックに繋がるような設定にしたい

Better

私としてはほどよくビジネスを意識した GameDay の採点スタイルを気に入っている。これをリスペクトしたい。もっと言えば DevOps や SRE を実践するチームが見ているような指標が得点に繋がるデザインにしたい。
「サービス稼働率」や「提供コストとパフォーマンスのバランス」を考慮したものにしたい。

無尽蔵にコストかけるだけでは高得点が取れないようにしたい。しかし、それをどうやって実現するかが難しい。

コストに相当するメトリックを減点基準に採用する（実際に発生するコストか、コストの代替となりうるハックされにくい指標の取り方を見つける）
構成中の特定のサービスだけを水平スケールしてもボトルネックが改善されない＝加点に繋がらないアーキテクチャにする（そうできるなら理想的）

制約条件

自分がこの企画をやりたい根幹が ISUCON なので、それを踏まえての考慮事項を書いていく。

※といっても、おそらく自分が考えている企画の方向性はかなり GameDay に近くなりそうな気はする

(1) 使えるリソースにほぼ制限がないこと

これがどう影響するかというと、以下だと考えている

採点方法

GameDay と比べると、ISUCON の採点スタイルは瞬間風速を最大化する方針に近い。
これだと横のスケールがしやすいサーバーレスなアーキテクチャでは得点が出やすくなってしまうのではないか？競技性が成立するのかどうかが心配。

ただ、これは私が考える「サーバーレス」はそこが大前提、という先入観もあるので、むしろ水平スケールしない構成や実装をあえて初期実装として、それを直しましょうというお題はアリかもしれない。

これは DB の R/W 系のネックでもよいし、ストリームのシャーディング不足でもよいし、Failure 率が高く無駄な Redrive によりつまりがちなキューリソースでも良い。いくつかのパターンは想定できそうな気がする。

できれば、ストリームのネックが最初に映る → 飛びつくとDBがパンクする、というトラップが用意できたらいいなと思う。

「金で解決」が有効なアクションになりづらいゲームデザインにしたい

たとえば、DDB のキャパシティを「とりあえず」で最大上限に設定するような行為がスコア貢献のウェイトを占めづらいようにしたい。

サービス利用料（要するにサービス提供コスト）をスコア反映できれば良いのだが、どうやってそれを実現できるだろうか？

コスト観点なら CUR を利用するのが最も確実だと思うが、数日は待たないと競技結果が出ないのであまり現実的ではない。また、すでに存在する AWS アカウントで参戦する人を想定するなら余計にこの手は使えない。個人アカウントの機微情報をこちらは見たくないし、参加者も見せたくないはず。

ついでに言えば、数字をハックした csv を人為的にアップロードされたらそれをどうやって見抜くのかも不明。
（いっそ週またぎでマラソン開催するとか？それはそれで面白そうではあるが、多方面の参加ハードルが高そう）

採点方法だけの話ではなく、お題となるアーキテクチャのボトルネック設定や負荷の掛け方など様々な方法うで調整余地はありそうな気もしている。

外部サービスの利用制限

上記の「金で解決」ともリンクする話。

例えば Momento や Algoria の利用など。
できれば禁止の方向にしたいが、それを仕組みとして禁止できる方法は浮かばない。

とはいえ、上位者になる経済的メリットがない＝スコアをハックするモチベが生じにくい企画にするなら、いっそアリにしても良いかも知れない。その場合は上位チームに解説パート付けてもらう時間がほしい。アプローチとして紹介してもらえば利用したサービスの宣伝にもなる。

仮にこの方針を推す場合は競技自体の性質と企画のゴールが変わるので、ISUCON 的な競技とは別路線のなにかになる。

hassaku63

コストの概念を採点基準に取り込む方法

あまりいいアイデアがない。方向性はいくつかあると考えている。
いずれも偽証されにくい調達方法が課題として共通している印象。

[1] 実際の料金

第一感では、最もただしくスコアを反映する要素と考えているが採用しづらい。データが出てくるまでのライムラグが最もネック。

次点は参加者の所有アカウントを使わせる想定である場合の個人情報で、そのまま CUR を取ってくるわけには行かない

[2] なんらかの主要メトリック

たとえば以下のような数字の総和。

DDB のキャパシティ消費量
Lambda の invocation time と、その実行時における搭載メモリの積

これらが採用できるなら理想的。ただし、調達方法に課題あり。

計測対象リソースの特定方法 ... 今回の企画の性質上使えるリソースは種類も量も制限を付けない。どうやって参加者自身が追加／削除したリソースをベンチマーク側から特定するのか？
偽証防止 ... 参加者が追加したリソースをベンチマーク側に認識させないことでコストのスコアをハックできてしまう。どうすれば防止できるか？
妥当な計測対象は？ ... どのサービスのどのメトリックを対象にするのか。基本的に使うサービスはある程度決まってくるお題にするつもりだが、制限は付けないので Lambda 以外の決め打ちはしづらい。
計測方法 ... 対象とするサービスによって都合は違いそうな気はするが。基本は Lambda の上に仕込むことになると考えている。計測対象として認識さえできているなら Extension を強制することで実行時間や外部サービスの呼び出しなどは計測できそう。DDB に関しては IO 関連のメトリックも取りたいがこちらは CloudWatch とか X-Ray 使う感じになりそう。ただこっちも計測対象特定の問題がある

[3] サービス提供できたことを示すなんらかの実績値

リクエストへの応答数の総和や、応答率あたり。

コストの概念を表現できてないので却下。とはいえサービス志向な観点が点数になるようにしたいので、これはこれでスコアの構成要素に入れたい。

hassaku63

企画名

ISUCON は商標なので基本的に使えないものとして考える。コミュニティで開催する分には問題なさそうではあるが、企画やる際にタイトルなり説明欄なりに ISUCON の名前に言及するなら商標の表示などの使い方のガイドライン遵守が必要なので注意

https://isucon.net/archives/54831921.html

Serverless の名前は入れたい、AWS 前提になるのでそれも入るなら入れたい

AWS Serverless Quest (ASQ) とか、The Day of Cloudy Serverless のようなネーミングを考えている。
前者は AWS の公式感がちょっとあるのでもうちょいマイナー感の出る単語でかつ頭文字で語呂良く読めるやつがほしい。後者だとちょっと大げさというかカッコつけてる感がある。あと、1日がかりのイベントを開催できるレベルになったら "Day" という表記は使いたい気もする

hassaku63

作問

自分の実務で経験してきたアプリケーションから出題するのが王道で作りやすい気はする。実際に歴代の ISUCON は出題企画してきた各社にゆかりのあるサービスがお題になるパターンが多い。

自分が割と関与してきたのは請求関係なので、そのへんからネタ出しするのが良さげ

候補 (1)

請求書の発行システム。技術要素としてポイントになりそうなのは

発行処理のバッチの高速化・並列化
- 送付時刻が遅れてクレーム＝減点
- Lambda の稼働コストに相当するものをどれだけ軽減できるか
配送トラブル（以下一例）
- メール送信の場合（バウンス、迷惑メール率。再送漏れて回収遅延の減点、とか）
- 配信用の認証付きアプリケーション or API の場合（ここまで作るとなるとやることが増えそう、散らかりそう）
外部 API の扱い
- 例えば請求データをデータソース（参加者からは介入不可能）から取得する処理、レイテンシが大きいとかスロットリングするとかの問題があるパターン