自動ニュース作成G
Suicaの新改札システムはようやっとキタ感が強いよねって話とか何ができるようになるのかとか耐障害性の話。
https://ossan.hatenablog.com/entry/2023/04/05/044022
2023-04-05 18:13:14
＞あー、やっとアーキテクチャ（システムの構造、の意）が完全に変わるんだ。っていう感想。私が交通系ICカード開発の仕事に関わってたのがもう20年近く前で（正確には15〜6年前）その頃から今日まで全くアーキテクチャの基本構造が変わってなかったんですよ。
＞20年変わらないってのも、なかなかすごいよね。ある意味、完成された構造だったわけですけども。とはいえ通信速度が向上したら、ネットワークの信頼性が向上したら、いずれこの形になるのは想定されてました。
古い考えが抜けきらない人のツイート→「ああああ・・・なんで変えちゃうの・・・」
◇
・15〜6年を何としても20年にしたいオーサーに草
・JRがインターネット回線使う理由無いだろ。都市部は普通に専用線持つんじゃねーの？ ゲームの通信とは速度も安定度も二桁違う。
・専用線もJRが独自に線路とかと一緒に引いてるヤツと、NTTの回線( https://www.ntt-east.co.jp/info-st/network/traffic_2019/senyo/index.html )は最低限存在するし、電波も使うだろうな
・自ニュ民かよ？ ＞下の資料はPDF注意。
・改札機で都度料金計算してるならともかく、自前の料金表と照合してるだけなのに回線越しのサーバでやった方が早いのか。10年以上前の機械だとそんなもんか
・料金表データベースの件数がちょっと考えたくないレベルで多そう（メモリ食ってそう）
・スイカの導入は2001年。ノードの分散さえうまくゆけば低機能でも多人数に対応が出来たんだが、あとは#5。トラブった時に復旧が遅くなると思うんだけどな。セントラルもモノプロセッサじゃなくて分散させてバックアップ体制取ってるんだろうけど。
・#6 どこかでアルゴリズム公開してたが、データベース引いてるわけじゃないよ。料金計算自体は0.2秒で終わるそうな。
・今まではスタンドアロンで処理できてたのが、サーバを介して処理することになったから、サーバでエラーが出たら改札から出られない民が出て阿鼻叫喚とかそういう話でしょ？読んでないけど。
・#9 そういうのはよくあるケースなので、設計時点で折り込んで開発するのが普通。セオリー的には、そのカードを従来モードとかのフラグ立てて、サーバから分離した環境で処理し、記録を保持しておいて、後でマージするための処理を行なうんじゃないかな。それがオートでできりゃいいけど、駅員や発券機、スマホとかでフラグ解除する仕様にするかも知れん
・あの手のカード系は、(基本の使い方では)カード間での関係が無いので、後で整合性を取る処理が楽そうに思う。カード間で金銭をやり取りするケースとかは、サーバと接続できない時は制限するとか、個人的には行けると思ってる。金銭が不足していてオートチャージとかは工夫が必要そうだけど。悪用する人が出てから、色々対応が増えるかもだね
・中に人が入ってたのをやっと解放する話になっただけという説。たぶん、次は改札にAIが搭載されておばちゃんと言い合いするようになる。