【特集】KDDIのLTEネットワークは大丈夫なのか？【1】LTE通信障害の原因と対策に関する記者会見（前編） ( 2013-06-12 18:30:00 )
『この度は、お客様・ご関係の皆様に御迷惑ご心配をお掛けしまして、改めてお詫び申し上げます。』と、KDDI田中社長より一連のau 4G LTE障害についての謝罪からスタートした。
KDDIは、この日（2013年6月10日）「一連のLTE通信障害の原因と対策について」の記者会見を行い、冒頭の謝罪の後、スライドに沿って、直近3回の障害について田中社長自ら丁寧な説明を行った。
昨年にスタートしたKDDIのLTEサービスに関連する大規模障害は、年末年始にも発生しており、4月27日・5月29日・5月30日の3度の長時間に渡る障害発生、またLTEエリアの誇大広告問題により、ユーザからの信頼度・期待度は大幅に低下しかねない事態での、記者会見開催だ。
以下、会見での説明と、「※」にてAppComing編集部コメントを前編後編に分けてレポートする。
（質疑応答・囲み取材・広報メール配信などによる情報を含むものとする。）
【1】4月27日・5月29日・5月30日の障害にについて、「サービス影響の概要」スライド通りに説明。
※ 東京・神奈川・山梨の一部で、59万人・6時間1分、56万人・18時間43分、64万人・9時間58分と、エリアは限定的ながら、深夜帯での障害とは異なり、何れも障害規模・影響が大きい。
【2】4月27日の障害直後の決算発表会（4月30日）で、改善について約束し、経営の最重要課題として取り組んだ矢先に本件障害が発生し、『大変申し訳なく思っています。』と、再びの謝罪。
※ 限られた質疑応答時間で、確認はできなかったが、1か月足らずで抜本的な改善を一気に図ることはできなくて当然だが、スグに実施できた事、できるのに実施していない・できていない事（人員増強や判断プロセス改善など）、より具体的な計画・目標や、そのマイルストンについて、もう少し具体的な説明があっても良かったのではないかと思われる。
【3】「一連のLTE通信障害の概要」スライドでは、3回の障害が何れもLTE基地局制御装置（MME＝Mobility Management Entity）に起因していることを概要説明。
※ このスライドの段階で、5月29日の障害から、ハードウェア障害時の通信障害再発リスクが高い事、バグを誘発する可能性が高い事への意識・認識が十分であれば、翌日にリリースを行わずリスク対策を十分に検討・実施していたのではないか？何を焦っているのか？なぜリリースを最実施すると決めたのか？と感じる対処だ。
【4】詳細説明の前に「au携帯電話ネットワークの全体構成」により主にLTEの実データと制御信号（Signaling Data）の流れについて説明。
※障害の原因となったMMEは制御信号データを処理するものであり、制御信号データが流れなければ、LTEの実データ通信は停止してしまう事になり、必須・重要な機能を担っている。
【5】LTE基地局制御装置(MME)について、全国で19セットあり、本件障害の発生した多摩のデータセンターでは、今回の東京・神奈川・山梨の基地局用の2セットと、別に障害が起きていないペアがある。
MMEには、2個のネットワークカード（Network Interface Card＝NIC）と、基地局の接続管理およびLTE端末の移動管理を行なっている10個の「呼処理カード」により構成されている。
※ 多摩には、現状4セットが配備されていることになる。各基地局に接続されたLTE端末は、2つのMMEの何れかに接続されている。 基地局単位でMMEを固定して接続してはいない。ペアとなっている片方のMMEが停止しただけの状態ならば、基地局単位で停止はしない事になるが、LTE端末の再接続により残された片方のMMEに負荷が集中することになることが分かる。
【6】4月27日のデータ通信障害の詳細について、稀にしか発生しない60バイト以下のフラグメントしたパケットがDNS起因で3件発生し、それにより3個のネットワークカードをダウンさせるバグが顕在化した。MMEの片方でネットワークカードが2個ともダウンしたことで、ペアのもう片方に制御信号が集中するが、そこでもネットワークカード1個が同理由でダウンしたことで、呼処理カードのリカバリー処理に関するバグまでも誘発・顕在化させ、輻輳状態に陥り、完全にこのMMEペアが機能しなくなった。
※ 60バイト以下のフラグメンテーション処理が、稀にしか発生しないにせよ、過去に発生していなかったのか、発生してもバグによる症状が出ていなかったのか、或いは症状は出ていたが原因を追求できておらず何らか手動の対処で済ませていたのか、手動で対処していたとするとその対処が運用側で共有されていたのか、など重要なポイントだ。
【7】5月29日のデータ通信障害の詳細について、4月27日の障害原因を解消する修正ファイルを1セット目の小山でリリース後、数週間の運用で問題無いと判断し全国で順次リリースを進め、4セットのMMEまで障害なく完了していたが、5番目となる多摩でのリリースではリリース中にハードウェア障害が発生し、元の状態に戻す（ロールバック）をするという判断に至り、ロールバックに伴い必要となるリセット・再起動のため、MMEの片方を停止させる事となった。
MMEの片方が停止したことで、ペアとなるもう1台のMMEにアクセスが集中し、4月27日と同様のリカバリー処理に関するバグを再発し、同様に輻輳が発生し障害発生に至った。
あるレベルの処理能力を超えると、この60バイト以下のフラグメンテーション処理時のバグが顕在化することが分かっている。
※ 4月27日のリカバー処理におけるバグ顕在化の段階で、過去に同様の事象が発生していないことから、60バイト以下のフラグメンテーション処理が発生すると同時に、何らかがフックとなり輻輳が発生するという状況からすれば、その「何らか」のフックを事前に特定し、対処してから実施すべきではなかったのか、或いは5月29日時点ではそれを特定できていなかったのかという事になる。
つまり、「あるレベルの処理能力を超える」ことが「何らか」だと、いつ判明したかに依るが、それが今回のリリース前に掌握しているのであれば、片系ダウンによる輻輳発生は十分に想定しうる事であり、MME2台ペアでの運用から3台で余裕を持たせてからリリースを実施していれば良かったのではないか？ということになる。或いは、「何らか」を掌握・切り分けせずに小規模なMMEセットからリリースしようという判断をしたのであれば、運を天に任せるがごとく、安易過ぎる。
4回目までのリリースは首都圏以外で実施したとするならば、最も負荷が掛かるであろう、障害時の影響度が大きい東京を含むエリアでのリリースに於いて、読みが甘かっただけで済む問題なのかと思える運用ではないだろうか。昨年末の障害の教訓は、ここで活かされていなかったのではないかとさえ思える。
【8】5月29日の音声通信障害について、LTEで接続していた端末が、全て3G網にハンドダウンしてしまうが、加入者情報管理システムがハンドダウンされた接続通知を受信し、MMEにその状態を通知するが、MME自体が既に処理できない状態になっており、MMEと2台ののHSS間が輻輳に至った。その輻輳により、音声通信を試みた端末の内、加入者管理ノード（SLF）を経由して輻輳中の2台のHSSに接続できなかった場合に、音声発着が困難または不可となる状況およびSMS配信遅延が発生した。（輻輳状態ではないHSSに接続した端末では、音声通信の障害は発生していない。）
※ 1つの輻輳が、別な輻輳を生んでしまうという、やむを得ない典型的なケースの1つであろう。SLFから輻輳していないHSSに接続した場合に、音声通信障害が発生していなかったということで、一定の冗長性はあったということになる。
【9】5月30日のデータ通信障害について、早期改善が必要と考え、連日の修正ファイルのリリースを行ったが、前日とは異なり、リリース作業を行うMMEへのトラフィックを徐々にペアとなるMMEに移すことで、リリースするMMEの負荷を抑制した状況で行なったが、トラフィックを受け入れるペア側のMMEで、3度目となるリカバリー処理に関するバグを再発し、同様に輻輳が発生し障害発生に至っている。
※ この2日目のリリースでの障害によりに、どのレベルの処理能力でリカバリー処理に関するバグが発生しているのかを掌握しないまま、トラフィックを移動させていた事が推察される。 安易な判断により、障害翌日のリリース実施で再発しており、昨年から発生している障害の根本原因は「人」なのではないか？ 5月29日のリリースにおいてハードウェア障害があろうと無かろうと、このリカバリー処理に関するバグが顕在化し、障害が発生している可能性は高いと推察する。
「あるレベルの処理能力」は、この緩やかなトラフィックの移行でさえも発生し、60バイト以下のフラグメンテーション処理が同時に発生している。 つまり、60バイト以下のフラグメンテーション処理は日常からあり、「あるレベルの処理能力」は、2台のMMEでは再現する可能性が高く、せめて29日の障害後に増強後に、或いは「何らか」を特定後に実施すべきという判断を行なっていれば、30日の障害は発生していなかったであろう。
30日のリリース前に「何らか」を掌握できていなかったとしても、10日の会見時には特定しており、本件の修正ファイルリリースを行わない限り再発していなかった障害を自ら余計に発生させているだけという点で、「人」の問題は根深いと考える。
【10】一連の通信障害の課題について、表でまとめている通り、2つのクリティカルバグへの対処、ハードウェア品質向上、運用品質向上・復旧時間短縮、高負荷耐性の向上を上げている。
「現在安定的に運用をしている状況」「暫定的に動いている」としているが、高負荷・過負荷対策としてMME2台構成を3台構成にするなどのロードシェア（負荷分散）も行なっている。
※ 顕在化したバグフィックスは完了しており、過負荷・高負荷対策を行いつつリリースをしていけば、全く同じ輻輳状態の発生・通信障害の発生は起こらないであろう。
ハードウェア品質の向上も、高可用性のあるハードウェア、故障率の低いユニット・パーツの組み合わせで、妥当かつ現実的なレベルで（費用面も含む）実現できるであろう。
一方、「運用品質の向上と復旧時間の短縮」という課題は、主に「人」「組織（または組織の体質）」に依るもので、過去の積み重ねもあり、根が深い問題だと考えられる。
【2】LTE通信障害の原因と対策に関する記者会見（後編） >>
- 【特集】KDDIのLTEネットワークは大丈夫なのか？
【1】LTE通信障害の原因と対策に関する記者会見（前編）
http://app-coming.jp/485.html
【2】LTE通信障害の原因と対策に関する記者会見（後編）
http://app-coming.jp/486.html
【3】障害は頻発したが、LTE通信品質が高いKDDI
http://app-coming.jp/487.html
- 【特集】KDDIの大規模な年末年始の障害における根本原因と対策
前編 http://app-coming.jp/367.html
後編1 http://app-coming.jp/368.html
後編2 http://app-coming.jp/369.html
