【KDDI通信障害】原因はコアルーター交換時の不具合とアクセス集中 負荷低減のため流量制御実施でつながりにくく 本格再開は未定 ★4 [ギズモ★]
■ このスレッドは過去ログ倉庫に格納されています
https://pctr.c.yimg.jp/t/amd-img/20220703-35189873-zdnet-000-2-view.jpg
https://pbs.twimg.com/media/FWtU8zPUYAAXe93.jpg
出典:@ishiit_aroka
KDDIの大規模通信障害、影響は最大3915万回線--事象が重なり復旧に遅れ
https://headlines.yahoo.co.jp/hl?a=20220703-35189873-zdnet-sci
KDDIは7月3日午前11時から、2日未明に発生した大規模な通信障害に関する記者会見を開いた。会見した代表取締役社長の高橋誠氏は、「社会インフラを担う安定的なサービスを提供しなければならない通信事業者として深くお詫びする」と謝罪を表明した。
通信障害は7月2日午前1時35分に発生し、全国で通話ができない、SMSの送受信ができない、データ通信の速度が遅くなる、途切れるなどの状態が3日午後現在まで続いている。3日午前11時時点の同社想定による影響範囲は、最大で約3915万回線。
中略
同社は、障害発生後から対応と復旧の作業を進めており(後述)、西日本エリアでは3日午前11時頃に、東日本エリアでは午後5時半頃に復旧作業の完了を予定。ただし、本格的な再開はネットワーク試験の検証結果によるとして未定という。
■複数の事象が重なり、復旧遅れる
同社によると、今回の障害は、東京・多摩ネットワークセンターで行っていたモバイルコアネットワークのコアルーター交換に起因する。通常保守の一環として2日午前1時35分からコアルーターのリプレース作業を行ったところ、新しいコアルーターで原因不明の故障が発生、音声トラフィックの通信経路が変更されず、約15分間に渡ってVoLTE(Voice over LTE)の音声通信が断絶、VoLTE交換機からアラートが発生した。この作業は外部委託ではなくKDDIが実施していたという。
このため午前1時50分に、手順に従って古いコアルーターへの音声トラフィックの切り戻し作業を実施。午前2時に事故対策本部を立ち上げた。しかし、午前2時17分頃から切り戻しに伴うアクセス集中によって、VoLTE交換機で輻輳が発生した。同社は午前2時52分にウェブサイトで障害情報を公開した。
午前3時から午後3時22分の約12時間にわたり、VoLTE交換機の負荷を低減するため、契約者端末からの信号接続要求の流量を制限。VoLTE交換機での呼処理プロセスのリセットと流量制限、無線設備でのデータおよび音声の接続要求の流量制限も実施した。
しかし、午後3時22分から加入者データベース(DB)の処理負荷が増加したという。取締役執行役員専務 技術統括本部長の吉村和幸氏によると、通常は契約者が通話やデータ通信をしていない状況でも端末と通信設備との間で、50分に1回の頻度で通信を行い、その際に位置情報を加入者DBに登録している。加入者DBでの処理後にVoLTE交換機にも位置情報が反映され、これがそろっていることで正常な通信が行われるという。
加入者DBの負荷の高まりは、上述のVoLTE交換機の負荷を軽減する各種作業の影響で、加入者DBへの位置情報の登録処理が不安定になったことが原因という。このため同社は、西日本収容の2台のパケットデータネットワークゲートウェイ(PGW)と東日本収容の2台のPGWを切り離し、加入者DBの負荷低減策を講じた。
さらに午後5時22分には、加入者DBに登録されるデータの不一致が発生した。今度はこれを修正する必要があり、先に切り離した東西日本収容の4台のPGWについてセッションをリセットしてデータの不一致を修正。その後に、別のPGW(計13台)についても切り離しとセッションのリセットを行ったとしている。
記者会見の時点で、障害発生のきっかけと見られるコアルーターの故障原因は調査中という。輻輳の発生による通信障害についても、事前の想定を超える事象が重なったことにより、復旧作業を手順通り実施したにもかかわらず復旧が長期化していると、同社では説明している。…
全文はソース参照
【写真】最初に発生した障害の概要。コアルーターを旧製品から新製品へ交換したところ何らかの不具合が発生した(日経クロステック)
https://cdn-xtech.nikkei.com/atcl/nxt/news/18/13226/ph2.jpg
【写真】コアルーターの切り戻し後に起きた障害の概要。VoLTE交換機へのアクセスが集中し、さらに加入者データベースのデータにも不一致が発生した(日経クロステック)
https://cdn-xtech.nikkei.com/atcl/nxt/news/18/13226/ph3.jpg
※前スレ
【KDDI通信障害】原因はコアルーター交換時の不具合とアクセス集中 負荷低減のため流量制御実施でつながりにくく 本格再開は未定 ★3 [ギズモ★]
https://asahi.5ch.net/test/read.cgi/newsplus/1656848457/ >>120
>>119を読んだ限りでは、そうなんだろうな。
DB情報の不一致の原因が掴めてないんだろう(^^;) >>125
わかりやすい
ためになった
ありがとう冗長パイセン! 今日の作業は終わったから明日作業員出てくるまではこの状態か? トドの詰まり自前の回線持ってない事業者は
残念ながらトラブルの復旧に弱い
回線のこと他所に任せてるから回線のこと分からない
トラブルも判ってないだろうなぁ > 866 自分:FBI WARNING ◆/V7CGJSSmle1 [sage] 投稿日:2022/07/03(日) 19:42:20.46 ID:3dd6rfG80 [11/14] (PC)
> >>855
> 彡"⌒ヾ
> ヽ( ^ω^)ノ ドコモの時も同じだが、一部を止めると大渋滞になって
> へノ ノ 悪循環が続くからな、完全に止めて順次流せばいいが
> ω ノ KDDIは全くできていない(グループ分けと優先順位を決めていない模様)
> > 行き当たりばったりの無計画な対応だけ > 892 自分:FBI WARNING ◆/V7CGJSSmle1 [sage] 投稿日:2022/07/03(日) 19:48:40.93 ID:3dd6rfG80 [12/14] (PC)
> 彡"⌒ヾ
> ヽ( ^ω^)ノ VoLTE交換機が故障してユニット交換して今回の大障害が発生して
> へノ ノ 同時にコアルーターも交換して更に状況悪化させたって事やろ
> ω ノ 復旧手順が無いまま無計画実行
> > > 906 自分:FBI WARNING ◆/V7CGJSSmle1 [sage] 投稿日:2022/07/03(日) 19:52:24.32 ID:3dd6rfG80 [13/14] (PC)
> 彡"⌒ヾ
> ヽ( ^ω^)ノ そういや、この大渋滞が原因でデータベースが落ちて
> へノ ノ 電話番号が消えた事件も発生したんだよな
> ω ノ
> > 〉〉114
とりあえずなんでも再起動、電源オフオンだ 位置登録要求の輻輳は、以前にあったドコモのトラブルと同じじじやわないか
原因は違うけど輻輳した理由は同じ いつ直るかもわからんってこのシステムって動かしてみないと上手くいくかもわからないようなもんなのか >>12 グローバル企業は地域のネットワーク使わないよねぇ
テスラみたいに・・・ >>118
コアルータってゲートウェイなんだな。
受信したパケットの切り分けと、
接続情報の制御・管理をやっているんだろう。
データと音声と緊急通信みたいな形で。 mmeとかpcrfとか懐かしいな
docomo関連の仕事やってたとき扱ってたわ DBが死んでるって話しあるけど、SIMに電話番号が存在せずにDB依存で処理してるのはどうなるんだ?
だいぶ前にドコモのメールDBがおかしな事になってカオス状態になった時の再来か? 会見してシステム障害だとテレビでやらないと、ショップの行列続くから、会見したのはいいと思う
ショップに行列つくるのはテレビしか見ない人達だから、テレビで報道しないとずっとスマホが壊れたと思って並んでしまうからね >>137
何々、障害対策のついでに、
コアルータの交換までやろうとしたのか?(^^;)
コストカットの成果か(^^;) >>143
当時よりルーティングテーブルが増大してるから経路復活だけでも時間がかかるだろうね
その上で加入者DBの破損(変な上書きか、一定以上更新されないため欠落してしまったか)が加わってしまったと見ている コレ、あとは復旧作業部隊は見守ってるしかできないの?
自動的に収束していくもんなの >>133
下請け孫請けで他所に頼みまくってたら、どこが悪いのかわからないという羽目になったわけか
それに下請け孫請けも自分のところではないってやるだろうしな
これ案外長期化しそう 明日にでもなおるんでないの。
つかわせないことには損害賠償の額もかわってくるだろうし
人命関連にも大きく影響しはじめる。
ドコモの通信障害事故とほぼ同じものと考えているのだが
ドコモの過去の記事が参考になる。
ドコモは改修時期を延期したことで完全復旧させたようにみえたし。
どこに問題点があるか隠れているか明確にするための耐久テストみたいな印象。
実機と実際の通信デバイスの挙動といった貴重なデータがとれたのではないか。
すべて妄想だが。 >>154
すり傷じゃないんだから自動的には治らないだろ
創造主レベルの設計なら自己治癒で収束するだろうけど >>155
pcrfにバグがあったと見ている
輻輳したときじゃないと顕在化されないような >>145
もしかしたら、壊れた原因がわからないんでないの?
原因がわからないから、復旧してもまた壊れるのかも システム自体の復旧は出来ても、位置登録の処理が追い付かなくて障害が長引くという事は、これからもあるんじゃないか これで本当にサービス終了したりするわけねーだろ( ´,_ゝ`)
ばかじゃねえのかwwww >>101
ネットワーク系、デジタルは日本の弱味そのものだからね
アナログ重視の社会体制の方が日本には向いてるよ
いつデジタルが壊れても大丈夫な状況の方がいいだろうね 通常の位置登録要求は、端末が移動してる時くらいだろう
静止時は、基地局からの情報を見て位置登録の更新の必要がある時だけ要求するんしゃなかったっけ
だから、普段はそんなにた沢山の要求はないのが、システのトラブルで一度に大量の要求があってパンクしたという感じか >>1
ぶっちゃけ一日やそこらで詳細な原因なんて解るわけないよな
だからこそ、トラブった時には元に戻して原因は後で調査するマニュアルになっってた訳だし
その元に戻す作業でトラブってしまっにっちもさっちも行かなくなった訳だが コレもう本当にダメかもしれんね
なんで最初に3G停止したの? 筑波の知りあいに聞いたら
物理的じゃないなら
ソフト障害だと言っていたので
上流のソフトで何か詰まっている
そこを流せば、秒で戻る
できないと、無期限で止まる >>166
と言うよりトラブルを想定してバックアップ(緊急対応)
予備機構をケチる癖が有る。一種の平和ボケ
どんなにトラブル回避に努めても、当たり前に発生するものとして
それに備える体制を許容する文化の醸成が必要じゃないかな? 位置登録のトラヒックがこんなにも障害を長引かせるとなれば、各社改修がありそう >>170
povo導入の費用捻出の為とか(^^;) >>166
コアルーターやソフトスイッチなんて国産品はないからな、昔はあったけど・・・
ITC勧告も日本発信のものってメディアアクセスや光多重など下位レイヤばかりだもん povoを0円運用してるけど何か埋め合わせあるの?
客として許せないんだけど?どう責任とるの? 全面復旧まで3日ぐらいかかるだろ
ダセーシステムだわ。みずほよりオンボロ >>175
むしろトラブルは当たり前に発生するものとして トラブルを許容する文化を社会に強制してきそうだw 元に戻すって事はバックアップしたデータリストアすることで、それ数百GBも数十TBもあったりしたら、リストアするだけで数時間〜数十時間かかるわけで、その間待つしか無いんや。世界最高速のSSDの並列接続でも遅すぎる。そんな世界 >>176
システムのバックアップは出来ても、移動体通信である以上は、位置情報は常に更新が必要
機器は正常になっても位置情報がリセットされたら、全ての端末が位置登録要求を出す
移動体通信の構造的な問題じゃないかな モバイル通信の基礎を知らないで勝手な推測してるバカが多くて笑う
こういう楽しい障害はそうそう無いから docomoからUQに移って5年程だが再びdocomo系列に戻る時が来るとはな
auは結構信用が有ったのだが最早それも地に落ちた
せめて今日の午前中迄に完全復旧していれば踏み留まったのに
残念ですよKDDIさん >>125
はい、ちゃいますそれ
通信キャリアのネットワークてのはあらゆる機器をこれでもかってくらい冗長してんのよ、ここも例外なくな
問題はバックアップ系にまでセッション情報を即時同期とってるとこ
だから主系で問題になってるセッションが副系にまで雪崩れ込んで、切り離すに切り離せん状況になった 現実に関東も高知、大阪
福岡は通話不可と
情報提供で出てる、異常事態だな >>162
原因は分かってるが、まだ根本は治せてないんだと思う。
輻輳でDBがおかしくなるから、流量制限をかけて少しずつリクエストを通して鎮火しようとしてる様に見える。 こっちはすでに直って電話使えるぜ
お前らいつまでもそんな所で燻ってないで来いよこっち側に SIMに携帯番号入ってないってauだけなん?
DBが機能してればSIMのIDから遡れるけど
それってDB死んだらアウトじゃないの?(´・ω・`)
IDから携帯電話問い合わせする一行程コストアップするよね
そもそもDB死んだらアウトなんだけどさ >>186
楽天は加入者DBが別なのでリソース相乗り部分(最初の経路問題による輻輳)だけだったんだろうね
ただし楽天でも同様なシステムだろうからそこの脆弱性やリカバリ能力についてはまだ未知数 土日だったことで今のところ会社員はそこまで被害受けてないが明日もこの状態なら更にやばいことになりそうだな
まぁ土日だったからこそ旅行やライブみたいな単価高いトラブルも生まれてるが 復旧作業完了
再開作業完了
これは別物あつかいなんだ 土日でよかった厨、あと一時間しかねえんだけど
どうすんのw kddiのコアルータはいろいろ高そうだな
俺のバッファローのとは性能が違うんだろうな IoT(この言葉も以前より聞かなくなったなー)をさらに進めていくと社会生活上の被害はめちゃめちゃ増大するわな。もはや電話とか画像閲覧だけじゃないから。
少なくとも別キャリアとのプラットフォーム選択が出来るようにならないと ここまで来ると
深刻なシステム障害受けてると
思うのが普通、こんなのは
日本初レベル >>204
何やったって、停電するだけで全部マヒやで。 >>203
FeliCaは外部との通信機能がなくても使える。 >>208
データセンターなら自家発で72時間は耐えられる(空調設備に食わせる部分込みで)
油槽もちゃんと持ってる
燃料の補給が出来ればかなりの長時間は行ける >>210
去年だったかドコモで通信障害あったとき駅から出れなくなったのって何が原因なんや? >>209
彡"⌒ヾ
ヽ( ^ω^)ノ 日清シスコのココナッツサブレはうまいよな
へノ ノ
ω ノ
> >加入者データベースのデータにも不一致が発生した
こりゃ直せねえわなw
4千万件もダブルチェックしながら手打ちとか笑えるで 俺と嫁の間の監視システムが停止したおかげで
数時間の自由時間を手に入れた 知ってるか?昔KDDIは通信キャリア事業やってたんだぜ?
という時代が >>220
その場合、「KDDIって何?」になってるんじゃないかね 「本格再開は未定、キリッ」
・・って、ちゃんと使えないキャリアにプラチナバンド渡しとくのはどうなのよ、マジで >>217
流石に手打ちはない。(笑)
VoLTEのシステムが回復すれば整合性が取れる筈。多分。 彡"⌒ヾ
ヽ( ^ω^)ノ 明日のサービス再開はまず無理やな
へノ ノ 今日の昼から進展していないから
ω ノ
> せいぎさんところのこうちゃくいんかな?
あそこはしょっちゅうしょうがいだしてたのに
よそのところにきびしいね ■ このスレッドは過去ログ倉庫に格納されています