テクニカルサポートノートシリーズの記事をChatGPTに手伝ってもらえるかを検証してみた

はじめに

猫とアポロチョコとSystems Managerが好きな、テクニカルサポートの m.hayakawa です。

DevelopersIO では、AWSテクニカルサポートノートシリーズといったカテゴリーで記事を掲載しております。

このシリーズでは、記事の内容が直感的であること、また、記事を読む時間を短くすることを目的に以下の構成とするよう定めています。

• 困っていた内容
• どう対応すればいいの?
• 参考資料

また、以下の内容となるようにも工夫しています。

• 一問一答形式の記事
• ドキュメントなどの情報ソースを明記し、明確な解決方法を記載する

ここで ChatGPT の出番です。ある程度アジェンダが定まっており、一問一答形式であり、結論が定まっている場合、テーマを与えればクオリティの高いものを出力してくれる可能性がありそうです。

ChatGPT に投げてみる

今回はPlayGroundを使ってみます。

以下のプロンプトを与えてみます。SSM Agent に関する問題を例示として与えてみます。 Model は text-davinci-003、回答のパターンはあまり求めていないため、templature は 1 にしました。

あなたはAWSテクニカルサポートの役割を担っています。

AWS Systems Manager Agent が EC2 にインストールされています。
Systems Manager の ping の状態が、Connection Lost になりました。
この問題を解決するための案内として、以下のアジェンダで文章を作ってください。

- 困っていた内容
- どう対応すればいいの?
- 参考資料

回答

### 困っていた内容

AWS Systems Manager Agent の ping の状態が、Connection Lost になっています。

### どう対応すればいいの?

1. AWS Systems Manager のアクセス権限を確認します。
2. EC2 内の Systems Manager Agent のログを確認して、原因を特定します。
3. EC2 Security Group の制限を確認して、コネクション試行ができるように許可設定を行います。
4. Agent の状態を見直し、再起動を行います。

### 参考資料

- [AWS Systems Manager のアクセス権限の確認方法](https://docs.aws.amazon.com/systems-manager/latest/userguide/getting-started-prereqs.html#get-started-role)
- [EC2 の Systems Manager Agent のログの確認方法](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-logs.html)
- [EC2 Security Group の制限の確認方法](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)
- [AWS Systems Manager Agent の状態の確認以上の方法](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ddetail-check-agent.html)

割と近めの答えが返ってきた感じがしています。しかもマークダウン記法ですね。 せっかくなのでひとつひとつ見ていきましょう。

1. AWS Systems Manager のアクセス権限を確認します。

これは近いところもありますが、SSM Agent がインストールされている EC2 にアタッチされている IAM ロールに、管理ポリシーAmazonSSMManagedInstanceCoreが付与されているか、という記載のほうがより具体的になりそうです。

ステップ 1: Systems Manager にインスタンスのアクセス許可を設定する - AWS Systems Manager

[Add permissions] (アクセス許可を追加する) ページで、以下を実行します。

[Search] (検索) フィールドを使用して、[AmazonSSMManagedInstanceCore] ポリシーを検索します。名前の横にあるチェックボックスを選択します。

2. EC2 内の Systems Manager Agent のログを確認して、原因を特定します。

SSM Agent のログは下記のフォルダに保存されています。

Windows

• %PROGRAMDATA%\Amazon\SSM\Logs\ フォルダ配下一式
• %PROGRAMDATA%\Amazon\SSM\InstanceData\ フォルダ配下一式
• %PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs\ フォルダ配下一式

Linux

• /var/log/amazon/ssm/amazon-ssm-agent.log
• /var/log/amazon/ssm/errors.log
• /var/log/amazon/ssm/audits/amazon-ssm-agent-audit-YYYY-MM-DD

このログを見ることで、何か問題が発生していないかを確認できます。

3. EC2 Security Group の制限を確認して、コネクション試行ができるように許可設定を行います。

SSM Agent の通信要件として、セキュリティグループのアウトバウンドルールで HTTPS 443 の通信を許可する必要があります。

ステップ 1: Systems Manager にインスタンスのアクセス許可を設定する - AWS Systems Manager

VPC エンドポイントを使用しない場合は、Systems Manager エンドポイントへの HTTPS (ポート 443) アウトバウンドトラフィックを許可するようにマネージドインスタンスを設定する必要があります。

4. Agent の状態を見直し、再起動を行います。

まれにですが、SSM Agent を再起動することで、状況が改善する場合があります。

再起動方法は EC2 へ SSH ログインし、以下のコマンドを実行します。

Windows

Restart-Service AmazonSSMAgent

Linux

sudo systemctl start amazon-ssm-agent

最後に

完璧ではありませんが、ある程度は網羅されていそうです。

もう少し記載内容を充実できそうな気がしますが、ある程度の記載項目の候補を出してくれるだけでも、相当な時間短縮になりそうです。

ある程度の書式があるものは、よさそうな回答が得られる可能性が高いと認識できました。

text-davinci-003でも、手伝ってもらうには十分な内容でありました。

GPT-4になったら、よりよくなりそうな気配なので、API で使える日が楽しみです。

ちなみに、AWS re:Post にも同様の記事があります。

公式ドキュメントは完全に網羅されていますが、text-davinci-003もエッセンスを抜き出した形になっているので、十分利用価値が高いと認識しました。

参考資料

ステップ 1: Systems Manager にインスタンスのアクセス許可を設定する - AWS Systems Manager

Amazon Linux 2 インスタンスに SSM Agent を手動でインストールする - AWS Systems Manager

Windows Server 用 EC2 インスタンスに手動で SSM Agent をインストールする - AWS Systems Manager