Case Study
スマートニュース株式会社
SmartNews 尾形暢俊氏
スマートニュース株式会社 エンジニアリングマネージャ Site Reliability Engineering 担当
日米2500万ダウンロードを超えるニュースアプリ「SmartNews（スマートニュース）」は、広範な提携メディアのコンテンツから注目のコンテンツを独自のアルゴリズムで選び出し、スマートフォンの画面に凝縮する。パーソナライズ路線を突き進まず、多様性のあるコンテンツに出会えるようにしているのが特徴だ。その背後で24時間365日働き続けているシステムの構築・運用をしているエンジニアに、緊急事態を知らせるインシデント管理システム、PagerDutyの使い心地を尋ねた。
―SmartNewsは、いまどれくらいの規模のシステムでサービスされていて、どんなふうに運用されているのでしょうか？
基本的に、サービスにはAmazonのAWSを使っています。使用しているインスタンス（仮想サーバ）の数は、SmartNewsの利用状況に合わせて変わるので時間帯によって違うのですが、ちょうど昼休みがすぎた今で数百インスタンス。まだ本番運用ではありませんが、一部のサービスにGoogle のGoogle Cloud Platformも使用しています。
これらのサーバ群はDatadogというクラウドサービスでサーバそれぞれの動作状況を収集していて、何か問題があるとアラートが出ます。その一方で、Runscopeというツールで特定のURLをたたいて、利用者がコンテンツを見たときに適切な内容と時間でレスポンスが得られているかをチェックしています。
―そこで何か問題が起きると電話が鳴るんですね？
そうです。DatadogやRunscopeのアラートはPagerDutyと連携させているので、重大な問題が起きれば電話が鳴ります。問題はDatadogでレベル分けして、電話を鳴らすほどでないものはSlackのチャットを使います。
そのほか、バッチ処理が所定の時間に終わらない、管理者がいつもとは違う端末からログインしたというような情報がメールで届くので、それもPagerDutyからアラートを出すように設定しています。
―PagerDutyはどんなふうに使われているのでしょうか？
PagerDutyを使っているのは、システム管理者ほぼ全員とビジネス部門2人の合わせて約40人。
基本的には、サービスごとに複数の担当エンジニアを設定して、アラートが出たときにはその時見られる人が見るようにしています。また、サービスによってはファーストラインで問題が解決しない場合のエスカレーション先に詳しそうな人に設定しています。でも、実際にはエスカレーションが必要になったことはあまりないですね。
ビジネス部門からは、何かあったときに責任をもってメディアの人たちに対応できるように、メディアリレーションのキーマンが加わっています。
現在のWebサービスは多彩な構成要素を編み上げて作られている。インシデント管理システムはそれらから送られてくるアラートを収集・分析し、緊急度の高いものは直接人に対応を訴える。
―オンコールのスケジュールを使うようになってから、みんなでアラートに張り付く必要がなくなったという話も聞きます。
SmartNewsの場合、いまはオンコールのローテーションを組んでいません。ニュースアプリの特性上、ユーザーがどっと来て利用する時間帯が決まっているんです。朝の通勤時間、お昼休み、夕方の通勤時間、就寝前の、1日に4回。週末の利用頻度は低い。だから、気を付けないといけない時間はそこに絞れます。
ただ、そろそろ規模が大きくなってきていて、さらに今後は米国での展開も考えているので、やっぱりスケジュールを組まないといけないかな、という相談を始めたところです。
―PagerDutyがあると気は楽になりますか？導入前はどうしていたのでしょう。
そうですね、僕が入社する前の導入以前を知らないのですが、おそらくSlackを使って、アラートの通知があるとチャンネルができてブブって音が鳴ったり、誰かが発言するとまた鳴っていたと思います。でも、夜寝ている時や週末に何かあったときに気づくかというと、それは厳しい。重大なことが起きたら必ず電話が鳴ってくれると安心感がありますし、がんばってチャットに張り付いている必要もありません。
PagerDutyは、スマホをマナーモードにしていても、それを上書きして鳴らせるように設定できるんです。だから寝る前にそうしておかないと、クッションの上で震えていても気付かない、別の部屋にいて聞こえない、などということになってしまいます。
もっとも、通勤の電車の中でそれが鳴ると、音量マックスでたいへんなことになります。そうそう、この設定の切り替えはワンクリックになるといいですね。
―コストはどうでしょうか？ある会社では、PageDutyを導入して監視サービスプロバイダーに委託していたのをやめた結果、コストダウンになったという話もありますが。
PgerDutyのようなツールを自作している会社もありますが、自分たちで作ってメンテナンスするコストを払うくらいだったら、既存のサービスにお任せするほうが結果として安い、というのが僕らの考え方です。
―これからどう使っていきたいか、何か考えていることはありますか？
自社ではまだ使っていませんが、PagerDutyのAPIを利用して問題発生時に実行する処理を書くことができるんです。これは、考えて使えばかなり便利になります。たとえば、ビジネス部門メンバーの呼出し用コマンドを作っておいて、SlackからPagerDutyにそのコマンドを送ると彼らの電話が鳴る、というように。
―PagerDutyがもうちょっとこうなったらいいと思うことはありますか？
あまり不満はないんですが、エンジニアが携帯電話を替えて電話番号が変わったとき、PageDutyの設定を変えていなかったということがまれにあります。それで防災訓練のように定期的に、人手でひとりひとり鳴らしてみたりしているのですが、それを一括でチェックするような管理の棚卸機能があるとうれしいですね。
―PagerDutyのエンジニアは、いろいろな種類の監視ツールからのデータを集めて、インシデントが起きるパターンを学習し、総合的に障害の予兆を掴めないかと考えているようです。まだどうなるかわかりませんが、紹介できる日を楽しみにしています。
