 |
| KDDIが年末年始の障害について説明 |
KDDIはこの年末年始、携帯電話サービス「au」において通信障害とサービス利用障害を3件立て続けに起こしました。
昨今、「iPhone 5」や「HTC J Butterfly HTL21」など、魅力ある端末が多く揃っていること、「auスマートパス」や「auスマートバリュー」といったよく考えられたサービス、そして、これら両者を支えるネットワークサービス「4G LTE」が非常に上手くかみ合って、1年と少し前までが嘘のような絶好調ぶりを見せてきたKDDI。
極端な話、今回の一連の障害は、それを一気に潰してしまいかねないものです。何故、起こってしまったのか。既報の通り、筆者は16日に開催された説明会に急遽参加しました。
また、それに加えて、後日、本ブログメディアのパートナーである「AppComing」の中の人のアレンジで実務担当の方に話を聞く機会も得ました。これらを総合して、筆者なりに事態を説明してみたいと思います。縦長になると思いますが、お付き合いください。
■2度の通信障害は何で起こったの？対策は？
4G LTEの障害を説明する内田氏
昨年12月31日と、今年1月2日に発生したLTE通信サービス「4G LTE」の障害についてはKDDI 技術統括本部 運用本部長の内田義昭氏が説明を行いました。
12月31日の障害の概要図
同じく詳細図
2回の障害は、原因が異なります。まず、12月31日の障害については…
といった感じで発生しました。SPSは、ユーザーの契約状況や通信状況を保存しているサーバーで、月間通信量が7GB超えた場合の通信速度制限などは、ここに保存されている情報をもとに行っています。保持している情報を、実際に端末の接続制御を行っている信号制御装置に渡して、各種制限などを行っています。
SPSに対するアクセス集中は、日付をまたぐ頃に毎日起こるものだそうです。iOSにせよ、Androidにせよ、データの更新確認を日付が変わると同時に行うアプリが多く、それをきっかけにして通信を開始するケースが多いからです。
12月31日は、そのような日付またぎのアクセスが直前の7倍も集中し、SPSの処理バッファーがあふれてしまいました。処理の応答には“制限時間”が設けられていて、SPS～信号制御装置間は3秒に設定されていました。要するに、この区間では、処理バッファーがあふれたとしても、再処理も含めて3秒以内に応答できれば「正常」に処理されたものとなるのです。
ところが、信号処理装置～信号中継装置間の制限時間がより短い2秒に設定されていたために、遅れながらも処理された信号まで破棄されてしまいました。結果として、信号制御装置がLTE端末の接続を全部切断してしまいました。
当然、接続を切断された場合は、端末側から再度接続を試みます。今回は最大で180万台の4G LTE端末が再接続要求を行うことになったため、信号制御装置が輻輳(混み合って繋がりにくい・繋がらない)状態になり、通信障害、となってしまったのです。
4G LTE端末には、ハンドオーバーできないフェムトセルエリアで使う時のことを想定して、LTE機能をオフにする機能が付いています（決して、強制的に3Gにつないで……、という意図で用意している訳ではありません）。この機能を使って、3Gで接続すれば何とかなるのでは、とも思われる方もいるかもしれませんが、上のスライドでも分かる通り、4G LTE端末が3G環境下にいる場合も、接続制御は4G LTE用の設備で行うため、影響を回避することはできませんでした。音声回線は、どのエリアにいても別系統の制御下にあるため影響を受けませんでした。
12月31日の障害に対する対策
この障害に対する対策として、障害のきっかけとなった処理の応答制限時間の不整合を解消しました。本来であれば、返答される側の時間を長めに取るべきだったのに、返答する側の時間の方が長く設定されているのはおかしなことです。そこで、返答する側であるSPS～信号制御装置間の応答制限時間を3秒→1.2秒に短縮しました。こんなに短くて大丈夫か、と思うところですが、本来は、平常のピーク時でもコンマ秒単位で処理できるので、問題ないようです。それだけの能力があるなら、なんで12月31日は処理しきれなかったのか、不思議でならない訳ですが、この辺の理由は明らかにはなりませんでした……。
ユーザー増を見越して予定されていたSPSの増強も前倒して行いました。これで、今回の障害発生時で比較すると、14倍のアクセス集中があっても正常に処理できるようになったそうです。過負荷時を再現して、事前に問題を洗い出すためのテスト環境も、数億円の追加投資で整備します。この手のテストツールは、数億円で結構すごいものが用意できるそうです。
これだけの対策をしてもSPSへアクセスが集中したり、故障したりして応答できなくなった時に備えて、信号制御装置が「代理応答」する機能も追加されました。これは、SPSが1.2秒以内に応答できなかった場合に、信号制御装置が「認証を通過した」という仮の応答をすることで、正常に通信を継続できるよう配慮したものです。
この場合、7GB以上通信しても通信制限をかけることができなくなる、という問題点がありますが、正常な通信を継続する、ということ重きを置いた結果です。接続認証は定期的に行っているので、SPSが正常になった後の認証で、通信制限対象にはきちんと通信制限がかかるようになっています。
1月2日の障害の概要図
同じく詳細図と対処法
1月2日の障害は、結果こそ一緒ですが、12月31日のそれとは発生原因が根本的に異なります。流れとしては…
という感じです。信号制御装置は、予備系の装置に呼処理バッファーと呼処理ログバッファーをリアルタイムコピーしています。本来は、「ログ」の方は通信に影響を与えないため、非優先処理で、ここに障害があっても“障害”とはみなされません。ところが、今回はソフトウェアの不備によってログのコピー遅延が障害と判定されてしまい、アラームが鳴動してしまいました。
通常、アラームが鳴動した場合は、復旧手順書に従って設備を予備系に切り替えて、不具合の起こった場所を交換して…、という作業をすれば問題ありませんでしたが、今回のアラームに対する対策が手順書から抜け落ちていたことと、障害が連続していた焦りもあり、装置全体を再起動してしまいました。結果、31日の障害同様、4G LTE端末の接続が全部切断され、再接続要求を処理しきれなくなった結果、繋がりにくい状況になってしまったのです。
この障害の根本原因は、信号制御装置のソフトウェア不備です。そのため、今回のエラーに対してアラートを発報しないようにする改修を月末までに行います。
一方で、手順書の不備や、復旧を焦ってしまったことなど、「ヒューマンエラー」の側面が、今回の障害を引き起こした一因であることも否定できません。そこで、障害発生時の復旧手順書の再確認・整備と、対応訓練の実施をあわせて行っています。
機械も最終的には人間の手によって維持・管理されています。マニュアルのチェックや訓練を定期的に積み重ねることも大切です。突発的な事象に対する対応能力は、日々の積み重ねによって高まっていくはずです。他キャリアの障害事例も含めて、共有していくことで、より強固なネットワークを作っていって欲しいところです。
■au ID認証決済のシステム障害は何で起こったの？対策は？
決済障害を説明する雨宮氏
一方、元旦にはau IDの認証決済システムにおいて障害が発生しました。これについては、KDDI 新規事業統括本部 新規ビジネス推進本部長の雨宮俊武氏が説明を行いました。
障害の概要
障害の影響範囲
障害は2度発生しました。最初に発生した障害では、深夜0時12分から2時間17分、最大で80万ユーザーが継続的にサービスを使えなくなりました。その後、一時的に復旧したものの、午前9時33分ごろから4時間、最大で120万ユーザーが断続的にサービスを利用しにくい状況が再度発生しました。2回の障害で、あわせて約1000件の問い合わせがあったそうです。
この障害の原因は…
といったところです。一旦復旧したものの、最初の障害時には、原因の特定ができなかったため、再度同じ原因でシステムが不安定になってしまったのです。
KDDIでは、au ID利用者増に備え、11月にサーバーの処理能力を増強したばかりで、現状のユーザー数であれば、かなり余裕で処理ができるはずでした。ところが、メモリー配置処理設定に誤りがあったせいで、データの断片化が発生。データが断片化すると、それを解消（デフラグメンテーション）しようとする訳ですが、これが結構CPUの処理能力を食ってしまうんです。
パソコンでハードディスクが断片化したときに、デフラグを実行すると、意外とCPUの負荷になることからも、想像に難くありません。メモリーのデフラグをしているところに、これまたそれなりに処理能力が必要な越月のバッチ処理（auかんたん決済の利用限度額リセットなど）が重なってしまいました。
要するに、設定ミスから、本来は余裕のあるシステムに過剰な負荷がかかり不安定になってしまった、ということです。
こういうとき、ふとバックアップサーバーがあれば、処理を続行できたのでは、と思うところです。もちろん、au IDの認証決済システムにもバックアップシステムがあります。いわゆる「ホットスタンバイ」でバックアップサーバーが常にメインのデータベースサーバーとデータ同期を取って待機していたのですが、メモリーも同じデータが展開されている故、バックアップサーバーでも同じ高負荷状態になってしまい、用を為さなかったのです。
障害への対策
今回の障害に関しては、ハードウェア・ソフトウェア性能ともに充分なので、誤っていた設定を正常なものに書き換えて対処しました。監視項目や障害発生時の復旧手順の見直しも実施しました。
■まとめ
昨年は、NTTドコモが通信・システム障害を連発して総務省から指導を受けました。今回、KDDIがたて続けに起こした障害は、その教訓が活かしきれなかったと言えるのかもしれません。より通信量が多いスマートフォンが普及した結果、通信事業者（キャリア）問わず、増大する様々な処理要求に何とか応えようと四苦八苦している状況です。
通信が長時間途絶えると、社会に与える影響も甚大なので、キャリア間を越えた障害時対策は、今後重要になってきそうです。KDDIも、「各キャリアと障害対処ノウハウは共有していきたい」としています。各キャリアの障害に対する取り組みには、今後も注目していきたいところです。
■関連リンク
・エスマックス（S-MAX）
・エスマックス（S-MAX） smaxjp on Twitter
・S-MAX - Facebookページ
・狙いは“持たせても安心”なこと――ドコモの「スマートフォン for ジュニア SH-05E」は本当に必要なプロダクトなのか【コラム】 - S-MAX - ライブドアブログ
・昨年末に静岡県の実家周辺でドコモの「Xi」とソフトバンクの「SoftBank 4G LTE」の通信テストをして思ったこと【コラム】 - S-MAX - ライブドアブログ
・本当に同じプラットフォームなの……？Android端末の「断片化」について考える【コラム】 - S-MAX - ライブドアブログ
・もう「ｱｱｱｯ」とは言わせない？――富士通製のスマートフォン、タブレット「ARROWS」の今後について考えてみる【コラム】 - S-MAX - ライブドアブログ
・人口カバー率と実人口カバー率は何が違う？進化中のLTEとは――ドコモのLTEサービス「Xi（クロッシィ）」はどう戦っていくのか（後編）【コラム】 - S-MAX - ライブドアブログ
・都市部でフルスペックのLTE展開ができないのはなぜ？――ドコモのLTEサービス「Xi（クロッシィ）」はどう戦っていくのか（前編）【コラム】 - S-MAX - ライブドアブログ
・KDDI
・au
4G LTEの障害を説明する内田氏
昨年12月31日と、今年1月2日に発生したLTE通信サービス「4G LTE」の障害についてはKDDI 技術統括本部 運用本部長の内田義昭氏が説明を行いました。
12月31日の障害の概要図
同じく詳細図
2回の障害は、原因が異なります。まず、12月31日の障害については…
日付変更時に加入者プロファイルサーバー(SPS)へのアクセス集中
↓
SPSの処理バッファーがあふれた結果、応答がなし、または遅延する状態に
↓
信号中継装置(通信信号を基地局に伝える装置)が“時間切れ”判定を下す
↓
LTE端末のパケット通信接続が一斉に終了
↓
LTE端末から一斉に接続要求が押し寄せる
↓
信号制御装置(SPS情報から信号を作る装置)が応答しきれず、再接続不可能に
↓
SPSの処理バッファーがあふれた結果、応答がなし、または遅延する状態に
↓
信号中継装置(通信信号を基地局に伝える装置)が“時間切れ”判定を下す
↓
LTE端末のパケット通信接続が一斉に終了
↓
LTE端末から一斉に接続要求が押し寄せる
↓
信号制御装置(SPS情報から信号を作る装置)が応答しきれず、再接続不可能に
といった感じで発生しました。SPSは、ユーザーの契約状況や通信状況を保存しているサーバーで、月間通信量が7GB超えた場合の通信速度制限などは、ここに保存されている情報をもとに行っています。保持している情報を、実際に端末の接続制御を行っている信号制御装置に渡して、各種制限などを行っています。
SPSに対するアクセス集中は、日付をまたぐ頃に毎日起こるものだそうです。iOSにせよ、Androidにせよ、データの更新確認を日付が変わると同時に行うアプリが多く、それをきっかけにして通信を開始するケースが多いからです。
12月31日は、そのような日付またぎのアクセスが直前の7倍も集中し、SPSの処理バッファーがあふれてしまいました。処理の応答には“制限時間”が設けられていて、SPS～信号制御装置間は3秒に設定されていました。要するに、この区間では、処理バッファーがあふれたとしても、再処理も含めて3秒以内に応答できれば「正常」に処理されたものとなるのです。
ところが、信号処理装置～信号中継装置間の制限時間がより短い2秒に設定されていたために、遅れながらも処理された信号まで破棄されてしまいました。結果として、信号制御装置がLTE端末の接続を全部切断してしまいました。
当然、接続を切断された場合は、端末側から再度接続を試みます。今回は最大で180万台の4G LTE端末が再接続要求を行うことになったため、信号制御装置が輻輳(混み合って繋がりにくい・繋がらない)状態になり、通信障害、となってしまったのです。
4G LTE端末には、ハンドオーバーできないフェムトセルエリアで使う時のことを想定して、LTE機能をオフにする機能が付いています（決して、強制的に3Gにつないで……、という意図で用意している訳ではありません）。この機能を使って、3Gで接続すれば何とかなるのでは、とも思われる方もいるかもしれませんが、上のスライドでも分かる通り、4G LTE端末が3G環境下にいる場合も、接続制御は4G LTE用の設備で行うため、影響を回避することはできませんでした。音声回線は、どのエリアにいても別系統の制御下にあるため影響を受けませんでした。
12月31日の障害に対する対策
この障害に対する対策として、障害のきっかけとなった処理の応答制限時間の不整合を解消しました。本来であれば、返答される側の時間を長めに取るべきだったのに、返答する側の時間の方が長く設定されているのはおかしなことです。そこで、返答する側であるSPS～信号制御装置間の応答制限時間を3秒→1.2秒に短縮しました。こんなに短くて大丈夫か、と思うところですが、本来は、平常のピーク時でもコンマ秒単位で処理できるので、問題ないようです。それだけの能力があるなら、なんで12月31日は処理しきれなかったのか、不思議でならない訳ですが、この辺の理由は明らかにはなりませんでした……。
ユーザー増を見越して予定されていたSPSの増強も前倒して行いました。これで、今回の障害発生時で比較すると、14倍のアクセス集中があっても正常に処理できるようになったそうです。過負荷時を再現して、事前に問題を洗い出すためのテスト環境も、数億円の追加投資で整備します。この手のテストツールは、数億円で結構すごいものが用意できるそうです。
これだけの対策をしてもSPSへアクセスが集中したり、故障したりして応答できなくなった時に備えて、信号制御装置が「代理応答」する機能も追加されました。これは、SPSが1.2秒以内に応答できなかった場合に、信号制御装置が「認証を通過した」という仮の応答をすることで、正常に通信を継続できるよう配慮したものです。
この場合、7GB以上通信しても通信制限をかけることができなくなる、という問題点がありますが、正常な通信を継続する、ということ重きを置いた結果です。接続認証は定期的に行っているので、SPSが正常になった後の認証で、通信制限対象にはきちんと通信制限がかかるようになっています。
1月2日の障害の概要図
同じく詳細図と対処法
1月2日の障害は、結果こそ一緒ですが、12月31日のそれとは発生原因が根本的に異なります。流れとしては…
信号制御装置の呼処理ログバッファーの予備系へのコピーが遅れる
(呼処理には影響なし)
↓
これが呼処理に関する「異常」と誤判定され、装置アラームが鳴動
↓
このエラーに対する処理の手順が書かれていなかった
(本来は予備系に切り替えた上で、問題のハードウェアを交換すれば問題なし)
↓
復旧を焦った結果、信号制御装置を丸ごと再起動
↓
LTE端末のパケット通信接続が一斉に終了
↓
LTE端末から一斉に接続要求が押し寄せる
↓
信号制御装置が応答しきれず、再接続不可能に
(呼処理には影響なし)
↓
これが呼処理に関する「異常」と誤判定され、装置アラームが鳴動
↓
このエラーに対する処理の手順が書かれていなかった
(本来は予備系に切り替えた上で、問題のハードウェアを交換すれば問題なし)
↓
復旧を焦った結果、信号制御装置を丸ごと再起動
↓
LTE端末のパケット通信接続が一斉に終了
↓
LTE端末から一斉に接続要求が押し寄せる
↓
信号制御装置が応答しきれず、再接続不可能に
という感じです。信号制御装置は、予備系の装置に呼処理バッファーと呼処理ログバッファーをリアルタイムコピーしています。本来は、「ログ」の方は通信に影響を与えないため、非優先処理で、ここに障害があっても“障害”とはみなされません。ところが、今回はソフトウェアの不備によってログのコピー遅延が障害と判定されてしまい、アラームが鳴動してしまいました。
通常、アラームが鳴動した場合は、復旧手順書に従って設備を予備系に切り替えて、不具合の起こった場所を交換して…、という作業をすれば問題ありませんでしたが、今回のアラームに対する対策が手順書から抜け落ちていたことと、障害が連続していた焦りもあり、装置全体を再起動してしまいました。結果、31日の障害同様、4G LTE端末の接続が全部切断され、再接続要求を処理しきれなくなった結果、繋がりにくい状況になってしまったのです。
この障害の根本原因は、信号制御装置のソフトウェア不備です。そのため、今回のエラーに対してアラートを発報しないようにする改修を月末までに行います。
一方で、手順書の不備や、復旧を焦ってしまったことなど、「ヒューマンエラー」の側面が、今回の障害を引き起こした一因であることも否定できません。そこで、障害発生時の復旧手順書の再確認・整備と、対応訓練の実施をあわせて行っています。
機械も最終的には人間の手によって維持・管理されています。マニュアルのチェックや訓練を定期的に積み重ねることも大切です。突発的な事象に対する対応能力は、日々の積み重ねによって高まっていくはずです。他キャリアの障害事例も含めて、共有していくことで、より強固なネットワークを作っていって欲しいところです。
■au ID認証決済のシステム障害は何で起こったの？対策は？
決済障害を説明する雨宮氏
一方、元旦にはau IDの認証決済システムにおいて障害が発生しました。これについては、KDDI 新規事業統括本部 新規ビジネス推進本部長の雨宮俊武氏が説明を行いました。
障害の概要
障害の影響範囲
障害は2度発生しました。最初に発生した障害では、深夜0時12分から2時間17分、最大で80万ユーザーが継続的にサービスを使えなくなりました。その後、一時的に復旧したものの、午前9時33分ごろから4時間、最大で120万ユーザーが断続的にサービスを利用しにくい状況が再度発生しました。2回の障害で、あわせて約1000件の問い合わせがあったそうです。
この障害の原因は…
データベースサーバーのメモリー配置処理設定に誤りがあった
↓
それが原因でメモリー上のデータにフラグメンテーション（断片化）
↓
メモリー解放処理でCPUに高負荷がかかる
↓
処理をこなしきれなくなる
↓
それが原因でメモリー上のデータにフラグメンテーション（断片化）
↓
メモリー解放処理でCPUに高負荷がかかる
↓
処理をこなしきれなくなる
といったところです。一旦復旧したものの、最初の障害時には、原因の特定ができなかったため、再度同じ原因でシステムが不安定になってしまったのです。
KDDIでは、au ID利用者増に備え、11月にサーバーの処理能力を増強したばかりで、現状のユーザー数であれば、かなり余裕で処理ができるはずでした。ところが、メモリー配置処理設定に誤りがあったせいで、データの断片化が発生。データが断片化すると、それを解消（デフラグメンテーション）しようとする訳ですが、これが結構CPUの処理能力を食ってしまうんです。
パソコンでハードディスクが断片化したときに、デフラグを実行すると、意外とCPUの負荷になることからも、想像に難くありません。メモリーのデフラグをしているところに、これまたそれなりに処理能力が必要な越月のバッチ処理（auかんたん決済の利用限度額リセットなど）が重なってしまいました。
要するに、設定ミスから、本来は余裕のあるシステムに過剰な負荷がかかり不安定になってしまった、ということです。
こういうとき、ふとバックアップサーバーがあれば、処理を続行できたのでは、と思うところです。もちろん、au IDの認証決済システムにもバックアップシステムがあります。いわゆる「ホットスタンバイ」でバックアップサーバーが常にメインのデータベースサーバーとデータ同期を取って待機していたのですが、メモリーも同じデータが展開されている故、バックアップサーバーでも同じ高負荷状態になってしまい、用を為さなかったのです。
障害への対策
今回の障害に関しては、ハードウェア・ソフトウェア性能ともに充分なので、誤っていた設定を正常なものに書き換えて対処しました。監視項目や障害発生時の復旧手順の見直しも実施しました。
■まとめ
昨年は、NTTドコモが通信・システム障害を連発して総務省から指導を受けました。今回、KDDIがたて続けに起こした障害は、その教訓が活かしきれなかったと言えるのかもしれません。より通信量が多いスマートフォンが普及した結果、通信事業者（キャリア）問わず、増大する様々な処理要求に何とか応えようと四苦八苦している状況です。
通信が長時間途絶えると、社会に与える影響も甚大なので、キャリア間を越えた障害時対策は、今後重要になってきそうです。KDDIも、「各キャリアと障害対処ノウハウは共有していきたい」としています。各キャリアの障害に対する取り組みには、今後も注目していきたいところです。
記事執筆：せう(Sho INOUE)
■関連リンク
・エスマックス（S-MAX）
・エスマックス（S-MAX） smaxjp on Twitter
・S-MAX - Facebookページ
・狙いは“持たせても安心”なこと――ドコモの「スマートフォン for ジュニア SH-05E」は本当に必要なプロダクトなのか【コラム】 - S-MAX - ライブドアブログ
・昨年末に静岡県の実家周辺でドコモの「Xi」とソフトバンクの「SoftBank 4G LTE」の通信テストをして思ったこと【コラム】 - S-MAX - ライブドアブログ
・本当に同じプラットフォームなの……？Android端末の「断片化」について考える【コラム】 - S-MAX - ライブドアブログ
・もう「ｱｱｱｯ」とは言わせない？――富士通製のスマートフォン、タブレット「ARROWS」の今後について考えてみる【コラム】 - S-MAX - ライブドアブログ
・人口カバー率と実人口カバー率は何が違う？進化中のLTEとは――ドコモのLTEサービス「Xi（クロッシィ）」はどう戦っていくのか（後編）【コラム】 - S-MAX - ライブドアブログ
・都市部でフルスペックのLTE展開ができないのはなぜ？――ドコモのLTEサービス「Xi（クロッシィ）」はどう戦っていくのか（前編）【コラム】 - S-MAX - ライブドアブログ
・KDDI
・au
記事一覧
記事一覧
