【品川区】
コンビニ交付障害の対応について
5月18日【木】6:30〜23:00まで
利用出来ません。
#マイナンバーカード
#コンビニ交付停止

— 松永よしひろ 立憲民主党 品川区政担当 (@Matsunaga_1127) May 16, 2023

これ根本原因がなおってないんだから、負荷テストなんて意味ないだろ・・・。 twitter.com/Matsunaga_1127…

— sky (@NtSkymura) May 17, 2023

時刻のみを処理キーしてるなこれ。キーに店舗コード持つだけで回避できる事象じゃん…。
APサーバとDBサーバの同一構成（それもどうなんだ）で事象起きないのも、要求を１つずつ受けて返して…しか処理しないからだね。低品質だから助かってるだけだけど、顕在化してないだけで他にも不具合ありそう。 twitter.com/Matsunaga_1127…

— オリベー(・×・) (@OlibeyI) May 17, 2023

どういう仕様なんだ…まさかuser_idではなく、request_datetimeでユーザー判別したり、request_datetimeをユニークIDとして利用する部分があるの？…いや、それサーバー構成の問題じゃなくない？ 普通にそんなことありえないだろう…今日日、新人エンジニアでもそんな設計せんやろ…どういうこと…？ twitter.com/Matsunaga_1127…

— amaranthine (@amaranthine) May 17, 2023

「同日同時刻（マイクロ秒）まで同一のタイミングで別人がコンビニ交付を行った際にデータが入れ替わる」😱 twitter.com/Matsunaga_1127…

— Haruhiko Okumura (@h_okumura) May 17, 2023

マイクロ秒の奇跡で別人のが出るんか。
出ちゃいけないのはそうだけど相当レアで草 twitter.com/Matsunaga_1127…

— にゃー (@nya3_sapporo_it) May 17, 2023

秒だからだめなんだ！
↓
よし、次はマイクロ秒だ！これならそーそーぶつからんやろ！！

あのさァ…… twitter.com/Matsunaga_1127…

— 酔いどれふりす (@HurisDrunk) May 17, 2023

入れ替わるって書いてあるけど、AさんがBさんの、BさんがAさんのになるわけではなく、AさんもBさんもAさんの、もしくはAさんもBさんもBさんのになるんじゃないかな？ twitter.com/Matsunaga_1127…

— Yu Takashina (@yu_takashina) May 17, 2023

・排他制御とは何か分かってないと思われたくないという意志が感じられない原因説明。知らないのでは？
・本当にマイクロ秒まで一致して事故になるの？時計の分解能について分かってないのでは？
・サーバが同じだから大丈夫、本当？負荷テストで何をテストするべきでどうやってなぜOKか報告できる？ twitter.com/Matsunaga_1127…

— こばやしなおき (@nasutter) May 17, 2023

冗談で「対応内容『ミリ秒単位にしました』とかじゃないだろうな」って言ってたけどまさか twitter.com/Matsunaga_1127…

— Ikeda Daigo (@hogedigo) May 17, 2023

こういうことが原因だと、「じゃぁ検証してみようぜ」ってノリで仲間内でデータ入れ替わりが発生しないかやろうとする輩が発生しそうなんだが、、、 twitter.com/Matsunaga_1127…

— mugi (@ura_mugi) May 17, 2023

GetTickCount並みの解像度のAPI使ったか、時間取得をinitialize処理で済まして数秒間内のリクエストをループで回した、とか？ twitter.com/Matsunaga_1127…

— wordi (@wordijp) May 17, 2023

えっ？？
これもしかして前に秒単位でバグってて「対応完了」って言ってたやつ？？
対応=マイクロ秒に変更ってマジ？？w

もうシステムエンジニア免許制にしろよwww
1割も残らないと思うけどwww twitter.com/Matsunaga_1127…

— Mialceal (@mialceal) May 17, 2023

端末IDとか使ってないのか？ twitter.com/Matsunaga_1127…

— まお（松岡洋） (@kuronekodaisuki) May 17, 2023

同一市内の証明書交付で、ユーザーの操作がマイクロ秒まで同一のタイミングになるって、めちゃくちゃ確率低いとおもうんだけど、本当にそれだけの原因？ twitter.com/Matsunaga_1127…

— ケビン松永 (@Canary_Kun) May 17, 2023

短時間で大量のリクエストが投げられるOLTPは、時刻パラメータだけでハンドリングすると死んでしまうよね。 twitter.com/Matsunaga_1127…

— Hajime Saito (@replicorn) May 17, 2023

この画像を起点に「秒単位ではダメだったから、今後はマイクロ秒単位にしたのか」的な言説が結構見られるけど、「誤発行状況」が最初の3例から増えてない所を見ると「最初からマイクロ秒単位だった」と言う話な気がする。実際、どうなんだろう。 twitter.com/Matsunaga_1127…

