20:06)年末年始、auのスマートフォンが繋がらない、もしくは繋がりにくく感じたことはなかっただろうか。IDに障害が発生したためだ。KDDIは1月16日、年末年始に続いた障害について説明会を開催した。最初の障害は、12月31日未明、auのLTEサービスに発生した。LTE対応モデルを対象に、0時~午前2時55分まで、通信サービスが利用できない状態になり、続いて午前2時55分~午前4時23分まで通信が利用しにくい状態になった。障害は全国で発生し、影響数は最大180万人に及んだという。原因はアクセス集中によって、加入者認証サーバーがオーバーフローを引き起こしたことに起因する。IDの認証が必要な各種サービスが利用できない状態になり、同日午前9時33分~午後1時33分にかけて、サービスが利用しにくい状況になった。この障害では、最初の利用不可の影響を最大80万人が、続く利用しにくい状態の影響を最大150万人が受けた。影響を受けたユーザーが重複している場合もあるという。原因は、データベースに必要なメモリを割り当てる(メモリアロケーション)処理に不適切な値があったためという。1月1日の障害1月2日の障害3度目の障害は、またしてもLTEサービスで起こった。LTEが全国で利用できない状態になった。原因は、信号制御装置のアラームが誤作動したことによるものだ。原因は異なるものの、いずれの障害も認証系にトラブルが発生しており、午前0時過ぎに最初の影響が出ている。平時であれば利用者の少ない時間帯といえるが、年末年始ともなれば夜更かしをしているユーザーも少なくない。LTEの障害については、自宅であればWi-Fiなどで通信を継続することもできたかもしれない。年末年始で帰省や旅先などWi-Fi環境のない利用者もいたことだろう。障害は通常、24時間以上続いた場合に利用者への返金措置や、翌月以降の利用料から返金分を差し引く形がとられる。今回の障害はいずれも24時間に満たないため、KDDIでは現時点で返金措置などを講じる予定はないとしている。12月31日未明の障害の詳細12月31日未明に起こったLTEサービス通信障害は、瞬間的に通常の7倍程度のアクセスが集中し、「加入者プロファイルサーバー」と呼ばれる認証システムが許容量を超えたことがきっかけになった。戻って通信許可、つまり接続が確立される。31日未明、一時的に接続要求が集中し、通信許可が許容量を超えたために加入者プロファイルサーバーのいわゆるバッファがオーバーフローを起こした。許容量を超えた接続要求信号は破棄されるため、応答がなく繋がらない状態になる。加入者プロファイルサーバーで認証された場合についても、その後の信号制御装置や信号中継装置でつまづく事態になる。信号制御装置は、最大で3秒間、加入者プロファイルサーバーからの応答を待ち、応答があれば信号中継装置へと応答を送る。信号中継装置側は最大2秒間、応答を待つ形になっていた。通常時は約0.1秒で認証応答がある。今回の障害では、アクセス集中によって、加入者プロファイルサーバーの認証処理が遅延し、認証に2秒以上かかる場合が出てきた。3秒以内でせっかく信号制御装置は通過しても、その先の中継装置は2秒以上の認証信号ははじいてしまう。認証が降りなかったLTE端末は、再び接続しようとするため、さらに接続要求数が増えて信号が輻輳状態になり、端末からの新規の接続ができない状態を引き起こしてしまった。KDDIでは、今回の障害対策として、信号制御装置の待受応答時間を3秒から1.2秒に変更する。仮に加入者プロファイルサーバーから応答がない、もしくは応答が遅い場合でも、信号制御装置が代理応答することで、信号中継装置のタイマー超過を防止する。代理応答するということは、加入者プロファイルサーバーで認証しないことを意味する。加入者プロファイルサーバーは、1カ月あたりのパケット通信量が7GB制限にかかるかどうかをチェックしている部分だ。7GB制限の対象者はこのチェックによって通信規制などがかかっている。今回の対策によって、認証設備からの応答がない場合や認証遅延が発生した場合、7GB制限をチェックしない仕組みになる。IDを利用する多くのサービスが影響を受けることになった。管理機能などで使われている。ポータルサービス「auスマートパス」などKDDIの自社サービスだけでも約120のサービスで認証が必要で、一般加盟店のサービスでは約2000サービスが影響を受けた。携帯電話の課金認証システムでは、通常月初に多くの処理が行われる。これは月額制サービスがあるためだ。auもかんたん決済利用限度額のクリア処理が毎月1日に行われるので、月初は処理が集中する。このため、KDDIでは、処理が集中しても対応できるような性能を確保しているという。KDDIは、2012年11月、データベース処理能力を拡大するためにハードウェアを増強したが、その際、処理を行うためのメモリの割当設定に誤りがあった。データベースが処理を行う場合、データを処理するメモリを割り当てるため、一旦CPU側でメモリ領域を作って解放処理する。パラメーター設定を誤ったことで、CPUに高い負荷がかかり障害が発生する事態になった。この不具合は、メモリの断片化が進み高負荷状態になると発生するというものだった。11月にデータベースを増強し、認証処理が多い12月1日を迎えた段階では、メモリの断片化が進んでおらず障害には至らなかった。KDDIでは、今回の障害では設備増強の必要はないとしており、パラメーターの設定を修正することで対応した。具体的には、処理領域を作るのではなく、空いてるところで随時処理する形に変更した。この方法ならメモリの断片化の影響を受けないという。障害発生時の復旧手順については見直すこととした。1月4日に実施しており、障害が起こっても復旧手順が短縮化されるという。1月2日の障害の詳細1月2日の障害は、機械的な不具合というより人為的要因によるLTEサービスの障害と言ってもいいだろう。1月2日の障害は、12月31日未明のLTE障害でも登場する信号制御装置のアラームが誤って作動してしまったことが引き金となった。前述した通り、LTE端末が通信する際には、端末が接続要求を出し、認証装置側がそれを認証して接続が確立される。“セッションをはる”などと言われる。信号制御装置では、利用通信量などを制御している。この装置には、呼び出し処理用のバッファとそのログ用バッファがあり、それぞれ、メイン装置と予備装置がある。切り替えて、メイン装置側の対処を行うという。今回、呼び出し処理用のログバッファが多少遅延した際、通信に影響がないにも関わらず、ソフトウェアが異常だと誤判定し、装置アラームが作動した。ソフトウェアの不具合によるもので、「バッファオーバーフローアラーム」の通信異常として警報を出してしまった。ここで人為的なミスが発生する。異常を検知した際にどう対応すべきかなどが記載された対応手順書に、アラームが作動したらどうすべきか記載がなかったのだ。担当者は、手順書に記載がないため、本来ならばメイン装置から予備装置に切り替えて対処すべきところを、メインも予備も含めて装置全体をリセットしてしまった。このため、LTE端末との接続が一旦全て切断された。切断されればLTE端末は再び接続しようとするため、一斉に接続要求信号を出し、過度にアクセスが集中してしまった。KDDIでは、1月30日までに信号制御装置のソフトウェア不具合を改修する。1月8日にはアラーム対応手順書を整備して、訓練も実施したという。技術担当者のコメントKDDIは、障害は連続したことを受け、1月30日までにアクセス集中時の装置館連携など、輻輳制御メカニズムを総点検する。運用本部長の内田義昭氏は、「すでに多くの部分で調査は終わっている」と話した。内田氏によると、12月30日時点で通常の6倍以上のアクセスがあったという。同社は31日も乗り切れると踏んだが、「結果を見ると耐えられない設計だった」(内田氏)という。障害を受けた今回の対策で、通常の14倍のアクセスにも耐えられる設計になったという。内田氏は、「日々のトラフィックを監視し、増強するかどうか判断している。認証部分については早め早めと考えていたが、スマートフォンについてはもっと早めに対処する方法を考えていかねばならない。現在は1分単位でトラフィックを監視しているが、もっと細かく1秒ぐらいの間隔で見ていかなければならない」と語った。同氏はLTE時代はさまざまなアプリが通信を行い、瞬間的なアクセス集中と言っても、それが1秒間の通信なのか、2分続くのか考慮する必要があるとし、「これまではピーク値ばかり気にしていた」と漏らした。ネットワーク装置の設計については、「日夜力を注いできた。個々の装置は素晴らしく、装置の両隣の装置もうまくつながっていたが全体を見たときにどうだったのか。深掘りして考えてきたつもりだったが充分ではなかった。一度集中してレビューしていく」と語った。このほか、手順書の不備については、「装置アラームが発生したら何をすべきかそこがぽつんと抜けていた。抜けていた」と話すに留まった。