Retty Tech Blog

実名口コミグルメサービスRettyのエンジニアによるTech Blogです。プロダクト開発にまつわるナレッジをアウトプットして、世の中がHappyになっていくようなコンテンツを発信します。

オンコール通知の移行

こんにちは、Rettyプラットフォームチームの中西です。

本投稿ではRettyが最近行ったオンコール通知サービスの移行の背景や具体的手順について紹介します。

移行の背景

Rettyでは主に以下の用途に限定したうえでインシデント管理プラットフォームとしてPagerDutyを利用していました。

オンコール周りで利用している機能

  • オンコールメンバーのローテーション管理(Schedules)
  • アラート通知(電話・Slack連携)
  • Ack/Escalationのアラートステータスの管理

一方、インシデント管理やポストモーテムなどの高度な機能までは活用できておりませんでした。

オンコール周りで利用していない機能

  • インシデント管理 -> Slack Workflowで専用のチャンネルを作成
  • ポストモーテム -> ポストモーテム用のGitHubリポジトリで管理
  • playbook(障害対応手順書)-> 別ドキュメントで管理

その為、モニタリングで利用していたDatadogに一本化することでコストの適正化を図りました。 Datadog On-Callのコストや機能を確認した結果、現状のオンコール環境の用途にマッチしているのと 必要最低限機能でPagerDutyと同様の運用ができると判断しDatadog Oncallへの移行を進めました。

以下は移行や設定を行った内容となります。

1. Oncall スケジュールの移行

PagerDutyにおけるSchedulesやEscalation Policyに相当する機能は、 Datadog On-Callにもほぼ同じ名前・構造で用意されていたため、UIベースでスムーズに設定移行ができました。

2. アラートの移行(CloudWatch Alarm → Datadog Monitor)

CloudWatch アラームの棚卸し

RettyではCloudWatch AlarmとDatadog Monitorの二種類が混在しており、 主にCloudWatch Alarmを使用しています。

CloudWatch Alarmに関してはSNSトピック連携でPagerDutyを設定しているのですが、 Datadog OncallはまだSNSトピック連携に対応しておらず、 直接CloudWatch Alarmから送る方法がなかったため、Datadog Monitor経由に切り替える必要がありました。

まずは既存のCloudWatch Alarmを一覧化し、通知先がPagerDutyに向いているものを対象にしました。

CloudWatch Metric Streams の導入

DatadogにCloudWatchメトリクスを連携する際、従来はGetMetric APIを使っていましたが、通知の遅延を避けるために CloudWatch Metric Streams を導入しました。 これにより、アラート検知までのタイムラグを大きく改善できました。

Datadog Monitor の作成

各プロダクトやAWSアカウントごとに担当を分け、Terraformを使ってDatadog Monitorを作成していきました。 ※以下はTerraformでの一例となります。

resource "datadog_monitor" "elb_api_5xx" {
  name                = "[ELB] API service ALB 5XX count alarm"
  type                = "query alert"
  on_missing_data     = "resolve"
  require_full_window = false
  query               = "sum(last_1m):sum:aws.applicationelb.httpcode_5xx{loadbalancer:app/api-alb/8axxxx}.as_count() >= 10"
  evaluation_delay    = 240
  message             = <<EOT
    {{#is_alert}}
    @slack-oncall_group1
    @oncall-oncall-group1
    {/is_alert}}
    {{#is_alert_recovery}}
    @slack-oncall_group1
    @oncall-oncall-group1
    {{/is_alert_recovery}}
    EOT
}

ここで苦労したのが、CloudWatch AlarmとDatadog Monitorの設定の違いでした。 CloudWatch Alarmと比べてDatadogは Queryで柔軟な条件設定が可能な反面 元のアラートの Datapoints to alarm 等の設定値とで微妙な閾値の調整が必要になりました。 こちらは移行後も適宜見直しを行っております。

移行の効果

移行後も大きなトラブルもなく以下を実現することができました。

  • 現状に則した必要最低限の機能の契約で大幅なコスト削減ができた
  • オンコール、監視モニタリングをDatadogで統一することができた

今後の予定

Datadog Monitor のしきい値の継続的な見直し

アラート移行時にも記載しましたが運用にあたって適宜修正を行っていきます。

Datadog On-Call に関連した機能の活用検討

Incident Management Workflow Automation と他にもDatadog On-Callと連携が可能な機能があるので、検証や使用の検討を行って行ければと思います。

最後までご覧頂きありがとうございました。