— Tsugawa/CubeSoft, Inc. (@tt_clown) May 17, 2023

この内容が本当ならDBアクセスする際のキーがマイクロ秒まで含んだ時刻ってことになるけどそれが重複した挙句狙ったレコードが取れない(もしくは複数取れる)ってことになるのでテーブル定義でPKが正しく定義されてない可能性が出てくるけど。。。

ばっかみたい。 twitter.com/Matsunaga_1127…

— やっぴ (@yappi0207) May 17, 2023

またいつものあそこか。 twitter.com/Matsunaga_1127…

— stada (@stada1974) May 17, 2023

次はナノ秒にしないとだねぇ…… twitter.com/Matsunaga_1127…

— あらまほし (@TasRealBel) May 17, 2023

なにか端末ごととかユーザーごととかのユニークものを使えない制約があるのかな？ twitter.com/Matsunaga_1127…

— そうしくん (@soshi_harami) May 17, 2023

前提が分からないんだけど、時間をキー情報にしてたのかな。こういうのって、セッション単位でメモリ領域を分けてると思うけど、何でこうなるのか分かってない。 twitter.com/Matsunaga_1127…

— ジョニー (@tako2539) May 17, 2023

作成する一時ファイルがタイムスタンプ付きのファイル名で、それで衝突検知（O_EXCL）をしているのかな。
ローカルファイルシステムならそれで動くけど、DBとAPが別インスタンスなら検知できなくて上書きとか。
そーゆー感じの障害なら分かるけど、それじゃ負荷試験ではテストした事になんないべ。😅 twitter.com/Matsunaga_1127…

— 海外 浩平｜KaiGai Kohei🌻 (@kkaigai) May 17, 2023

「マイクロ秒まで同一のタイミングで別人がコンビニ交付を行った際にデータが入れ替わる」
「負荷テストを実施（して再点検）」

設計はとりあえずそういうものだとして、負荷テストで再現しなければ問題ないと言える類の問題なのかしら twitter.com/Matsunaga_1127…

— Kazuho Oku (@kazuho) May 17, 2023

これ、何で「交付」＝データ出力処理で、元のデータが更新されるのか、意味が分からない。何が起きているのだろうか。

そもそも DB 使ってて、こんなこと起こす方が難しいような…（DB 使ってないのかな？）

同時刻で…とか言ってるあたり、設計の悪さというか、全般的な筋の悪さがあるような予感。 twitter.com/Matsunaga_1127…

— Koji Saito (@KojiSaito) May 17, 2023

マイクロ秒でも被るときは被るし、そもそもタイマーの精度が1マイクロ秒単位なのかという問題が。
負荷テストをしたらボロボロ被ったりして。 twitter.com/Matsunaga_1127…

— わんだらぁ (@StellaInerrans) May 17, 2023

だからユニークなキーに時刻を用いるのはダメなんだってばさ・・・ twitter.com/Matsunaga_1127…

— 辻狂い (@tsujigurui) May 17, 2023

マイクロ秒……
もうこれを突き詰めていけば、『君の名は。』や『転校生』みたいな入れ替わりの理論も構築できるのではなかろうか。

そもそも論で言えば、タイムスタンプなんてものを固有の識別の材料にしてる段階で、うん。 twitter.com/Matsunaga_1127…

— 栗野鱗 (@crin_o_line) May 17, 2023

OSがLinux系ならばtickは10msなので、µs単位の精度は出ないんじゃないかなあと思う
なので実際は10msはデータが入れ替わりそうな予感 twitter.com/Matsunaga_1127…

— Fairlight aka 八霧 (@erliquin) May 17, 2023

秒→マイクロ秒の変更が意図通りに効いていれば発生頻度が百万分の一になるはずなので、どう考えてもマイクロ秒の精度出ていませんね。
0.1秒くらいの精度かなあ。 twitter.com/Matsunaga_1127…

— Ichigo Mayo (@15my) May 17, 2023

マイクロ秒ってこれのことか
次はナノ秒で対策してきそうw

内部システムでもなく同時に何人が操作するかも分からん超重要公共システムなのに時間で排他制御設計とか適当すぎるだろ twitter.com/Matsunaga_1127…

— tenpar (@hypertenpar) May 17, 2023

この話、みんな「マイクロ秒」に目が行ってるけど、個人的には「APとDBのサーバーが異なる場合に起きる」ってのが興味深い。同一サーバー上でやってる分には上手く排他できる、ってことなのかしら。あと逆に「品川区は住民情報のDBサーバーにAP相乗りしてるんだ」ってのと^^;; twitter.com/Matsunaga_1127…

— Tak H (@takh78) May 17, 2023

そもそもここに書かれてる内容がの正誤がよくわからんな。

