Suicaが運賃計算とかの処理をセンターサーバ化するという話が4月に出ていたので、今更ながら自分用に整理する
新しい Suica 改札システムの導入開始について - JR東日本
ちょうど今日（昨日）が本番だったみたいなので*1
従前の処理方式
今まで（現在）の処理方式は、マスタデータをセンターサーバから毎朝駅舎内の「駅サーバ」または会社毎に持つ「社局サーバ（≒社サーバまたは（交通）局サーバ」にデータを落とし、さらに改札端末群に配布している。
このアーキテクチャでは首都圏朝ラッシュのピーク時処理能力を重視して、運賃計算などを毎回センターサーバに問い合わせることなく、改札端末とICカードのみで処理を完結できる。これが200ms以内に改札処理を完遂する仕様を実現し、日本人のFelica / Suica / 日本人技術者信仰を惹起している。
反面、運賃計算は改札端末内にある運賃テーブルを走査する形でやっているみたいなので*2いわゆるラッチ内乗換範囲が拡大するとDB量が肥大、それだけ端末側の処理性能も求められるようになってしまう。
なので現在はSuicaが利用できる地域であっても、首都圏地域と他の地域などを分割し、それを跨いだ使用が出来なくなっている。
新しい処理方式
今回発表された処理方式では、改札機にICカードをタッチする度にセンターサーバへ問合せが発生する。運賃計算をセンターサーバで実施することで、運賃計算区間の制約が無くなり、企画券や（もしかしたら）ICカードに2種類以上の定期券を載せたりすることができるかもしれない*3。
改札端末に運賃計算機能を求めないので、理論上は改札端末をダム端末として扱える。実際にはサーバ・NW障害などを考え、改札機におけるFatな処理も残すらしいが*4。
新旧差分の整理
新旧環境の大きな差分として挙げられるのは、やはりトランザクション毎に発生する通信の範囲が挙げられる。現行方式では、Suicaカードと改札端末の間で通信が発生するだけだったが、新方式だと更にセンターサーバへの通信が発生する。
一般的に言えば、この端末とサーバ間の通信速度・輻輳が律速点になりそうだけど、JRというか鉄道各社は線路脇に光ファイバーを這わせていることが常なので、1トランザクションにそこまでのデータ量を要するとも思えないので、十分な専用線を確保できると考えて良いだろう*5。
実際には残高情報とかもセンターサーバで管理したりするわけだろうけど
ただ、Suicaの過去障害だと「ネガデータが特定の件数になった場合に改札のPGMがハング」という前科があり、この場合は特定の改札機ベンダのやらかしだった為利用できる改札機も存在したのに対し、センターサーバだと複数のサーバーサイドSWを開発するというのが考えにくいので、設計・実装不良があると全台影響となってしまう。それを考えると改札機を全てダム端末にすることはできず、一程度のスタンドアロン運用を想定するんだろうか。
*1:弘前－青森間で「Suica」対応 北東北3県45駅で利用可能に - 弘前経済新聞
*2:“エリアをまたいだ乗車”実現なるか？ 「Suica」の改札システムが順次リニューアル 2026年度完了予定 - ITmedia Mobile ここの話は公式な裏があんま取れない
*3:新しい Suica 改札システムの導入開始について - JR東日本
*4:JR東「Suica」改札の新システム ラッシュ時に通信遅延や不具合起きたら: J-CAST
*5:「センターサーバ方式Suica」に関する疑問をJR東日本に聞いた【鈴木淳也のPay Attention】-Impress Watch、光ファイバ心線・ケーブル管路等の使用について｜企業サイト：JR東日本、光ファイバー賃貸借事業｜東京メトロ
