Suicaのシステム改訂、少しづつ解ってきましたね。モデルとして参考になるし技術的必然性とブラッシュアップの繰り返しで今後もサバイバルしていってほしいですね

思いつきそうな課題は一通りQ＆Aされてる印象。
回答で気になったのは、トラブル時の改札機解放が想定されてなさそうな点かな。

知りたかったあたりの事聞いてくれてる記事だ。

うむうむ。しかし、結構丁寧に答えてくれるね。

暫くは、PASMO持っていれば良いか((( ( ･ิω･ิ)

これ読むとまだまだ色々できることありそう。

ざっくり概要
・あくまで改札機の話でありSuica決済は無関係
・従来並の処理速度は確保される
・オンラインアプデ可能に(今までできんかったんかい……)

組み込み処理をサーバー化するメリットは重々承知だが、負荷の読めなさ、負荷変動させる要因の多さ、耐障害性を確保する為のコスト等、茨の道だし間違いなくサーバー化起因の大障害は起きるだろう。これはノウハウ構築が大変だ。

えー、、なんか「こういうサービスを追加する構想あるの！」みたいな前向きなの出てくるかと思ったけど。今の方式を変えなきゃならないって物が見えてこなくて、今の方式が技術的に凄まじいだけど、ちょっと残念、、

はい＞

記事内に「高速なサーバーを導入することで、運賃計算などの処理に要する処理時間が短縮可能となり、」とありますが、センターサーバー何台の予定なんだろう？？🤔

仮にサーバー1台なら、ラッシュ時のネ演算＋ネットワークのRTT含めて1回200ミリで捌けるのか疑念がw

【今週の人気記事】

改札の中はただテーブル参照しているだけという認識だったが、そんな事はないんだろうか
そんな時間がかかる計算って何してるんだろう？ 素直に経路探索？ でもまさか改札機のマイコンでDPはしないでしょ？

今後の改修を見据えてなんやな、なるほどなぁ

「おそらく、これまで短く済んでいた処理はより時間がかかる可能性があるが、それでも「200ミリ秒」という基準を超えることはない。」

「Suicaの物販利用において今回導入するシステムを使用する予定はございません。」そっすよね。利用明細に「物販」が並ぶ日々はまだまだ続きそう...

これは設計次第かな？Update型にして順次配信すれば良かった気がするんですけどねぇ。

サーバや回線の冗長化は（当然）やるということだけど、大丈夫かなぁ／

センターサーバなので早くなる、の部分をもう少し詳しく知りたい。けど、「一日のうちで、こことこの駅使ったら割引」とか、凄まじくややこしい事もやりやすくはなるのかな。単なる経路計算だけセンターサーバにする理由が薄そうだし。

ざっと読んだけど勘違いと言うほど勘違いでもなさそうな。
・運賃計算はあくまでセンターサーバ（夜間バッチで改札に主要経路テーブルもたすとかはなさそう）
・障害防止策は冗長化、監視等通り一遍のモノ（複合障害や災害時処理をどこまで想定するのか

いやあの うーん....コストや処理性能アップ!の話を聞きたいわけじゃないんだよなぁ....

>システムの稼働状況については、24時間365日体制で監視を行い、万が一事象が発生した場合に迅速な対応ができる体制をとる予定です。

止まる可能性があるってことじゃねーか

「従来までであれば作業員が対象駅の改札を走り回って行なっていたソフトウェアアップデートや改修作業が、センターサーバーへの集中化により一気に軽減されることになる」
うーん、これソフトウェア配信の話であって処理をセンター集中させる理由ではないよなあ。

良い取材。

ついでに交通系を統合してくれないかな〜

ローカルサーバがどこにあるかまではよく知らないけど、改札一つ一つにあったとしたらデプロイめんどくさそうだ

うーん，将来的な構想についてはイマイチ奥歯に物の挟まったような説明だが，要は改札機もシンクライアント化しないと，抜本的なコスト削減にはならないということかな。究極的には入出場もバリューもセンターサーバで一括管理して，カードには何も書き込まない，みたいな。

そりゃカード自体の仕組みを変える必要はないのは質問するまでもなく当たり前だろとしか。

これ読む限り前回の記事ずいぶん飛ばしてたな？

Suicaは、高速処理が便利なので、通信してたら、いくら保険掛けても止まるときが来そうで。

自動チャージできないんだっけ？
2万?10万超えてるイクスカいたけど。

エリアまたぎを見越して，首都圏Suicaエリアの改札ぜんぶ入れ替えるとなると，数年がかりだな。JR東はカネあるかもしれんが，私鉄PASMO陣営も変える必要があるからね。：

運賃算出の条件と結果を改札機がキャッシュすればトータルではセンターサーバでの計算がかなり少なくなるのかな。

「たまたま処理が遅かったために引っかかる人」の頻度が増えることにならないといいけど＞

ほーん。元々ローカルでの計算がそこそこ重かったのでそこは軽くなるのと、ネットワークとサーバ設備を頑張って200msに抑えるってことか…
うーん。大丈夫なのかなぁ。
実績は十分とは言え、最近の日本の会社は信じられない大ボケをかましたりするしなぁ…

広報の人丁寧に答えすぎじゃない？（褒めてる

よくわかる記事。さすがに「JR東海とのエリア跨ぎ」について質問はしなかったか。

> 詳細は公開されていないが、JR東日本は自前の通信網を抱えており、

まじか

「センターサーバー方式では運賃計算などの処理をサーバー化することにより処理スピードが向上するため、技術的にはエリアまたぎが可能となります。Suicaエリアの統合につきましては検討中の内容であるため、実施時期含めて詳細は決まっておりません。(JR東日本広報)」

本当に中央集権型なんだ……てっきり駅かエリア毎にエッジサーバー置く的なやつかと👀
トラフィック量エグそうだし中央サーバーのパフォーマンス要件厳しそう……

正直メリットが皆無に見える。JRは異常時のためだけにローカル処理を残すことになるし、ユーザは具体的な拡張機能(現時点で完全未定)が提供されないと全く無意味。

気になってたレイテンシーや耐障害性についても言及されてた。大丈夫なんかなあ。

Twitterのツイート画像見てると，カードリーダ部分だけ取り付けると思ったら，改札機そのものを交換しているんだよな。関東エリアも変えていくとカネかかるなぁ。：

【今日の人気記事】

そもそもISO/IECのTypeAやTypeBの速度ではダメだから、SonyのFelicaで内部決済にしたんじゃなかったっけ？／

今はまだ改札機とセンターサーバーの役割分担の最適解を探ってる段階に読めて、将来的にはオープンループと「ID化」は望まれてる気がする
ただFeliCa(NFC-F)脱却はまた別軸だと思うけど、ここまで来たらJREにも別に拘りは無いのでは

安定稼働の鍵はやっぱりネットワークの状況次第か
---

後で読む

結局、"物販"問題、低速な決済端末が幅を利かせている問題、印紙税節税による2万円問題は何も解決しないのね。

運賃計算をセンター側に持ってくだけで、改札機-Suica間のやりとりは現状とほぼ同じみたい。ポストペイとかはまだまだ先の話。

【鈴木淳也のPay Attention】

結局エリアまたぎも物販の利用拡大はに進まず。キャッシュレスの本来の便利さには遠い。やはり茨交の考えであるシームレスな決済はクレジットとコード決済が有利か？

|'ㅂ')速度は変わらないってホントかな？？

すごい。みんなが聞きたかったことを全部聞いてくれた感ある。恐らく、新旧混在の移行期間中は運賃改定が出来ない縛りを持つ？…いや、縛りではないか。ただ積極的にはやりたくない期間になりそう。

現状の設計が(当時としては)素晴らしいので改悪と決め付ける派と、さすがに変な改悪はしないだろうと信じる派と分かれがちで、実際にどうなるのか気になる(僕は後者派)

(｡･ω･｡)ﾉ

結局のところ凡庸なアーキテクチャに成り下がるというのは事実だろうけども、マシンスペックの向上によりそれで大丈夫だからそうするというだけの話でしょう。
冗長化で障害発生率がゼロになることはないので、「迅速な対応」には期待したいところです。

これ問題でそうだよな

【鈴木淳也のPay Attention】

200msは行けると踏んでるのはわかった。これ現行だとどれくらいの速度なんだろうな。

運賃計算などにかかる処理時間は短縮されるが、新たにネットワーク通信による時間が追加となるため、ICカード処理全体の時間は現在と概ね変わらない見込み。

これは大規模リプレースの序章って感じかな。かなり手堅く進めてるなーって印象。

＞本年5月27日に開始する「Suica」を使った出改札サービスにおいて、北東北３エリアをまたいでSuicaをご利用することはできません。エリア統合につきましては検討中の内容であり、実施時期含めて詳細は決まっておりません。(JR東日本広報)

泣いちゃった

エリア跨ぎはまだまだ先って感じね？
そういや、しばらく行ってないが、新青森でSuicaのまま乗り換えると弘前で自動改札通れなかったのが対応になったんだっけか。
----

なるほどねえ
通常運用は問題なさそう
実際の懸案事項は通信障害時だろうか

知りたいことが網羅されてた、ありがたい！
あらためて、アーキテクチャーを変えていくことの凄さよ。

改札の処理時間の件は、(物販は別として)通信時間込みでも現行と変わらない程度になるらしい。やっぱり時代が進んでそのあたりの目処がついたのかな。

__φ( ╹ω╹ ) 。ｏＯ（

この件は（たぶん憶測で）否定的な意見が散見されたけど、この記事でしっかり取材されてるので答え合わせとしてご一読推奨な気がする

改札速度はギャバンの蒸着より早く、シャリバン赤射より遅いわけか

物販向けの無いのか、店舗への導入コスト下げられてシェア拡大できそうなのに -

センターサーバ方式ではRTTの増加をサーバの処理速度で相殺し，運賃計算などの処理は現状の200msec.と同等．
：

Suicaも新しい時代が来たみたいなのだが、おもしろいな···

なるほどねー。定期区間をまたいだ料金計算時間が短縮される一方、単純な計算は通信コストが加わっても200msec以内に収まるのね。バックエンド投資も大変だ。

新しいサービスはもう少し先になりそうだ。

見てる

そういえば「古いシステムはコストが高いから全部入れ替えだー！！！」って言った人が報国会系アカウントにちらほらいたけど、結局は耐障害性は維持しつつ、ってことで全然全部入れ替えじゃなかったですねえ。

現時点では「土台を整備する」に留まるわけねー、良くも悪くも
否定派の懸念も期待派の希望もまだ現実化はしない、と

【鈴木淳也のPay Attention】

ネットワークアクセス分の時間増加は計算処理時間の短縮でチャラって感じか

最初はほとんどサービスメンデ変わることは無いのね。エリア跨ぎも未定と

なるほど、気になってた処理速度は独自通信網による安定した高速通信＋改札機より遥かに高速なサーバーでの処理で同品質の処理速度を確保してると

現行の改札機では処理能力に限界があり、複雑な利用パターンなどを計算する場合に時間を要している現状があります。

みてた

結局運賃計算部分のオンライン処理加わるにせよ大部分のオフライン処理そのまま残るっていう有識者ほど勝手に勘違い事案だったわけですね。

：センタ方式で東芝のキャラバンやオムロンの更新計画とおさらばできるのか…

なんか思ってたより微妙だな…

コストメリットは現在のところ小、改修工数が改善、処理速度もほぼ変わらず、エリアまたぎは検討中：

みてる :

「作業員が対象駅の改札を走り回って行なっていたソフトウェアアップデートや改修作業が」軽減。
「Suicaの物販利用において今回導入するシステムを使用する予定はございません」

インフラ障害への備えを担当者に聞いたインタビュー記事があったから読んだけど、サーバとネットワーク冗長化という基本が書いてあるだけだった。まあ、そうよね

通信時間分増えるが計算処理は短くなってトータルでは従来の仕様の範囲内に収まる設計か。
ネットワークも専用の回線なら速そうではある。

エリア統合できないんかい

【鈴木淳也のPay Attention】