FC2ブログ

鈴の音情報局blog

携帯関連の将来や最新の技術情報や業界の行く末などを適当に綴るblogです。 内容の信憑性は?余り信じない方がいいと思います。
本家の鈴の音情報局はこちら→http://suzusuzu.dip.jp:8800/
スマホ・携帯端末アクセス[ランキング][アクセスシェア(グラフ)] (毎年10/1にログをクリア)

先日のドコモの障害を検証

2011年6月6日に発生したネットワーク障害の発生経緯および対策などについて

ドコモは6日の機器の故障による輻輳についての説明を行った。

これでドコモのネットワークの作り方の一端が垣間見えたように思う。
故障の状況から見た表側からはバックアップが無いように思われたが、さすがにそんなことはなかった
ようでプライマリの0系、セカンダリの1系というように同じものが2系統稼動していたようだ。

一台づつの切り替えが行えるはずなので、0系の関東の契約情報を司っている部分が故障したら
そこだけが切り替わる事になっていたのだが、システム全体が0系から1系に切り替わってしまい、
1系に対して再登録情報が全国中から押し寄せる事になってしまったのが今回のトラブルの要因
だったということだ。


しかしユーザーから見た障害はそこではない。

>サービス制御装置の負荷を下げるために、午前9時26分頃より通信規制を実施し、午後0時46分には
>パッケージ故障を修復し、1系から0系へシステム切替を行ないました。しかしながら、依然として高負荷
>状態が続いたため、通信規制を更に強め装置の負荷状況を見ながら少しずつ規制を解除していきました。

障害に見えた実態は「通信規制」なのだ。
つまり1系に切り替わって高負荷になったとしても、その負荷を分散できるシステムになっていれば
こんなことにならなかったと言える。

0系から1系に一気に切り替わったのは制御ソフトに大バグが潜んでいたのかも知れない。
そもそも基幹部にその程度の信頼性のソフトを制御に利用していることも問題なのだが、それだけの
大トラフィックが一気に押し寄せないようにシステムを設計することが大事だ。


ドコモ発表資料より引用


0系・1系のデュアルシステムの場合、1系は0系と同じように同時稼動はしていない。
用語に関して細かい定義が業界によって違うが、今回の場合は上記の行のように定義する。
0系の故障を受けて1系に切り替え、1系が稼動した。
今回はそういう稼動法だったとこの説明から見ることが出来る。

この図を見ると0系と1系の間に「同じ情報を常に保持」と書かれている。
私はそれは間違い(嘘?)だと指摘する。これがドコモの正式な発表の資料だとは信じられない。

仮にドコモが発表したように「同じ情報を常に保持」していたなら、例え1系に切り替わっても
特に位置登録信号が増えることは無い。0系が稼動していた時と同じ状態で何もなかったように
処理を引き継ぐだけです。

しかし1系に切り替わって位置登録信号が増えるということは1系は常時稼動しているのではなく、
1時間に1回なりというタイミングで最新情報を0系からコピーしてもらっていたものと推測されます。

0系からのコピーを受けて30分後に0系から1系に切り替わったとすると、その30分の間に
移動した端末は位置登録行うことになります。端末が一斉に移動する通勤時間帯に突然1系への
切り替えが起こったのですから悲惨な結果になったと考えられます。

>この要因は、サービス向上に向けたソフトウエアアップグレード中のユニットが、
>平日朝の通勤時間帯にパッケージ故障したことによります。

一日で一番クリティカルな時間帯に基幹部のソフトウエアのアップグレードを行うという非常識な
ことをしています。アップデートが原因で故障した可能性も排除できません。
それが原因でなくともアップグレードによりシステムが不安定になる可能性もあり、このような
リスクを伴う作業はその機材の負荷が上がる時間帯は避けるべきです。基本がなっていません。
※後注:コメント欄で「実際にソフトの入れ替えは当該時刻ではなく、
      3日に行ったという意見がありました。」


本来こういった非常に重要で国全体の通信の根幹を支えているような部分は0系・1系が
同時稼動していないデュプレックスシステムではなく、二つの
システムを同時に処理を行い、その処理結果の比較をして間違いが無いことを確認する
デュアルシステムとして動かすべきです。
私はこのような巨大システムのプロでは有りませんが、その私から見てもドコモの
このシステムは素人設計以下の脆弱さを感じます。(色んなコメントを頂いたところ、
やはりそれなりにしっかりしているようですのでここは撤回)

