はじめに
運用現場の作業を安全かつ効率的に自動化する PagerDuty Runbook Automation（以下、RBA） と Amazon EC2 の連携チュートリアル。いよいよ今回が全3回シリーズの最終回となります！
- 第1回：基盤構築および Runner セットアップ編
- 第2回：AWS セキュリティ・権限設定編
- 第3回：ノード連携とジョブ実行編（本記事）
これまでに、RBA の Runner 構築と、External ID を用いたセキュアな IAM 連携（認証設定）が完了しています。
今回は総仕上げとして、AWS 環境にある Amazon EC2 インスタンスを RBA の「ノード」として動的に読み込み、実際に「メモリ使用率を確認する」という実践的なジョブを作成・テストしてみましょう。
【Step 1】Node Source の追加（Amazon EC2 の読み込み）
RBA が AWS 環境を操作できるようになりましたが、今のままでは「どのサーバーを操作していいか」を RBA が把握していません。そこで、AWS プラグインを利用して Amazon EC2 インスタンスの情報を動的に取得する「Node Source」を設定します。
- RBA コンソールで対象のプロジェクトを開き、左メニューの
Project SettingsからEdit Nodesをクリックします。
Sourcesタブを開き、Add a new Node Sourceをクリックします。
- プラグイン一覧から
AWS EC2 Resourcesを選択します。
- 以下の項目を設定します。
- Runner Selector:
Local Runner（または第1回で作成した Runner のタグ）を指定します。
- Region: 対象の Amazon EC2 が存在するリージョン（例：
ap-northeast-1）を入力します。 - Only Running Instances: チェックを入れます（起動中のインスタンスのみを対象にするため）。
- その他の項目はデフォルトのままで問題ありません。
- Runner Selector:
- 画面下部の
Saveボタンをクリックして保存します。
設定完了後、左メニューの Nodes をクリックします。フィルタを All Nodes に変更し、対象の Amazon EC2 インスタンスが一覧に表示されていれば、連携（ディスカバリ）は完璧に成功しています！
💡 参考：公式ドキュメント（Amazon EC2 Node Source の設定）
Amazon EC2 Node Source | Rundeck Docs
【Step 2】初めてのジョブ作成（メモリ使用率の確認）
対象のサーバーが認識できたので、いよいよ運用自動化の最小単位である「ジョブ」を作成します。
今回は、インシデント対応時の一次切り分けなどでよく使われる「メモリ消費量の上位5プロセスを取得するコマンド」をジョブとして定義してみましょう。
左メニューの ジョブ をクリックし、画面右上の new Job を選択して以下の通り設定します。
1. Details（詳細）タブ
- Job Name:
Check-Memory - Description:
メモリ使用率
2. Workflow（ワークフロー）タブ
Add a step をクリックし、Node Steps の中から Command を選択します。
- Command: 以下の Linux コマンドを入力します。
ps -eo pmem,pid,cmd | sort -k 1 -nr | head -5 - Step Label:
メモリ使用率
入力が完了したら、ステップを保存（Save）します。
3. Nodes（ノード）タブ
このジョブをどのサーバーに対して実行するかを指定します。
Execute locallyからDispatch to Nodesに変更します。- Node Filter: 対象のノード名（例：
.*test1.*）やタグを入力して、対象サーバーを絞り込みます。 - マッチしたノード（Matched Nodes）に、先ほど読み込んだ Amazon EC2 が表示されることを確認します。
すべての入力が完了したら、画面左下の 保存 をクリックしてジョブを保存します。
【Step 3】ジョブの実行と結果確認
作成したジョブを実行して、動作検証を行います。
- 保存したジョブの画面から、
今すぐジョブを実行をクリックします。 - ジョブが開始されると、実行ログの画面に遷移します。
Log Outputタブを開き、Amazon EC2 上で実行されたコマンドの結果（メモリを消費している上位5つのプロセス）が表示され、ステータスが Succeeded になれば大成功です！
エンジニアが直接サーバーに SSH ログインしてコマンドを叩くことなく、RBA のコンソールから（裏側では AWS Systems Manager を経由して）安全にサーバーの状態を確認することができました。
アイレットエンジニアの視点：なぜこのコマンドをジョブ化したのか？
今回ジョブに設定した ps -eo pmem,pid,cmd | sort -k 1 -nr | head -5 というコマンドは、メモリ使用率（pmem）でプロセスを降順にソートし、上位5件を抽出するものです。
例えば、システムのメモリアラートが発報された際、エンジニアは急いでサーバーにログインし、「今、何がメモリを食っているのか？」を調査します。しかし、この一次調査の手順を RBA でジョブ化しておけば、誰でも（あるいは PagerDuty からの自動実行で）ワンクリックで状況を把握できるようになります。
本番環境へのアクセス権限を広く付与しなくても、安全にトラブルシューティングの初動を行えるようになるのが、RBA を導入する最大のメリットの一つです。
おわりに：自動化による運用改善とアイレットの支援サービス
全3回にわたって、PagerDuty Runbook Automation と Amazon EC2 の連携手順をゼロから解説してきました。
- 第1回：基盤構築および Runner セットアップ編
- 第2回：AWS セキュリティ・権限設定編
- 第3回：ノード連携とジョブ実行編（本記事）
今回のブログ連載では、PagerDuty Runbook Automation を活用したシステム運用の自動化基盤の作り方をご紹介しました。手動運用が抱える属人化やヒューマンエラーといった課題を解決し、より効率的で信頼性の高いシステム運用体制を構築するために、ぜひ本ツールの導入をご検討ください。
弊社アイレットでは、現在インシデント対応を「PagerDuty」と自社システム「AMS」を組み合わせて自動化・効率化しております。その実践的な知見やノウハウを活かし、お客様のシステム運用の「内製化支援サービス」等も行っております。
「運用を自動化したいが、どこから手を付ければいいか分からない」「自社の環境に合わせた最適な自動化フローを構築したい」といったお悩みがございましたら、ぜひアイレットへお気軽にご相談ください！
本連載が、皆様の現場における「運用自動化の第一歩」を後押しするヒントになれば幸いです。
全3回、最後までお読みいただき誠にありがとうございました！
簡単30秒