思ったよりカバーできてないんだ
Suicaやめてくれよ。。 nfcだけで対応してくれよ サーバで処理するなら残額もsuicaに入れる必要ないじゃん
夢がひろがりんぐ
運賃の自動計算ができなくても、Suicaやクレカで切符が買えるだけでまずはかなりの問題は解決する気がするんだがなあ。
今まであの自動改札機で直接計算してたのか…！
せっかく分散処理で堅牢なシステムを構築してたのに、集中処理に先祖返りさせる判断したわけだ。主にコストの理由なんだろう。AWS落ちるとスマホゲームが軒並み止まるような障害が将来は自動改札でも発生するのだろう
クレジットカード決済なら運賃をその場で計算する必要すら無いってのは楽観視しすぎかな。
サーバ止まって全部止まる未来が見える。たまの休みで良いかもな
改札機側じゃなくてサーバー側で運賃計算処理する大転換はシステム的に胸熱だな
ローカルのGPSなんて偽装可能では……？
6つのエリア、というのがすごい表現だなと。仙台はわかるにしても盛岡エリアとは。/ “鶴岡と酒田の間にある藤島から東酒田までの6駅は対象外” 少なくとも路線ごとに対応しようよ…
Suicaのタッチから0.2秒以内に完了させるのは、サーバー方式はSuicaが登場した2001年当時なら無理でも今なら十分いけそう。改札機がかなり安くなるだろうし、運用コストも下がりそう。障害時を鑑みてもペイしそう。
サーバーサイドに寄せたとしてそれが SPOF にならぬよう策は練られているでしょう。社会インフラだから 99.999%ぐらいの稼働率なのでは
ぱっと見「ローカルの運賃テーブルで解決が無理ならサーバに投げる」方式だと思うけど、模式図見たらそうじゃないんだよな……
システム屋としては、改札機よりサーバーやネットワークの方が想像できるので、障害のこと考えただけでも恐ろしい。
「六割」って「六分割」か。
サーバを使う方式だとスイカに限定されずクレカとかでも同様に使えるようになりそう。
冗長性なくしてどうすんだ。閉塞からのボトルネックが発生してトラブル未来しかみえん。
｢Suicaの6割問題｣が変わる､JR東日本が改札機を減らして全駅対応を急ぐ理由､運賃計算をサーバーに移す大転換
思ったよりカバーできてないんだ
Suicaやめてくれよ。。 nfcだけで対応してくれよ サーバで処理するなら残額もsuicaに入れる必要ないじゃん
夢がひろがりんぐ
運賃の自動計算ができなくても、Suicaやクレカで切符が買えるだけでまずはかなりの問題は解決する気がするんだがなあ。
今まであの自動改札機で直接計算してたのか…！
せっかく分散処理で堅牢なシステムを構築してたのに、集中処理に先祖返りさせる判断したわけだ。主にコストの理由なんだろう。AWS落ちるとスマホゲームが軒並み止まるような障害が将来は自動改札でも発生するのだろう
クレジットカード決済なら運賃をその場で計算する必要すら無いってのは楽観視しすぎかな。
サーバ止まって全部止まる未来が見える。たまの休みで良いかもな
改札機側じゃなくてサーバー側で運賃計算処理する大転換はシステム的に胸熱だな
ローカルのGPSなんて偽装可能では……？
6つのエリア、というのがすごい表現だなと。仙台はわかるにしても盛岡エリアとは。/ “鶴岡と酒田の間にある藤島から東酒田までの6駅は対象外” 少なくとも路線ごとに対応しようよ…
Suicaのタッチから0.2秒以内に完了させるのは、サーバー方式はSuicaが登場した2001年当時なら無理でも今なら十分いけそう。改札機がかなり安くなるだろうし、運用コストも下がりそう。障害時を鑑みてもペイしそう。
サーバーサイドに寄せたとしてそれが SPOF にならぬよう策は練られているでしょう。社会インフラだから 99.999%ぐらいの稼働率なのでは
ぱっと見「ローカルの運賃テーブルで解決が無理ならサーバに投げる」方式だと思うけど、模式図見たらそうじゃないんだよな……
システム屋としては、改札機よりサーバーやネットワークの方が想像できるので、障害のこと考えただけでも恐ろしい。
「六割」って「六分割」か。
サーバを使う方式だとスイカに限定されずクレカとかでも同様に使えるようになりそう。
冗長性なくしてどうすんだ。閉塞からのボトルネックが発生してトラブル未来しかみえん。