はじめに
以前作成・構成を構築した Minecraft サーバの自動停止機構ですが、起動時に自動で付与された EIP をユーザに通知する方法が メール しかありませんでした。
ユーザーはゲーマーなので、できれば Discord に通知したい と考えました。
AWS 環境上から Discord へ通知を実施するためには SNS ではなく、基本的には Lambda を使用し、Discord Webhook を通じてメッセージをプッシュする 形で実現できます。構成図はこのような形になります。
必要な作業を整理すると、以下の通りです。
- Lambda のコーディング
- 作成した Lambda を SNS にサブスクリプション
- 実装テスト
ただ正直なところ、メールで配信しているものを Discord に配信するだけなのに、思ったより労力がかかりそう という印象を受けました。（Lambda は使用せず、SNS から直接通知を飛ばせると思っていました...）
Discord へのメッセージ通知を実施する汎用 Lambda のコード（Python）を使って、実際に通知できるかテストするところまではやりました。コードは こちらの JavaScript のコード をお借りして、Claude に Python 用に書き換えてもらいました。
でも そこから先の作業はめんどくさくなって手が止まってしまいました。
そこで思いついたのが、
「これ、kiro を使えばすぐ出来そうだな...」
配信したい内容は E-mail 配信用のメッセージ成型 Lambda 内に記載されていますし、配信先となる Discord Webhook の URL もテスト用 Lambda に記載されています。
以前社内の勉強会でkiro-cliを触った際、自動でリソース情報を確認し、リソースの追加・削除等を実施していたことを思い出し、今回のケースで活用できるのではないかと考えました。
ということで、自分でほとんど環境に触らず、自動起動停止の際に付与された EC2 の EIP を Discord にも通知されるように環境を変更しました。
kiro-cli について
kiro-cliの概要等については以下の公式ブログを確認してください。
https://aws.amazon.com/jp/blogs/news/introducing-kiro-cli/
kiro-cli（以下、kiro と記載します）は今回 CloudShell 上で利用しました。理由は以下の二点です。
- CloudShell 上では kiro がプリインストール※されているから
- 現在使用しているローカルのマシンが Windows で、導入に手間がかかりそうだったから
「使ってみよう！」レベルの思い付きだったので、とっつきやすい CloudShell を使用した形です。軽微な利用なら全く問題ないかと思います。
実行された内容
kiro-cli を起動し、以下のメッセージを投げました。
「現在 AWS SNS にて EC2 が自動起動された際に付与された EIP をメール通知する機構を搭載しています。これと同様のことを Discord でも実施したいと考えています。自動起動された EC2 の EIP を読み取り、それを Discord にプッシュ通知する Lambda を作成してください」
AI に投げる文章としては標準的なレベルかと思います。
kiro が実行した内容の流れはおおよそ以下の通りでした。
現在の構成の確認（SNS・Lambda）
↓
リソースの作成・設定（Lambda 関数作成・SNS サブスク登録）
↓
テスト実施
所要時間は約 2 分 でした。
⚠️ 実行中の確認メッセージについて
実行中に何回か以下の確認メッセージが出力されました。
Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:
| 入力 | 意味 |
|---|---|
y |
許可 |
n |
拒否 |
t |
セッション中の全操作を信頼（事前確認なしで実行） |
t の「信頼」は後から理解しました。メッセージ内に記載されている通り、kiro を当該セッションにおいて信頼する（≒全ての操作を容認）ということになります。リソースを参照するときはもちろん、リソースに変更を与える場合においても事前確認なく処理を実行してしまいます。 便利な反面、思わぬ操作をされる可能性があるので、t の使用には注意が必要です。
その他の注意点
- 環境確認の工程ですべての Lambda を確認していました。 今回は全て関連性があり、数も 3 つしかなかったので特に問題ありませんが、多数の関数を使用している環境では注意が必要です。
- kiro が爆速で処理してくれるので流されがちですが、環境に変化を与える処理を実施する場合は、kiro が実行しようとしている内容をしっかり確認する必要があると認識しました。
構築物
Lambda 関数
以下が kiro が作成したコードです。
import json
import os
import urllib.request
DISCORD_WEBHOOK_URL = os.environ['DISCORD_WEBHOOK_URL']
def lambda_handler(event, context):
# SNSからメッセージを取得
sns_message = event['Records'][0]['Sns']
subject = sns_message.get('Subject', '')
message = sns_message.get('Message', '')
payload = json.dumps({
"content": f"**{subject}**\n```\n{message}\n```"
}).encode('utf-8')
req = urllib.request.Request(
DISCORD_WEBHOOK_URL,
data=payload,
headers={
'Content-Type': 'application/json',
'User-Agent': 'DiscordBot (https://example.com, 1.0)'
},
method='POST'
)
with urllib.request.urlopen(req) as res:
print(f"Discord response: {res.status}")
メッセージ成型用 Lambda で作成されたメッセージから 題名と本文を参照し、マークダウン形式で整形、Discord WebHook へ HTTP POST リクエストを送信する というフローになっています。
おそらく、テスト用に作成した Discord へメッセージを転送する関数を参考にして、この関数を作り上げたようです。ちなみにそのテスト関数内に Discord Webhook の URL も記載してあったので、kiro 作成の関数内でもその URL が通知先として設定されています。
実装したい機能が十分に搭載されているのはもちろん、マークダウン形式での整形という追加の機能まで乗せてきたのはすごい と思いました。
テストについては自動的に実施され、想定通りのメッセージが Discord に届いていたので問題ない認識です。
（インスタンス ID 等は加工で消していますが、適切な内容が記載されていました）
まとめ
たった一言を伝えるだけで、kiro は実装してほしいものを実装してくれました。
kiro ならこういうことが出来ると知ってはいましたが、思った以上に便利でした。
環境に変更を加える場合はその処理の前に実施の可否も聞いてくれるので、トラブルも思ったよりは発生しにくそうな感じがしました。
今回はほぼ構築とテストでしたが、それ以外の工程も実施可能らしいので、今後は設計やトラブル時の環境調査等にも活用してみたい と思いました。
それでは失礼します。
余談
Lambda 関数内で記載されている通知先の 'DISCORD_WEBHOOK_URL' は 環境変数 が設定されていました。
実はこの完成品を見るまで、この環境変数という機能を知りませんでした...
業務上、実際の構築はほぼ実施しないので、このような自己学習の場も AWS に対する全体的な理解を深めるうえで重要 だなと改めて実感しました。