アカウント名:
パスワード:
新サービスを始めるというなら、予測不可能性もある程度仕方が無いと思うが、今動いているサービスで、必要な同時接続数や、帯域などのデータは十分すぎるほど持っているだろうになんでやっちまったのかな。
「見積もりが甘かった」って、見積もりじゃなくて実データ取れるよね。
データが取れてなかったんですよ。
今回入れ替えた機器で、やっとデータ取りもできるようになる予定でした。
同時接続数のデータはあったようです。それを元に容量を見積もっていて、それは問題が無かった。しかし、「1時間当たりの接続数」のデータは従来型では取れなかったようです。
そのため、従来機器の「1時間当たりの接続数」性能が過剰だったと見積もられ、新型では能力が落とされました。この過小評価が、今回のトラブルの原因です。
更に、20日に小規模に入れ替えて試験していたのに、機器の安定稼働を確認するに留まり、接続数の確認を怠りました。これが決定的なミスとなります。
実績データが無い状態で容量見積もり失敗したのはまぁ仕方なかったとしても、小規模実地試験での試験項目になっていなかったのはマズいです。従来型より性能が劣っている箇所があるにかかわらず、確認していないというのは初歩的ミスと言われてもしかたありません。ここは他山の石としたい所ですね。
なるほど、スマートフォンが思ったより増加しなかったということですねNTT資料よりまとめると、[新型交換機の単体性能(従来比)] 同時接続数は7倍 処理能力も2倍
しかしシステムとしては、【従来型パケット交換機(11台)】 同時接続数 88万 処理信号量 2750万
【新型パケット交換機(3台)】 同時接続数 180万 処理信号量 1410万(←減少)
スマホ用に同時接続数は増えたが、処理できる信号量はむしろ減っている。というか減らしすぎ。コストダウンでしょうか。
#もっと従来機からスマホへの乗換が必要か? (この点でタレコミ記事はミスリード) #やはり机上設計の根拠として、現場データは大事ですね
http://www.nttdocomo.co.jp/info/news_release/2012/01/26_00.html [nttdocomo.co.jp]これかな?
想定負荷量: 71万接続/1200万信号
機器1台あたり: 60万接続/470万信号
茸「3台あったらまかなえる!」
ちょっとまて、予備系はどこいった?
予備系は主系と同じ容量で、アクティブ-スタンバイ型だったために、今回のような容量不足によるダウンの場合には無力だったんじゃないかな?ロードバランス型で予備機がスタンバイ状態になっていて、容量不足の場合に予備機で性能をブーストできる方式なら、多少は違ったでしょうけどね。
えっ?負荷分散させるために設置したパケット交換機をActive/Passive方式で設計してるって常識的に考えてありえないと思いませんか?
処理信号量(トラヒック)というのが、データーサイズなのかパケット数なのかよくわからなかったのですが、どうやらパケット数のようです。スマホではiModeよりパケット数は減る(又は従来能力は過大)と予想していたが、実際はAndoroid OS起因や、アプリのkeep-alive等でそれほど減らなかったということか。
え~と、少し前のFOMAは大量通信をすると10分間通信規制がかかっていたと思いますが、1時間当たりのデータ量すらわからないのに、どうやって規制をかけていたんでしょう?
パケット数に対し課金するシステムがあるのでユーザに対して集計はできていたものの地理的な軸での集計ができていなかったのでは?
実データって、とれるのかな?技術的には問題ないようにもおもうけど、倫理とかでやらなさそう。下手に採取して個人情報がもれたら、いちユーザとして許さんよ。
固定電話の時代だって研究・開発のための実データの収集はやってましたよただし音声データそのものを収集すると盗聴になるので、整流後の信号レベルの変化を記録するなどしてました(それだけでもかなり役に立つデータが得られるそうです)
負荷とかのデータから個人情報って漏れるのかな。スイッチ側でSNMPか何かでデータ取ってればそれで済むことなんじゃ・・・
むしろやっててまったく不思議はないとしか思えないんですがね。つい最近auがAirPushでやらかした(しかも情報収集は停止できないと明言した)ばかりだし。
現在のセッション数とか統計情報でええがな
データは取れるだろうけど、ハードウェアのリプレースを含む開発だから、相当前から始まってるはず。単純にそのときからの予測から大きく外れたということでしょ。データは取れても、開発側からは常にモニタできるわけじゃない。
予想以上の状態になっているのが分からなかったのは現地事前調査しないで工事したのが原因なんだろう。
1/20に先行切替した分も性能不足で、容量は少しずつ下がってたのかな。
単純に端末の性能が上がっているからじゃないの。
#いまどきチャットってあんた・・・。
> #いまどきチャットってあんた・・・。
iPhoneのSMSのインターフェースは「チャット」と言っていいと思う。他のOSは知らないけれど。
ハードの要件(同時接続数と信号量のバランス)を読み損ねたのは仕方ないと思います。しかし複数台で構成されていてスケーラブルなシステムなはずで入れ替える前に再度必要量を検討して余力を持たせた台数にするべきだったのではないかと。それをやった結果が現行システムのバランスの悪さだから想定してたと思うんですがねぇ。それにしても(能力-想定)が(実際-能力)より大きいってのはいくらなんでも?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
何でそんなことが (スコア:3, すばらしい洞察)
新サービスを始めるというなら、予測不可能性もある程度仕方が無いと思うが、
今動いているサービスで、必要な同時接続数や、帯域などのデータは十分すぎるほど持っているだろうに
なんでやっちまったのかな。
「見積もりが甘かった」って、見積もりじゃなくて実データ取れるよね。
Re:何でそんなことが (スコア:5, 興味深い)
データが取れてなかったんですよ。
今回入れ替えた機器で、やっとデータ取りもできるようになる予定でした。
同時接続数のデータはあったようです。それを元に容量を見積もっていて、それは問題が無かった。
しかし、「1時間当たりの接続数」のデータは従来型では取れなかったようです。
そのため、従来機器の「1時間当たりの接続数」性能が過剰だったと見積もられ、新型では能力が落とされました。
この過小評価が、今回のトラブルの原因です。
更に、20日に小規模に入れ替えて試験していたのに、機器の安定稼働を確認するに留まり、接続数の確認を怠りました。
これが決定的なミスとなります。
実績データが無い状態で容量見積もり失敗したのはまぁ仕方なかったとしても、小規模実地試験での試験項目になっていなかったのはマズいです。
従来型より性能が劣っている箇所があるにかかわらず、確認していないというのは初歩的ミスと言われてもしかたありません。
ここは他山の石としたい所ですね。
Re:何でそんなことが (スコア:2, 参考になる)
なるほど、スマートフォンが思ったより増加しなかったということですね
NTT資料よりまとめると、
[新型交換機の単体性能(従来比)]
同時接続数は7倍
処理能力も2倍
しかしシステムとしては、
【従来型パケット交換機(11台)】
同時接続数 88万
処理信号量 2750万
【新型パケット交換機(3台)】
同時接続数 180万
処理信号量 1410万(←減少)
スマホ用に同時接続数は増えたが、処理できる信号量はむしろ減っている。
というか減らしすぎ。コストダウンでしょうか。
#もっと従来機からスマホへの乗換が必要か? (この点でタレコミ記事はミスリード)
#やはり机上設計の根拠として、現場データは大事ですね
Re:何でそんなことが (スコア:2)
http://www.nttdocomo.co.jp/info/news_release/2012/01/26_00.html [nttdocomo.co.jp]
これかな?
想定負荷量: 71万接続/1200万信号
機器1台あたり: 60万接続/470万信号
茸「3台あったらまかなえる!」
ちょっとまて、予備系はどこいった?
Re: (スコア:0)
予備系は主系と同じ容量で、アクティブ-スタンバイ型だったために、今回のような容量不足によるダウンの場合には無力だったんじゃないかな?
ロードバランス型で予備機がスタンバイ状態になっていて、容量不足の場合に予備機で性能をブーストできる方式なら、多少は違ったでしょうけどね。
Re:何でそんなことが (スコア:1)
えっ?
負荷分散させるために設置したパケット交換機をActive/Passive方式で設計してるって常識的に考えてありえないと思いませんか?
Re: (スコア:0)
処理信号量(トラヒック)というのが、
データーサイズなのかパケット数なのかよくわからなかったのですが、
どうやらパケット数のようです。
スマホではiModeよりパケット数は減る(又は従来能力は過大)と予想していたが、
実際はAndoroid OS起因や、アプリのkeep-alive等でそれほど減らなかったということか。
Re:何でそんなことが (スコア:1)
え~と、少し前のFOMAは大量通信をすると10分間通信規制がかかっていたと思いますが、1時間当たりのデータ量すらわからないのに、どうやって規制をかけていたんでしょう?
Re:何でそんなことが (スコア:1)
パケット数に対し課金するシステムがあるのでユーザに対して集計はできていたものの
地理的な軸での集計ができていなかったのでは?
Re: (スコア:0)
実データって、とれるのかな?
技術的には問題ないようにもおもうけど、倫理とかでやらなさそう。
下手に採取して個人情報がもれたら、いちユーザとして許さんよ。
Re:何でそんなことが (スコア:2, 興味深い)
固定電話の時代だって研究・開発のための実データの収集はやってましたよ
ただし音声データそのものを収集すると盗聴になるので、整流後の信号レベルの変化を記録するなどしてました
(それだけでもかなり役に立つデータが得られるそうです)
Re:何でそんなことが (スコア:2)
負荷とかのデータから個人情報って漏れるのかな。
スイッチ側でSNMPか何かでデータ取ってればそれで済むことなんじゃ・・・
ヽ(・Д . )ノ
Re: (スコア:0)
むしろやっててまったく不思議はないとしか思えないんですがね。
つい最近auがAirPushでやらかした(しかも情報収集は停止できないと明言した)ばかりだし。
Re: (スコア:0)
現在のセッション数とか統計情報でええがな
Re: (スコア:0)
データは取れるだろうけど、ハードウェアのリプレースを含む開発だから、相当前から始まってるはず。
単純にそのときからの予測から大きく外れたということでしょ。
データは取れても、開発側からは常にモニタできるわけじゃない。
Re: (スコア:0)
予想以上の状態になっているのが分からなかったのは
現地事前調査しないで工事したのが原因なんだろう。
1/20に先行切替した分も性能不足で、容量は少しずつ
下がってたのかな。
単純に端末の性能が上がっているからじゃないの。
#いまどきチャットってあんた・・・。
Re: (スコア:0)
> #いまどきチャットってあんた・・・。
iPhoneのSMSのインターフェースは「チャット」と言っていいと思う。
他のOSは知らないけれど。
Re: (スコア:0)
ハードの要件(同時接続数と信号量のバランス)を読み損ねたのは仕方ないと思います。
しかし複数台で構成されていてスケーラブルなシステムなはずで
入れ替える前に再度必要量を検討して余力を持たせた台数にするべきだったのではないかと。
それをやった結果が現行システムのバランスの悪さだから想定してたと思うんですがねぇ。
それにしても(能力-想定)が(実際-能力)より大きいってのはいくらなんでも?