  |
はてなキーワード: ISUCONとは
場所はあんまりいうとバレるから関東近郊のDCを借りて、酒と食べ物買って飲み食いしながら夜はめちゃくちゃに障害復旧するっていう催し。
こういういわゆる障パを主催している幹事に誘われて初めて参加した。
インシデントバー（インシデントばっかり発生する）とか少しだけ行ったことあって、技術的好奇心があったから参加した。
リビングで適当に酒飲んだりご飯食べてたら、いきなりKubernetesをオンプレに展開したいとか唐突に言い出して、障害パーティーがスタートした。
適当に近くの運用担当とペアになってどんどん運用部屋（ISMSで規定されている）に吸い込まれていく。
1回1時間弱くらいで手順を確認して、コンソールからコマンド打って、復旧確認して休憩して、また近くのダブルチェック担当と障害復旧しに行く。
部屋中に溢れる指さし確認の声がうるさくて眠たくならない。
これまで、無理に安全側に倒す方ではなかったけど、転職イベントとかで口説かれたりして転職するかしないかという駆け引きのコミュニケーションばかりしていた。
この回転寿司のように障害復旧を繰り返す姿はスポーツのような動物園に来たような気がした。
正直、全然酒に酔えなくて全く楽しめなかった。全然技術的達成感を感じなかった
幹事には楽しかったからまた誘ってとか社交辞令を言ったけど、多分もう障害パーティーはいかないだろうな。
ISUCONみたいな絡みが好きみたいな感じで、ああいう作業だけしてる場はある意味人間の動物的な本質なのかもしれないが理解できなかった。
金払ってまで障害復旧はしたくはねーな。
ISUCON 9 参加記 - kyuridenamidaのブログ
ISUCON9 レギュレーション違反の対応について [追記あり] : ISUCON公式Blog
「パスワードを平文で保存すること禁止する」というレギュレーションに対して、「パスワード+#」が違反したと見なされたのが最初の見解。
ここでいう「平文」が出てくる文脈は、初期実装のbcryptからも明らかなように暗号理論の文脈だと考えられる。ここに疑念を挟む人はまずいないだろう。
そして暗号理論の文脈で言う「平文」とは明確な定義があり、今回で言えば「パスワード文字列そのもの」だ。
これは学問的には異論の余地がないので、このことを知らなかった人や、どっちもどっち論に立っていた人は、素直にごめんなさいすべきだ。
たとえば以下のツイート主が主張するような「原理的に元に戻せるのは全部平文」なんて定義は暗号理論では受け入れられていない。複合可能なら全部平文なの？
どこまでが平文って、そりゃ原理的に元に戻せるのは全部平文でしょ。Base64で保存してたパスワードが流出しました！でも平文じゃないから安全です！とでもいうのかよ(´･_･`)いやまじで。— Hideyuki Tanaka (@tanakh) September 11, 2019
もう話はここで終わってもいいのだが、まだまだ論点があるので続ける。
この立場に立っている人も結構いるように見かけたが、レギュレーションからそれが読み取れないので無理がある。
第一に、レギュレーションでは暗号強度に関して全く触れられていない。
第二に、OKな暗号強度の線引きがあるのならベンチマークでチェックすべきだ。
特に後者は今回（自分の知る限り）誰も言っていなかった気がするが、セキュリティの側面も持たせるのなら仕組みで担保しなきゃダメだろう。
運営側が想定していたレギュレーションが、平文よりも高い暗号強度での保持であったとしても、そのことが明確にわかる文章になっていないので、レギュレーション文言の実装バグとしか言いようがない。
実はこの立場で運営を擁護していた人が一番多かった気がしてしまうのだが、見事にハシゴを外されてドンマイとしか言いようがない。
たとえば有名人だとこの人とか。
平文保存がルールに抵触したかどうかは全く興味ないけど、「パスワードの末尾に#つけてから保存してたから平文じゃないです」っていうのは言い訳としては成り立たないよね。ウェブアプリケーション開発者・運用者として、仮にパスワードデータベースが流出したとして、顧客にそう言えるの？っていう— Kazuho Oku (@kazuho) September 11, 2019
残念ながらISUCON運営公式の言説として、平文とまではいかなくても暗号強度を犠牲にすることは想定内であったことがアナウンスされている。
bcryptによる負荷の対処方法として、サーバを追加、軽量なハッシュ関数での代替、あるいは平文での保持を開発チームにおいて想定しましたが、現実の問題として、パスワードなどの情報流出などの事件が発生しており、平文での格納は一般的に推奨されない実装方法だという認識を同時に持ちました。
ウェブアプリケーション開発者として、みたいなことを大上段に出されても、ISUCONは現実のウェブサービスであれば許容できないようなハックを用いてでも高速化するコンテストである、という文脈は、それこそ過去のISUCONで確立されてきたものなわけで、ISUCONを知らないのなら黙っといたほうがいい、としか言いようがない。
なお実サービスでは当然やらないことをやるのはどうよ、みたいな話を持ち出すと、今回おそらく運営の脳内レギュレーションではMD5あたりもOKだったのでは、という辺りを考え出すと、やはりどこがラインなのか明確じゃないよねって話に結局なる。（2019年にMD5を許す実サービスは流石にないよね？）
そこを明確にしたいなら文章化（脳内レギュレーションの実装）をがんばるか、ベンチマークなどで担保するしかなかったという結論は変わらない。
それが出来ないなら何でもありになるのは当然の帰結だし、それを美学だとかプライドだとか個々人の価値観が大きく異なる概念で縛ろうとするのは、こと競技に関しては真摯な姿勢ではない。
（たとえば大相撲のような競技でも、横綱が変化しちゃダメという美学に関して喧々諤々な議論が起きたりする）
王道はこれ。
脳内レギュレーションを明文化できていなかった、という反省を踏まえて次がんばるしかない。
今回は他チームから問い合わせがあったらしいが「平文」の定義をきちんと調べさえすれば、想定していた回答ではないが「パスワード+#」は平文ではないので今回のレギュレーション違反には当たらない、という結論を伝えるべきだったように思う。
現実的な落とし所はこっちだったかもしれない。おそらく該当チームも、これなら反発はしなかったんじゃないか。
ということで騒ぎは終わりにしたい、という気持ちに関しては多くの人の一致を見るはずだ。
一方で運営側の朝令暮改のような対応に不信感や疑問を持つ人が多いのも事実だと思う。
ボランティアでがんばってるんだから目を瞑ろう、という感情的な意見もまあ分かる。お疲れ様だ。
またこれは個人的な見解だが、特に今回の予選問題は過去最高傑作と言っても過言ではないくらいよく出来ていると思うし、流通額をスコアとするビジネス上の目的を意識させるというメッセージ性も素晴らしいと思うので、今回の一件を持って問題作扱いされてほしくない気持ちは正直ある。
でもきちんと総括しないで先に進んでも誰も幸せにならないのもまた事実だと思う。
ということで、運営側はレギュレーション文言がバグっていたことをちゃんと認めて、該当チームに落ち度が全く無かったことを謝罪した上で、次に進んでほしい。
競技中に質問に答えなかったこと、参戦後のブログを根拠に裁定をくだしたことも悪手だと思うが、それ以上に、「レギュレーション違反はなかった」ことをきちんと伝えて名誉回復してあげるのが一番の筋のはずだ。
いきなり自分と比較して自分の方が大変だから甘えるな的な発言してるし、
あんまりにも「大変だから何も言うな」的な意見が多いので、「あ？年1回しかやってねえコンテストだろうが！？こっちとどっちのが大変だと思ってるんじゃ！？」っていいたくなってきたｗ— chokudai(高橋 直大)🌸🍆🍡 (@chokudai) 2019年9月11日
ダメなところをダメって言うのは大切だけど、良いところを良いって言うのも大切なので、そこは忘れないように。
ISUCONは大会コンセプト自体がめちゃめちゃ良いので、良い感じに発展してほしいわけですよ。
（成熟したところで、ビジネス化して開催回数を増やすのがAtCoderのお仕事かなーと思ってます— chokudai(高橋 直大)🌸🍆🍡 (@chokudai) 2019年9月11日
まずはそれでスタープレイヤーになる夢をみんなにもってもらい、野球選手になりたい子供のようにプロのITプレイヤーになりたいとか思う子を増やす
試合は何かしらのコンペとし、期間は3日〜2週間程度とする（案件によって違う）
テーマにそったハッカソンや、ISUCONみたいのや、リプレイス案件とする
その期間、チームは外出禁止の泊まり込み作業とする（作業の外部持ち出し禁止）
泊まり込みのため、1週間やったら次の1週間はメンバーは休みを義務付けられる
1日目にコンペ概要発表があり、PMはそれを資料に落とし込み、その枠内でアーキテクチャ、プログラマ、デザイナ、テスタなどをアサイン調整し、決定後交代不可
1週間常に見てる余裕がある一般社会人もいないので、毎日定時にPMは作業進捗報告を義務とする
最終日に、コンペでどちらが選ばれたかを含め、その他の定量的評価で勝敗を決める
例えば、コンペ選択 10点、メンバが残業しなかったボーナス 10点、スピード納品 日数x5点、資料充実度、テスト充実度、不具合チェック など
狙いとしては、競技として巨人戦のようにみんながテレビやニュースで見るようになれば、
どういう発注がよくて、どういうPMがよくて、設計のよさ、プログラマ・デザイナはどういうことが求められていて、それに応えていくか、
の選球眼というか、まわりの目を育てられるといいなあ
