新しいSuica改札システム、運賃計算は改札機ではなくサーバーで 115
ストーリー by nagazou
災害の多い国なので心配ではある 部門より
災害の多い国なので心配ではある 部門より
JR東日本は4月4日から交通系IC「Suica」に「センターサーバー方式」を採用した、新しい改札システムを導入したという。従来のSuicaとの違いとしては、改札機で実行していた運賃計算を、サーバ側で行うようになったこと。サービス機能の拡張性向上、高速処理による複雑な計算の実行、改修作業の工期短縮化とコストダウンが実現可能になったとしている。従来型のスタンドアローン型は耐障害性などのメリットもあったが、ICカードにデータを記録するため記憶容量に限界があり、Webやスマートフォンとの親和性にも課題があったとしている（JR東日本リリース[PDF]、ITmedia）。
時間足りるんやろか (スコア:2, すばらしい洞察)
Suicaの決済で使っている時間が0.2秒（200ms）
JRは駅間をファイバーでつないでるんだっけ？そこの中にサーバおくとして
遠くの駅に行けば行くほど距離による通信時間が延びる
まぁ往復20msとして残りが180msで180msで計算終わらせるようにするのキツそう
目標決済時間伸ばすのかもしれんけど
普通に駅にエッジサーバおいて本体のサーバに対して入場記録とか送るんじゃだめなのか？
Re:時間足りるんやろか (スコア:1)
サーバーとの通信が絶対に必要なQRコード決済をすでに導入している駅もあるし、どうせ必要になるならSuicaだけ改札で処理しても無駄にシステムが複雑化するだけって判断かな。
あと超高速の決済が必要になるそもそもの理由にもオフピーク定期券 [srad.jp]の導入とかで手を付けていくみたいだし
Re:時間足りるんやろか (スコア:1)
電車乗るだけで「光速は俺らには遅すぎる」って言えるかも知れんってか
Re: (スコア:0)
足りなかったらしないべにゃあ
Re: (スコア:0)
えきねっとの新幹線eチケットサービスで実績あるしね
Re: (スコア:0)
Suicaって、バスでも使ってるんだよね。
Re:時間足りるんやろか (スコア:4, 参考になる)
改善したかったのは改札を出ない会社跨いでの乗り継ぎ、東海道線のJR東と東海のような、です。
バスの場合乗り換える際には必ず一度精算するので、このタイプに変更する必要がありません。オートチャージには対応して欲しいですけど。
おそらく自販機もそのままでしょう。
将来的にカードと結びついているなら現状の最大チャージ額以上の買い物ができるようになるならば、それに対応したい店舗はレジの改修か入れ替えでしょう。
バーコード決済対応でレジはインターネットに繋がっているので、物理的にはそれほど困難ではないハズです。ソフトウェア的には私には分かりません。
Re: (スコア:0)
使用頻度の高い（おそらくは近距離／周辺駅の）料金はキャッシュして、
使用頻度の低いものにあたるとサーバーに問い合わせるくらいの
最適化はしてるんじゃね？
間に合わないことがあっても、レアケースなら許容範囲
Re: (スコア:0)
あらかじめ計算した全通りの組み合わせデータベースを改札のマシンにインストールしといて料金改定のたびに新しくすればいいじゃない。
Re:時間足りるんやろか (スコア:1)
Re:時間足りるんやろか (スコア:1)
最短というのがわかりにくいが、「入場駅からもっとも近い、定期区間内の駅」ということですね
Re:時間足りるんやろか (スコア:1)
そのページを読みましたが、10^40って「ルートの組み合わせの数」ではなく、「乗車パターンの数」みたいですよ。
だそうで。
ってことで、
乗継割引があるから、入場駅だけでは運賃が決まらないので、
「その駅から到達可能な駅の運賃（最終的な駅間の運賃）」だけでは無理だと思います。
次は (スコア:1)
クラウド化？
Re:次は (スコア:2, すばらしい洞察)
マイナカードに紐付けられた口座からの自動引き落としでは
Re:次は (スコア:2)
マイナカードで何もかも引き落とせるようになったら楽と言えば楽なんだがなぁ
誰がシステム組むんだろう 国?銀行?カード会社?
Re:次は (スコア:1)
VEW CARDがある以上そこは手放さないでしょう。
Re:次は (スコア:5, おもしろおかしい)
あなたのコメントにはアイがないですね。
Re:次は (スコア:1)
奴はとんでもないものを盗んでいきました
Re: (スコア:0)
納品までの期日です。
Re:次は (スコア:1)
スイカにEinkとかの表示デバイスを取り付けて残り金額、JRからのお知らせ等の情報表示
Re: (スコア:0)
普通にモバイルSuicaでええやんか
Re: (スコア:0)
AIでこのSuica IDはこの時間ならあの駅に行きそうだから料金いくら
ってやるんじゃないでしょうか
Re: (スコア:0)
混雑時と閑散時で別料金とか
Re:次は (スコア:1)
もう始まってます。
Re: (スコア:0)
資料に蜘蛛の絵が掻いてある
運賃計算は鬼門だからな。 (スコア:1)
新駅とかで変更されたりすると、新駅から既存駅の全運賃を再計算しないと駄目。
しかもJR外の私鉄もノーラッチやワンラッチの相互接続で繋がってるから、JRの機材も私鉄の新駅にも対応しないと駄目。
なので新駅や新型機直後は違算が多発したりする。
一時期の某社が違算不具合を短期間に連発して新型運賃計算プログラムを作る動機になってたはず。
で、JRと私鉄で運賃の特例が微妙に違ったりして、とてもバグが出やすい。
それを、JRが担当できれば一貫性が生まれるし、更改費用も圧縮出来る。
ユーザーメリットとしては、計算量で殴れるようになれば、熱海とかの壁を破れるようになるかも。
私鉄発着は識別コードが被ってるって耳に挟んだことがあるからしばらくかかるかもだけど。
Re: (スコア:0)
運賃計算結果はサーバ内でキャッシュして、2回目以降は2駅間の運賃を返すだけじゃないの?
定期券だと定期券の区間内の各駅と入退場駅間の総当たりしなけりゃダメかもしれないけど。
Re: (スコア:0)
組み合わせ計算してみ？
定期入のSuicaを考慮したら10^40とか、普通の規模のストレージに収まる量じゃないから。
Re:運賃計算は鬼門だからな。 (スコア:2, 参考になる)
そのためにICカードの場合は「乗換改札通過フラグ(と乗換改札通過時に一旦清算)」+「乗換改札通過フラグがない場合は最短区間で乗車したものとする」+「定期券区間が経路上に含まれる場合は最大活用する」という条件付けで計算量を圧縮してるんだけどね。
上記ルールがあるので、みどりの窓口とか特急・指定席券対応券売機で経路指定で買った切符のほうが安くなるケースが存在する。
Re: (スコア:0)
途中で送ってしまった。
関東圏だけでそれ。
色々刈り込んでも10^26とかそういう世界なので、よく使う分をキャッシュは出来ても、全部は無理。
それに、自動改札はある種のリアルタイムシステムで、デッドラインが有るからワースト性能の方が重要。
キャッシュで効率化出来ても、素で所定の性能を満たせないと困る事になる。
運賃のキャッシュは営業日が変わるまで機器側で持っても良いわけだし。
それと、#4440464で言いたかったのは仕様が複雑かつ、テスト量が莫大すぎて、
各機器個別で運賃計算持つのは開発やテストの費用と時間効率が良くないって話。
センターで計算になれば、JRがやりたがってる変動運賃制とかもやりやすくなるしね。
Re: (スコア:0)
計算量を減らすために、途中で関所的な改札機を置くんじゃね？
そこまでの経路の運賃を計算してしまえば、降車駅で一気に計算する時間を削減できる。
Re: (スコア:0)
それ、何処に置くの？
乗り換え改札以外に追加するって事だよね？
隣接駅ユーザどうするのさ。
Re: (スコア:0)
いままでは、作った新料金計算プログラムを夜間バッチ等で配信するのが、
センターのサーバで夜間新に、新料金対応プログラムに切り替えるみたいなので、
どっちにしても手間は大してかわらないのでは？
Re: (スコア:0)
その料金プログラムを作る工数のお話です。
お約束のように想像できる近未来 (スコア:1)
システム障害で改札全停止やろなぁ
どんな「対策」で万全に備えたつもりでも一度は通らなきゃいけない通過儀礼みたいなものだ。
Re:お約束のように想像できる近未来 (スコア:1)
その時は手動でSuicaに鋏が入ります
モバイルSuicaの場合はスマホなりスマートウォッチなりに…
Re: (スコア:0)
色々と前例があるからねぇ
多くの人が懸念してるのはそこだろう
大学生協がICカード→アプリ化、食堂の待ち時間3倍で苦情殺到 | スラド IT [it.srad.jp]
限界なのはそう (スコア:0)
25年前のシステムに後付でいろいろ増設して、これからも色々と新サービスを追加していきたいんだからどこかで刷新は必要なんでしょうね。
Re: (スコア:0)
端末やら全部更新されるにも20年くらいかかるのかな。それでも田舎では磁気使ってそう
Re: (スコア:0)
人口減少に伴い廃駅になるのが先では。
Re: (スコア:0)
おやおや、「新たな利権が」が抜けてるぞい
# スラド的揶揄
Re: (スコア:0)
鉄道とバス以外の履歴がなんでも「物販」なのが、いずれ改善されるかな
反応遅そう (スコア:0)
「実はこっそり新宿の改札一つ丸ごとテスト運用してました」とでも言ってもらわないとねえ。
反応速度のせいで止められそうな気がする。
Re: (スコア:0)
あの、新宿駅全体ですら流行ってるゲームサーバーよりかトランザクション数が大幅に少ないのでテストにならないと思うのですが...
どちらかというとモデルとしてはプリンタと一緒で、カードのリードライトのコストがどれだけかかるかりほうが時間単位に係わる問題になると思うので、サーバー側についてはそんな気にしなくてもいいはず。
あと気にしなきゃいけないのは回線の多重化かな?こちらは閑散駅のほうが携帯電話回線で賄えるのでやりやすいかもしれない。
あと、これはJR東日本のプレスリリースだけど、いわゆる全国の交通系ICはニアリーイコールでJR東日本情報システムのものになるので、順次既存他地域他会社もサーバーサービス化することで双方のメンテナンスコスト下げたいんだと思われる。
Re:反応遅そう (スコア:1)
JR新宿駅の乗降者数が1日100万人以下。
例え1時間に200万トランザクション全て発生したとしても、秒間500トランザクションにしかならない。
一方今のオンラインゲームは、大規模な所では秒間1万とか10万トランザクションという世界。
ゲームで200msの遅延なんて許されるはずもなく、リアルタイムに低遅延処理する必要がある。
運賃の計算は、ゲームと違ってユーザ相互の影響や、DBのリアルタイムな更新なんかも少ないので非常に軽い処理でしょう。
Suicaを始めた20年前のサーバ・通信環境では難しかったのでローカル処理は妥当だった。
でも20年たって技術水準が変わり、何が難しいか低コストかも変わってしまったという例ではないでしょうか。
なんせ (スコア:0)
2001年稼働のシステムですからねぇ。
当時としては奇跡のようなシステムでしたけど、それだけに異様な程複雑ですし、
ツギハギの連続で拡張性が限界。
この決断はどこかでしなければならなかった。
あと、スマホやアプリが普及して、どんなサービスも落ちるという事が広く周知された事は大きいかも。
絶対落ちちゃ駄目と、年に2～3回落ちるくらいならと割り切るのでは全然違うし。
サーバは一番過酷な性能を要求される新宿に置くんですかね。
それとも新宿渋谷池袋の中間点？
JR新宿駅の平均乗降客数158万人ってなんぞ。
Re:なんせ (スコア:1)
ちょうど新宿駅南にJR東本社があるので、そこかな？
Re: (スコア:0)
乗降客数は少なくても、料金計算の複雑な東京駅の方が厳しい・厳しくなるのでは？
Re: (スコア:0)
でも新幹線ってまだまだ切符のほうが多い感じがするよ
センターサーバー方式？！ (スコア:0)
つまり一箇所で集中管理するってこと？
これはすごいターゲットになりそうｗ
ワーム仕掛けてラッシュ時にサーバダウンさせれば・・・
毎日数百万人が遅延、経済損失も面白そう
サーバをチェックしても問題なし
何が原因かさっぱりわからない
”出来る一般社員”程度のレベルじゃあワームに気が付けないってよｗ
北半島民なら面白がって挑戦するのでは？