静かにシステムを守る人たち：アトラスの監視業務の日常
目次
こんにちは、ヨンウです。現在、アトラスでConfitサービスの監視業務を担当しています。今回はアトラスで実際に行っている監視業務について、その流れや考え方を簡単に紹介したいと思います。
サービスが安定して動作しているとき、その裏側で何が起きているのかはあまり意識されません。しかし、この「何も起きていない状態」は偶然ではなく、継続的な監視と判断によって成り立っています。
アトラスにおける監視業務は単なる障害対応ではなく、障害を未然に防ぐことに重きを置いています。
モニタリング：シグナルを集める
アトラスでは、さまざまなシステムからのアラートをSlackの専用チャンネルに集約しています。これにより、Slackを見るだけでサービス全体の状態を把握できる構成になっています。
各チャンネルでは、以下のようなシグナルが継続的に通知されます。
- EC2インスタンスの状態異常
- メモリ使用率やRDS使用率の閾値超過
- ECSリソースの不整合
- Bugsnagによるアプリケーションエラー
- Step Functionsやバッチ処理の失敗
- WAFによる不正リクエストの検知
※ AWS WAFの通知運用については、以前公開した「アトラスのAWS WAF通知―アップデートの変遷」「アトラスのAWS WAF通知 〜その後〜」でも紹介しています。
これらのアラートは単に「問題が発生した」ことを示すログではなく、システムで発生している問題や、その兆候を含めたシグナルです。
監視業務は単なるアラート対応ではなく、以下のような流れで行われています。
- シグナルを素早く検知する
- 発生状況を分析して判断する
- 必要な対応を行う
- 再発しないように改善する
シグナルを分析し、判断する
すべてのアラートがそのまま障害につながるわけではありません。重要なのは、「何が起きたか」ではなく、そのシグナルが「何を意味しているか」です。
また、発生したエラーについても、一時的なものなのか、障害の前兆なのかを見極める必要があります。例えば、同じアプリケーションエラーであってもその意味によって、後続の対応は大きく変わります。
- 一時的に発生しており、対応が不要なものなのか
- 特定条件で継続的に発生している不具合なのか
必要な対応と改善
実際に問題が確認された場合、対応は単なる対処では終わりません。
- バッチ処理が繰り返し失敗する場合
→ 再実行だけでなく、ロジック修正やリトライ構造の改善を行う - WAF で継続的に攻撃が検知された場合
→ 特定IPのブロックに加え、WAFルール自体を強化する - WAFでクロスサイトスクリプティング（XSS）の疑いが検知された場合
→ リクエスト内容を確認し、HTMLタグ・Base64文字列など特定の入力パターンによる誤検知かどうかを調査する
→ 必要に応じてWAFルールや例外設定を調整し、同様の事象が繰り返されないよう改善する
このように、対応は現在の問題を解決するだけでなく、再発しないように構造を改善することまで含まれます。
プロアクティブな対応：脆弱性管理
監視業務は、現在発生している問題だけでなく、将来的に発生しうるリスクにも対応します。
アトラスでは、Security Next、GitHub Security Alert、Spring Security Advisoriesに加え、My JVNやJPCERT/CCなどの公的な情報ソースも含め、複数のチャネルから脆弱性情報を自動収集しています。
収集された情報は、以下の観点で評価されます。
- 脆弱性の対象コンポーネントがサービス内で使用されているか
- 使用されている場合、実際に影響があるか
- 影響がある場合、その緊急度はどの程度か
これらをもとに優先度を判断し、対応を進めます。
おわりに
監視業務は目立たず、時に単調に見えることもありますが、サービスの安定性を支える上で欠かせない役割です。
その中で監視とは単に問題を処理するのではなく、 問題が繰り返されないようにシステムを継続的に改善していくプロセスだと考えています。
ここまで、監視業務の流れについて簡単にご紹介しました。
監視業務の紹介を通じて、私たちが大切にしている価値観や文化を少しでも身近に感じていただけたでしょうか。こうしたアトラスの考え方に興味を持ってくださった方と、より良いサービスを一緒に作り上げていけると嬉しいです。
