パスワードを忘れた? アカウント作成
16554222 story
交通

新しいSuica改札システム、運賃計算は改札機ではなくサーバーで 115

ストーリー by nagazou
災害の多い国なので心配ではある 部門より
JR東日本は4月4日から交通系IC「Suica」に「センターサーバー方式」を採用した、新しい改札システムを導入したという。従来のSuicaとの違いとしては、改札機で実行していた運賃計算を、サーバ側で行うようになったこと。サービス機能の拡張性向上、高速処理による複雑な計算の実行、改修作業の工期短縮化とコストダウンが実現可能になったとしている。従来型のスタンドアローン型は耐障害性などのメリットもあったが、ICカードにデータを記録するため記憶容量に限界があり、Webやスマートフォンとの親和性にも課題があったとしている(JR東日本リリース[PDF]ITmedia)。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 時間足りるんやろか (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2023年04月08日 7時54分 (#4440456)

    Suicaの決済で使っている時間が0.2秒(200ms)
    JRは駅間をファイバーでつないでるんだっけ?そこの中にサーバおくとして
    遠くの駅に行けば行くほど距離による通信時間が延びる

    まぁ往復20msとして残りが180msで180msで計算終わらせるようにするのキツそう
    目標決済時間伸ばすのかもしれんけど

    普通に駅にエッジサーバおいて本体のサーバに対して入場記録とか送るんじゃだめなのか?

    • by Anonymous Coward on 2023年04月08日 10時47分 (#4440538)

      サーバーとの通信が絶対に必要なQRコード決済をすでに導入している駅もあるし、どうせ必要になるならSuicaだけ改札で処理しても無駄にシステムが複雑化するだけって判断かな。
      あと超高速の決済が必要になるそもそもの理由にもオフピーク定期券 [srad.jp]の導入とかで手を付けていくみたいだし

      親コメント
    • 電車乗るだけで「光速は俺らには遅すぎる」って言えるかも知れんってか

      親コメント
    • by Anonymous Coward

      足りなかったらしないべにゃあ

      • by Anonymous Coward

        えきねっとの新幹線eチケットサービスで実績あるしね

    • by Anonymous Coward

      Suicaって、バスでも使ってるんだよね。

      • by Anonymous Coward on 2023年04月08日 10時26分 (#4440523)

        改善したかったのは改札を出ない会社跨いでの乗り継ぎ、東海道線のJR東と東海のような、です。
        バスの場合乗り換える際には必ず一度精算するので、このタイプに変更する必要がありません。オートチャージには対応して欲しいですけど。
        おそらく自販機もそのままでしょう。

        将来的にカードと結びついているなら現状の最大チャージ額以上の買い物ができるようになるならば、それに対応したい店舗はレジの改修か入れ替えでしょう。
        バーコード決済対応でレジはインターネットに繋がっているので、物理的にはそれほど困難ではないハズです。ソフトウェア的には私には分かりません。

        親コメント
    • by Anonymous Coward

      使用頻度の高い(おそらくは近距離/周辺駅の)料金はキャッシュして、
      使用頻度の低いものにあたるとサーバーに問い合わせるくらいの
      最適化はしてるんじゃね?

      間に合わないことがあっても、レアケースなら許容範囲

      • by Anonymous Coward

        あらかじめ計算した全通りの組み合わせデータベースを改札のマシンにインストールしといて料金改定のたびに新しくすればいいじゃない。

  • by Anonymous Coward on 2023年04月08日 7時11分 (#4440439)

    クラウド化?

  • by Anonymous Coward on 2023年04月08日 8時08分 (#4440464)

    新駅とかで変更されたりすると、新駅から既存駅の全運賃を再計算しないと駄目。
    しかもJR外の私鉄もノーラッチやワンラッチの相互接続で繋がってるから、JRの機材も私鉄の新駅にも対応しないと駄目。
    なので新駅や新型機直後は違算が多発したりする。
    一時期の某社が違算不具合を短期間に連発して新型運賃計算プログラムを作る動機になってたはず。

    で、JRと私鉄で運賃の特例が微妙に違ったりして、とてもバグが出やすい。
    それを、JRが担当できれば一貫性が生まれるし、更改費用も圧縮出来る。

    ユーザーメリットとしては、計算量で殴れるようになれば、熱海とかの壁を破れるようになるかも。
    私鉄発着は識別コードが被ってるって耳に挟んだことがあるからしばらくかかるかもだけど。

    • by Anonymous Coward

      運賃計算結果はサーバ内でキャッシュして、2回目以降は2駅間の運賃を返すだけじゃないの?
      定期券だと定期券の区間内の各駅と入退場駅間の総当たりしなけりゃダメかもしれないけど。

      • by Anonymous Coward

        組み合わせ計算してみ?
        定期入のSuicaを考慮したら10^40とか、普通の規模のストレージに収まる量じゃないから。

        • by Anonymous Coward on 2023年04月08日 9時12分 (#4440487)

          そのためにICカードの場合は「乗換改札通過フラグ(と乗換改札通過時に一旦清算)」+「乗換改札通過フラグがない場合は最短区間で乗車したものとする」+「定期券区間が経路上に含まれる場合は最大活用する」という条件付けで計算量を圧縮してるんだけどね。

          上記ルールがあるので、みどりの窓口とか特急・指定席券対応券売機で経路指定で買った切符のほうが安くなるケースが存在する。

          親コメント
        • by Anonymous Coward

          途中で送ってしまった。
          関東圏だけでそれ。

          色々刈り込んでも10^26とかそういう世界なので、よく使う分をキャッシュは出来ても、全部は無理。
          それに、自動改札はある種のリアルタイムシステムで、デッドラインが有るからワースト性能の方が重要。
          キャッシュで効率化出来ても、素で所定の性能を満たせないと困る事になる。
          運賃のキャッシュは営業日が変わるまで機器側で持っても良いわけだし。

          それと、#4440464で言いたかったのは仕様が複雑かつ、テスト量が莫大すぎて、
          各機器個別で運賃計算持つのは開発やテストの費用と時間効率が良くないって話。
          センターで計算になれば、JRがやりたがってる変動運賃制とかもやりやすくなるしね。

          • by Anonymous Coward

            計算量を減らすために、途中で関所的な改札機を置くんじゃね?
            そこまでの経路の運賃を計算してしまえば、降車駅で一気に計算する時間を削減できる。

            • by Anonymous Coward

              それ、何処に置くの?
              乗り換え改札以外に追加するって事だよね?
              隣接駅ユーザどうするのさ。

    • by Anonymous Coward

      いままでは、作った新料金計算プログラムを夜間バッチ等で配信するのが、
      センターのサーバで夜間新に、新料金対応プログラムに切り替えるみたいなので、
      どっちにしても手間は大してかわらないのでは?

      • by Anonymous Coward

        その料金プログラムを作る工数のお話です。

  • by Anonymous Coward on 2023年04月08日 11時25分 (#4440557)

    システム障害で改札全停止やろなぁ

    どんな「対策」で万全に備えたつもりでも一度は通らなきゃいけない通過儀礼みたいなものだ。

  • by Anonymous Coward on 2023年04月08日 7時49分 (#4440453)

    25年前のシステムに後付でいろいろ増設して、これからも色々と新サービスを追加していきたいんだからどこかで刷新は必要なんでしょうね。

    • by Anonymous Coward

      端末やら全部更新されるにも20年くらいかかるのかな。それでも田舎では磁気使ってそう

      • by Anonymous Coward

        人口減少に伴い廃駅になるのが先では。

    • by Anonymous Coward

      おやおや、「新たな利権が」が抜けてるぞい

      # スラド的揶揄

    • by Anonymous Coward

      鉄道とバス以外の履歴がなんでも「物販」なのが、いずれ改善されるかな

  • by Anonymous Coward on 2023年04月08日 7時54分 (#4440457)

    「実はこっそり新宿の改札一つ丸ごとテスト運用してました」とでも言ってもらわないとねえ。

    反応速度のせいで止められそうな気がする。

    • by Anonymous Coward

      あの、新宿駅全体ですら流行ってるゲームサーバーよりかトランザクション数が大幅に少ないのでテストにならないと思うのですが...
      どちらかというとモデルとしてはプリンタと一緒で、カードのリードライトのコストがどれだけかかるかりほうが時間単位に係わる問題になると思うので、サーバー側についてはそんな気にしなくてもいいはず。
      あと気にしなきゃいけないのは回線の多重化かな?こちらは閑散駅のほうが携帯電話回線で賄えるのでやりやすいかもしれない。

      あと、これはJR東日本のプレスリリースだけど、いわゆる全国の交通系ICはニアリーイコールでJR東日本情報システムのものになるので、順次既存他地域他会社もサーバーサービス化することで双方のメンテナンスコスト下げたいんだと思われる。

      • by Anonymous Coward on 2023年04月08日 20時57分 (#4440800)

        JR新宿駅の乗降者数が1日100万人以下。
        例え1時間に200万トランザクション全て発生したとしても、秒間500トランザクションにしかならない。

        一方今のオンラインゲームは、大規模な所では秒間1万とか10万トランザクションという世界。
        ゲームで200msの遅延なんて許されるはずもなく、リアルタイムに低遅延処理する必要がある。

        運賃の計算は、ゲームと違ってユーザ相互の影響や、DBのリアルタイムな更新なんかも少ないので非常に軽い処理でしょう。
        Suicaを始めた20年前のサーバ・通信環境では難しかったのでローカル処理は妥当だった。
        でも20年たって技術水準が変わり、何が難しいか低コストかも変わってしまったという例ではないでしょうか。

        親コメント
  • by Anonymous Coward on 2023年04月08日 8時10分 (#4440465)

    2001年稼働のシステムですからねぇ。
    当時としては奇跡のようなシステムでしたけど、それだけに異様な程複雑ですし、
    ツギハギの連続で拡張性が限界。
    この決断はどこかでしなければならなかった。
    あと、スマホやアプリが普及して、どんなサービスも落ちるという事が広く周知された事は大きいかも。
    絶対落ちちゃ駄目と、年に2~3回落ちるくらいならと割り切るのでは全然違うし。

    サーバは一番過酷な性能を要求される新宿に置くんですかね。
    それとも新宿渋谷池袋の中間点?
    JR新宿駅の平均乗降客数158万人ってなんぞ。

    • by tsukachan (26170) on 2023年04月08日 23時26分 (#4440832)

      ちょうど新宿駅南にJR東本社があるので、そこかな?

      親コメント
    • by Anonymous Coward

      乗降客数は少なくても、料金計算の複雑な東京駅の方が厳しい・厳しくなるのでは?

      • by Anonymous Coward

        でも新幹線ってまだまだ切符のほうが多い感じがするよ

  • by Anonymous Coward on 2023年04月08日 11時03分 (#4440546)

    つまり一箇所で集中管理するってこと?
    これはすごいターゲットになりそうw
    ワーム仕掛けてラッシュ時にサーバダウンさせれば・・・
    毎日数百万人が遅延、経済損失も面白そう
    サーバをチェックしても問題なし
    何が原因かさっぱりわからない
    ”出来る一般社員”程度のレベルじゃあワームに気が付けないってよw

    北半島民なら面白がって挑戦するのでは?

typodupeerror

犯人はmoriwaka -- Anonymous Coward

読み込み中...