デュアルシステムは常に二つのシステムが同時に同じ事をしているので1時間毎のコピーの
ような作業が不要で、故障箇所を停止して故障しなかったほうの結果を引き続き採用すれば何の
トラフィックの増加もなく普通にその故障をやり過ごせるのです。何故他社にMNPしたユーザーに
まで影響が及ぶような基幹部でそれをしていないのか不思議でなりません。

仮に0系から1系に切り替えが起きたとして、その場合1系が配下に「新しい位置登録情報を
送って頂戴」というコマンドを出していると思われます。しかしそれでは輻輳を自分で呼び込むような
ものです。設計時に問題点として取り上げられていないなら不思議でなりません。
問題として取り上げられた上でそのままGOサインが出たのならその思想を疑います。

私が設計するなら1系に切り替わったらプライマリに立場を移した1系はとりあえず
セカンダリに落ちた0系に「生き残っている最新情報を送れ」と指示を出すようにします。
そのコピーが終わった後で初めて担当地域の機器に位置登録情報の再登録を要請させます。

余計な作業が増えて0系からの切り替えに仮に1分かかったとしてもその1分で基地局を
跨いだ端末の位置情報の登録程度なら輻輳するなんてことは無いでしょう。
今回の輻輳事故は自らトラフィックを呼び込むような設計にしてあった事が原因です。
機械は故障するのが前提のものであり、その故障が原因のように自体を矮小化している
ドコモに腹立ちを覚えます。

私からすればこれは同じ機材でも問題なく防ぎきれたことであり、タコ過ぎる設計が問題
じゃないかと思います。レベルで言えば福島第一原発の津波対策レベルのお話にならない状態です。


また、これだけの重要なシステムが何故一箇所にしか置いていなかったのか。
一箇所にしかないとは書いていませんが、私には恐らく東京のどこか一箇所に設置されて
いただけのように思えてなりません。もし本当に一箇所しかなかったとすると、そこが災害で壊滅
又は通信テロなどが起こった場合は完全にアウトです。
さすがにこの部分に関してはこの予想は外れていると願いますが・・・。

あと運用でも信じられないことがありました。


故障を回復してシステムを元に戻すのはいいのですが、この1系から0系に戻す作業を
行ったのは12:46と書かれています。この時間は昼休みで人が動き回っている時間帯です。
何故こんな人の動き回って位置登録の激しく起こる時間帯に0系に戻す必要が有ったのか。

私が責任者ならその日は1系でやり過ごしてトラフィックが落ち着いた深夜に0系に戻すようにします。
この程度のリスクを避ける運用は常識だと思っていたのですがドコモでは当たり前ではなかったようです。
ここだけ見ると恐ろしく危機管理の出来ていない素人集団に見えて仕方が有りません。


そもそも何故0系と1系は同時稼動が出来ないのか。
1系に切り替わってトラフィックが増えたとしましょう。
そうするとそのトラフィックを分散させるように生き残っている部分の0系と切り替わった1系を
平行動作をさせて高負荷を一時的に分散化させるという動作の仕組みも盛り込んでおくべきでしょう。

これらを考えるとどうやら運用で切り抜けられた可能性が高いように思います。


※後注:他キャリアの簡単な実情の内容と比較した情報をどうやらプロっぽいと思われる方から
     情報がありました。それによると、これでもドコモはマシな方らしいです。
     更にこれだけのディスクローズがその他社では無かった可能性が高く、
     情報を公表したドコモを評価すべきかもということも併せて頂きました。
     有難うございました。
関連記事
  1. 2011/06/15(水) 19:45:52|
  2. 携帯
  3. | トラックバック:0
  4. | コメント:10
<<ドコモ、こっそりとHSDPA 14Mbpsサービス開始 | ホーム | 各キャリアの2011夏端末の発売日一覧>>

コメント

用語ですが、
デュアルシステム:同時稼働し、結果の比較を行う
デュプレックスシステム:トラブルが起きたら、待機系へ切り替え
と思うのですが。
  1. URL |
  2. 2011/06/15(水) 20:12:18 |
  3. hisatti #3un.pJ2M
  4. [ 編集]

一点だけ。
ソフトウェア更新を行ったのは6月3日。
その日の朝に行っていたわけではありません。
  1. URL |
  2. 2011/06/15(水) 20:14:34 |
  3. あ #mQop/nM.
  4. [ 編集]

昼間は確かに人は動くけど、信号数は落ち着いてるんじゃないかな~。

通勤時間帯は移動距離とボリュームの乗算がピークに達するので、論外だけど、夜中からの延長戦の結果かもしれない。

報道発表で気になる点は私もありますが、また違った観点を持っています。

