🦔

Prometheus + Step Functions + Lambdaで構築するサーバレスオンコール基盤

takehiro1111

2025/10/14に公開

 1. 前提
 ブログを書いた背景Lambda のランタイムバージョン更新対応に携わる中で、既存のオンコール基盤のリファクタリングと改修を実施しました。具体的な実装や要件ははあまり記述していませんが、アーキテクチャの参考例になればと思いブログに起こしました。

 オンコール体制の方針弊社では全員 CTO というテーマを掲げて、各エンジニアが主体的に事業及びプロダクトに関わる文化を醸成しています。

それに伴い、オンコール体制もエンジニア全員が参加する体制をとっています。
全員CTOとは？と気になる方はEntrance Book覗いてみてください😄

https://note.nextbeat.co.jp/n/nd6f64ba9b8dc

 具体的な監視項目監視項目は大きく分けて 2 つあります。
アプリケーションの死活監視
設定したエンドポイントを GET で叩き、HTTP ステータスコード200以外を一定時間連続で検知した場合に Slack 通知、架電を実施

アプリケーションのリソース監視
具体的には一部機能で使用しているEC2、OpenSearchのCPU、Memory、Storageのメトリクス



 2. アーキテクチャ

 オンコール通知のフロー
Prometheusでアプリケーションの死活監視、インフラのリソース監視を実施

AlertManagerでアラートを受け取り、API Gatewayのエンドポイントを叩いてStep Functionsを起動

Step FunctionsでLambdaを順次実行するワークフローを管理

Lambdaで Slack 通知、各開発者の携帯への架電を実施

 3. 各コンポーネントの説明URL 監視を例に、主要なコンポーネントについてざっくり説明します。

 3-1. Prometheus
 全体のアラートルール
PromQLでシンプルにレスポンスが200で返ってこない場合にアラートを発火するルールにしています。
- alert: URL Alert(critical)
    expr: probe_success == 0
    for: 5m
    labels:
      severity: critical # critical or warning

 URL 監視エンドポイントを指定し、別コンポーネントに切り出しているblackbox-exporterを利用して監視しています。
 - job_name: 'product-A-url'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
        - https://hoge.com/fuga
        - https://hoge.com/piyo

 3-2. AlertManagerPrometheus のアラートを受け取り、API Gateway のエンドポイントを叩いて Step Functions を起動します。
route:
  receiver: "slack"
  group_by: [instance, alertname] # アラート発砲時のグルーピングは改善したい...
  group_wait: 10s # 最初のアラートが来て10秒待ってから通知
  group_interval: 5m # 一度通知した後に次の通知まで5分待機
  repeat_interval: 30m #  解消されていないアラートは30分ごとに再通知

receivers:
  - name: "slack"
    webhook_configs:
      - url: "https://{api_gateway_id}.execute-api.{aws_region}.amazonaws.com/{stage}/alerts"
        send_resolved: true # アラートが解消された場合も通知

 3-3. Step FunctionsAlertManager からのリクエストを受け取り、Lambda を順次実行するワークフローを管理します。

severityの値に応じて発火するバックエンドの Lambda を分岐させています。


 3-4. Lambda（Python で実装）各 Lambda の役割は以下の通りです：
ReceiveAlerts
API Gateway からのリクエストを受け取り、severityの値を返す

DynamoDBからオンコール担当者の電話番号を取得し、以降の Lambda に引き継ぐ
PhoneCall

Twilioの API を利用して電話通知を実施
さらに API Gateway のエンドポイントを叩いて電話の発信を行う
電話が繋がった場合はsuccess、繋がらなかった場合はfail、電話をかける必要のないプロダクトはskipを返す
誰かが電話に出るまで、DynamoDB から取得した電話番号のリストを基に電話をかける処理をループします。
SlackNotification / SlackAlert

SlackのSDK経由でアラート通知を実行する

 3-5. Slack通知エンジニア全員が参加している、クリティカルな障害を検知する Slack チャンネルへ通知しています。

 4. まとめ今回はオンコール基盤のアーキテクチャについて、ざっくり紹介しました。

SaaSに依存しないオンコール基盤の一例として参考になれば幸いです！