徒然ぶろぐ

バスカードがあるのにわざわざ PASMO で乗っても、現金で乗っている気分。帰宅するときに乗ってみました。乗車したのは 17 時過ぎだったけど、PASMO マイページにはまだ反映されていない。

まぁ、バスの端末はどうみてもネットワークに接続されていないから、それこそ即時反映されていたらどうなっているのか知りたい。鉄道の改札機は、「初ラッシュの月曜以降もPASMOは安定稼働」、パスモの担当者：ITproに拠ればネットワークに繋がっているようだ。

PASMOの利用データは、自動改札機から各駅に置いた管理サーバーにいったん蓄積。一定の間隔でセンター側に送信している。サーバーには1日分以上を蓄積できる容量を備えており、「PASMOのセンター側に処理が集中することはない。データは定期的にある程度のまとまりでセンター側に送り、バッチで処理することにしている」（同）という。こうした仕組みのため、「今日はPASMOのシステム全体やプログラムに問題がないことが、実際の運用で確認できた。明日以降も大丈夫だろう」（同）とカットオーバーの成功を安堵の声で語る。

「初ラッシュの月曜以降もPASMOは安定稼働」、パスモの担当者：ITpro

Suica のものではあるが、総務省のところに モバイルビジネス研究会説明資料というのがあり、これの 7 ページ目に Suica システムが載っている。やはり、Suica でも駅に ID 管理サーバを設置し、これが ID 管理センターサーバと通信をするような設計になっている。

SUICAやPASMOの紛失再発行の技術的な仕組みを教えて下さい - Yahoo!知恵袋によると、各駅に設置されている ID サーバは、不正利用を防ぐための照合用（“ブラックリスト”と例えられている）とのこと。一々メインサーバへアクセスしてたら遅延が発生しまくりの、サーバが処理仕切れなさそうだもんね。分散処理って素敵だわ。しかしブラックリストが肥大化すると、各駅で処理するのも大変なんじゃないかな……と、思ってみる。

試しに計算をしてみよう。ID はユニークな数値と考えられるため、データベースに対して二分探索を行うのが効率よさそう。予め ID をソートしておく必要はあるが、これはメインサーバが暇を持て余している際に行えば良いだろう。二分探索で必要な最大検索回数は、データ数 n に対して log2 n 回。モバイルビジネス研究会説明資料の 8 ページ目に Suica と PASMO を併せて 3,000 万枚を超えるとの見込みが出ているため、ここでは 3,000 万エントリで試算する。勿論、登録されるデータは遙かに少ないため、計算結果より最大探索回数は少ない。log2 30,000,000 = 24.83845916、故に最大 25 回の探索で終わる。

探索回数は 25 回で終わるけど、そのエントリを保存しておく領域が大変だなぁ。多分カード裏面に印刷されているものが ID と思われるので、英字 2 字 + 数字 15 桁。16 桁の整数と思えば良いので、log2 1017 = 56.47277761、故に 57 ビット必要。面倒なので、57 ビット＝7.125 ビット≒8 バイトとする。これを 3,000 万エントリ分なので、8 x 30,000,000 = 240,000,000 bytes = 240 MB。……、あまり容量は取らなかった。

そんな無駄な計算をしている間も、夜は更けていく。