プレスリリース配信サービスを手がけるPR TIMESのサービスが7時間停止し、89本のプレスリリースが配信できなくなった。原因はネットワークスイッチの異常停止。データセンターを移行中だったためネットワークを含めた二重化ができておらず、システム全体が止まった。初動体制の見直しとデータセンターの早期移行によって再発防止を図る。

 PR TIMESのプレスリリース配信システムが停止したのは2019年8月19日のことだ。同日午前3時35分から午前10時47分まで7時間にわたってシステムが使えない状況が続いた。この間に配信する予定だった85社のプレスリリース89本が配信できなくなった。

 PR TIMESは会員企業に代わってプレスリリースを報道機関などに配信するサービスを有償で提供する。会員企業の広報担当者はPR TIMESが提供するWebベースのシステムを使い、プレスリリースのデータを登録したり、配信先の出版社や新聞社などを指定したりする。プレスリリースはメールなどで送り、配信日時を指定する予約配信も可能だ。約3万2000社が利用している。

深夜の障害を早朝に気付く

 PR TIMESのシステムを使うと雑誌や新聞など1万2000媒体の編集部のほか、1万5000人以上の記者や編集者にプレスリリースを配信できる。同社のサービスで配信しているプレスリリースの本数は月に1万4000本。プレスリリースを掲載する同社サイトのPV(ページビュー)は月間2000万以上で、国内のプレスリリース配信サービスとして最大規模である。

 配信サービス用システムに障害が発生したのは8月19日の午前3時35分だった。しかしPR TIMESのエンジニアは午前6時30分過ぎになるまで約3時間ほど障害に気付かなかった。

 PR TIMESはシステム運用に関するアラート(警告)メッセージを、ビジネスチャットのSlackで集約していた。サーバー監視ツールが出すアラートメッセージがSlackに自動投稿される仕組みだ。Slackのメッセージが届くとスマートフォンやパソコンの画面に通知が表示され、メールも届く。今回は障害が深夜に発生したため、エンジニアはこれらのアラートに気付かなかった。

 しかもエンジニアが障害に気付いたのは自宅だった。同社はエンジニアの自宅からシステム内部にアクセスするのを禁止していた。そこでエンジニアは急ぎ出社して対応することにした。他のエンジニアにも障害を知らせたところ、午前8時ごろにエンジニアが本社に集まり、調査に乗り出せるようになった。

 調査開始当初、エンジニアはソフトウエアに問題があるとみて、サーバーを中心に調べた。データベース(DB)管理システムは単体で正常に稼働していたので、エンジニアはWebサーバーなどにアクセスし、バッチプログラムの稼働状況やDB上のデータの整合性などを詳しく調べていった。

 調査と並行して会員企業への連絡を進めた。調査開始とほぼ同じタイミングの午前8時14分、PR TIMESの公式Twitterアカウントでシステムに障害が発生している事実を公表した。加えてカスタマーサポート部門と連携し、プレスリリースの予約配信を設定していた会員企業に電話などで直接連絡した。DBが正常に稼働していたので、エンジニアはプレスリリースの予約配信を設定していた会員企業の一覧などのデータを抽出できた。

 調査を進めるとWebサーバーのソフトウエアにも問題が無いと分かった。そこで午前10時ちょうど、データセンター(DC)の担当者と連携してハードウエアの障害について本格的に調べ始めた。機器をつぶさに確認していったところ、午前10時30分にWebサーバーとDBサーバーをつなぐネットワークスイッチで障害が発生していると分かった。

この先は有料会員の登録が必要です。「日経コンピュータ」定期購読者もログインしてお読みいただけます。今なら有料会員(月額プラン)が2020年1月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら