なぜspモードはIPアドレスの紐付を行っていたかを考えてみる [アーキテクト]
2011年12月20日にdocomoのspモードで、「メールアドレスの置き換え」という障害が発生しました。
本当の原因等はメディアにお任せいたします。
(例えばITProなどはいかがでしょうか)
どうやら原因は、ドコモのセンター側でIPアドレスとメールアドレスを紐付していたが、センター側が高負荷状態となり紐付に不整合が発生してしまった・・ということ。
ということで、「なんでIPアドレスを紐付たのだろう??」と勝手に考えてみるのが本稿の趣旨。
まずはじめに携帯のメールと通常のSMTP(POP/IMAP)メールとの違いを把握してみたい。
通常のメール(POP/IMAP)はメールの着信確認を、クライアントサイドから行う。1分とか極端に短い確認間隔を設定しない限り、送信後ほぼリアルタイムに着信することはない。
それに対して携帯のメールは、センター側から携帯端末にメールをプッシュすることで(通信可能状態にあれば)ほぼリアルタイムに着信する(と聞いたことがある)。このリアルタイム性がうけたのか携帯のメールってほぼチャットのように利用されていることがありますよね。
さて、ここでどうやって携帯端末にプッシュするか、その仕組みを考えてみたい。仮定として、利用するネットワークは純粋なIPネットワークであること。
センターからプッシュするためには送信したいメールアドレスのIPアドレスを知らなければならない。端末側からのメール着信確認のアクションがない以上、何らかのかたちで端末側のIPアドレスを把握しておく必要がある。
ここでおそらくspモードではメール->IPアドレスに変換するダイナミックDNSのような仕組みを作り上げたんでしょう。端末側のIPアドレスが変更された場合は自動的に変換テーブルを更新しちゃんと同期がとれていれば問題はないはずだと。
IPアドレスではなく、端末固有のIDで管理すればよかったのではないか、と私もはじめは考えたのですが2つの理由からそれはできないと考えられたものと思います。
こうして今までのspモードの仕組みができあがったと・・・。
では、どうすれば今回のような問題は起きなかったのかを考えてみると・・・、意外と解決策は難しい?
なんらかの形でメールアドレス->IPアドレス変換は必要になるのはほぼ間違いない(はず)。
とはいえIPアドレスとメールアドレス変換テーブルが完全に同期する保証はないことが今回証明されている。
・・・端末ID-IPアドレスの組み合わせもセンター側で管理し、メールをプッシュする際に端末IDを送信し端末側で受信する際端末IDが異なっていたらrejectする、という案もあるかもしれない。これで99%は問題がなくなるはず。(センター側の同期は相当のことがない限り、破たんしないようなので)けれど、今回のような問題が発生することを想定し、かつ受信側でcrackされてどんな端末IDでも受け入れられる仕組みを作られたら、と思うと100%完全ではない。
おそらく回答に近いものはAndroidのC2DMのような仕組みなんだろうな。ただ、ユーザGoogle Acountの認証Tokenのようなものがないので、そこに何か代替手段を考えないといけないのかもしれない・・・。
今回の事故を教訓に、何か問題があっても最悪の事態にならないフェールセーフな設計を心掛けなければいけないな・・と実感しております。(それにしてももし本当にspモードを設計していたら、自分はどんな解決をしただろうか・・)
--
当然のことながら、ここで仮定している仕組みはspモードの本当の仕組みではありません(と思いたい・・・)。事故原因報道および私自身の想像でつくりあげた架空のものです。
本当の原因等はメディアにお任せいたします。
(例えばITProなどはいかがでしょうか)
どうやら原因は、ドコモのセンター側でIPアドレスとメールアドレスを紐付していたが、センター側が高負荷状態となり紐付に不整合が発生してしまった・・ということ。
ということで、「なんでIPアドレスを紐付たのだろう??」と勝手に考えてみるのが本稿の趣旨。
まずはじめに携帯のメールと通常のSMTP(POP/IMAP)メールとの違いを把握してみたい。
通常のメール(POP/IMAP)はメールの着信確認を、クライアントサイドから行う。1分とか極端に短い確認間隔を設定しない限り、送信後ほぼリアルタイムに着信することはない。
それに対して携帯のメールは、センター側から携帯端末にメールをプッシュすることで(通信可能状態にあれば)ほぼリアルタイムに着信する(と聞いたことがある)。このリアルタイム性がうけたのか携帯のメールってほぼチャットのように利用されていることがありますよね。
さて、ここでどうやって携帯端末にプッシュするか、その仕組みを考えてみたい。仮定として、利用するネットワークは純粋なIPネットワークであること。
センターからプッシュするためには送信したいメールアドレスのIPアドレスを知らなければならない。端末側からのメール着信確認のアクションがない以上、何らかのかたちで端末側のIPアドレスを把握しておく必要がある。
ここでおそらくspモードではメール->IPアドレスに変換するダイナミックDNSのような仕組みを作り上げたんでしょう。端末側のIPアドレスが変更された場合は自動的に変換テーブルを更新しちゃんと同期がとれていれば問題はないはずだと。
IPアドレスではなく、端末固有のIDで管理すればよかったのではないか、と私もはじめは考えたのですが2つの理由からそれはできないと考えられたものと思います。
- 携帯時代の「かんたんログイン」で端末固有のIDを利用していたが、この方式はセキュリティ上問題があるとされ、その利用をためらった。端末固有IDが偽装されたら・・という思いもあったかも。
- こちらのほうが仕組み上問題なのだが、端末固有IDをつかっても送信先を特定できない。メールアドレス->端末固有ID→IPアドレスの変換の仕組みが結局必要。
こうして今までのspモードの仕組みができあがったと・・・。
では、どうすれば今回のような問題は起きなかったのかを考えてみると・・・、意外と解決策は難しい?
なんらかの形でメールアドレス->IPアドレス変換は必要になるのはほぼ間違いない(はず)。
とはいえIPアドレスとメールアドレス変換テーブルが完全に同期する保証はないことが今回証明されている。
・・・端末ID-IPアドレスの組み合わせもセンター側で管理し、メールをプッシュする際に端末IDを送信し端末側で受信する際端末IDが異なっていたらrejectする、という案もあるかもしれない。これで99%は問題がなくなるはず。(センター側の同期は相当のことがない限り、破たんしないようなので)けれど、今回のような問題が発生することを想定し、かつ受信側でcrackされてどんな端末IDでも受け入れられる仕組みを作られたら、と思うと100%完全ではない。
おそらく回答に近いものはAndroidのC2DMのような仕組みなんだろうな。ただ、ユーザGoogle Acountの認証Tokenのようなものがないので、そこに何か代替手段を考えないといけないのかもしれない・・・。
今回の事故を教訓に、何か問題があっても最悪の事態にならないフェールセーフな設計を心掛けなければいけないな・・と実感しております。(それにしてももし本当にspモードを設計していたら、自分はどんな解決をしただろうか・・)
--
当然のことながら、ここで仮定している仕組みはspモードの本当の仕組みではありません(と思いたい・・・)。事故原因報道および私自身の想像でつくりあげた架空のものです。
ぜんぜん原因違うかも・・・(というか違うな)
http://www.nttdocomo.co.jp/binary/pdf/corporate/technology/rd/technical_journal/bn/vol18_3/vol18_3_045jp.pdf
によればPush通知はSMSを経由しているそうです。
また、今回数多くのサービスがいったん停止状態になったことを考えるともう少し基本的なことでミスがあったのかな。(POP等の認証が特別ということで、この部分が怪しいかも)
by たーとる (2011-12-26 16:08)