PagerDuty上の古のRulesetsを読み解きながらEventOrchestrationに移行したなかで得られたもの
こんにちは！
株式会社ココナラ システムプラットフォーム部インフラ・SREチームのクララです。
本記事は株式会社ココナラ Advent Calendar 2024 19日目の記事です。
また、PagerDuty Advent Calendar 2024 19日目の記事も兼ねています！
2025/1/31にEOLが予定されている PagerDuty の Rulesets という機能を、後継機能である Event Orchestration に移行しました。
移行に伴い、膨大な数のルールを断捨離・再構成したので、その一部始終を記載します。
はじめに
ココナラでのPagerDuty活用
ココナラではオンコール運用にPagerDutyを活用しています。
PagerDuty単体で実現可能になった部分を、自作ツールから移行している箇所もありますが、ココナラでのPagerDuty活用は以下の記事に記載があります。
Rulesets と Event Orchestration
オンコール運用を行っていると、発生したアラートに対して追加の情報(Runbook, 重要度, タイトル)を付与したり、既知であり対応が進行中の事象は通知を抑止したい場面があります。
PagerDutyでは Event Orchestration でこれらの実現をサポートしています。
Event Orchestration の登場以前、PagerDutyには 2025/01/31 にEOLを迎えるRulesetsという機能がありました。(使用は推奨されませんが、2024/12現在もあります)
PagerDuty導入が2016年で、Event Orchestration登場以前だったため、ココナラでもRulesetsを使っていました。
課題
移行前、Rulesetsの設定についてのルールやマニュアルはない状態でした。
結果、ルールが無造作に足され、不必要になっても削除されず、古文書のようになっていました。
この状態では「新規に追加するルールの適切な配置場所が分からない」、「追加したときに既存のルールに影響を与えるのではないか」などを理由に設定作業の心理的安全性が低下します。
さらに、この 心理的安全性の低下は、Runbookの整備・アラートの抑止などが行われない状態を継続させ、最終的にはオンコール対応の負荷増やアラートの狼少年化を進行 させます。
これらの課題を改善・回避するために、以下の対応を行いました。
- Rulesets から Event Orchestration への移行
- Rulesets から引き継いだルールを Event Orchestration で断捨離・再構築する
対応
Rulesets から Event Orchestration へ
Rulesets から Event Orchestration への移行は、PagerDutyが提供するツールでとてもシンプルに完了しました。
PagerDutyが提供するツールで移行を行うと、Rulesets上のルールを可能な限りそのままEvent Orchestration上にコピーします。
具体的な方法は公式ドキュメントを参照するのが一番良いと思います。
(2024/12/13 参照)
EventOrchestration で長大になったルールを断捨離・再構築する
移行はできましたが、ルールの複雑性はそのままです。
まずは断捨離から
削除の根拠が明確にあるルール
ルールに目を通すと、以下のような理由から使用されていないと判断できるものがありました。
これらは、念の為スクリーンショットを撮った上で削除しました。
- 既に廃止されたAPI・バッチに関連するもの
- 過去使用していたが、今は使用していないインフラリソースに関連するもの
- 設定していた期限を超過して
Expiredになっているもの
削除の根拠が明確にはないルール
一方で、「使われていなさそうだけど、明確にはどうか分からない」ルールもありました。
これはEvent Orchestrationの Disable を使用して、一定期間ルールが無くても問題が発生しないことを確認した上で削除しました。
(一定期間の間にプロダクトの開発者にヒアリングも行いました)
また、抑止(Suppress)のルールであれば、PagerDutyのAlertsページでのStatusカラムでのフィルターで、実際にルールによって抑止されたアラートを確認できます。
そしてアラートの内容から、どの抑止ルールが使用されているかを確認できます。
次に、ルールの再構築
「課題」を解決する
- 新規に追加するルールの適切な配置場所が分からない
- 追加したときに既存のルールに影響を与えるのではないか
これらを理由にルールの設定作業の心理的安全性が低下している、というのが課題でした。
解決のためには、「ルールの視認性向上」、「明確な意図を持ったルール配置」が必要だと考えました。
ルールの視認性向上
Rulesetsでは記事前半のスクリーンショットの通り、ルールが直列で羅列されており、上から順に評価されます。
一方で、Event Orchestration Rulesでは複数の分岐を組み合わせて、ルールを構成できます。
うまく分岐させることで視認性の向上が期待できます。視認性の向上を前提に「明確な意図を持ったルール配置」を考えます。
ルールがどう評価されるかは、PagerDuty のテックブログ記事が分かりやすいです。 (2024/12/13 参照)
明確な意図を持ったルール配置
まず、監視種類(メトリクス監視,ログ監視,シンセティック監視,...)ごとに分岐させました。
├── application_error
├── logs
├── metrics
└── synthetic
この分岐だけでは、まだログやアプリケーションの配下にルールが多くあり、視認性が低い状態でした。
そのため第二階層として、マイクロサービスごとに分岐させました。
├── application_error
│ ├── service_a
│ └── service_b
├── logs
│ ├── service_a
│ └── service_b
├── metrics
│ ├── service_a
│ └── service_b
└── synthetic
この分岐によって、最下層には最大でも10弱程度のルールが属する状態にまで整理できました。
また分岐の条件を定めたことで、新規に追加するルールの適切な配置場所 が明確になりました。
例えば、「メトリクス関連のアラートにトリガーされるサービスBの通知に情報を付加したい」という場合には、以下の位置に追加すればOKです。
Event Orchestrationの機能的な制約
Event Orchestrationで作成するルールのクォータには、以下の制約があります。(2024/12現在)
- 直列に繋げるルールの数は25個まで
- 分岐の数は25個まで
これらのEvent Orchestrationの機能的な制約を満たした上で、視認性を確保するためにも第二階層を設ける必要がありました。
本当はこうしたかった (マイクロサービス運用者への提案 と PagerDuty玄人への釈明)
ルール配置の第二階層ではマイクロサービスごとに分岐を行いました。
一方で、マイクロサービスを運用しており、PagerDutyを使用している場合は、マイクロサービスごとにPagerDuty上のServiceを分ける 方が良いプラクティスだと思います。
PagerDuty の Event Orchestration には 2種類のルールがあります。
- Global Integration から受け取ったイベントを処理して Routing Rules に渡す Global Rules
- Service から受け取ったイベントを処理する Service Rules
この記事では、Service Rulesについて記載してきました。
マイクロサービスごとにServiceを分けることで、1つのService内のService Rulesで設定するルールの絶対量が減り、さらなる視認性と運用性の向上が見込めます。
それを理解した上で、ココナラでは複数マイクロサービスを1つの大きなチームで開発・運用している都合上、今回は1つのService Rulesで管理しています。
(二度目の引用で恐縮ですが) 上記の記載は、PagerDuty のテックブログを併せてお読みいただくと分かりやすいと思います。
(2024/12/13 参照)
これから
今回の移行対応で Event Orchestration のルールが整備され、視認性・運用性は向上しました。
またルールの設定のドキュメントを作成し、開発メンバーと連携しました。
ですが、開発メンバーとPagerDutyの接点は多くはなく、設定方法の浸透はまだまだな状態です。
この現状を受けて、PagerDutyそのもの、オンコール対応に便利な機能、そしてルールの設定方法のEnabingが次なる仕事だと考えています。
より健全なオンコール体験へ向けて、改善の旅は続きます。
最後に
株式会社ココナラ Advent Calendar 2024、
明日は@jozukauさんによる、「1年半のマネージャー経験から得た、自己流の1on1術」 です。
ココナラでは積極的にエンジニアを採用しています。
採用情報はこちら。
カジュアル面談希望の方はこちら。
Discussion