を14日間無料で試してみる
を14日間700以上ものツールと連携。システム障害を自動的に検出・診断するだけでなく、適切な障害対応メンバーをアサインし、デジタル業務全体の修復ワークフローを自動化します。
ITインフラの効率的な構築や保守運用を実現するには、「Terraform」の活用が有効です。
「PagerDuty」を導入している企業のなかには、Terraformの活用を検討しつつも、具体的な活用方法がわからず導入できていない企業も存在するのではないでしょうか。
「PagerDuty」はTerraformに対応しており、スケーラブルなインシデント対応および管理に貢献します。業務効率化やヒューマンエラー防止のためにも、Terraformの活用を前向きに検討するとよいでしょう。
この記事では、Terraformを活用するメリットや「PagerDuty」をTerraformで管理する方法、Terraformを利用する際の注意点などについて解説します。
目次
Terraformとは？利用するメリット
Terraformとは、IaC（Infrastructure as Code）と呼ばれるツールの一種です。
※IaC：サーバーなど、システムインフラの構築をコードで管理する仕組みのこと
Terraformは、HashiCorp社が中心となって開発・提供するツールです。無償で利用できるコミュニティ版のほか、さまざまな機能が追加された有償版のSaaSが提供されています。
Terraformの利用により、サーバーなどのインフラ構築をソースコードで行なえるようになります。
コードで管理すればヒューマンエラーの防止につながり、作業を行なう担当者が異なる場合でも、安定した品質を保つことが可能です。
近年では、複数のクラウドサービスを組み合わせて利用する「マルチクラウド環境」を構築している企業は珍しくありません。Terraformは、異なるクラウドサービスの統合が可能なため、効率的に運用できるでしょう。
Terraformを活用することで「PagerDuty」をよりスケーラブルに管理することが可能
現在の運用環境を「PagerDuty」でどのように再現するかは、新規ユーザーにとって悩みの種かもしれません。
「PagerDuty」には、インシデント管理やほかのシステムのインテグレーション、ワークフローの運用など、自動化の導入に役立つ多くの要素があります。
一方で企業にも、ユーザーやチーム、サービス、インテグレーション、オーケストレーションなど、多くの要素があります。
より複雑化する「PagerDuty」環境を管理するためには、TerraformやPulumiなどといったInfrastructure as Code／IaCツールを使用し、プログラムによる大規模管理を行なうのがおすすめです。
ここでは、Terraformを例に説明します。なお、TerraformのPagerDutyプロバイダーはこちらをご覧ください（Pulumiについては今後別の投稿で紹介する予定です）。
Terraform初心者の方は、HashiCorpが公開しているドキュメントを参照して始めてみてもいいかもしれません。
また、YouTubeにもTechWorld with Nanaによるチュートリアルなど、たくさんの優れた説明動画があります。
「PagerDuty」を始める際は、規定の手順に従います。
新規アカウント作成の際には、決まった順序に沿って作る必要のある構造もいくつかありますが、Web UIが手順を表示しますのでご確認ください。
次の例では、すでに「PagerDuty」アカウントをお持ちで、ユーザーのオンボーディングが完了していることを前提としています。
「PagerDuty」を始める際の手順について、詳しくはPagerDuty Universityのオンライン学習を参考にしてください。
TerraformでPagerDutyをコード化する方法
ここでは、本番環境がすでに稼働中であることを前提として、コード化する方法について解説します。
Google Cloud が提供しているmicroservices-demoプロジェクトに含まれているサービスを実際に使用しながら、説明します。
このデモ環境でのサービスおよび依存関係の作成、インテグレーションの実施はやや複雑です。サービスと関連性を定義する際には、README内のサービス図が参考になるでしょう。
作業が完了した際には、Microservices Demo環境を再現した完全なサービス一式が仕上がり、各サービスの依存関係も定義済みとなる予定です。
汎用的なインテグレーションエンドポイントも定義されているため、アラートの受信も可能です。
サンプルのコードについては、こちらのGitHubアカウントからご確認ください。
1.必要な基本情報を入力する
まず、ローカルデータとしてチームメンバーをTerraformファイルに含めます。
Terraformをすでに使用中の場合は、データ保持のためにデータモジュールやローカルファイルを使用していただいて問題ありません。
Terraformでユーザー管理をする場合は、pagerduty_userのプロバイダーのドキュメントをご確認ください。
なお、ローカルデータとしてユーザーを含める場合は、ユーザーIDが必要になります。
2.スケジュールとエスカレーションポリシーを作成する
「PagerDuty」アカウントにユーザーが追加されたら、次は1つ以上のスケジュールとエスカレーションポリシーを作成します。
なお、この作業はサービスを作成する前に行なってください。なぜなら、サービス構築の要件に、エスカレーションポリシーの作成が含まれているためです。
エスカレーションポリシーをサービスごとに作成することも可能ですが、ここではエスカレーションポリシーを明示的に作成します。
それぞれのエスカレーションポリシーは、少なくとも1つのスケジュールを含みます。個々の担当者を含む、エスカレーションポリシーの作成も可能です。
以下は、チームメンバーの地域データなども含むスケジュールの一つです。pagerduty_scheduleリソースを使用しています。
time_zoneについても、検討する必要があります（対応タイムゾーンについては、PagerDuty API docsをご覧ください）。
少なくとも1 layerには、start、rotation_virtual_start、rotation_turn_length_seconds、usersが必要です。
スケジュールには、制限やその他機能を含めることもできます。詳しくは、プロバイダーのドキュメントをご覧ください。
pagerduty_escalation_policyリソースを使用して、エスカレーションポリシーを作成すると、このようにpagerduty_scheduleリソースが表示されます。
pagerduty_escalation_policyリソースにも、要件がいくつかあります。
escalation_delay_in_minutesと、targetを含むname、1つ以上のruleブロックが必要です。
targetにはidが必要ですが、これは上記で定義したスケジュール（pagerduty_schedule.msd_apps_sched.id）に関連付けられています。
3.サービスを作成する
次は、サービスを作成します。
microservices demoを参照すると、この環境下には12のサービスを作成できます。loadgeneratorサービスは除外し、環境に適合する11の技術的サービスを作成しましょう。
また、business serviceも作成し、service graphにデモ環境全体を表したいと思います。
サービスには、最もベーシックな設定を使用します。
リソースの引数については、プロバイダーのドキュメントをご確認ください。変更や追加が発生した場合は、Terraformでいつでも対応が可能です。
サービスに必要なのは、nameとescalation_policyのみです。alert_creationの引数の使用は、現時点では推奨されていません。
新しい設定では、全サービスでcreate_alerts_and_incidentsが使用されるため、alert_creationはコード内に必要ありません。
ここでは、一貫性を保つために、すべてのサービスを同じ方法で作成します。
escalation_policyリソースはTerraformで作成されたため、リソースの参照でidを直接含めることができます。
サービスごとに異なるエスカレーションポリシーを使用することもできますが、ここでは2つのみを作成しました。
1つはDBREチーム向け、もう1つはアプリケーションチーム向けです。
前述のとおり、アプリケーションスタック全体を反映するために、ビジネスサービスを作成します。
ビジネスサービスは、アプリケーションに影響をおよぼすインシデントが発生した際に、サービスグラフページを使って他部門が特定する際に役立ちます。
オリジナルの環境図では、User に当たる部分と見なすことができるでしょう。
pagerduty_business_serviceリソースは、技術サービスのリソースに若干類似していますが、関連する escalation_policyはありません。
pagerduty_business_serviceリソースには、複数の追加の引数があります。詳しくは、provider docsをご覧ください。
4.サービスの依存関係を追加する
環境下のすべてのサービスを定義したら、service dependenciesで関係性を追加します。
依存関係を設定すると、サービス全体でインシデントが与える可能性のある影響を判断できるようになります。
それぞれの依存関係は、dependent_serviceとsupporting_serviceの関係として個別に定義する必要があります。
Microservices Demo READMEのグラフ図に示されている規則に従い、dependent_serviceは supporting_servicesの上位に配置されますが、それに依存するすべてのサービスの下位に配置されます。
また、FrontendサービスとMicroservices Demoビジネスサービスの間に依存関係を作成します。
以下のリソースでは、FrontendサービスとCheckoutサービス間の依存関係を作成します。
これらのサービスは、いずれもTerraformで作成されたため、そのidと typeの特性を参照することができます。
ビジネスサービスと技術サービスとの依存関係は、pagerduty_business_service リソースであることから、若干異なります。
すべてのサービスの依存関係が定義されると、Web UIを使用してREADMEのオリジナルのアプリケーショントポロジー図と比較することができます。
グラフのオブジェクトを調整し、オリジナルと同じように整列させます。
5.すべてのアラートを受信できるように（インテグレーション）する
最後に、すべてのサービスがアラートを受信できるようにします。
「PagerDuty」で使用できるインテグレーションにはさまざまな種類がありますが、いずれのサービスでも基本的な Events API v2インテグレーションを使いたいと思います。
メールのインテグレーションや特定のベンダーの参照など、その他のインテグレーションに関する定義方法については、プロバイダーのドキュメントをご覧ください。
「PagerDuty」でサービスが定義され、イベントを受信するためのインテグレーションが整い、基本的な機能を展開する準備ができました。
また、これらの基本的なリソースを使用することで、イベントオーケストレーション と 自動アクションのような便利なソリューションの組み込みや、チームのニーズを満たすためのより高度なインテグレーションを行なうことができます。
「PagerDuty」のTerraformプロバイダーに関する最新情報は、プロバイダーのドキュメントをご覧ください。
まとめ：Terraformを活用することで「PagerDuty」の運用環境を効率的に再現できる
Terraformは、ITインフラの効率的な構築や保守運用を実現するツールの一つです。また「PagerDuty」を管理するうえでも、役立つでしょう。
すでに「PagerDuty」を導入している企業は、Terraformを活用することで「PagerDuty」をよりスケーラブルに管理できるようになります。これにより、それぞれの企業において最適なインシデント対応を目指すことができるでしょう。
インシデント対応ツールの導入を検討している段階の企業も、将来的にはTerraformで管理する可能性があることも見据え、「PagerDuty」の導入を検討してみてはいかがでしょうか。
ダウンロード資料はこちら
https://www.pagerduty.co.jp/resources/
14日間の無料トライアルはこちら
https://ja.pagerduty.com/sign-up/
この記事が気になったら
PageDuty公式アカウントをフォロー
この記事の著者
関連ブログ記事
人気記事
検索
タグ目次
