6月12日までに発生した障害について、障害の内容と再発防止策をお知らせします。
※社内サービス名などの社内用語は一般的な言葉に置き換えています。
5月30日【ユーザーフォロー】ユーザーフォローに失敗する 等
■ 障害発生時間
2018年5月30日14時30分ごろ ～ 2018年5月30日19時40分ごろ
■ 障害の発生したシステム
リレーションデータベース基盤
■ 障害の影響が波及したシステム
ユーザーフォロー基盤, 通知連携基盤
■ 障害の内容
特定のユーザーによる攻撃的なアクセス（過剰なユーザーフォロー状態の操作）によって、ユーザーフォロー基盤が利用しているリレーションデータベース基盤が過負荷状態に陥りました。
その結果、ユーザーフォロー基盤をはじめとした、リレーションデータベース基盤を利用するサービスが正常に利用できない状態になりました。
■ ユーザー影響
・ユーザーフォローの表示に関する不具合
- フォローしている数が表示されない
- フォローされている数が表示されない
- フォローユーザーの一覧が表示されない
・ユーザーフォローの新規設定/解除が行えない
■ タイムライン
・14時30分 リレーションデータベース基盤の過負荷を検知し、調査を開始しました。
・14時46分 ユーザーフォロー基盤のAPIが高負荷になっていたことから、該当APIを一時的にメンテナンス状態にし、応答を停止させました。
これによりリレーションデータベース基盤の負荷は落ち着きましたが、外部からの攻撃的なアクセスは継続していました。従って、このままメンテナンス状態を解除しても再度過負荷に陥ることが予想されたため、さらなる調査と対策の検討を進めました。
・16時45分 アクセス内容を精査した結果、ユーザーフォロー基盤のAPIのうち、一部のAPIについてはメンテナンス状態を終了させても負荷面の問題が無いと判断し、メンテナンス状態を終了させました。
・19時35分 ユーザーフォロー基盤のAPIにアクセス回数制限機能を緊急で実装しました。これにより負荷が一定以上に高まらないように制御できると判断し、ユーザーフォロー基盤全体のメンテナンス状態を終了させました。
■ 再発防止策
・ユーザーフォロー基盤にアクセス回数制限機能を追加します（実施済み）
・ユーザーフォロー基盤に、過負荷状態に耐えられるようにキャッシュを追加します。
・より多くのアクセスに耐えられるように、リレーションデータベース基盤のチューニングやアーキテクチャ変更を検討します。
2018年5月30日14時30分ごろ ～ 2018年5月30日19時40分ごろ
■ 障害の発生したシステム
リレーションデータベース基盤
■ 障害の影響が波及したシステム
ユーザーフォロー基盤, 通知連携基盤
■ 障害の内容
特定のユーザーによる攻撃的なアクセス（過剰なユーザーフォロー状態の操作）によって、ユーザーフォロー基盤が利用しているリレーションデータベース基盤が過負荷状態に陥りました。
その結果、ユーザーフォロー基盤をはじめとした、リレーションデータベース基盤を利用するサービスが正常に利用できない状態になりました。
■ ユーザー影響
・ユーザーフォローの表示に関する不具合
- フォローしている数が表示されない
- フォローされている数が表示されない
- フォローユーザーの一覧が表示されない
・ユーザーフォローの新規設定/解除が行えない
■ タイムライン
・14時30分 リレーションデータベース基盤の過負荷を検知し、調査を開始しました。
・14時46分 ユーザーフォロー基盤のAPIが高負荷になっていたことから、該当APIを一時的にメンテナンス状態にし、応答を停止させました。
これによりリレーションデータベース基盤の負荷は落ち着きましたが、外部からの攻撃的なアクセスは継続していました。従って、このままメンテナンス状態を解除しても再度過負荷に陥ることが予想されたため、さらなる調査と対策の検討を進めました。
・16時45分 アクセス内容を精査した結果、ユーザーフォロー基盤のAPIのうち、一部のAPIについてはメンテナンス状態を終了させても負荷面の問題が無いと判断し、メンテナンス状態を終了させました。
・19時35分 ユーザーフォロー基盤のAPIにアクセス回数制限機能を緊急で実装しました。これにより負荷が一定以上に高まらないように制御できると判断し、ユーザーフォロー基盤全体のメンテナンス状態を終了させました。
■ 再発防止策
・ユーザーフォロー基盤にアクセス回数制限機能を追加します（実施済み）
・ユーザーフォロー基盤に、過負荷状態に耐えられるようにキャッシュを追加します。
・より多くのアクセスに耐えられるように、リレーションデータベース基盤のチューニングやアーキテクチャ変更を検討します。
5月31日【生放送】一部の番組において、モバイルデバイスの一部での視聴、およびタイムシフト視聴ができなくなった
■ 障害発生時間
2018年5月31日21時0分ごろ ～ 2018年5月31日21時3分ごろ
■ 障害の発生したシステム
旧生放送システム ドワンゴ社内向けAPI
■ 障害の影響が波及したシステム
新配信システム、旧生放送配信システム、特殊端末向けトランスコードシステム
■ 障害の内容
ニコニコ生放送は、老朽化した生放送システムを刷新するために、新生放送システムを開発しました。旧生放送システムを保守しながら新生放送システムを開発し、徐々に移行を進めています。
旧生放送システムが提供するドワンゴ社内向けAPIのなかに、番組情報を取得するために古くから使われている番組情報取得APIがあります。
同等のAPIは新生放送システムにも実装されており、各サービスにおいて徐々に移行を進めているのですが、旧生放送システムの社内向けAPIにもまだ利用サービスがいる状態です。
旧生放送システムの社内向けAPIについて、これまでは利用する側のサービスが各自キャッシュをしていました。負荷対策という面ではそれで問題なかったのですが、生放送側にキャッシュを移設すればメンテナンスコストを集約して削減できること、またキャッシュ制御を生放送側で柔軟に行えるようになり、サービス品質の向上が見込めることから、旧生放送システムの社内向けAPIにキャッシュシステムを新設することになりました。
また、それとは別の話として、旧生放送システムの社内向けAPIでは、歴史的な理由から特殊なアクセスキーをURLに設定しないと利用できない状態になっていました。利用しづらいため、アクセスキーなしでも利用可能になるように、並行してリファクタリングを進めていました。
それぞれのアップデートが本番に反映されたのち、5月31日の19時ごろより、旧生放送システムの社内向けAPIの負荷が上昇していることが検知されました。調査したところ、上記2つのアップデートを行うチーム間で情報伝達に齟齬があり、「アクセスキーを含まない形で旧生放送システムの社内向けAPIにアクセスすると、キャッシュシステムが有効にならない」ことが判明しました。間の悪いことに、非ログイン視聴が可能な人気生放送番組が配信されていたため、常になく生放送視聴者が集まっており、このままでは過負荷によりニコニコ生放送システム全体が停止してしまうことが予想されました。
そこで、アクセスキーを含まない形でも旧生放送システムの社内向けAPIのキャッシュシステムが有効になる修正を作成し、本番に投入することにしました。ただし、旧生放送システムの社内向けAPIは無停止更新に対応していなかったため、数分程度APIの応答が停止し、番組情報の編集や新規の生放送視聴開始ができなくなってしまうという問題がありました。しかし、生放送システム全体がダウンするよりは悪影響が少ないと考え、本番更新を実施しました。
その結果、旧生放送システムの社内向けAPIを本番更新している数分の間に番組情報を更新（番組の作成・開始・情報更新・終了・予約削除）を行った場合、関連システムとの連携が行われず、データに不整合が発生することになりました。
特に、該当時間中に番組を開始（作成ではない）をしていた場合、新配信システムの番組情報更新がうまく行われず、新配信システムから旧生放送配信システムへの番組開始通知が届きませんでした。
その結果、該当番組において、番組そのものは正常に配信・視聴できるものの、旧生放送配信システムを利用するタイムシフト録画などの一部生放送機能が正常に動作しない状態になってしまいました。
■ ユーザー影響
該当時間中に配信を開始した生放送番組において、旧生放送配信システムを利用する機能（タイムシフト録画や、特殊端末向けトランスコードシステムを経由した視聴（Playstation Vitaアプリでの生放送視聴など））ができない。
■ タイムライン
5月31日 19時2分 旧生放送システムの社内向けAPIの負荷が上昇していることに気づく
5月31日 19時10分 負荷上昇の原因がキャッシュシステムの不備であることが判明
5月31日 19時15分 負荷上昇を誘発している番組を発見し、今後も負荷が上昇しつづける可能性が高いことが判明
5月31日 21時0分ごろ キャッシュシステムの更新パッチを作成し、本番更新した
5月31日 21時3分ごろ キャッシュシステムの本番更新が完了した
■ 再発防止策
・ニコニコ生放送は巨大なシステムであり、複数のチームが協同して開発を行っています。意図しない副作用の発生を防ぐため、設計レビューをより綿密に開催し、チーム間の情報共有を密にするように心がけます。
・今回の障害の引き金となった旧生放送システムの社内向けAPIについて無停止更新ができるよう改修を進めるとともに、無停止更新が可能な新生放送システムへの移行を推し進めます。
2018年5月31日21時0分ごろ ～ 2018年5月31日21時3分ごろ
■ 障害の発生したシステム
旧生放送システム ドワンゴ社内向けAPI
■ 障害の影響が波及したシステム
新配信システム、旧生放送配信システム、特殊端末向けトランスコードシステム
■ 障害の内容
ニコニコ生放送は、老朽化した生放送システムを刷新するために、新生放送システムを開発しました。旧生放送システムを保守しながら新生放送システムを開発し、徐々に移行を進めています。
旧生放送システムが提供するドワンゴ社内向けAPIのなかに、番組情報を取得するために古くから使われている番組情報取得APIがあります。
同等のAPIは新生放送システムにも実装されており、各サービスにおいて徐々に移行を進めているのですが、旧生放送システムの社内向けAPIにもまだ利用サービスがいる状態です。
旧生放送システムの社内向けAPIについて、これまでは利用する側のサービスが各自キャッシュをしていました。負荷対策という面ではそれで問題なかったのですが、生放送側にキャッシュを移設すればメンテナンスコストを集約して削減できること、またキャッシュ制御を生放送側で柔軟に行えるようになり、サービス品質の向上が見込めることから、旧生放送システムの社内向けAPIにキャッシュシステムを新設することになりました。
また、それとは別の話として、旧生放送システムの社内向けAPIでは、歴史的な理由から特殊なアクセスキーをURLに設定しないと利用できない状態になっていました。利用しづらいため、アクセスキーなしでも利用可能になるように、並行してリファクタリングを進めていました。
それぞれのアップデートが本番に反映されたのち、5月31日の19時ごろより、旧生放送システムの社内向けAPIの負荷が上昇していることが検知されました。調査したところ、上記2つのアップデートを行うチーム間で情報伝達に齟齬があり、「アクセスキーを含まない形で旧生放送システムの社内向けAPIにアクセスすると、キャッシュシステムが有効にならない」ことが判明しました。間の悪いことに、非ログイン視聴が可能な人気生放送番組が配信されていたため、常になく生放送視聴者が集まっており、このままでは過負荷によりニコニコ生放送システム全体が停止してしまうことが予想されました。
そこで、アクセスキーを含まない形でも旧生放送システムの社内向けAPIのキャッシュシステムが有効になる修正を作成し、本番に投入することにしました。ただし、旧生放送システムの社内向けAPIは無停止更新に対応していなかったため、数分程度APIの応答が停止し、番組情報の編集や新規の生放送視聴開始ができなくなってしまうという問題がありました。しかし、生放送システム全体がダウンするよりは悪影響が少ないと考え、本番更新を実施しました。
その結果、旧生放送システムの社内向けAPIを本番更新している数分の間に番組情報を更新（番組の作成・開始・情報更新・終了・予約削除）を行った場合、関連システムとの連携が行われず、データに不整合が発生することになりました。
特に、該当時間中に番組を開始（作成ではない）をしていた場合、新配信システムの番組情報更新がうまく行われず、新配信システムから旧生放送配信システムへの番組開始通知が届きませんでした。
その結果、該当番組において、番組そのものは正常に配信・視聴できるものの、旧生放送配信システムを利用するタイムシフト録画などの一部生放送機能が正常に動作しない状態になってしまいました。
■ ユーザー影響
該当時間中に配信を開始した生放送番組において、旧生放送配信システムを利用する機能（タイムシフト録画や、特殊端末向けトランスコードシステムを経由した視聴（Playstation Vitaアプリでの生放送視聴など））ができない。
■ タイムライン
5月31日 19時2分 旧生放送システムの社内向けAPIの負荷が上昇していることに気づく
5月31日 19時10分 負荷上昇の原因がキャッシュシステムの不備であることが判明
5月31日 19時15分 負荷上昇を誘発している番組を発見し、今後も負荷が上昇しつづける可能性が高いことが判明
5月31日 21時0分ごろ キャッシュシステムの更新パッチを作成し、本番更新した
5月31日 21時3分ごろ キャッシュシステムの本番更新が完了した
■ 再発防止策
・ニコニコ生放送は巨大なシステムであり、複数のチームが協同して開発を行っています。意図しない副作用の発生を防ぐため、設計レビューをより綿密に開催し、チーム間の情報共有を密にするように心がけます。
・今回の障害の引き金となった旧生放送システムの社内向けAPIについて無停止更新ができるよう改修を進めるとともに、無停止更新が可能な新生放送システムへの移行を推し進めます。
6月2日～6月5日【ユーザー生放送・チャンネル生放送】新規に生放送の配信ページを開くことができない。また、配信開始に失敗する。
■ 障害発生時間
2018年6月2日 21時40分頃 ～ 2018年6月2日 22時26分頃
2018年6月3日 20時00分頃 ～ 2018年6月3日 20時17分頃
2018年6月4日 20時15分頃 ～ 2018年6月4日 20時21分頃
2018年6月5日 6時10分頃 ～ 2018年6月5日 7時15分頃
2018年6月5日 20時44分頃 ～2018年6月5日 21時35分頃
■ 障害の発生したシステム
新生放送システム 番組情報データベースクラスタ
■ 障害の影響が波及したシステム
ニコニコ生放送（ユーザー生放送、チャンネル生放送）
■ 障害の内容
2018年2月、チャンネル生放送が新配信システムおよび新生放送システムに移行しました。これにともなって、チャンネル生放送の統計情報を集計するサービスも新生放送システムに移行したのですが、このサービスには番組情報データベースを過剰に利用し、データベースサーバのメモリを過剰に消費するバグがありました。複数回の修正を行い、メモリの過剰消費は止まりましたが、すでに消費されてしまったメモリは解放されず、swap使用量も危険な水準に近づいていました。
ただし、「メモリ使用量が危険域にあるとはいえ、サービス自体は正常に稼動していること」「問題を解消するにはデータベースプロセス自体を再起動する必要があること。そのためにはニコニコ生放送全体の停止メンテナンスが必要になること」「6月7日にニコニコ全体停止メンテナンスが予定されていること」から、すぐには停止メンテナンスを行わず、6月7日の全体停止メンテナンスでメモリ増設を含めた対策を行う予定でした。
6月2日 21時40分ごろ、夜間のピーク時間の負荷に耐えられず、Master（書き込み処理）を担っていたDBサーバ（DB01）がダウンしました。データベースクラスタにはフェイルオーバーが設定されていたため、Masterサーバがダウンしたのち、30秒以内に自動的にSlaveサーバ（読み出し処理用サーバ）の一台（DB02）がMasterに昇格し、システム全体としての可用性は維持されました。
ただし、Masterサーバのダウンを検知してからフェイルオーバーが完了するまでの15秒～30秒の間は、番組を作成することができませんでした。
同日22時ごろ、番組開始にともなう負荷の上昇に耐えきれず、新しくMasterの役割を担ったDBサーバ（DB02）の動作が不安定になりました。特に、該当サーバにMasterの役割が移行したあとも、Slaveとしての役割も同時に果たしつづけたため、ディスクI/Oが飽和し、読みこみ・書き込みともに非常に遅い状態が発生しました。
その結果、視聴が開始しづらく、番組を作成しづらい（非常に時間が掛かる、またはタイムアウトする）状況が発生しました。アクセスの主たる要因は生放送番組判定APIだったため、APIのキャッシュが貯まってキャッシュヒット率が上昇するつれ、時間の経過と共にデータベースへのアクセスが減少し、22時26分ごろに過負荷が解消されました。
同日深夜、同様の障害を避けるため、ダウンした旧Master機（DB01）にメモリを増設したうえでSlaveDBとしてクラスタに再参加させ、再度の障害が発生したときには旧Master機（DB01）にMasterの役割が戻るように設定を行いました。また、開発機として利用していたデータベースサーバ（DB04）にも、念のためにメモリの増設を行いました。
6月3日 20時ごろ、番組開始にともなう負荷の上昇により、新しくMasterの役割を担ったデータベースサーバ（DB02）の動作が不安定になり、応答が遅延するようになりました。ただし、サーバ自体がダウンするにはいたらず、20時17分ごろに負荷は落ち着きました。
ニコニコ生放送は、0分や30分といった区切りのよい時間から番組が放送されることが多いため、このままでは21時にまた負荷でサーバが不安定になることが予測されました。そこで、新しくMasterの役割を担ったデータベースサーバ（DB02）からSlaveの役割を外す設定変更を行いました。同時に、開発機だったサーバをSlaveとしてDBクラスタに追加し、正常なクラスタ台数に戻しました。
6月4日の15時30分ごろから、対策検討会が開かれました。その結果、データベースサーバのメモリ不足を、サービス停止なしで安全に解消する方法がないことが判明しました。できるだけ早いタイミングで停止メンテナンスを行うことが合意されましたが、同日夜にかけて多くの番組が放送される予定であること、旧Masterサーバ（DB01）がメモリ不足に陥ってから72時間以上安全にサービスを提供していた事実に鑑み、6月5日の午前6時から停止メンテナンスを実施することになりました。
このとき、少しでも停止メンテナンスの時間を短くするために、DB01にMasterの役割を戻すフェイルオーバーだけを実施することにしました。
Slaveサーバのメモリを増設し、再起動してメモリを解放する作業は、必要であればクラスタ全体を停止させずに（クラスタからSlaveサーバを1台ずつ切り離して）行うことが可能だったので、停止メンテナンス中には作業をしないことにしました。Slaveサーバの対処をいつ行うかについては、6月5日の臨時停止メンテナンス後に検討することになりました。
6月4日 20時15分ごろ、夜間ピークタイムにともなう負荷上昇により、新しくMasterの役割を担ったDBサーバ（DB02）がダウンしました。
これにより自動的に旧Master機（DB01）にフェイルオーバーが行われ、クラスタ全体が健全な状態に復帰するはずでしたが、実際はフェイルオーバーが開始されるより前に、新しくMasterの役割を担ったDBサーバ（DB02）が自動的に再起動されてしまいました。このとき、書き込み禁止モードで再起動されたため、Masterサーバへの書き込みができなくなり、番組の作成ができなくなってしまいました。この状態は、20時21分ごろに手動で書き込み禁止モードを解除するまで続きました。
6月5日の6時から6時10分に早朝に短時間の臨時停止メンテナンスを行い、Masterサーバの役割を、メモリを増設した旧Master機（DB01）に戻しました。このとき、DB02をSlaveとして再参加させるためには手動でデータの整合を取る必要があるため、この時点ではクラスタに参加させませんでした。
しかし、メンテナンス終了後も、最大1/2の確率でユーザー生放送・チャンネル生放送番組の視聴が開始できない不具合が発生しました。
調査の結果、DB02を参照している設定が一部に残っていたためであると判明したため、設定を修正し、7時15分に障害がおさまりました。
6月5日の日中、Slaveの再起動をするべきか、するとしたらどのようにするか、を検討しました。
このとき、6月7日の停止メンテナンスにおいて、メモリ追加およびストレージのグレードアップがすでに計画されていたことから、予定通り停止メンテで作業したほうがよいのではないか、という判断になりました。
6月5日の20時44分ごろ、Slaveサーバの1台（DB03）がダウンしました。これにより、番組の新規視聴が一定の確率でできなくなってしまいました。DB03を使用しないように設定を変更し、20時55分ごろに状況が収束しました。
6月6日 13時から14時ごろ
アプリケーションの定期本番更新にともない、DB01をMasterに、DB02, DB03をSlaveに利用する通常の体制に戻りました。また、この時点で、DB01からDB03がすべてメモリ増設・再起動によるメモリ開放が完了した状態になりました。
■ ユーザー影響
生放送番組を視聴開始することが（一定の確率で）できない。
番組の配信ページへのアクセスにアクセスすることが（一定の確率で）できない。
■ タイムライン
5月30日以前 チャンネル生放送統計情報収集サービスがデータベースサーバのメモリを食い潰す問題を認識し、プログラムの改修を行った。しかし、すでに食い潰されたメモリは開放されず、通常時よりメモリが少ない状態が続いていた。
6月2日 21時40分ごろ データベースクラスタのMasterサーバ（DB01）がダウンし、フェイルオーバーが完了するまでの短時間（30秒以下）、番組作成ができない状態になった。フェイルオーバーは成功し、Slaveサーバの一台（DB02）がMasterに昇格し、サービスは正常な状態に戻った。
6月2日 22時ごろ 新しくMasterとなったサーバ（DB02）も負荷に耐えきれず、応答に長い時間がかかるようになった。その結果、視聴開始失敗や番組作成の失敗が発生するようになった。
6月2日 22時26分ごろ キャッシュヒット率上昇による負荷の自然減により、状況がいったん収束した。
6月3日 20時ごろ DB02が負荷に耐えきれず、応答に長い時間がかかるようになった。その結果、視聴開始失敗や番組作成の失敗が発生するようになった。
6月3日 20時17分ごろ キャッシュヒット率上昇による負荷の自然減により、状況がいったん収束した。
6月3日 20時30分ごろ DB02からSlaveの役割を外すとともに、開発機だったサーバを新しくSlaveとして利用できるように設定した。
6月4日 20時15分ごろ DB02が負荷上昇に耐えられずダウンした。フェイルオーバーが行われるはずであったが、フェイルオーバーに失敗し、さらに書き込み禁止モードで再起動されてしまった。これにより、番組の作成ができなくなってしまった。
6月4日 20時21分ごろ DB02の書き込み禁止モードを解除した。
6月5日 6時0分から6時10分 ユーザー生放送・チャンネル生放送の緊急メンテナンスを行い、メモリを増設したDB01にMasterの役割を戻した。
6月5日 6時10分 最大1/2の確率で生放送番組の視聴が開始できない不具合が発生した。
6月5日 7時15分 上記障害の原因が判明し、修正を行った。
6月5日 20時44分 Slaveサーバの1台（DB03）がダウンしたため、DB04にアプリケーションの参照先を変更する作業を開始した。
6月5日 20時55分 上記の影響が収束した。
6月6日 13時ごろ データベースクラスタが、DB01からDB03を使う正常な体制に戻り、障害が収束した。
■ 再発防止策
今回メモリ不足が発生したデータベースクラスタにおいて、メモリの増設を行う。（実施済み）
コネクション取得時に異常だった接続先情報をキャッシュし、接続先を判断することで、一部データベースサーバの異常によるリクエスト全体の失敗を防止するようアプリケーションを改修する。(実施済み)
サービスの追加開発など、新規にシステム負荷が増加するような本番変更を行う場合、CPU使用率・メモリ消費量などの負荷検証をより厳密に行うようにする。また、本番環境でのシステム負荷をより継続的・密に行えるような監視システムを導入し、特に新規のシステムが追加されたときには注意して見守るような監視体制を整える。
サービスを停止してでもメンテナンスを行うべきかどうかの判断は、状況を楽観視せず、より慎重に行うようにする。
2018年6月2日 21時40分頃 ～ 2018年6月2日 22時26分頃
2018年6月3日 20時00分頃 ～ 2018年6月3日 20時17分頃
2018年6月4日 20時15分頃 ～ 2018年6月4日 20時21分頃
2018年6月5日 6時10分頃 ～ 2018年6月5日 7時15分頃
2018年6月5日 20時44分頃 ～2018年6月5日 21時35分頃
■ 障害の発生したシステム
新生放送システム 番組情報データベースクラスタ
■ 障害の影響が波及したシステム
ニコニコ生放送（ユーザー生放送、チャンネル生放送）
■ 障害の内容
2018年2月、チャンネル生放送が新配信システムおよび新生放送システムに移行しました。これにともなって、チャンネル生放送の統計情報を集計するサービスも新生放送システムに移行したのですが、このサービスには番組情報データベースを過剰に利用し、データベースサーバのメモリを過剰に消費するバグがありました。複数回の修正を行い、メモリの過剰消費は止まりましたが、すでに消費されてしまったメモリは解放されず、swap使用量も危険な水準に近づいていました。
ただし、「メモリ使用量が危険域にあるとはいえ、サービス自体は正常に稼動していること」「問題を解消するにはデータベースプロセス自体を再起動する必要があること。そのためにはニコニコ生放送全体の停止メンテナンスが必要になること」「6月7日にニコニコ全体停止メンテナンスが予定されていること」から、すぐには停止メンテナンスを行わず、6月7日の全体停止メンテナンスでメモリ増設を含めた対策を行う予定でした。
6月2日 21時40分ごろ、夜間のピーク時間の負荷に耐えられず、Master（書き込み処理）を担っていたDBサーバ（DB01）がダウンしました。データベースクラスタにはフェイルオーバーが設定されていたため、Masterサーバがダウンしたのち、30秒以内に自動的にSlaveサーバ（読み出し処理用サーバ）の一台（DB02）がMasterに昇格し、システム全体としての可用性は維持されました。
ただし、Masterサーバのダウンを検知してからフェイルオーバーが完了するまでの15秒～30秒の間は、番組を作成することができませんでした。
同日22時ごろ、番組開始にともなう負荷の上昇に耐えきれず、新しくMasterの役割を担ったDBサーバ（DB02）の動作が不安定になりました。特に、該当サーバにMasterの役割が移行したあとも、Slaveとしての役割も同時に果たしつづけたため、ディスクI/Oが飽和し、読みこみ・書き込みともに非常に遅い状態が発生しました。
その結果、視聴が開始しづらく、番組を作成しづらい（非常に時間が掛かる、またはタイムアウトする）状況が発生しました。アクセスの主たる要因は生放送番組判定APIだったため、APIのキャッシュが貯まってキャッシュヒット率が上昇するつれ、時間の経過と共にデータベースへのアクセスが減少し、22時26分ごろに過負荷が解消されました。
同日深夜、同様の障害を避けるため、ダウンした旧Master機（DB01）にメモリを増設したうえでSlaveDBとしてクラスタに再参加させ、再度の障害が発生したときには旧Master機（DB01）にMasterの役割が戻るように設定を行いました。また、開発機として利用していたデータベースサーバ（DB04）にも、念のためにメモリの増設を行いました。
6月3日 20時ごろ、番組開始にともなう負荷の上昇により、新しくMasterの役割を担ったデータベースサーバ（DB02）の動作が不安定になり、応答が遅延するようになりました。ただし、サーバ自体がダウンするにはいたらず、20時17分ごろに負荷は落ち着きました。
ニコニコ生放送は、0分や30分といった区切りのよい時間から番組が放送されることが多いため、このままでは21時にまた負荷でサーバが不安定になることが予測されました。そこで、新しくMasterの役割を担ったデータベースサーバ（DB02）からSlaveの役割を外す設定変更を行いました。同時に、開発機だったサーバをSlaveとしてDBクラスタに追加し、正常なクラスタ台数に戻しました。
6月4日の15時30分ごろから、対策検討会が開かれました。その結果、データベースサーバのメモリ不足を、サービス停止なしで安全に解消する方法がないことが判明しました。できるだけ早いタイミングで停止メンテナンスを行うことが合意されましたが、同日夜にかけて多くの番組が放送される予定であること、旧Masterサーバ（DB01）がメモリ不足に陥ってから72時間以上安全にサービスを提供していた事実に鑑み、6月5日の午前6時から停止メンテナンスを実施することになりました。
このとき、少しでも停止メンテナンスの時間を短くするために、DB01にMasterの役割を戻すフェイルオーバーだけを実施することにしました。
Slaveサーバのメモリを増設し、再起動してメモリを解放する作業は、必要であればクラスタ全体を停止させずに（クラスタからSlaveサーバを1台ずつ切り離して）行うことが可能だったので、停止メンテナンス中には作業をしないことにしました。Slaveサーバの対処をいつ行うかについては、6月5日の臨時停止メンテナンス後に検討することになりました。
6月4日 20時15分ごろ、夜間ピークタイムにともなう負荷上昇により、新しくMasterの役割を担ったDBサーバ（DB02）がダウンしました。
これにより自動的に旧Master機（DB01）にフェイルオーバーが行われ、クラスタ全体が健全な状態に復帰するはずでしたが、実際はフェイルオーバーが開始されるより前に、新しくMasterの役割を担ったDBサーバ（DB02）が自動的に再起動されてしまいました。このとき、書き込み禁止モードで再起動されたため、Masterサーバへの書き込みができなくなり、番組の作成ができなくなってしまいました。この状態は、20時21分ごろに手動で書き込み禁止モードを解除するまで続きました。
6月5日の6時から6時10分に早朝に短時間の臨時停止メンテナンスを行い、Masterサーバの役割を、メモリを増設した旧Master機（DB01）に戻しました。このとき、DB02をSlaveとして再参加させるためには手動でデータの整合を取る必要があるため、この時点ではクラスタに参加させませんでした。
しかし、メンテナンス終了後も、最大1/2の確率でユーザー生放送・チャンネル生放送番組の視聴が開始できない不具合が発生しました。
調査の結果、DB02を参照している設定が一部に残っていたためであると判明したため、設定を修正し、7時15分に障害がおさまりました。
6月5日の日中、Slaveの再起動をするべきか、するとしたらどのようにするか、を検討しました。
このとき、6月7日の停止メンテナンスにおいて、メモリ追加およびストレージのグレードアップがすでに計画されていたことから、予定通り停止メンテで作業したほうがよいのではないか、という判断になりました。
6月5日の20時44分ごろ、Slaveサーバの1台（DB03）がダウンしました。これにより、番組の新規視聴が一定の確率でできなくなってしまいました。DB03を使用しないように設定を変更し、20時55分ごろに状況が収束しました。
6月6日 13時から14時ごろ
アプリケーションの定期本番更新にともない、DB01をMasterに、DB02, DB03をSlaveに利用する通常の体制に戻りました。また、この時点で、DB01からDB03がすべてメモリ増設・再起動によるメモリ開放が完了した状態になりました。
■ ユーザー影響
生放送番組を視聴開始することが（一定の確率で）できない。
番組の配信ページへのアクセスにアクセスすることが（一定の確率で）できない。
■ タイムライン
5月30日以前 チャンネル生放送統計情報収集サービスがデータベースサーバのメモリを食い潰す問題を認識し、プログラムの改修を行った。しかし、すでに食い潰されたメモリは開放されず、通常時よりメモリが少ない状態が続いていた。
6月2日 21時40分ごろ データベースクラスタのMasterサーバ（DB01）がダウンし、フェイルオーバーが完了するまでの短時間（30秒以下）、番組作成ができない状態になった。フェイルオーバーは成功し、Slaveサーバの一台（DB02）がMasterに昇格し、サービスは正常な状態に戻った。
6月2日 22時ごろ 新しくMasterとなったサーバ（DB02）も負荷に耐えきれず、応答に長い時間がかかるようになった。その結果、視聴開始失敗や番組作成の失敗が発生するようになった。
6月2日 22時26分ごろ キャッシュヒット率上昇による負荷の自然減により、状況がいったん収束した。
6月3日 20時ごろ DB02が負荷に耐えきれず、応答に長い時間がかかるようになった。その結果、視聴開始失敗や番組作成の失敗が発生するようになった。
6月3日 20時17分ごろ キャッシュヒット率上昇による負荷の自然減により、状況がいったん収束した。
6月3日 20時30分ごろ DB02からSlaveの役割を外すとともに、開発機だったサーバを新しくSlaveとして利用できるように設定した。
6月4日 20時15分ごろ DB02が負荷上昇に耐えられずダウンした。フェイルオーバーが行われるはずであったが、フェイルオーバーに失敗し、さらに書き込み禁止モードで再起動されてしまった。これにより、番組の作成ができなくなってしまった。
6月4日 20時21分ごろ DB02の書き込み禁止モードを解除した。
6月5日 6時0分から6時10分 ユーザー生放送・チャンネル生放送の緊急メンテナンスを行い、メモリを増設したDB01にMasterの役割を戻した。
6月5日 6時10分 最大1/2の確率で生放送番組の視聴が開始できない不具合が発生した。
6月5日 7時15分 上記障害の原因が判明し、修正を行った。
6月5日 20時44分 Slaveサーバの1台（DB03）がダウンしたため、DB04にアプリケーションの参照先を変更する作業を開始した。
6月5日 20時55分 上記の影響が収束した。
6月6日 13時ごろ データベースクラスタが、DB01からDB03を使う正常な体制に戻り、障害が収束した。
■ 再発防止策
今回メモリ不足が発生したデータベースクラスタにおいて、メモリの増設を行う。（実施済み）
コネクション取得時に異常だった接続先情報をキャッシュし、接続先を判断することで、一部データベースサーバの異常によるリクエスト全体の失敗を防止するようアプリケーションを改修する。(実施済み)
サービスの追加開発など、新規にシステム負荷が増加するような本番変更を行う場合、CPU使用率・メモリ消費量などの負荷検証をより厳密に行うようにする。また、本番環境でのシステム負荷をより継続的・密に行えるような監視システムを導入し、特に新規のシステムが追加されたときには注意して見守るような監視体制を整える。
サービスを停止してでもメンテナンスを行うべきかどうかの判断は、状況を楽観視せず、より慎重に行うようにする。
6月7日・8日【動画・生放送など】広範なコンテンツが利用できない
■ 障害発生時間
2018年6月7日 20時29分頃 ～ 2018年6月7日 21時26分頃
2018年6月8日 20時29分頃 ～ 2018年6月8日 20時45分頃
■ 障害の発生したシステム
ニコニコシステム間連携API基盤（エンタープライズサービスバス）
■ 障害の影響が波及したシステム
ニコニコシステム間連携API基盤を利用する全サービス
■ 障害の内容
ニコニコ動画のPC・SPWeb・iOS・Androidアプリには、ユーザー行動を記録するためのロガーが実装されています。これは例えば「ユーザーがどの画質を選択して再生したのか」「自動画質選択はきちんと機能しているか」などを計測するもので、収集された計測結果を改善に役立てています。
この機能はJavaScriptで作られており、ページロード時・視聴開始時・ページ離脱時の3回にわけてログを送信します。送信に失敗した場合は、ブラウザのlocalstorageを利用した送信キューにログを保存し、次に接続が回復したときに、再度送信を試みます。
6月7日のメンテナンス開始時刻にも、多くのユーザーが動画を視聴したままの状態でした。これにより、多くのブラウザに「あとで送信するべきログ」が送信キューに保存されました。
メンテナンス終了にともない、送信キューに蓄積されていたログの送信が再開されましたが、PC・SPWebのロガーの実装にバグがあり、送信完了したキューが正常に破棄されませんでした。
その結果、多くのブラウザから継続的にログが送られ続けてしまいました。送信間隔はタイマーによって制御されていましたが、そのwait間隔は500ミリ秒だったため、1秒間に約2回の送信が実行されました。これにより、通常の数倍におよぶログが送信されることとなりました。
当該ログはニコニコシステム間連携API基盤を経由してドワンゴのサーバに保存されます。従ってニコニコシステム間連携API基盤は、通常より遥かに多い件数の通信を受けとりました。
本来であればニコニコシステム間連携API基盤はこの規模の負荷にも耐えられるはずでしたが、それ以前にニコニコ生放送で「KeepAliveをONにしているにも関わらず、コネクションを使い回さない。それによって通信ポートを食い潰してしまう」というバグが発生していたため、ニコ生側のアプリケーション改修が完了する、もしくはワークアラウンドが実施されるまでは、ニコニコシステム間連携API基盤が利用しているサーバーのKeepAliveをOFFにして運用していました。
ニコニコシステム間連携API基盤が利用しているロードバランサ（LB）と配下のサーバの通信は、HTTP（TCP）プロトコルを利用しています。
つまり、LBおよび配下のサーバはそれぞれIPアドレスをもち、通信ごとに新しいポートを開いて通信します。ポートは1つのIPアドレスごとに約6万個しかありませんので、使い終わったポート番号は順次再利用されます。
通常であればそれで問題なかったのですが、一時的に通信件数が爆発的に増加した結果、LBのポート番号が枯渇する状態が発生しました。
これは特に、通信完了後の通信断を行ったあと（双方がFIN – ACKをやりとりしたあと）、しばらくTIME_WAIT状態に遷移し、ポート番号を再利用しないTCPの挙動によるものでした。
TIME_WAIT状態のポートが大量に貯まった結果、正常な通信が遅延しました。また、それだけではなく、LBからサーバへの死活監視もhttpで行っていたことが問題を大きくしました。
LBからサーバへの死活監視は、サーバの特定のパスにhttpリクエストを送り、それが正常に（”200 OK”のHTTPレスポンスが）返ってくることで「サーバが生きている」と判定しています。
しかし、TIME_WAIT状態のポートへSYNを送信すると、（正常なレスポンスであるSYN + ACKではなく）通信切断時に送信したACKを再送信します。つまり、スリーウェイハンドシェイクが成立せず、通信が開始されません。
これによりLBのヘルスチェック機構が誤作動し、配下のサーバがダウンしたとみなして切り離してしまいました。その結果、残ったサーバに負荷が集中し、連鎖的なダウンを引き起こしてしまいました。
■ ユーザー影響
約50%の確率で、ニコニコシステム間連携API基盤を利用したシステムが利用できない（動画・生放送コンテンツ視聴が出来ない、ニコレポが見えない、RPGアツマールが利用できないなど）
■ タイムライン
6月7日 20時31分ごろ ニコニコシステム間連携API基盤でエラーが頻発しているとのアラートが監視システムより報告される
6月7日 21時ごろにかけて 早朝のニコニコ全体停止メンテナンスでさまざまな変更を行っていたため、問題の切り分けに時間がかかった。問題のありそうなLBを切り離したり、関連サービスを再起動したりしたが改善せず
6月7日 21時26分ごろ 負荷が解消され、正常な状態に復帰する。この時点では具体的な負荷原因は判明せず
6月8日 20時29分ごろから、再度ニコニコシステム間連携API基盤でエラーが頻発する。待機していた開発チームが、原因調査と並行して、負荷の分散によるシステム安定化を試みる
6月8日 20時45分ごろ 正常な状態に復帰する
6月8日 22時19分ごろ LBのポート枯渇が原因であることが判明したため、TIME_WAIT状態のポートを減らすために、KeepAliveが有効になるようにサーバの設定を変更する
6月9日 昼ごろ 異常な通信の原因が動画視聴ページのロガーであったことが判明し、送信キューが正常に処理されるように改修を行う。ユーザーがページをリロードしたタイミングで新しいバージョンになるように本番更新を行った
6月9日 夜 万が一おなじ障害が再発したときのためにニコニコシステム間連携API基盤チームが待機し、作業手順書を作成。また、障害の予兆を検知できるようにモニタリング設定を行い、ユーザー影響が出る前に負荷の分散と安定化ができるように準備を整えた
6月9日 深夜 ピーク時間帯を越えても障害が再発せず、通信件数も正常に戻ったため、対応完了として解散
■ 再発防止策
ロガーを修正し、完了した送信キューが正常に削除されるようにします（対応済み）。
ポートの枯渇を防ぐため、通信が再利用されるようKeepAlive機能をONにします（対応済み）。
2018年6月7日 20時29分頃 ～ 2018年6月7日 21時26分頃
2018年6月8日 20時29分頃 ～ 2018年6月8日 20時45分頃
■ 障害の発生したシステム
ニコニコシステム間連携API基盤（エンタープライズサービスバス）
■ 障害の影響が波及したシステム
ニコニコシステム間連携API基盤を利用する全サービス
■ 障害の内容
ニコニコ動画のPC・SPWeb・iOS・Androidアプリには、ユーザー行動を記録するためのロガーが実装されています。これは例えば「ユーザーがどの画質を選択して再生したのか」「自動画質選択はきちんと機能しているか」などを計測するもので、収集された計測結果を改善に役立てています。
この機能はJavaScriptで作られており、ページロード時・視聴開始時・ページ離脱時の3回にわけてログを送信します。送信に失敗した場合は、ブラウザのlocalstorageを利用した送信キューにログを保存し、次に接続が回復したときに、再度送信を試みます。
6月7日のメンテナンス開始時刻にも、多くのユーザーが動画を視聴したままの状態でした。これにより、多くのブラウザに「あとで送信するべきログ」が送信キューに保存されました。
メンテナンス終了にともない、送信キューに蓄積されていたログの送信が再開されましたが、PC・SPWebのロガーの実装にバグがあり、送信完了したキューが正常に破棄されませんでした。
その結果、多くのブラウザから継続的にログが送られ続けてしまいました。送信間隔はタイマーによって制御されていましたが、そのwait間隔は500ミリ秒だったため、1秒間に約2回の送信が実行されました。これにより、通常の数倍におよぶログが送信されることとなりました。
当該ログはニコニコシステム間連携API基盤を経由してドワンゴのサーバに保存されます。従ってニコニコシステム間連携API基盤は、通常より遥かに多い件数の通信を受けとりました。
本来であればニコニコシステム間連携API基盤はこの規模の負荷にも耐えられるはずでしたが、それ以前にニコニコ生放送で「KeepAliveをONにしているにも関わらず、コネクションを使い回さない。それによって通信ポートを食い潰してしまう」というバグが発生していたため、ニコ生側のアプリケーション改修が完了する、もしくはワークアラウンドが実施されるまでは、ニコニコシステム間連携API基盤が利用しているサーバーのKeepAliveをOFFにして運用していました。
ニコニコシステム間連携API基盤が利用しているロードバランサ（LB）と配下のサーバの通信は、HTTP（TCP）プロトコルを利用しています。
つまり、LBおよび配下のサーバはそれぞれIPアドレスをもち、通信ごとに新しいポートを開いて通信します。ポートは1つのIPアドレスごとに約6万個しかありませんので、使い終わったポート番号は順次再利用されます。
通常であればそれで問題なかったのですが、一時的に通信件数が爆発的に増加した結果、LBのポート番号が枯渇する状態が発生しました。
これは特に、通信完了後の通信断を行ったあと（双方がFIN – ACKをやりとりしたあと）、しばらくTIME_WAIT状態に遷移し、ポート番号を再利用しないTCPの挙動によるものでした。
TIME_WAIT状態のポートが大量に貯まった結果、正常な通信が遅延しました。また、それだけではなく、LBからサーバへの死活監視もhttpで行っていたことが問題を大きくしました。
LBからサーバへの死活監視は、サーバの特定のパスにhttpリクエストを送り、それが正常に（”200 OK”のHTTPレスポンスが）返ってくることで「サーバが生きている」と判定しています。
しかし、TIME_WAIT状態のポートへSYNを送信すると、（正常なレスポンスであるSYN + ACKではなく）通信切断時に送信したACKを再送信します。つまり、スリーウェイハンドシェイクが成立せず、通信が開始されません。
これによりLBのヘルスチェック機構が誤作動し、配下のサーバがダウンしたとみなして切り離してしまいました。その結果、残ったサーバに負荷が集中し、連鎖的なダウンを引き起こしてしまいました。
■ ユーザー影響
約50%の確率で、ニコニコシステム間連携API基盤を利用したシステムが利用できない（動画・生放送コンテンツ視聴が出来ない、ニコレポが見えない、RPGアツマールが利用できないなど）
■ タイムライン
6月7日 20時31分ごろ ニコニコシステム間連携API基盤でエラーが頻発しているとのアラートが監視システムより報告される
6月7日 21時ごろにかけて 早朝のニコニコ全体停止メンテナンスでさまざまな変更を行っていたため、問題の切り分けに時間がかかった。問題のありそうなLBを切り離したり、関連サービスを再起動したりしたが改善せず
6月7日 21時26分ごろ 負荷が解消され、正常な状態に復帰する。この時点では具体的な負荷原因は判明せず
6月8日 20時29分ごろから、再度ニコニコシステム間連携API基盤でエラーが頻発する。待機していた開発チームが、原因調査と並行して、負荷の分散によるシステム安定化を試みる
6月8日 20時45分ごろ 正常な状態に復帰する
6月8日 22時19分ごろ LBのポート枯渇が原因であることが判明したため、TIME_WAIT状態のポートを減らすために、KeepAliveが有効になるようにサーバの設定を変更する
6月9日 昼ごろ 異常な通信の原因が動画視聴ページのロガーであったことが判明し、送信キューが正常に処理されるように改修を行う。ユーザーがページをリロードしたタイミングで新しいバージョンになるように本番更新を行った
6月9日 夜 万が一おなじ障害が再発したときのためにニコニコシステム間連携API基盤チームが待機し、作業手順書を作成。また、障害の予兆を検知できるようにモニタリング設定を行い、ユーザー影響が出る前に負荷の分散と安定化ができるように準備を整えた
6月9日 深夜 ピーク時間帯を越えても障害が再発せず、通信件数も正常に戻ったため、対応完了として解散
■ 再発防止策
ロガーを修正し、完了した送信キューが正常に削除されるようにします（対応済み）。
ポートの枯渇を防ぐため、通信が再利用されるようKeepAlive機能をONにします（対応済み）。
6月7日【TV・セットトップボックス系デバイス】約2/3の確率でニコニコの起動に失敗する
■ 障害発生時間
2018年6月7日9時0分 ～ 2018年6月7日10時14分ごろ
■ 障害の発生したシステム
各種デバイス向けAPI変換サービス
■ 障害の影響が波及したシステム
TV・セットトップボックス系デバイス（HTML5ブラウザアプリ対応スマートTV、Amazon Fire TV・au Smart TV Stick・光BOX+など）
■ 障害の内容
6月7日のニコニコ全体停止メンテナンス中、複数の予期しない動作が発生していました。
・ニコニコ全体停止メンテナンス中に、NicoBoxアプリから異常な回数のリクエストが発生していました。原因は調査中ですが、NicoBoxアプリのメンテナンスモードが不完全だったことが原因ではないかと推測されます。
・ニコニコアカウントAPIが正常にメンテナンスモードに切り替わらず、HTTP 500エラーをHTML形式で返答していました。ニコニコアカウントAPIは通常JSON形式で応答するため、各種デバイス向けAPI変換サービスではHTML形式の応答をパースすることができず、エラーとなりました。
・各種デバイス向けAPI変換サービスでは、エラーが発生した場合、原因追及を容易にするためにstack traceを含めた形でログを出力します。それにより、エラーが頻発した場合、通常より早いペースでログが肥大化しがちです。
以上の動作が組み合わさった結果、全体停止メンテナンス中の数時間で各種デバイス向けAPI変換サービス群のストレージを使い切ってしまいました。また、メンテナンス中であったため監視サービスを停止しており、ストレージの枯渇に気づくことができませんでした。
TV・セットトップボックス系デバイスのアプリでは、起動時にランキングを表示するための通信を行います。しかし、ストレージを使い切った各種デバイス向けAPI変換サービスは正常なレスポンスを返すことができませんでした（途中で送出に失敗するため、ヘッダに書かれたContent Lengthと異なる長さのレスポンスになってしまい、ERR_CONTENT_LENGTH_MISMATCHが発生する）。これにより、約2/3の確率でアプリケーションの起動に失敗する状態になりました。
■ ユーザー影響
セットトップボックスやスマートTVにおいて、約2/3の確率でアプリケーションが起動できない。
■ タイムライン
6月7日 8時58分頃 各種デバイス向けAPI変換サービスの動画ランキング取得APIにおいて、`ERR_CONTENT_LENGTH_MISMATCH` が発生することを確認
6月7日 9時16分頃 各種デバイス向けAPI変換サービスで発行している、予期されたエラーではないことを確認
6月7日 9時41分頃 ログでストレージが枯渇していることに気づき、ログ削除を試みる
6月7日 10時11分 障害収束
■ 再発防止策
ニコニコアカウントAPIがメンテナンス時にJSON形式で応答するように改修します（実施済み）。
大規模メンテナンス時には、連携先サービスだけでなく、各種デバイス向けAPI変換サービス自体もメンテナンスモードに移行する運用をするべきか再検討します。
NicoBoxアプリにおいて、通信回数を減らす改修や、完全なメンテナンスモードの実装を検討します。
2018年6月7日9時0分 ～ 2018年6月7日10時14分ごろ
■ 障害の発生したシステム
各種デバイス向けAPI変換サービス
■ 障害の影響が波及したシステム
TV・セットトップボックス系デバイス（HTML5ブラウザアプリ対応スマートTV、Amazon Fire TV・au Smart TV Stick・光BOX+など）
■ 障害の内容
6月7日のニコニコ全体停止メンテナンス中、複数の予期しない動作が発生していました。
・ニコニコ全体停止メンテナンス中に、NicoBoxアプリから異常な回数のリクエストが発生していました。原因は調査中ですが、NicoBoxアプリのメンテナンスモードが不完全だったことが原因ではないかと推測されます。
・ニコニコアカウントAPIが正常にメンテナンスモードに切り替わらず、HTTP 500エラーをHTML形式で返答していました。ニコニコアカウントAPIは通常JSON形式で応答するため、各種デバイス向けAPI変換サービスではHTML形式の応答をパースすることができず、エラーとなりました。
・各種デバイス向けAPI変換サービスでは、エラーが発生した場合、原因追及を容易にするためにstack traceを含めた形でログを出力します。それにより、エラーが頻発した場合、通常より早いペースでログが肥大化しがちです。
以上の動作が組み合わさった結果、全体停止メンテナンス中の数時間で各種デバイス向けAPI変換サービス群のストレージを使い切ってしまいました。また、メンテナンス中であったため監視サービスを停止しており、ストレージの枯渇に気づくことができませんでした。
TV・セットトップボックス系デバイスのアプリでは、起動時にランキングを表示するための通信を行います。しかし、ストレージを使い切った各種デバイス向けAPI変換サービスは正常なレスポンスを返すことができませんでした（途中で送出に失敗するため、ヘッダに書かれたContent Lengthと異なる長さのレスポンスになってしまい、ERR_CONTENT_LENGTH_MISMATCHが発生する）。これにより、約2/3の確率でアプリケーションの起動に失敗する状態になりました。
■ ユーザー影響
セットトップボックスやスマートTVにおいて、約2/3の確率でアプリケーションが起動できない。
■ タイムライン
6月7日 8時58分頃 各種デバイス向けAPI変換サービスの動画ランキング取得APIにおいて、`ERR_CONTENT_LENGTH_MISMATCH` が発生することを確認
6月7日 9時16分頃 各種デバイス向けAPI変換サービスで発行している、予期されたエラーではないことを確認
6月7日 9時41分頃 ログでストレージが枯渇していることに気づき、ログ削除を試みる
6月7日 10時11分 障害収束
■ 再発防止策
ニコニコアカウントAPIがメンテナンス時にJSON形式で応答するように改修します（実施済み）。
大規模メンテナンス時には、連携先サービスだけでなく、各種デバイス向けAPI変換サービス自体もメンテナンスモードに移行する運用をするべきか再検討します。
NicoBoxアプリにおいて、通信回数を減らす改修や、完全なメンテナンスモードの実装を検討します。
6月10日【ユーザー生放送・チャンネル生放送】新規視聴開始や配信開始ができない
■ 障害発生時間
2018年6月10日 18時00分頃 ～ 2018年6月10日 18時05分頃
2018年6月10日 20時00分頃 ～ 2018年6月10日 20時10分頃
■ 障害の発生したシステム
旧生放送配信システム ドワンゴ社内向けAPI
■ 障害の影響が波及したシステム
ニコニコ生放送（ユーザー生放送・チャンネル生放送）
■ 障害の内容
先日、旧生放送配信システム ドワンゴ社内向けAPIにキャッシュサーバーが実装されました。
旧生放送配信システム ドワンゴ社内向けAPIへのアクセスのなかには、特段キャッシュ機能を必要としないものもありましたが、わかりやすさとメンテナンスコスト低減のために、旧生放送配信システム ドワンゴ社内向けAPIへのアクセスはキャッシュサーバを利用するように統一しました。
しかし、人気番組をトリガーとした突発的な大量アクセスにより、キャッシュ機能を必要としないリクエストが同時多発的かつ大量に発生し、キャッシュサーバに想定以上の負荷が発生してしまいました。これにより、ユーザー生放送・チャンネル生放送の視聴ページを新たに開くことができなくなり、同時に配信開始もできなくなってしまいました。
■ ユーザー影響
ユーザー生放送・チャンネル生放送を新規に視聴開始できない。
また、ユーザー生放送・チャンネル生放送を新規に配信開始できない。
■ タイムライン
6月10日 18時0分ごろ 旧生放送配信システム ドワンゴ社内向けAPIが不安定になる
6月10日 18時1分ごろ 旧生放送配信システム ドワンゴ社内向けAPIの負荷が増大していることに気づく。ただし、この時点では人気番組による自然な負荷増大だと判断、状況を注視する
6月10日 18時5分ごろ 負荷の自然減により旧生放送配信システム ドワンゴ社内向けAPIが安定した状態に戻る
6月10日 20時0分ごろ 旧生放送配信システム ドワンゴ社内向けAPIが再度不安定になる
6月10日 20時1分ごろ 旧生放送配信システム ドワンゴ社内向けAPIの負荷が再度増大していることを検知、調査を開始
6月10日 20時7分 キャッシュシステムにアクセスが集中したことで、旧生放送配信システム ドワンゴ社内向けAPIのキャッシュサーバに予想外の高負荷がかかっていることが判明
6月10日 20時10分 アクセスの自然減により、障害収束
6月10日 21時36分 応急処置として、キャッシュサーバ構成を2台->5台に増強
■ 再発防止策
負荷対策として、キャッシュサーバを増強します（実施済み）。
キャッシュ機能を利用しないAPIについては、キャッシュサーバではなく旧生放送配信システム ドワンゴ社内向けAPIに直接アクセスするようにします。
また、上記対策が完了するまでの間は、キャッシュサーバを一時的に利用しないようにします（実施済み）。
2018年6月10日 18時00分頃 ～ 2018年6月10日 18時05分頃
2018年6月10日 20時00分頃 ～ 2018年6月10日 20時10分頃
■ 障害の発生したシステム
旧生放送配信システム ドワンゴ社内向けAPI
■ 障害の影響が波及したシステム
ニコニコ生放送（ユーザー生放送・チャンネル生放送）
■ 障害の内容
先日、旧生放送配信システム ドワンゴ社内向けAPIにキャッシュサーバーが実装されました。
旧生放送配信システム ドワンゴ社内向けAPIへのアクセスのなかには、特段キャッシュ機能を必要としないものもありましたが、わかりやすさとメンテナンスコスト低減のために、旧生放送配信システム ドワンゴ社内向けAPIへのアクセスはキャッシュサーバを利用するように統一しました。
しかし、人気番組をトリガーとした突発的な大量アクセスにより、キャッシュ機能を必要としないリクエストが同時多発的かつ大量に発生し、キャッシュサーバに想定以上の負荷が発生してしまいました。これにより、ユーザー生放送・チャンネル生放送の視聴ページを新たに開くことができなくなり、同時に配信開始もできなくなってしまいました。
■ ユーザー影響
ユーザー生放送・チャンネル生放送を新規に視聴開始できない。
また、ユーザー生放送・チャンネル生放送を新規に配信開始できない。
■ タイムライン
6月10日 18時0分ごろ 旧生放送配信システム ドワンゴ社内向けAPIが不安定になる
6月10日 18時1分ごろ 旧生放送配信システム ドワンゴ社内向けAPIの負荷が増大していることに気づく。ただし、この時点では人気番組による自然な負荷増大だと判断、状況を注視する
6月10日 18時5分ごろ 負荷の自然減により旧生放送配信システム ドワンゴ社内向けAPIが安定した状態に戻る
6月10日 20時0分ごろ 旧生放送配信システム ドワンゴ社内向けAPIが再度不安定になる
6月10日 20時1分ごろ 旧生放送配信システム ドワンゴ社内向けAPIの負荷が再度増大していることを検知、調査を開始
6月10日 20時7分 キャッシュシステムにアクセスが集中したことで、旧生放送配信システム ドワンゴ社内向けAPIのキャッシュサーバに予想外の高負荷がかかっていることが判明
6月10日 20時10分 アクセスの自然減により、障害収束
6月10日 21時36分 応急処置として、キャッシュサーバ構成を2台->5台に増強
■ 再発防止策
負荷対策として、キャッシュサーバを増強します（実施済み）。
キャッシュ機能を利用しないAPIについては、キャッシュサーバではなく旧生放送配信システム ドワンゴ社内向けAPIに直接アクセスするようにします。
また、上記対策が完了するまでの間は、キャッシュサーバを一時的に利用しないようにします（実施済み）。
6月12日【ニコニコサービス全体】一部のインターネットサービスプロバイダにおいて、ニコニコサービスが利用できない
■ 障害発生時間
2018年6月12日6時30分ごろ ～ 2018年6月12日9時3分ごろ
■ 障害の発生したシステム
ニコニコが利用している回線事業者
■ 障害の影響が波及したシステム
ニコニコサービス全体
■ 障害の内容
ニコニコに対してインターネット回線を提供している回線事業者に起因する問題によって、一部のインターネットサービスプロバイダ（ISP）の一部エリアとの通信ができなくなる現象が発生しました。
これにより、該当ISPを利用しているユーザーのうち、一部の方々がニコニコサービスを利用できませんでした。
また、ニコニコが利用している課金決済サービスとの通信にも問題が発生したため、該当ISPを利用していないユーザーにおいても、正常に決済が行えない状態になっていました。
■ ユーザー影響
一部のISPから、ニコニコサービスが利用できない。
プレミアム会員費・チャンネル会員費・ニコニコポイント購入などの決済ができない。
■ タイムライン
6月12日 6時30分 回線事業者での障害が発生
6月12日 7時16分 サービスが利用できない旨のユーザー問い合わせが増加していることを認識する
6月12日 7時45分 プレミアム会員費やチャンネル会員費の決済でエラーが発生することを確認
6月12日 8時15分 回線事業者に障害調査を依頼
6月12日 8時23分 一部のISPからのアクセスのみが失敗することが判明
6月12日 8時29分 ニコニコのシステム間通信には問題が無いことを確認
6月12日 9時3分 回線事業者より障害復旧の連絡
■ 再発防止策
ニコニコシステムでの障害ではないため、直接的な再発防止策はありません。
2018年6月12日6時30分ごろ ～ 2018年6月12日9時3分ごろ
■ 障害の発生したシステム
ニコニコが利用している回線事業者
■ 障害の影響が波及したシステム
ニコニコサービス全体
■ 障害の内容
ニコニコに対してインターネット回線を提供している回線事業者に起因する問題によって、一部のインターネットサービスプロバイダ（ISP）の一部エリアとの通信ができなくなる現象が発生しました。
これにより、該当ISPを利用しているユーザーのうち、一部の方々がニコニコサービスを利用できませんでした。
また、ニコニコが利用している課金決済サービスとの通信にも問題が発生したため、該当ISPを利用していないユーザーにおいても、正常に決済が行えない状態になっていました。
■ ユーザー影響
一部のISPから、ニコニコサービスが利用できない。
プレミアム会員費・チャンネル会員費・ニコニコポイント購入などの決済ができない。
■ タイムライン
6月12日 6時30分 回線事業者での障害が発生
6月12日 7時16分 サービスが利用できない旨のユーザー問い合わせが増加していることを認識する
6月12日 7時45分 プレミアム会員費やチャンネル会員費の決済でエラーが発生することを確認
6月12日 8時15分 回線事業者に障害調査を依頼
6月12日 8時23分 一部のISPからのアクセスのみが失敗することが判明
6月12日 8時29分 ニコニコのシステム間通信には問題が無いことを確認
6月12日 9時3分 回線事業者より障害復旧の連絡
■ 再発防止策
ニコニコシステムでの障害ではないため、直接的な再発防止策はありません。
連日の不具合によって、ユーザーの皆様にはご不便・ご迷惑をおかけいたしました。大変申し訳ありませんでした。
再発防止に取り組み、今後は同じ障害を繰り返さないようにいたします。
