メディアドゥの一次受け障害監視体制についてご紹介

はじめに

こんにちは。
IT統括本部SRE部の中村です。
2022年の4月にメディアドゥに中途入社し、徐々に仕事に慣れてきた2年目のメンバーです。
メディアドゥでは複数の自社サービスを提供しており、それらのサービスを24/365で提供するための監視体制を構築しています。

最近になって、私が一次受けの障害監視フローの改修を担当させていただくようになりました。
今回はメディアドゥの一次受けの障害監視フローをどのように構築しているのかお話しできればと思います。

一次受けの監視フロー

一次受けの監視フローは主にAWSのCloudWatch、SNS、EventBridge、Lambda、Connect、SESなどのサービスを使用して構築しており、その他のツールとしてNewRelic等も利用して障害検知を実現していますが、今回はAWSに絞って説明しようと思います。

障害検知から担当者への通知フローは以下のような流れで実施しています。

1.CloudWatchアラームを作成
2. 1の条件をトリガーに、SNSへメッセージ送信、EventBridgeを呼び出す
3-1. SNS、EventBridgeをトリガーに障害通知用SESにメッセージを送信
3-2. SNS、EventBridgeをトリガーにConnect呼び出し用Lambdaを起動

※その日の担当者が電話に出なかった場合、他の障害監視メンバーが電話に出るまでConnectを繰り返し起動する仕組みとなるため、アラート発生時には必ず確認できる体制となっています。

4-1. SESから担当者に障害通知メール送信
4-2. Connectから担当者に障害通知電話を発信
5. 担当者がメールと電話を受領し確認・対応を開始する

工夫している点

【通知の冗長性】
携帯への通知としてSES(メール)とConnect(電話)の2つのサービスを採用しています。
これは以下の点でメリットがあると考え、このような形でフローを構築しています。

・SREで必ず一次受けができる
→その日の担当者が対応できない状況にあった場合は複数人の担当者に電話が掛かるため、深夜帯にアラートを検知した場合にもメールのみの通知と比べて担当者が気づきやすいです。

また、その日の担当者がアラートに気づかず電話を受けることができなかった場合、次の担当者に電話が掛かる仕組みのため、対応漏れを防ぐことができます。

・AWSサービス障害に備える
→SESもしくはConnectの片方のみでフローを構築すると、AWSのサービス障害時にアラートに気付けない可能性があります。

また、携帯の受信環境についても冗長化できるものと考えています。メールボックスの更新が自動で行われなかったことによりメールが来なかった場合でも、電話を受信することでアラートに気付けたということもあるため、通知フローの冗長化は必須であると考えています。