本記事は、開発チームがお届けするブログリレーです！
既に公開されている記事もありますので、こちらから他のメンバーの投稿もぜひチェックしてみてください！
1. はじめに
システムの運用中に「あれ？なんだかサーバーの調子が悪いぞ？」と感じたとき、まず何を確認しますか？
多くの場合、サーバーが「どれくらい稼働しているか」や「どれくらいファイルが圧迫されているか」を示す CPU使用率、メモリ使用率、ディスク使用率ではないでしょうか。
これらの値は、サーバーの稼働状況を確認するための非常に重要な指標です。
普段は監視ツールが異常を検知してくれるかもしれませんが、より詳細な調査や、特定の状況下での確認が必要になることもあります。
しかし、手動でサーバーにログインしてコマンドを叩くのは、1台ならまだしも、複数のサーバーや緊急時では大きな負担になります。
こんな状況は避けたいですよね。そこで役立つのが PagerDuty Runbook Automation (PD RBA) です！
今回は、PagerDuty Runbook Automation (PD RBA) を活用して、AWS EC2 サーバー内の CPU使用率、メモリ使用率、ディスク使用率 の調査を自動化する道のりをご紹介します。
これによって、サーバーの異変にいち早く気づき、迅速に対応できるようになります。
2. PD RBAとRunnerの準備
PD RBAでEC2のステータスを確認するには、まずRunnerを準備する必要があります。
2.1 Runnerとは何か？なぜ必要なのか？
Runner は、PD RBAから受け取った自動化ジョブ（指示）を、実際にターゲットとなる環境（今回の場合はAWSアカウント内）で実行するためのエージェントです。
「なぜPD RBAから直接AWSにアクセスしないの？」と思うかもしれません。
これにはいくつかの理由があります。
PD RBA本体から直接AWSにアクセスするのではなく、AWSアカウント内にRunnerを配置することで、不要なネットワークアクセスを減らし、セキュリティを高めることができます。
特定のネットワーク内（例えばVPNの向こう側など）にあるリソースに対して、Runnerがそのネットワーク内にいればアクセスできるようになります。
多数のジョブを同時に実行する場合など、Runnerを複数配置することで負荷を分散し、安定した自動化を実現できます。
このように、Runbook Automation が AWS に「直接」アクセスしない構成をとる理由は、管理対象の AWS 環境が Runbook Automation インスタンスにとってネットワーク的に遠隔にある、またはセキュリティゾーンによって隔離されている場合に、Runner を中間役として配置することで、セキュリティを維持しつつ、効率的かつ確実に自動化を実行するためです
今回は、このRunnerをAWS環境内にデプロイし、PD RBAからの指示を受けてEC2のステータスを確認する役割を担ってもらいます。
2.2 Runnerの作成とインストール（概要と注意点）
Runnerの作成とインストールは、以下の公式ドキュメントを参考に進めます。
Runnerの作成と権限設定
Runnerのインストールとセキュリティ確保
大まかな手順は以下の通りです。
①PD RBAコンソールでRunnerを作成
PD RBAのWeb UIから新しいRunnerを作成し、APIキーなどの認証情報を取得します。この情報はRunnerがPD RBAと通信するために必要です。
②AWS上にRunnerをインストールするサーバーを準備
EC2インスタンスなど、Runnerをインストールするサーバーを用意します。OSや必要なリソース（メモリ、CPU）は上記のドキュメントで確認しましょう。
③Runnerをインストール
取得した認証情報を使って、サーバーにRunnerソフトウェアをインストールし、起動します。
【注意点】
RunnerがインストールされたサーバーからPD RBA本体（クラウドサービス）へ、そしてターゲットとなるAWSリソースへ、それぞれ必要なネットワーク接続が確立されているか確認しましょう。
Runner作成時に取得するAPIキーなどの認証情報は、非常に重要な情報です。
第三者に知られないよう、厳重に管理してください。
3. クロスアカウント連携の仕組み
複数のAWSアカウントを運用している場合、PD RBAのRunnerが「Aアカウント」にデプロイされていて、EC2のステータスを確認したいインスタンスが「Bアカウント」にある、という状況が考えられます。
この「他のアカウントのEC2を見る」ための仕組みが クロスアカウント連携 です。
3.1 IAMロールを使った権限委譲
AWSでは、あるアカウントのリソースに別のアカウントからアクセスさせるためにIAMロールが使われます。
例えば、Runnerが「Aアカウント」にいて、「Bアカウント」のEC2インスタンスのステータスを見たいとします。
このとき、「Bアカウント」が「RunnerがいるAアカウント」に対して、「うちのEC2のステータスを見る役割を一時的に貸してあげよう」と権限を与えるのです。
この仕組みをAWSでは AssumeRole（ロールの引き受け） と呼びます。
Runnerは指定されたIAMロールを引き受けることで、そのロールが持つ権限を使って「Bアカウント」のリソースにアクセスできるようになります。
3.2 ターゲットAWSアカウントでのIAMロール設定
実際に「Bアカウント」（EC2インスタンスがある方）でIAMロールを作成しましょう。
AWSコンソールでIAMサービスを開き、「ロール」→「ロールを作成」を選択します。
「AWSアカウント」を選択し、「別のアカウント」にチェックを入れます。
ここに、Runnerがデプロイされている「Aアカウント」のAWSアカウントIDを入力します。
このロールが何ができるかを定義します。
EC2のステータスを確認するためには、最低限以下の権限が必要です。
ec2:DescribeInstanceStatus ec2:DescribeInstances
ポリシー例（JSON形式）：
JSON
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstanceStatus",
"ec2:DescribeInstances"
],
"Resource": "*"
}
]
}
（※Resource: “*”はすべてのEC2インスタンスを対象としますが、必要に応じて特定のインスタンスに絞ることも可能です。）
ロールに分かりやすい名前（例: PDRBA_EC2StatusCheckerRole）を付けて作成します。
これで、Runnerがこのロールを引き受けることで、「Bアカウント」のEC2ステータスにアクセスできる準備が整いました。
4. PD RBAジョブの作成
いよいよ、PD RBA上で実際にEC2のステータスを確認するジョブを作成します。
4.1 新しいジョブの作成
PD RBAのWeb UIにログインし、「Projects」から適切なプロジェクトを選択するか、新規プロジェクトを作成します。「Jobs」メニューから「New Job」をクリックし、新しいジョブを作成します。
4.2 ノードソースの設定：Runnerを経由してAWS EC2を認識させる
ジョブがどのサーバー（ノード）で実行されるかを定義します。
「Runner」のセクションで、作成済みのRunnerを選択します。これにより、PD RBAのRunnerを介してAWSにアクセスするようになります。
4.3 ステップの追加：EC2ステータス取得コマンドの実行
次に、ジョブが実際に何をするかを定義します。
今回は、Linuxコマンドを使って各種使用率を取得します。
①ジョブ作成画面の「Workflow」タブを開きます。
②「Add a step」をクリックし、コマンドステップを追加します。
③スクリプトの内容に、CPU使用率、メモリ使用率、ディスク使用率を取得するためのLinuxコマンドを記述します。
CPU使用率が高いTOP5を抽出します。
メモリ使用率が高いTOP5を抽出します。
ディスク使用率が高いTOP10を抽出します。
これで、指定したEC2インスタンスのCPU使用率、メモリ使用率、ディスク使用率を確認できる自動化ジョブが完成しました。
5. 実行と結果の確認
作成したジョブを実行して、実際にEC2インスタンスのCPU使用率、メモリ使用率、ディスク使用率が確認できるか試してみましょう。
①ジョブの詳細画面に戻り、「EC2 Instance ID」欄に対象のEC2インスタンスを入力します。
②「今すぐジョブを実行」を押下します。
ジョブが実行されると、リアルタイムでログが表示されます。
ログには、SSH経由で実行されたコマンドの出力（CPU使用率、メモリ使用率、ディスク使用率）が順番に表示されます。
もしSSH接続エラーやコマンド実行エラーが発生した場合は、その旨がログに記録されます。
CPU使用率が高いTOP5の抽出結果です。
メモリ使用率が高いTOP5の抽出結果です。
ディスク使用率が高いTOP10の抽出結果です。
このように、PD RBAを通じてEC2インスタンスのサーバー内部情報を自動的に取得し、その結果をジョブログで確認できるようになりました。
6. まとめ
今回の記事では、PD RBA を使って EC2 インスタンスの CPU使用率、メモリ使用率、ディスク使用率 の調査を実施しました。
PagerDutyでアラートを検知したものに対して、ジョブを起動させることで、自動で調査を実施することが可能です。
しかし、自動化の真価は「検知」に留まりません。
検知した異常に対して、自動的に対応する、つまり 自動復旧 などの次のアクションへ繋げることで、運用の手間を劇的に削減し、システムの安定稼働に貢献できます。
弊社のこちらの記事「PagerDutyを活用したインシデント対応の自動化」で紹介されているように、異常を検知した後の具体的なアクションを自動化する例は多岐にわたります。
今回の調査の自動化を応用することで、一貫した運用フローを構築できます。
手動運用が抱える課題を解決し、より効率的で信頼性の高いシステム運用体制を構築するために、ぜひPagerDuty Runbook Automationの導入をご検討ください。
弊社では、現在インシデント対応を「PagerDuty」と「AMS」というシステムを用いて自動化しております。
その知見を生かし、お客様のシステムの内製化支援等も行っていますので、ご興味がある方は、アイレットへお気軽にご相談ください。
簡単30秒