こんにちは、SREの林です。
これはTerraform Advent Calendar 2021の6日目の記事です。
Oisix ra daichi Inc.（以後はORDと省略）のTerraformの利用事例の一つとして、TerraformでPagerDutyをどのように管理しているかを紹介します。
ORDにおけるPagerDutyの利用について
Terraformについて記載する前に、ORDでどのようにPagerDutyを活用しているかを記します。
ORDにおけるPagerDutyの導入
ORDではシステムの状態を監視するために複数のSaaSや監視ツールを利用しています。 PagerDutyを導入する以前はそれらのサービス・ツール群で発生したインシデントはそれらのツール自身で通知を行なっており、その手段もメールやSlackなどバラバラでした。
それでも騙し騙し運用していたところ、2017年、2018年と続けて会社統合を行い、システムも関係者も多く増え、従来のインシデント管理には限界を感じた当時のSREチームによってPagerDutyの導入が行われました。*1
ORDにおけるPagerDutyに集約しているSaaS・監視ツール
2021-12-06の現在、PagerDutyでは以下のSaaS・監視ツールからのインシデントを集約しています。 旧システム(Old System)と新システム(New System)と表現しているのは、2021-07にAWSへの大規模なクラウド移行を行ったことで"未移行のシステム"と"移行済みのシステム"を呼び分けるためです。*2
| 名前 | 用途 |
|---|---|
| Mackerel | 主に旧システムのInfrastructureを監視。かなり使い込んできた |
| Nagios | 旧システムの中でも特に古いシステム監視に使われていて、現メンバーにとって黒魔術な監視も少なくない |
| Papertrail | 旧システムのLog管理。シンプルで使いやすいけれど、機能が物足りないことも... |
| New Relic | 旧システムおよび新システムでAPMを利用。素晴らしい解析力で救われたことがしばしば |
| DataDog | 新システムでInfrastructure, Logs, APMを利用。Observabilityをやっていき。Network Monitringも検証を始めた |
| Zabbix | 大崎本社、物流拠点などのネットワーク機器の監視。主要なネットワークベンダ機器はTemplateがあって助かる |
PagerDutyの素晴らしい点の一つとして ”対応していないSaaS・監視ツールはほぼ存在しない” と言ってよいほど豊富なIntegration機能を持つことです。 PagerDutyのWebサイト内のIntegrations ページ冒頭には以下の文言があります。「600以上の連携を持つ業界最大級のエコシステム」は伊達ではありませんし、上述した表のORDで利用するSaaS・監視ツールは全て対応しています。
As part of PagerDuty’s 600+ platform integrations, they constitute a select tier in the industry’s largest ecosystem of native integrations.
一方で国内の独自サービスなど対応していないサービスも当然あります。それらをカバーするために以下のIntegrationが用意されているため、万が一サービス・ツールが未対応であっても集約が可能です。
- Custom API
- CLI tool(PagerDuty Agent)
一例として、ORDではマネージドなVPNサービスを拠点間接続のために利用しており、それらの通知はEmail Integrationで連携を行っています。
ORDにおけるTerraformを用いたPagerDutyの管理について
本題のTerraformでPagerDutyをどのように管理しているかを記します。
PagerDuty Provider
TerraformにはPagerDutyを管理するためのProviderも有志によって開発されています。
Terraform Registry - PagerDuty Provider
直近のVersion 2.1.1では以下のリソースに対応しており、ORDでのユースケースで困ることはほぼありません。
- pagerduty_addon
- pagerduty_business_service
- pagerduty_escalation_policy
- pagerduty_event_rule
- pagerduty_extension
- pagerduty_extension_servicenow
- pagerduty_maintenance_window
- pagerduty_response_play
- pagerduty_ruleset
- pagerduty_ruleset_rule
- pagerduty_schedule
- pagerduty_service
- pagerduty_service_dependency
- pagerduty_service_event_rule
- pagerduty_service_integration
- pagerduty_slack_connection
- pagerduty_tag
- pagerduty_tag_assignment
- pagerduty_team
- pagerduty_team_membership
- pagerduty_user
- pagerduty_user_contact_method
- pagerduty_user_notification_rule
なお直近の大型変更としては2021-10-21にv2.0.0が公開されタグの管理ができるようになりました。ORDではv1.x.xの頃からTerraformでPagerDutyを管理してきたため現在タグを利用しておらず、今後タグをどのように活用するかは検討段階です。*3
ORDのTerraform PagerDutyリポジトリのディレクトリ構造
ORDのPagerDutyを管理するTerraformのリポジトリの構造は至ってシンプルです。階層構造を使わないフラットな作りになっていて今のところ運用上の不満もありません。
一般的にフラット構造はシンプルで管理がしやすい反面、リソース量の増大とともに terraform plan , terraform apply の時間がかかることで運用が辛くなりますので、今後サービスやPagerDutyでの複雑さが増えるにつれて階層構造に変えるタイミングが来るかもしれません。*4
.github/workflows/pr_tf_plan.yml README.md backend.tf escalation_policy_api_management.tf escalation_policy_cms_default.tf escalation_policy_daichi_default.tf escalation_policy_dmeal_default.tf escalation_policy_helpdesk_default.tf escalation_policy_infra_non_prod.tf escalation_policy_logistics.tf escalation_policy_managedvpn.tf escalation_policy_oisix_default.tf escalation_policy_oisix_high_priority.tf escalation_policy_overseas.tf escalation_policy_qa_sre_test.tf escalation_policy_radish_boya_default.tf escalation_policy_radish_boya_sys_default.tf escalation_policy_smc.tf escalation_policy_sre.tf escalation_policy_sre_test.tf escalation_policy_vitality_papertrail.tf schedules.tf services.tf teams.tf users.tf versions.tf
ディレクトリ構成のポイント
- pagerduty_escalation_policyは個別のtfファイルとする
- 増減や記述が多くなりがちであるため
- それ以外は単一のtfファイルにまとめて記載(schedules, service, teams, users)
- 増減や記述が少ないかつ一覧性が高くなる
- .github/workflows/pr_tf_plan.ymlで定期的な
terraform planを行い手動操作による差分を検知
Terraform Codeのサンプル
参考までにコードの一例を記します。
以下はマネージドVPNからのEmail Integrationで発火するサービスのエスカレーションポリシです。
管理する拠点数も多いことから月に1回程度の頻度でアラートが発生していますが、数分後には復旧することが大半でした。
そのため30分間の待ち時間を入れることで、不要なアラートを人間にまで飛ばすことを抑制しています。
# escalation_policy_managedvpn.tf
resource "pagerduty_escalation_policy" "managedvpn" {
description = "メール通知で発火する。大半は自動で解決している。なら、解決してなさそうな問題だけ通知する。"
name = "Managed VPN"
num_loops = 0
teams = []
rule {
# 自動復旧するかもしれないので待ち時間を入れる
escalation_delay_in_minutes = 30
target {
id = pagerduty_schedule.wait.id
type = "schedule_reference"
}
}
rule {
escalation_delay_in_minutes = 30
target {
id = pagerduty_schedule.sre_1st.id
type = "schedule_reference"
}
target {
id = pagerduty_schedule.sre_shadow.id
type = "schedule_reference"
}
}
rule {
escalation_delay_in_minutes = 30
target {
id = pagerduty_schedule.sre_2nd.id
type = "schedule_reference"
}
}
}
PagerDutyをTerraform管理して良かったこと -> IaCのメリット
実の所、PagerDutyにはリッチなWeb GUIが提供されており、日々の運用でWeb GUIから手動で変更することも少なくありません。 その場合はTerraformのコードへ後から差分を吸収しています。
そうまでしてTerraformコードの状態を維持する目的は、Terraformがもたらす "Infrastructure as code(IaC)" のメリットを享受するためです。
現状、PagerDutyにはWeb GUIでの操作記録を残し、ロールバックができるような機能は無い認識です。 Terraformのコードが最新状態を保っていれば、その状態に戻すことができるため安心してGUI操作ができます。*5
Gitのログを見れば過去の変更の履歴を確認できますし、同じようなサービス、エスカレーションポリシを追加する場合にコードの流用ができて作業工数を削減できる場合があります。
Terraformのコードにはコメントが利用できるためDescriptionに書ききれないようなコメントをコードに残すことができます。*6
このようなIaCのメリットを見据え、今後もORDのSREチームではTerraformの活用を続けますし、その適用範囲はAWSやPagerDutyだけでなく幅広い用途に広がっていくかもしれません。*7
手作業でGUIを操作するような何かに対して「これってTerraformで管理できるのでは？ ＝ IaCのプラクティスを適用できるのでは？」と思うと、大体Terraform Providerがあるほど成熟しつつあるTerraformエコシステムに今後も期待が高まります。*8
それでは、Happy Terraforming !
Yukiya Hayashi
SRE Section
