LINEのプライベートクラウド「Verda」のインシデント対応の体制
LINE株式会社が提供するサービスは、2011年に登場したコミュニケーションアプリ「LINE」が有名だ。しかし、前身時代を含めると20年以上の歴史のある企業である。そのサービスの基盤となるインフラは物理サーバーや仮想マシンが混在しており非効率だったことから、2016年よりプライベートクラウド「Verda（ベルダ）」の構築が始まった。
「最初はOpenStackベースの仮想マシンとベアメタルサーバーを管理する基盤としてプロトタイプができ、その後ロードバランサーやDNSなど、サービスインフラに必要な機能が追加されていていきました。今は基本的な計算資源からそれを抽象化するようなサービス、ネットワーク機能、データベースなど、パブリッククラウドのようにさまざまな機能を拡張してきました」と語るのは、VerdaのSREを担うVerda Reliability Engineeringチームのメンバーである萬治 渉氏。
現在のVerdaは物理サーバー5万台弱、仮想サーバーは約10万台、データストアやロードバランシングなどのインスタンスが2万弱ほど稼働している。LINEが展開するビジネスに必要な各種サービスが展開されているが、パブリッククラウドのように外部ユーザーが利用できるように公開されているわけではない。そしてこのVerda上の各サービスを開発するメンバーは80名ほどで、Verdaの開発と運用を一貫して担っている。萬治氏のようにSREを担当するメンバーは5名。なお、萬治氏自身もYAMLなどのコードを書くインフラエンジニアである。
Verdaの各サービスを利用するユーザーの困りごとや障害発生時の対応、情報共有も開発者が行っている。PagerDuty導入以前のVerdaのインシデント対応フローは、Slackの専用チャンネルに投稿されるアラートを開発者が見て、気づいたメンバーが自発的に対応するといったものであった。しかし、アラートが増えると重要度の判断が難しく、誰が対応すべきかが明らかでないことから、即時対応ができないこともあった。
そうした課題を背景に、萬治氏は、上司のすすめもあってPagerDutyを試用して導入を決定する。インシデント対応を外部のMSP（マネージドサービスプロバイダ）企業に依頼するといった選択肢もあるが、そうはしなかった。「外部に頼むには、インシデントを検知してから担当者に通知するまでを文書でマニュアル化しなければなりません。それならコードを書いたほうが圧倒的に速いのでPagerDutyを使うことにしました」（萬治氏）
萬治氏は、Verdaのインシデント対応の改善のためPagerDutyやその他アプリの設定だけでなく、各チームとの調整や、オンコール対応などの整備にも関わった。その背景について「Verdaの規模が大きくなるにつれ、緊急対応の割合が増えてきたため、インシデント対応のスピードを速くするために重要なアラートが開発者に届く仕組みを作りたかったのです」と語った。
現在は、緊急対応が必要なインシデントに24時間体制で対応するオンコール対応を、それぞれのサービス開発チームで体制を組んで実現している。チームごとに1週間あたり2人のエンジニアがつく体制で、アラートが発生したときに担当者に電話をかけたりアラート音で通知したりしている。担当となる頻度はチームの規模によって異なり、月に1回〜2回巡ってくる体制となっている。
なお、Slackに専用チャンネルを設け、PagerDutyからの通知を受けたタイミングで、サポート担当者のスケジュールからその時点の担当者のメールアドレスを返すAPIを使って、メンションする担当者を自動的に割り当てる試みも実施している。対応内容は別途課題管理アプリケーションとも連携してチケット化する。これによって、チーム内で誰がどのインシデントに対応していることや、進捗状況もわかりやすくなった。
PagerDutyの導入で確実に対応できるオンコール体制を確立
PagerDuty導入の検討は萬治氏が入社した2019年から行われていた。インシデント対応の基本的なルールづくりと導入の検証などを経て、2020年3月にはPagerDutyの利用を開始した。導入はスムーズにできたが、新しいルールのメンバーへの定着には苦労した。
「メンバーに電話がかかるようになったので、導入後は現場の戸惑いも見られました。そこで、インシデントの優先順位を決めてアラートを減らす仕組みを作る活動をしていきました。電話を減らし、インシデント対応を効率化する前向きな活動を行っていることの理解をしてもらい、新しい運用ルールの賛同を得ていきました」（萬治氏）
萬治氏は各チームと対話しながら、アラートの定義をして、部門や担当者を明確にするよう設定を行った。また、重要度の高いインシデントで電話をコールした後に対応中、別のインシデントのコールが重ならないような工夫もした。誰かがインシデント対応中は現在の状況をとらえているはずだから、その間のアラート発報は不要だという判断だ。
チームごとの週次のオンコール当番2名は、プライマリとセカンダリがあり、セカンダリの人がユーザーサポート担当者となり、緊急対応が必要な時にはプライマリ担当にオンコールを届けるフローとなっている。
「以前はチャンネルに投稿されたインシデントをみんなで見て、誰かが対応していたのですが、リアクションする人もいれば、しない人もいますので、状況が判断しにくかったのです。PagerDutyの導入によって担当者が明確になるメリットを感じています」（萬治氏）
アラート件数の減少もPagerDuty導入効果の一つだ。特にロードバランサーは、かつて週に60件の重要度の高いアラートが発報されていたが、今では全く発報されない週も多くなった。萬治氏らのチームは、ロードバランサーチームのプロダクション会議に参加して、アラートの種類や件数を調べて解決していったのだ。
萬治氏が気に入っているPagerDutyの機能に「routing_key」（Integration Key）がある。文字列ひとつでどのサービスチームに通知をするかの指定に使っている。「インシデントを発行するときに、認証情報などのアクセスキーなどを管理したり、サービスを特定する識別子を設定したりするなど、管理するものが増えることが考えられますが、routing_keyだけで管理できるのはとても便利です」（萬治氏）
レポートや振り返りなど、さらなるインシデント対応の効率化を目指す
現在、VerdaでのPagerDutyの活用はオンコールやサポート担当の割り当てがメインだが、萬治氏は今後、インシデントレポートの生成や分析にも役立てたいと考えている。LINE社内には重大な障害やイベントを報告するフローがあり、これを、PagerDutyを使ってインシデントレポートを自動生成するような効率化を考えているのだ。今後の改善活動やPagerDutyに対して求めることについて萬治氏は次のようにコメントした。
「インシデントの発生状況の振り返りを効果的に実施するために、PagerDutyをもっと活用できればと考えています。そのためにPagerDuty側のAnalysisページをカスタムする機能や、統計の元データであるインシデントのリストをCSVなどの変換しやすい形で取得できるAPIがあると助かります。そうした機能を活用して、インシデントレポートの自動生成を通した継続的かつ定量的な振り返りを実現したいです」
