こんにちは！システム開発チームです。
弊社では、Slack ワークフローを活用して、検証環境の EC2 インスタンス起動などの運用作業を効率化しています。
Slack 上から AWS リソースを操作する際は、AWS Chatbot / Amazon Q Developer in chat applications の @Amazon Q コマンドを利用できます。ただし、リソースを変更する場合など、コマンドによっては実行前に以下のような確認操作が入ることがあるため、Slack ワークフローから自動で実行する場合は少し手間になります。
そこで、AWS コマンドを投稿したあとに @Amazon Q run を続けて投稿し、確認操作までワークフロー内で完結させるようにしました。
こちらの記事では、確認操作を自動化する方法と、その際に発生した「run が早すぎて失敗する問題」とその回避方法を紹介します。
※なお、本記事では分かりやすさを優先して @Amazon Q と記載していますが呼び出す場合は、表示名ではなく bot user の member ID を使う方法が推奨されています。こちらについては、また別の記事でまとめたいと思います。
やりたかったことは、Slack ワークフローから AWS リソースを起動することです。イメージとしては、以下のような流れです。
Slack ワークフローを起動
↓
@Amazon Q コマンドを投稿
↓
AWS 側の確認メッセージが返ってくる
↓
@Amazon Q run を投稿
↓
AWS コマンドが実行される
たとえば、EC2 インスタンスを起動する場合であれば、Slack ワークフローから @Amazon Q コマンドを投稿し、その後に @Amazon Q run を投稿して実行する、という形です。こうすることで、Slack 上に表示される確認メッセージに対して、手動で [Run] ボタンを押さなくても自動実行できるようになります。
最初は、とても単純に以下のような流れにしていました。
@Amazon Q コマンドを投稿
↓
@Amazon Q run を投稿
つまり、AWS コマンドを投稿した直後に、続けて @Amazon Q run を投稿する形です。
一見これでうまく動きそうに見えます。
@Amazon Q run で実行する。この順番になってくれれば問題ありません。
しかし、実際にはたまにうまく動かないことがありました。
原因は、Slack ワークフローの処理が速すぎることでした。期待していた順番は以下の通りです。
@Amazon Q コマンドを投稿
↓
AWS 側の確認メッセージが返ってくる
↓
@Amazon Q run を投稿
↓
実行される
しかし、タイミングによっては次のような順番になってしまいます。
@Amazon Q コマンドを投稿
↓
@Amazon Q run を投稿
↓
AWS 側の確認メッセージが返ってくる
こうなると、@Amazon Q run が AWS 側の確認メッセージに対する応答として扱われず失敗する場合があります。こちらとしては「run」と言っているつもりでも、AWS 側ではまだ確認メッセージを出す前なので、実行指示として受け取ってもらえない状態です。
こういうとき、まず考えるのは Slack ワークフローの遅延機能です。@Amazon Q run の前に少し待てば、AWS 側の確認メッセージが返ってきた後に run を投稿できそうです。
ただ、今回ほしかったのは数秒の遅延であり、Slack の遅延機能は最低でも分単位で指定する形なので、「3 秒だけ待つ」「5 秒だけ待つ」といった用途には向いていません。
今回の用途では、1分待ってしまうと長すぎます。AWS 側の確認メッセージが返ってくるまで数秒だけ待てればよく、逆に待ちすぎるとタイムアウトとなり確認操作のタイミングを逃してしまう可能性があります。
そのため、Slack 標準の遅延機能ではなく、別の方法で数秒程度の間を作ることにしました。
最終的には、@Amazon Q run を投稿する前に、スレッドへメッセージを 2 件ほど投稿するようにしました。流れとしては以下の通りです。
@Amazon Q コマンドを投稿
↓
待機用メッセージを投稿
↓
待機用メッセージをもう 1 件投稿
↓
@Amazon Q run を投稿
待機用メッセージの内容は、特に重要ではありません。例えば以下のようなメッセージです。
AWS 側の確認メッセージを待機中...
実行準備中...
目的は、Slack ワークフローのステップをいくつか挟むことで、@Amazon Q run が投稿されるタイミングを少しだけ後ろにずらすことです。
これにより、AWS 側の確認メッセージが返ってきた後に @Amazon Q run が投稿されやすくなり、結果として確認メッセージへの応答として扱われ、期待通りに AWS コマンドが実行されるようになりました。
実際には、以下のような構成にしています。
1. ワークフローを起動
2. スレッドに @Amazon Q コマンドを投稿
3. スレッドに待機用メッセージを投稿
4. スレッドにもう 1 件、待機用メッセージを投稿
5. スレッドに @Amazon Q run を投稿
ポイントは、@Amazon Q コマンドと @Amazon Q run を連続で投稿しないことです。間に何かしらのステップを挟んで、AWS 側の確認メッセージが返ってくるための時間を作ります。
弊社では、メッセージ投稿を 2 件挟むことで安定しました。ただし、必要なメッセージ数は環境やタイミングによって変わる可能性があります。
もし 2 件で安定しない場合は、メッセージ数を増やす、別のステップを挟む、そもそもの構成を見直す、といった対応が必要になるかもしれません。
この方法は、あくまで簡易的な回避策です。Slack や AWS 側の仕様として、「メッセージを 2 件挟めば必ず何秒待てる」と保証されているわけではありません。
そのため、以下のような場合には挙動が変わる可能性があります。
また、公開環境や重要な本番リソースに対して使う場合は、誤操作を防ぐための設計も別途考えた方がよいです。@Amazon Q run によって確認操作を自動化できるということは、裏を返すと、ワークフローが起動されればそのまま AWS リソース操作まで進むということでもあります。
そのため、以下のような点には注意が必要です。
ちょっとした検証環境の起動などであれば便利ですが、重要な操作に使う場合は、権限や承認フローも含めて設計した方が安全です。
弊社では、Slack ワークフローから AWS リソースを起動する際、AWS Chatbot / Amazon Q Developer in chat applications の確認操作を @Amazon Q run で自動化しました。ただし、AWS コマンド投稿直後に @Amazon Q run を投稿すると、AWS 側の確認メッセージが返ってくる前に run が送信されてしまい、期待通りに実行されないことがあります。
Slack 標準の遅延機能もありますが、分単位の待機になるため、今回のように数秒だけ待ちたいケースには少し使いづらいです。そこで、@Amazon Q run の前にスレッドへのメッセージ投稿を 2 件ほど挟むことで、自然に数秒程度の遅延を作るようにしました。
少し力技ではありますが、今回のケースではこれで安定して動くようになりました。
Slack ワークフローから AWS リソース操作を簡単に実行したい場合など、ご参考になれば幸いです。