AWS SAM + Slack Bolt for PythonでSlack botをつくる
書いたこと
- Lazy Listenerを利用し、ackが必要なイベントかつ3秒以上時間がかかる処理を実現する
- Lambda Function URLを利用してHTTP Endpointをつくる
Slack Bolt for PythonでSlack botをつくる
このチュートリアルを参照しつつ、つくります。割愛。
ある程度、チュートリアルに沿って、ローカルでSocket Mode有効でつくってから、Lambdaで動かすように次のLazy Listernerを有効にするように自分はしています。
Lazy Listenerの利用
Boltで受けられるイベントは各種ありますが、アクション(action)、コマンド(command)、ショートカット(shortcut)、オプション(options)、およびモーダルからのデータ送信(view_submission)を処理する場合は、Slack側からのリクエストに対して3秒以内に ack()
を返す必要があります。
ただ、Lambdaで動かす場合、HTTPレスポンスを返却したタイミングでプロセスが終了されるため、ackを返したあとに処理を継続させることができません。この対応として、Slack Bolt for Pythonでは、Lazy Listenerという機能が提供されています。
これは、HTTPでSlackからリクエストを受け取ったLambdaプロセスが、時間のかかる処理を実行するLambdaを非同期で呼び出して、ackレスポンスを返却することで実現されています。
例にあるように、ack
と、 lazy
の引数にそれぞれack処理と、時間のかかる処理を分けて書けます。lazyには複数の関数を渡せ、それぞれ並列に実行されます。
lazyに1つ処理を指定した場合、1つのイベントに対してack処理とlazy処理でLambdaが2度invokeされることになります。上に書いてあるackが必要なイベント以外をハンドルする場合はackが不要なので、その場合Lazy Listenerを使うと無駄にinvokeの回数が増えるので、この場合はLazy Listenerを有効にしないほうがよいです。
以下は、行頭にHelloもしくはhelloという文字列があったときにHello!を発言する場合です。 (messageイベントはackが不要なのでlazyを使う必要はないです)
import logging import re from slack_bolt import App, Say from slack_bolt.adapter.aws_lambda import SlackRequestHandler SlackRequestHandler.clear_all_log_handlers() logging.basicConfig(level=logging.INFO) app = App(process_before_response=True) def handle_message(message, say: Say): print(message) say("Hello!") rule = re.compile("^[Hh]ello") app.message(rule)( ack=lambda ack: ack(), lazy=[handle_message] ) def handler(event, context): print("invoked", event) slack_handler = SlackRequestHandler(app=app) return slack_handler.handle(event, context)
とにかくackだけ返したければ
ack=lambda ack: ack(),
と書けばOK
呼び出しをCloudWatch Metricsにputする
Slack botを作った場合、Slackからの呼び出しは同じLambda Functionが呼び出されるだけなので、複数のイベントをハンドリングする場合、どのイベントがどのくらい呼び出されているのかを調べるのが困難です。このときCloudWatch metricsにメトリックを記録すると便利です。
以下のように定義して、handle_shortcut
ではackしつつmodalを開いたりし、do_something
では時間のかかる処理を行い、step_handle_shortcut
ではCloudWatch metricsにメトリックを記録します。
do_something
と step_handle_shortcut
は並列にinvokeされます。
app.shortcut("shortcut")(
ack=handle_shortcut,
lazy=[do_something, metric.step_handle_shortcut]
)
metric.py
では
import boto3 import os import datetime def put(step: str): client = boto3.client("cloudwatch") env = os.getenv("ENV") # 別途定義する response = client.put_metric_data( Namespace=f"FooBarSlackApp/{env}", MetricData=[ { "MetricName": "Request", "Dimensions": [ { "Name": "Step", "Value": step }, ], "Timestamp": datetime.datetime.utcnow(), "Value": 1, }, ] ) print(response) def step_handle_shortcut(): put("handle_shortcut")
SAMでデプロイ
最低限必要なのは Lambda Function と、HTTP EndpointとしてのLambda Function URLです。 HTTP EndpointとしてAPI Gateway (v1, v2) を利用している例があったりしますが、特に高度な定義も必要なければ、Lambda Function URLを使用するほうが、定義が簡単で、かつ、利用料金もLambda側に含まれるので安価になります。(大抵はまぁ誤差みたいな金額だと思いますが)
src/
配下にコードを配置した場合、以下のようなコードで実現できます。
AWSTemplateFormatVersion: "2010-09-09" Transform: AWS::Serverless-2016-10-31 Description: Slack bot sample Resources: HandlerFunction: Type: AWS::Serverless::Function Properties: CodeUri: src/ Handler: app.handler Runtime: python3.11 Timeout: 30 Policies: - AWSLambdaRole FunctionUrlConfig: AuthType: NONE Outputs: HandlerFunctionUrl: Value: !GetAtt HandlerFunctionUrl.FunctionUrl
FunctionUrlConfig
を定義してやると、Lambda Function URLが有効になります。SlackからのリクエストにIAM認証を利用することはできないので、AuthType: NONE
になります。(bolt内でSlackの特定のアプリから来た正当なリクエストか signing_secret
を利用して検証しています)
Slack appの Interactivity eventsのURL、Slash commandのURL、Event SubscriptionsのURL (それぞれ有効にするかは使うイベント次第) にこのLambda Function URLのURLを指定してやる必要があるので、Outputs
で出力をしています。
SAMでリソースが勝手に作られて、その名前が Lambda Function名に Url
を足したものになるので、Lambda Functionが HandlerFunction
の場合、 HandlerFunctionUrl
になります。