3つの自治体の障害はそれぞれ原因が違うし、
ここに書かれてる原因は川崎市で発生したものっぽいけど、あれの原因は川崎市側システムと富士通側をつなぐプラグイン内の処理で川崎市独自のものって話しだったけど、品川でも使われてたの？ twitter.com/Matsunaga_1127…

— ツーシーム投げ猫 (@0000snao) May 17, 2023

なんでタイムスタンプで一意性が確保できると思うのか…。UUIDでも使っとけばいいのに。文字数に上限があって入り切らないとかかなぁ… twitter.com/Matsunaga_1127…

— sawat1203 / さわてぃー (@sawat1203) May 17, 2023

時間をキーにすんな
仕様バグじゃん twitter.com/Matsunaga_1127…

— Susumu Takagi (@susumu_taka) May 17, 2023

F通さんボロボロじゃないか(´Д` )

設計がクソなのか、上からの要求がめちゃくちゃなのかはわからんがタイムスタンプをIDに使うってのが twitter.com/Matsunaga_1127…

— たじま☆☆☆☆☆☆ (@ta1210) May 17, 2023

ミリ秒でもぶつかるでしょ…
イメージファイルのファイル名に端末固有のIDを振れば物理的に衝突を避けることができると思うけど、仕様上それが許容されないのかしら twitter.com/Matsunaga_1127…

— カズ (@kazu3929enl) May 17, 2023

アクセスがマイクロ秒単位で同期した→ありうる

ありうるけどさ
サーバにアクセスする道が1本しかないとかそういうこと？
おら頭悪ぃからよくわかんねぇけどそれぞれの端末のIDとかで区分するものじゃないの？

同一のタイミングでデータの取り違えって twitter.com/Matsunaga_1127…

— お嬢と執事©️️🗝 (@okekenai) May 17, 2023

開発中に「この仕様やばいよ。」って意見出てきそうだけど、毎度のように下請けの下請けの下請け。みたいな構造になってて、意見が通らない。開発してるけど、何のためのものか知らない。みたいな状況なのが原因じゃないのかなあ。という勝手な思い込み。twitter.com/Matsunaga_1127…

— fukaishi (@fukaishi) May 17, 2023

…時刻以外の要素もファイル名に含むなどして扱うなどしていたならば一意に出来たのでは？　…とか部外者としては思うなどしている…… twitter.com/Matsunaga_1127…

— こひつじas防人％食用に適さない (@as_sakimori) May 17, 2023

まだ同一端末からなら理解できなくはないけど複数端末から処理するよね？やっぱり衝突するよね？どうかしてるのでは（婉曲的表現 twitter.com/Matsunaga_1127…

— IINUMA Norio（ぬま）💉 💉 💉💉 (@Norio_IINUMA) May 17, 2023

ユニークになるようにまじで気を付けるところなのだが。。 twitter.com/Matsunaga_1127…

— 三芳町に住むパパ🐳 (@papa_miyoshi) May 17, 2023

特に驚きはありません。
ずっと言ってますけど、関連技術者が確定申告などで接してたらバックエンドのシステムが上流からまともに練られていないことは想像できるでしょう。なのに物理カードにこだわるのって明らかに素人発想だし、そんなプロジェクトの末端なんて（以下略）
twitter.com/Matsunaga_1127…

— snow (@snow_gray_) May 17, 2023

これ本当なんか・・(;・∀・)何がどうなったらこんな仕様が通ってまうねん・・。 twitter.com/Matsunaga_1127…

— ameta (@ameta_amiot) May 17, 2023

対策にナノ秒まで広げて、APサーバにDB移動しそうw twitter.com/Matsunaga_1127…

— でこ (@dekosea) May 17, 2023

チューチュー食っててむせたわ……。

> 同日同時刻（マイクロ秒）
セッションIDに時刻使ってんのかしら……。被るて💦

> APサーバとDBサーバが同一構成
フツー分けるし、そこは冗長性担保できる構成にするべきだぜ(;^ω^)

何だかなぁ……。 twitter.com/Matsunaga_1127…

— 🚴‍♂️🔧KAZUBOH🎨🖼 (@KAZUBOH_BH) May 17, 2023

マイクロ秒はまだ問題が想像できるのですが、APサーバとDBサーバの件はよく分かりませんな？
サーバ構成によって設計を変えているとしても、排他制御を変えるというのはあまり聞かないですが…具体的に何が起きたのか、報告出たら読んでみたいですのー。 twitter.com/Matsunaga_1127…

— ulthar / ユゴ猫 (@catulthar) May 17, 2023

ああ、マイクロ秒の話題ってこれかｗ

タイムスタンプなんかで衝突を防げるわけないだろｗ
端末の固有IDもくっつけておけｗ twitter.com/Matsunaga_1127…

— n-kiduki (@nkiduki) May 17, 2023

朝から良いものを見た、今日一日は笑顔で働けそうだ twitter.com/Matsunaga_1127…

— 伊月遊 (@ituki_yu) May 17, 2023