【特集】KDDIの大規模な年末年始の障害における根本原因と対策（前編） ( 2013-01-24 13:00:00 )
2012年12月31日の大晦日、2013年1月1日の元旦早々、そして1月2日と3日連続でKDDIで最大180万人という大規模な障害が発生した。
そこから約2週間経過した1月16日に、これら障害に関する問い合わせのあった報道期間およびジャーナリストに対する緊急の説明会を実施したが、AppComingでは、事前問い合わせを行なっていなかった為、説明会の取材はできなかった。
説明会の当日および翌日には、多くの記事がネット上のメディアにも掲載され内容を確認したものの、個々の障害における対処が中心であり、根本原因の解消に向けた取り組みが確認できないこともあり、説明会資料を入手すると同時に個別取材を依頼し、1月22日午後にKDDIを訪問取材することができたのでレポートする。
各メディアなどの記事掲載情報については、過去記事を参照頂きたい。
- 『KDDIは、年末年始に発生したau 4G LTE関連の障害について、取材依頼のあったメディアに対して実施した。』http://app-coming.jp/364.html
各メディアの報道を見ると、情報量、記事内容の難易度（専門用語の有無など）、主として取り上げているポイント（見出し）もバラバラではあったが、本特集では、前編に障害の概要および根本原因への対策について技術的な詳細を省略したサマリー的内容とし、後編では、サマリーの各内容詳細について、質疑応答の内容を含め、やや技術的な表現を含む内容とする。
1. 発生した障害
3日連続での大規模な障害発生ではあったが、それぞれは3つの別々な障害であり、以下の通り対処策が進められている。
- 12月31日：au 4G LTEデータ通信サービス停止
概要：過負荷状態に起因するサーバの処理能力不足と通信機器の設定ミスによるau 4G LTE対応機種におけるデータ通信サービスの停止
発生時間：2012年12月31日午前0時0分～2012年12月31日午前4時23分・4時間23分
影響数：最大180万（4G LTE端末）
対策：起因したサーバへのアクセスを同日に一次停止の後、設定変更および改修を実施（完了済み）、サーバの増強（1月24日完了予定）
- 1月1日：au ID認証システム関連サービス停止
概要：au ID認証システムの過負荷状態と設定ミスに起因する当該システムを使用するサービスの停止および断続的な停止
発生時間：2013年1月1日午前0時12分～午前2時29分・2時間17分、および、2013年1月1日午前9時33分～午後1時33分・4時間
影響数：最大80万人および最大150万人（重複あり・対象サービス利用者）
対策：原因となった設定変更、監視項目および手順の見直し（完了済み）
- 1月2日：au 4G LTEデータ通信サービスの停止
機器のソフトウェアバグと手順書の漏れに起因する運用者の作業ミスによるau 4G LTE対応機種におけるデータ通信サービスの停止
発生時間：2013年1月2日午前0時17分～2013年1月2日午前2時10分・1時間53分
影響数：最大175万（4G LTE端末）
対策：手順書の整備・訓練実施（完了済み）、バグの改修（1月30日完了予定）、過負荷時の装置間連携動作を確認・点検。（1月30日完了予定）
何れの障害においても、音声通話および3G端末におけるデータ通信は正常に稼働しており、12月31日および1月2日の障害では、LTE端末がLTEエリアまたはEVDOエリアの何れにおいても、データ通信をできないという障害であった。
2. 取材主旨（根本原因の解消・解決に至っているのか？）
以上の通り、3つの障害は、今月末までに全ての対策が完了する予定だが、果たしてこれらは『根本原因を解決しているのだろうか？』『今後、これらとは異なるものの類する障害発生を抑止するための対策が図られているのだろうか？』といった疑問や懸念を確認するために、訪問取材を行った。
取材は、KDDI広報部に大まかな主旨を事前に伝えた上で、取材窓口となった広報部から1名、ネットワーク本部コアネットワーク技術部から1名、技術統括本部運用本部運用品質管理部から1名、新規事業統括本部新規ビジネス推進本部コンテンツビジネス部より1名の計4名から、説明会資料を元に簡単な解説を受け、AppComingが当日に持参した質問事項への回答とディスカッションにより、これら根本原因の解消に向けた取り組みを確認するに至った。
3. 設定の管理およびチェック機能が働いていないのでは？
関連する複数部門での相互チェック機能があり、社員が実施しているが、結果としては多数のパラメータ（数は状況掌握のために確認しているが、KDDIの要望により非公開とする）の精査が不十分で誤りに気付くとができなかった。
今回の障害に関連する機器・サーバ設定値をチェックしたところ、今回の1点のみが誤っていたとのことで、一定のチェック機能は働いていたと言えるが、今回のような重大な事故とも言える障害に至ったことで、相互チェックするというルールだけではなく、より具体的なチェック機能の整備が期待される。
また、今回のような障害は、各拠点センター側で発生しているが、約2万の基地局側の設定については精査していないという。但し、基本設定は共通であり、各基地局毎の状態・運用により電波の吹き方などの設定変更はあるものの、障害発生時には、設定管理データベースにより、基地局開設からの変更履歴も管理がされており、問題は無いとのことだ。
1基地局での障害および障害時の隣接する基地局の管理・コントロールのみであれば、各拠点およびセンター側で十分に対応できることを確認した。
4. 人の問題は、今回とは異なる障害で同様の問題が起きるのでは？
運用に契約スタッフは操作要員として採用しているが、社員が各チームに配備されており、管理がされているという。 また、手順がないインシデント発生時に運用者（チーム）のみで判断してエスカレーションしていないのでは？という疑問があったが、1月2日の障害発生時、上長へのエスカレーションは行われ、電話会議により指示を出していたという。
2日続けての大規模障害直後の警戒態勢に入り、障害発生時は30分以内に解消するという目標を設定したという背景もあり、年末とは異なるアラートで、かつ実際にはユーザ側での障害が発生して無いにも関わらず、機器をリセットしたことで、ユーザ側での障害を発生させている。
アラート自体がバグで発報されているが、鳴り止まぬアラートの状態など、切り分けができないままでの緊急リセット自体が理解しがたいが、それ以前に、リセットしたことによる過負荷までも想定し、かつ冷静であれば、正しい被害状況の確認を優先して最後の手段とも言えるリセットは行なっていなかったかもしれない。
いち早く復旧しなければいけないという追い込まれた心理状態、正しい判断や行動ができなかったこと、正しく状況を伝えきれないこと、あるいは障害を正しく把握できない状況下での例外処理は、今後も起こりうることだろう。
これらのへの対策は、『本来は手順に従って行うもの』という前提から手順書の見直し・修正が必要であり、月末までには完了する予定だ。更に、例外処理に対処をする為にも、エスカレーションを含む運用上のルールの見直し等により、根本的な問題を解決していくという説明があった。
ソフトウェアバグ、誤報（アラート）と実際の差異、適切な判断・行動のためのスキルと冷静さ、漏れなき手順の整備、例外処理のルール改善など、全て人系に依るものだが、担当した個人やベンダーの問題ではなく、組織としての問題として、説明にあったような取り組みにより、根本原因を解消することが期待される。
5. 品質保証への取り組みが不足しているのではないか？
急速な4G LTEユーザの拡大は、従来とは異なるLTE関連システムを急速にスケールアウトしなければいけないという状況がある。
NTTドコモのLTE展開においても、LTE対応スマートフォンの普及が開始した2011年12月以降に連続して大規模障害が発生したが、今回のKDDIのケースにおいて、その教訓は活かされていないのかと思える今回の一連の障害は、品質保証の取り組み＝テストが不十分な事が根本原因にあるのではないか？と思われる過負荷障害だった。
「結合テストも過負荷試験も行なっていた」が、テストケース（シナリオ）の網羅性の不足や、異常な負荷を想定する限界値までを確認するような過負荷テストや、長時間に渡る負荷テストは事前に十分に行われていなかったようだ。
そこで一部報道にあった１～２億円という数字だが、これは、過負荷試験装置の導入予算としての数字だった事を確認ができた。 過負荷装置の予算としては、十分な予算範囲ではないかと思われ、検証環境の強化は、根本原因解消に大きく貢献することが期待される。（その他の対策を含めて１～２億であったら少なすぎるということになるが、限定的用途であり、その他は別予算・別体制であることが確認できた。）
6. なぜ年越しのタイミングではなく大晦日の０時過ぎに過負荷が発生したのか？
１日のピークとなる過負荷状態は、毎日0時過ぎに発生していることを11月には掌握していたという。
具体的には、様々なアプリケーションのアップデートや、ニュース・天気の配信などが、Android・iPhoneの何れも0時台をピークとして発生することで過負荷状態となり、直前23時台の7倍のトラフィックが発生するという。（その他の時間帯にも過負荷は発生しているが0時台が最大だ）
対策として、12月初頭にサーバ増強したが、今回の障害に至った。当然ながらKDDI提供のアプリケーションが原因ではない。
負荷発生の主たる原因は、サードベンダーのアプリやウィジェットであり、KDDIは個別のアプリ名の言及を避けたが、広く普及・インストールされていることから、プリインストールされているアプリ、スマートパスで提供されているアプリ、まとめてアップデート配信が実施されるようなアプリプラットフォーム（ソーシャルゲームプラットフォーム）など、KDDIが積極的に提携・採用しているアプリやウィジェットが無関係では無さそうだ。
NTTドコモやソフトバンクでは、今のところ、同様の障害には至っていないものの、同様な負荷が発生している可能性も十分に考えられる。
限られたモバイルネットワーク資産を一括更新・配信により、異常な負荷を発生することをKDDI単体で抑止することは困難であろうことから、この根本原因を解決するには、アプリデベロッパー・プラッフォームベンダー側の改善協力が必須ではないかと思われる。
本取材においても、各社の情報共有については実施しているという話があり、1月21日のNTTドコモ春モデル発表会での囲み取材に答えた加藤社長も、キャリア各社で障害などに関する情報共有をしっかり行う事を名言しており、毎日0時に負荷のピークが発生するような事象は業界共通の懸念として、広くデベロッパー・ベンダー側に改善を要望することが、早期の根本原因解決に繋がるものと思われ、対応が期待される。
外部要因、ソフトウェアのバグ、人為的ミスなどにより、障害は発生し得るものという大前提の中で、如何に根本原因を排除し、あるいは、原因とならぬように回避するかといった対策を継続することが再発防止や類する障害発生の防止・抑止において、とても重要だ。
発生した障害の規模や影響度、障害への対処策も必要かつ重要な情報ではあるが、情報の不足や偏りから、根本原因の解消に向かっているのか判断ができない場合には、記者以外の専門家やエキスパート、あるいは一般コンシューマの厳しい視点・意見・懸念事項を伝えていくことが、重要な改善策になるだろう。
以上、取材サマリーとして、専門用語や技術的な内容を避け、訪問取材での確認内容をレポートしたが、後編では、より具体的な質疑のやり取りなどを含め、レポートする。
関連記事
- 『KDDIは、年末年始に発生したau 4G LTE関連の障害について、取材依頼のあったメディアに対して実施した。』
http://app-coming.jp/364.html
- 【特集】KDDIの大規模な年末年始の障害における根本原因と対策（前編）
http://app-coming.jp/367.html
- 【特集】KDDIの大規模な年末年始の障害における根本原因と対策（後編１）
http://app-coming.jp/368.html
