Home > au障害(2)

au障害(2)


  • Posted by: F&F
  • 2013年1月20日 11:04

IP系の制御はどれも同じなのだが、過負荷に余り強くない。
Googleのメール障害にしても然りで、機器を再起動させたとたんに一斉に再リクエストがかかって立ち上がらなくなる。

これはWeb系のサーバでも同様で、安定動作が始まってしまえば良いのだがそれ以前にトラフィックが集中すると立ち上がれなくなる。
ネットワークサーバの場合は手動でネットワークケーブルを引っこ抜くとか、ルータにフィルタをかけてIPアドレス制限をするなどしながら立ち上げれば何とかなる。
トラフィックが落ち着いてくれば運用は正常化するからだ。

通信量の制限や通話制限なども同様で、一定以上の呼が集中するとシステム全体の動きに影響が出る。
そこで通話や通信量を監視して、危険水準に達しないうちに制限を発動してしまう。
純粋な回線交換の場合はIP通信と違って過負荷にならない。
通信回線数以上の通信が行われないのだから当たり前で、しかしIPの場合は通信あたりの速度が遅くなるだけでいくらでも通信を詰め込む事が出来る。
そしてドコモにしてもauにしても遅延が増大してシステム応答がおかしくなった。

auは認証サーバが応答出来ずに通信が不成立になった。
通信が成立しないので移動機は再リクエストをかける。
ここで又呼の集中が起こって状況は悪化する。

auでは対策して混雑時には一部制御をスキップするようにした。
本来であれば制御全体の高速化が必須なのだが、とりあえず直す為に時間のかかる処理を抜いたと言う事だ。

ネットワーク屋や認証系に関して、スマートフォンがやたらと行う通信を理解していなかった事が原因だ。
スマートフォンを実際に使い、いかに無駄な通信がバッテリを消耗させているかに気づけば対策は出来たと思う。
しかしネットワーク屋は出来上がったスマートフォンのユーザでしか無く、スマートフォンの利用者増による通信量の増加を考えなかった。

   

Comments:0

コメント投稿には JavaScript が必要です。ブラウザのJavaScript 機能を有効にしてください。

サインインしなくてもコメントの投稿は出来ます。
サインインしている場合はお名前などを入力せずに、そのまま投稿できます。

登録は簡単&それによって何かが起きるわけではないのでお気軽にどうぞ。
登録ページ書き込み→確認メール送信→確認メールのURLクリックで承認、の手順です。
確認メールに書かれたURLにアクセスしないと登録は完了せず、正しいログイン状態に移行できません。
コメント フォーム
コメント投稿完了までには少し時間がかかります。
二重投稿にご注意下さい。

Home > au障害(2)



VC