SREの林 aka もりはやです。
この記事はPagerDuty Advent Calendar 2023 の2日目の記事です。
- はじめに
- ORDにおけるPagerDutyの利用について 2023年版
- ORDにおけるTerraformを用いたPagerDutyの管理について 2023年版
- PagerDutyへの印象は変わった
- PagerDutyのサービスの進化と対象の広がり
- おわりに
はじめに
1日目の記事は @jacopen さんのPagerDutyに入社して3週間が経ったので、色々紹介してみるでした。Pagey(ペイジー)くんのつぶらな瞳が大変印象に残りました。*1
さて、オイシックス・ラ・大地株式会社（以後当社）ではシステムのインシデント管理にPagerDutyを利用しています。そしてそのコンフィグレーションの管理をIaCツールのTerraformを利用しています。それらの内容を約2年前の2021-12-06に紹介しました。
本記事では2年ほど経って当社のPagerDutyとTerraformの状況がどのようにアップデートされたかをご紹介します。
ORDにおけるPagerDutyの利用について 2023年版
2021年は以下の構成図をご紹介しました。
2023年の現在は大きくは変わりませんが以下のようになっています。
変化のポイントとしては3点があります。
- Old Systemを監視していたNagios監視を廃止しました。当社はメインの監視サービスとしてDatadogを利用しているため、Nagiosで行っていた監視項目を確認しながら必要なものだけDatadogへ移行することで廃止することができました
- APMとして利用していたNewRelicをDatadog APMへ置き換えました。Datadogの統合監視に寄せる形でAPMをDatadogのサービスへ集約しています。LogsもPapertrailからほぼDatadogに寄せましたが一部が残っています*2
- Old Systemの割合が大きく減りました。枠としてはOld Systemを残さざるを得ませんでしたがサーバ台数やリソース数については2021年の25％程度に縮小できています*3
ORDにおけるTerraformを用いたPagerDutyの管理について 2023年版
2023年現在も継続してTerraformでPagerDutyの管理を行なっていますが、ディレクトリの構成変化がありました。
2021年は以下のようにコメントしています。
ORDのPagerDutyを管理するTerraformのリポジトリの構造は至ってシンプルです。階層構造を使わないフラットな作りになっていて今のところ運用上の不満もありません。
しかし、その後PagerDuty利用者や管理するコンフィグレーションの数が増えることによって運用上の問題が発生しました。
フラット構成では terraform plan , terraform apply を行うたびに全てのリソースへのAPI Callが発生してしまい、APIの
Rate Limitに引っ掛かるようになってしまいました。*4
そのため現在は以下のようにディレクトリを分割して管理を行なっています。
.
├── README.md
├── aws_oidc
│ ├── README.md
│ ├── aws_oidc.tf
│ └── backend.tf
├── schedules
│ ├── backend.tf
│ ├── data_teams.tf
│ ├── data_users.tf
│ ├── escalation_policy_<System name>.tf
│ ├── schedule_<System name>.tf
│ └── versions.tf
├── services
│ ├── backend.tf
│ ├── business_service_<System name>.tf
│ ├── data_escalation_policy.tf
│ ├── data_team.tf
│ ├── service_<System name>.tf
│ ├── services.tf
│ └── versions.tf
└── users
├── README.md
├── backend.tf
├── <System Name>_users.tf
├── <System Name>_team.tf
└── versions.tf
5 directories, xx files
各ディレクトリは名前が用途を表していますが、簡単に説明すると以下になります。
- aws_oidc: Terraform state fileのバックエンドとして作成するS3への権限を、GitHub ActionsでCIする中でOIDCによって取得させています
- schedules: PagerDutyコンソールの"People"タブの中にある"Escalation Policies"と"Schedules"のコンフィグを管理しています*5
- services: 各サービスのポリシーとの紐付け、サポート時間、ビジネスサービスとの紐付けなどのコンフィグを管理しています
- users: チームやユーザを管理しています。認証はAWS IAM Identity Center(旧AWS SSO)を利用していますが、ユーザ管理はTerraformで行なっています
フラットな構成から用途別にディレクトリ分割をした他にはBusiness servicesの機能も利用するようになっており、サービスの集合体としてのビジネスごとに、ステータスをシンプルに見えるダッシュボードが見れるようになっています。
なおこの辺りのディレクトリ構成やPagerDutyのコンフィグレーションについてはSREチームメンバーのらきさん(@raki)がリードして進めてくれました。いつもサンキューです！
PagerDutyへの印象は変わった
上述したように、2021年からの変化としてPagerDuty連携するシステムや、コンフィグを管理するTerraformのディレクトリ構成などの変化を挙げてきましたが、一番大きな変化はPagerDutyのWebコンソールの利用回数かもしれません。
2021年7月に大規模ECサービスをAWSへリフト＆シフトを行った当社は、その後の数ヶ月間はPagerDutyを毎日のように利用していました。移行したばかりのシステムの運用がこなれておらず、監視システムもDatadogに一新したばかりで不必要なアラートが連発するような状況だったためです。
その当時は自分がオンコール担当になるのが本当に嫌で、実際に週に2回程度は深夜に「カリフォルニアからの電話」*6を受けて、精神的にも肉体的にも大変だったし、AWSとターミナルとDatadogとPagerDutyを常に開いているような状況でした。
そのままでは誰も幸せにならないため、週次のSREチーム会議をはじめとして不要アラートの整理を数ヶ月かけて行い、現在は夜間にエスカレーションされるケースは月に一度も発生しない状況に改善することができています。アラートの整理においてはPagerDutyの豊富なAPIを活用し、簡単なPythonスクリプトを用いて棚卸しなどを行いました。
こうして、以前は毎日のように開いていたPagerDutyの画面を開く回数は大幅に減り「システム運用に欠かせない役立つ存在」から「システム運用を支えているあって当然の存在」として印象が変わってきました。
PagerDutyのサービスの進化と対象の広がり
この状況は安定した点では良いですが、悪く言えば停滞とも言えます。 冒頭でも紹介した1日目の @jacopen さんの記事内にある通り「障害が起きたら電話かけてくるサービス」としての活用にとどまっています。*7
PagerDutyのかかげる「Operations Cloud」は従来のインシデント管理だけでなくサービス全体の運用をカバーし改善する魅力的なものに見えますので、その進化に引き続き目を向けていこうと考えています。*8
おわりに
これまでも、これからも、24時間のECサービスをお客様に届けるためにPagerDutyは重要な縁の下の存在です。 その重要なコンフィグレーションをTerraformで管理していくことは続けていきたいですね、新しい機能の取り込みやコードの改善を行いながら。
*1:真面目な話も後で言及しています
*2:この結果としてDatadog Logsが高い問題が発生し、現在別のソリューションを検討しています
*3:正直なところ旧環境のお掃除をやりきれていないとも言えます
*4:Rate Limitについてもアップデートが入っているようで、現在の値であれば当社規模のリポジトリならフラットのままでも問題なかった可能性もあります
*5:今見直すとWebコンソールに合わせてPeopleに名前を変えても良いかもしれない
*6:当時のPagerDutyの電話通知は海外からの発信でした。2023年現在は日本国内から電話がくるようになっています
*7:それは十分に素晴らしい機能ですが
*8:コストと効果の天秤はつねにありますが
