Case Study
株式会社Jストリーム
株式会社Jストリーム
プラットフォーム本部 技術開発部 プラットフォーム開発課 齊藤一輝氏、塩野目雄氏、久保智尋氏
Jストリームは、1997年に世界で初めてインターネットによる動画配信を事業化したパイオニアだ。今も企業向けに動画配信のためのプラットフォームを提供し続けているほか、ライブ配信や 映像制作、ウェブサイト構築などのサービスも提供している。同社の事業を支えている1つは高品質な動画配信プラットフォームとその安定性だ。障害の発生を防ぐために、同社はハードウエアからアプリケーションまでの様々なレイヤーについて、複数の監視ツールを組み合わせて監視している。その多種多様なツールからのアラートを集約し、対応状況を可視化・共有することが1つの課題だった。そのためのツールとして、インシデント管理サービスPagerDutyが活躍している。
―この度はお忙しいところご参加いただきありがとうございます。まず自己紹介をお願いします。
齊藤さん）こんにちは、PagerDutyを使った運用を主に担当している齊藤です。
塩野目さん）PagerDutyを導入する際に、担当チームにおりました塩野目です。ここにいるメンバーはサーバーの運用・構築を行っている部隊になります。弊社はCDNというものを構築して運用しているのですが、久保が主に開発を担当し、齊藤と私が運用をしておりました。
久保さん） 私は主に「J-Stream CDNext」という国産CDNサービスの運用を担当しております。CDNに関わる機能としてアクセスログの分析も担当しています。齊藤とは運用にかかわる部分を担当しています。CDNEXTの開発運用チームとしては久保や齊藤と一緒に仕事をしています。
―Jストリーム様の事業内容について、ご紹介いただけますか?
久保さん）では私から。Jストリームはもともと動画の配信をビジネスの基盤としております。エンターテインメント分野の、例えばコンサートの配信などは当初からビジネスにしております。それ以外にも、最近はビジネス向けのセミナーや、株主やお客様とのコミュニケーションでの手段として動画が活用されています。その配信を管理するためのサービスとして「J-Stream Equipmedia」を提供しています。これは基本的なビデオのアップロードやエンコード、配信の管理ができるプラットフォームになっています。これと、先ほど申し上げたCDNサービスであるCDNextがあるわけですが、これは大規模なhttpアクセスに対応する必要があるウェブサイトや、動画のようにとても大きなデータを配信するための配信プラットフォームサービスです。この2つが大きな柱になっています。
PagerDutyの導入を担当された久保智尋さん(左)、 塩野目雄さん
塩野目さん）このほかに、ライブの現場を担当することも非常に多いですね。今はコロナの影響もあって、そうした現場対応の依頼を受けることが増えています。
―ありがとうございます。多数のいろいろなデバイス向けの、動画などの大量のデータ配信を可能にするためのサービスを提供されているわけですね。なぜPagerDutyが必要だったのでしょうか?
齊藤さん） 導入前は、複数の監視システムや、サーバーから直接に、別々の担当者にアラートが飛んでいました。アラートの送信先が一元的に把握できていなかったこともありました。
久保さん） 基本はシステムの正常性の監視を行っていてアラートが飛ぶわけですが、その監視には、サーバーやネットワークなどいろいろな階層があります。階層ごとに監視のシステムがそれぞれ違うのです。Zabbixのようなものや、アプリケーションとして動作しているかどうかを定期チェックするスクリプトなどがあります。それぞれに、アラート発報の仕方や送信先が違うのです。誰がいま対応できているのかも、しばらく把握できないことがありました。
全部の監視が1つのツールで行われているのなら問題がないのですが、階層によって違いますし、独自の監視スクリプトを動かしている場合もあります。
監視を担当している人がちゃんとポリシーを決めておらず雑にアラートを投げていたこともありました。そういったものが拾えない状況でした。
塩野目さん） 導入したのは2年ほど前ですが、そのころは、独自スクリプトで検知をして個人にエスカレーションをするということもありました。やはりツールによって、どこまでエスカレーションをするのかもかなりバラバラでした。エスカレーションをきちんと管理しないとこれ以上は無理だな、という感じでした。
―PagerDutyを見つけられたのは、どういう経緯ですか？
塩野目さん） 私が、おそらくウェブの記事だったと思いますが、エスカレーションの管理ツールがあるということを見つけて、トライアルをしてみたんです。求めていたのは、あまり自分たちで管理をしたくなかったので、SaaSとして提供されているもので、機能がシンプルであることでした。
トライアルが14日間というのはやはり短かったですが、PagerDutyのUIは英語でも分かりやすかったですね。
―いろいろな監視ツールをお使いですが、インテグレーションについてはすぐ利用できましたか？
齊藤さん） はい、メールによるアラートのインテグレーションはすごく分かりやすかったですし、PagerDuty側で監視ツールのインテグレーションが用意されていますので、あまり苦労した覚えはないです。設定に関する記事がありましたし、Digital Stacksさんの日本語訳のページを案内していただいたので、それを活用しました。
PagerDutyの導入を担当された齊藤一輝さん
塩野目さん） ZabbixとGCPのCloud Monitoringにつないでいるほかに、Slackとも連携させています。SlackでもAckが返せますよね。あの連携は便利です。通知はSlackのほかレベルによっては電話でのコールも使い分けています。
久保さん） やはり最後のエスカレーションは電話ですね。本当に緊急に必要な通知は電話にしています。そのほかをSlackにしています。
―Jストリームさんではリモートワーク化が進んでいるそうですが、モバイルアプリをお使いになる機会は多いのでしょうか？
塩野目さん） アラートを拾ったときには、Ackをしないとエスカレーションしてしまいます。だからモバイルを使うことが多いですね。それに（スマホのアプリで）誰がAckしているかが見えるのも個人的には便利だと思っています。24時間365日の運用をしていることもあるので、そういう場合はスマートホンのアプリとスマートウォッチを連携させて気づきやすくするといった使い方もしています。
―導入前の問題点は解消されたのでしょうか？
齊藤さん） インシデントの状況の可視化はかなり改善されました。今年（2020年）に2年目の更新をしたのですが、1年目と比べてアラートへの対応の時間などが短縮してきたことが目に見えて分かるようになりました。
今回はコロナの影響もあり、Zoomでインタビューさせていただき、その後にJストリーム本社をお借りしてみなさんを撮影しました。このメンバーが集まるのも久しぶりとのこと。
以前はメールで個人に（アラートが）送られていたりして、誰が解決に向けて対応しているかが見えにくかったのです。それがSlackなどを通じて、誰が対応しているかとか、どんな対応しているかといったことを、すごく共有できるようになりました。アラートの管理については（情報が）1つのWeb GUIにまとまっていて、何がアラートとして設定されているかとか、何が何件起きたかといった過去が追えることが、当初の課題であった情報の一元化の解決になったと思います。
―なるほど。お役に立てていることが分かり大変嬉しいです。どうもありがとうございました。
