Twitterじゃ収まらないのでブログに書こうかと。

とうの昔にi-modeを捨て、しかもこの間日本にいない私には、実害まるでないのですが。。。
新システムの構築にリアルタイムに関わっている身としては、気になって仕方の無い事故。

ITProで、SPモードの障害の続報読みました。
[続報]spモード障害、なぜ処理能力オーバーで「メールアドレスの置き換え」が起きたのか

これ、プッシュ型のメール配信の難しさが根本にあると思います。

私なりに考察した結果をたとえ話にすると、、、

年がら年中引っ越しが絶えないアパートに、名前も確認せず宅配便届けてました。
なので、引っ越しのピークシーズンになったら、違う人に荷物が届いちゃった(`□´)コラッ!
今後は、ちゃんとはんこ押してもらって確認してから届けるようにしますm(._.)m


記事では、メールアドレスとIPアドレスを紐付けたところに問題があるんじゃなかろうか的な、ニュアンスを漂わせています。
でもIPの仕組みからしてプッシュでデータを送るなら、どのみちIPアドレスに結びつけるしかない。
IPアドレスを動的に振り出している仕組みと、メール配信は別のシステムだろうし、現実的に考えてIPアドレス振り直しから、マッピングテーブルの更新と参照をアトミックに行うなんてきっとムリ。
つまり、IPアドレスが変わる度にテーブルをロックして参照をブロックするなんて物量を考えたら絶対現実的じゃない。
事実そうはなっていなかったんだと思います。

でもさすがに、何かしらの排他制御あったんじゃないかと思うけど、IPアドレス振り出しのプロトコルを考えるとそもそも排他制御にはムリがありあそう。


だから、この問題はもともと潜在的な問題として認識されていたんじゃないだろうか?

とはいえ、今回のドコモの対応案は現実的と言えそう。
おそらく、メール配信システムが端末を特定するときに、マッピングテーブルから引き当てた端末に、データを送る前に本当に本人かどうか検証するプロセスを入れるってことじゃないだろうか?
その検証には、固有IDをつかうのかな?
そういう意味では、もとの記事のニュアンスは正しいとも言える。

もし、そういう対応をするとしたら、端末側も更新が必要になりそうだから大工事になりそうですね。
一時的な対処として、一定以上輻輳したらメール送信を待機させる様な仕組みを入れる必要もありそう。

あれ、ここで一つ心配になりました。他のキャリアのMMSはどうなっているの?
・・・


いや〜、しかし勉強になりました。
当事者の皆さんには本当に不謹慎というか気の毒ですが、こういうトラブルを自分なりに考察してみるのはSEにとっていいトレーニングになります。


複数のシステムを連携させる仕事をしている私にとって、今回のトラブルは「明日は我が身」。
通信ほどシビアなタイミング問題は起きにくいとしても、一度冷静に振り返ってみる必要はありそう。
なぜなら、こういう不整合は程度のこそあれ、よくあることだから。。。