それは、なんで規制したの?ってところです。位置登録は端末が生きてる限り永久に続くので、リベンジ位置登録を抑止せずに、HLRへの入り口を規制したら、経路上のノードが死ぬのでは?経路上のノードが死んだら、そりゃ無関係なユーザーにも不都合を感じさせて当然。わざわざ影響範囲を広げる処置は妥当なの?ってところです。

以上、参考まで。
  1. URL |
  2. 2011/06/15(水) 21:04:49 |
  3. [削除:削除待ち中] #-
  4. [ 編集]

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます
  1. |
  2. 2011/06/15(水) 22:25:12 |
  3. #
  4. [ 編集]

絵を見る限り、「システム切替」は介入せず、「自動的になってしまった」という風に見えますね。

収容率が172万/5000万人(3.4%)なので、これ以上の細切れ分散はあまり意味がなく、「負荷分散」は十分であると思いますが、いかがでしょうか?
(つまり、高負荷を理由にしているが、うさんくさいと言う意味でもあります)
  1. URL |
  2. 2011/06/16(木) 00:52:48 |
  3. あ #-
  4. [ 編集]

感想ですが、対応している間、現場は実際に何が引き金を引いたのかというところは、ここまでは分かって
なかったんじゃないかと思います。分かっていたのなら、夕方に切り戻しするでしょうかね?早く定常状態に
戻したいという気持ちがあったんじゃないかと想像しています。

また、ソフトウェアアップデートというのを実際に朝の8時からやってたかというとそういう意味ではなく、
片系統のみ別のソフトウェアにしての運用中だったのではと読みました。片側を入れ替えて1日とか数日
運用して、もう片方を入れ替えるという、ややアンバランスな状態だったとか、そういう風に思います。

リトライが発生して輻輳というのを「設計が甘い」といわれてしまえばそれまでですが、短期間・短時間・
頻回なトラブルにおいては、リトライが有効に作用して、ユーザの利便性をが損なわれることを防ぐ、
というのはあります。翻って大規模障害になると、その動きが自らのシステムを攻撃する方向に変わる
ので、どちらに重きを置くかは難しいところです。

平時の利便性を重視するかわりに重篤な障害のときは悲惨なことが起きる。あるいは、多少の障害でも
影響が出るが、重篤な障害でもあまりひどくならない。昨今は状況的には前者を許さなくなっているとは
思いますが、運用者としていろいろと考えさせる事象でした。
  1. URL |
  2. 2011/06/16(木) 01:10:40 |
  3. VO #sqCyeZqA
  4. [ 編集]

以下は3gpp上の解釈なので、今回に該当するかどうかは断言出来ませんが、
位置登録は無線区間の報知情報変化に基づく、移動機トリガーなので、
0系と1系が仮にミラーリングをしていなくても、系切替によって位置登録が新たに発生することはないと思います。

この辺の基本的からくりについては、こちらが分かりやすそうです。これでも結構難解で、記事も古いので、現状からは変わっている可能性もあります。よろしければどうぞ。
http://www.nttdocomo.co.jp/corporate/technology/rd/technical_journal/bn/vol8_1/041.html
  1. URL |
  2. 2011/06/16(木) 01:11:46 |
  3. あ #-
  4. [ 編集]

わあ、技術者がいっぱい・・・(笑)
なんだか考えさせられるコメントが多いですね。
設計会議しているみたいです。
Twitterでも詳細な内容のコメントを頂いたりと参考になる意見が多いです。

デュアル・デュプレックスはわざわざ色を変えて間違っているという恥ずかしい
事をやらかしてしまいました;;
今から直しておきます。
  1. URL |
  2. 2011/06/16(木) 01:50:52 |
  3. #GpEwlVdw
  4. [ 編集]

本件は日経BP ITproの記事が一番詳しいです。参照なさってください。
  1. URL |
  2. 2011/06/16(木) 09:25:44 |
  3. あ #j9g3P57.
  4. [ 編集]

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます
  1. |
  2. 2011/06/17(金) 21:59:09 |
  3. #
  4. [ 編集]

コメントの投稿(投稿時には必ず何らかの名前を付けてください)


管理者にだけ表示を許可する

(名前を入れないとクリックできません)

トラックバック

トラックバックURLはこちら
http://suzunonejh.blog15.fc2.com/tb.php/1617-7f0e48aa
この記事にトラックバックする(FC2ブログユーザー)

最近の記事

機能リンク

最近のコメント

カテゴリー

ブログ内検索

ブログリンク

RSSフィード

QRコード

QR

月別アーカイブ



メールフォーム

お問い合わせ・ご質問はこちらから。

名前:
メール:
件名:
本文:

suzunone.m(あっと)gmail.com に
直メでもOKです。