Suicaの新改札システムはようやっとキタ感が強いよねって話とか何ができるようになるのかとか耐障害性の話。
あー、やっとアーキテクチャ（システムの構造、の意）が完全に変わるんだ。っていう感想。
私が交通系ICカード開発の仕事に関わってたのがもう20年近く前で（正確には15〜6年前）その頃から今日まで全くアーキテクチャの基本構造が変わってなかったんですよ。
www.watch.impress.co.jp
20年変わらないってのも、なかなかすごいよね。ある意味、完成された構造だったわけですけども。
とはいえ通信速度が向上したら、ネットワークの信頼性が向上したら、いずれこの形になるのは想定されてました。
逆に言うと20年経ってようやく「新しい形式に移行できるぜ！」ってなったわけで、検証もこの間に重ねられてきてたって事だと思います。
思いつきで移行なんかしないですよ、鉄道会社の方々って。
だって障害発生したらニュースになるんだものｗ
私は過去に下記のようなブログとかも書いてるんで、ちゃんとシステムを知ってる人って分かると思います。
ossan.hatenablog.com
そもそも現行Suicaってどういう構造で精算してるの？
改札機側で料金表テーブル使って処理してます。料金表に一致するパターンで乗降してれば精算可。ロジックは基本的に使わない形です。
下みたいなテーブル作って、改札機に持たせるわけですね。
| 乗車駅 | 経由 | 降車駅 | 料金 |
|---|---|---|---|
| A駅 | Z駅 | B駅 | 200円 |
| B駅 | Z駅 | A駅 | 200円 |
| A駅 | Z駅 | C駅 | 250円 |
| C駅 | Z駅 | A駅 | 250円 |
このデータを大量に作って改札機に持たせます。
駅が逆のパターンとかいらんやん、なんで作るねん、と思ったあなた、世の中には逆方向だと料金が違うケースがあるんです。だから作る。
（いや、逆方向パターンを作らない鉄道会社もあるだろうけども）
経由の上限は鉄道会社によって違うんですが、1つではないです、あくまで例。
なので、料金表テーブル外のパターンは改札機でエラーになります。
Suicaで乗車して、遠くの駅で降りた時に改札機で「駅係員にお知らせください」みたいなエラー出た経験がある方がかなりいらっしゃると思いますが、それが改札機に持ってない料金表テーブル外のパターンです。
新改札システムは都市間移動も改札機で通過できるよ
今回の新改札システムだと、サーバ側でやるので、これまでは改札機でエラーになってた料金表テーブル外の処理もできるようになります。
実際、説明に書かれてますね。
利用者はかなり快適になるんじゃないでしょうか。
様々な企画券（青春18きっぷとか）がSuicaで使えるようになる、はず。
サーバ側での処理に変わればロジックを使ったパターンでの精算ができるようになるので、一定の期間内の乗降を割引する、みたいなことも可能になります。
なので色々と企画券が作れるようになるし、webで購入して自分のSuicaに企画券を載せて次の土日に使う、とかもできるようになります。
有名な企画券だと「青春18きっぷ」とか、これまでとちょっと形が変わるかもしれませんがSuicaに載せるのが可能になると思います。
他には、例えば首都圏にある各地域のアンテナショップで商品購入したら、現地のお買い物とか施設入場が割引になります、とかもSuicaだけで完結させたりとか出来ますね。
そんな感じの事例も今回のプレスリリースに書かれてるし可能性はすごくある。
ダイナミックプライシングが身近になる
政治的にもデリケートな話だからか、プレスリリースには記載がないですが。
現在は「ポイント還元」という形で実施してるダイナミックプライシングも、サーバ側のロジック処理で料金そのものを変更して実施可能になります。
極端な話、特定の駅だけ絞って導入する事も可能なので、そのあたりの議論も進むと思います。
www3.nhk.or.jp
耐障害性の話
センターサーバ方式になるので、障害時に全体に広がりやすいのでは、という話もありますが現行のシステムでも起きてるので何とも言えない。
例えば、2007年10月12日のケース。
www.itmedia.co.jp
下の資料はPDF注意。
首都圏のICカード自動改札機トラブルに関する検討会とりまとめ
https://www.mlit.go.jp/kisha/kisha07/08/081227/01.pdf
この時は朝に改札機起動したらネガデータ（このICカード使えないよ、データ）の取り込み時にエラーが発生してリトライのループになって起動完了しないってパターンでした。
障害対応として実施したのは、サーバ側との通信切断で改札機のみスタンドアロン運用だったんですが、今回の新改札システムにも似たような、障害発生時のスタンドアロン運用パターンも実装されているでしょうから大差はないと考えて良いかと。
精算データはとりあえず駅サーバに貯めておいて、後でバッチでセンターサーバに投げるとかの遅延処理はすでに現行システムの基本処理として実装されてるわけですし、そのあたりを障害対応用に拡張してるはず。
障害復旧は新改札システムのほうが早いかもしれない（あくまで私の感想ですよね）
むしろ、私は障害発生後の復旧は今回の新改札システムのほうが早いのではないかと考えてます。
これまでのアーキテクチャだと、障害発生後に改札機側で完了してる精算処理と中央サーバ側の記録との整合性を取るための同期処理がかなり大量に必要だったはずです。
新改札システムではサーバ側で精算処理が完了してる記録のみを正として障害復旧させる、と割り切れば復旧時間の短縮にも繋がるように思います。
素人が思いつくようなパターンは基本的には全て検証済で導入に踏み切ってるわけで、それでも障害が発生したら、まぁかなり想定外の出来事だったんだなと考えるしかないのよ、ほんと。
