おぎろぐはてブロ

なんだかんだエンジニアになって10年以上

AWS SAM + Slack Bolt for PythonでSlack botをつくる

書いたこと

  • Lazy Listenerを利用し、ackが必要なイベントかつ3秒以上時間がかかる処理を実現する
  • Lambda Function URLを利用してHTTP Endpointをつくる

Slack Bolt for PythonでSlack botをつくる

このチュートリアルを参照しつつ、つくります。割愛。

slack.dev

ある程度、チュートリアルに沿って、ローカルで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_somethingstep_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 になります。