안정적인 Slack 앱 구축

Slack 앱을 만드는 것은 재미있습니다! 그런데 당신의 앱은 신뢰할 수 있나요?
직접 빌드하는 동안 인기 있는 오픈 소스 Slack 앱에서 두 가지 일반적인 문제를 발견했습니다.

1. 많은 앱이 이벤트를 동기적으로 처리하므로 시간 초과가 발생할 수 있습니다. Slack은 3초 이내에 응답을 기대하지만 앱이 AI/RAG 파이프라인을 트리거하는 경우 AI 모델이 응답을 생성하는 데 더 오랜 시간이 걸릴 수 있습니다(예: 새로운 o1 모델은 "생각"하는 데 최대 10초가 걸릴 수 있음). Slack의 모범 사례에서는 이벤트를 대기열에 추가하고 비동기식으로 처리하는 것을 권장합니다.

2. 많은 앱이 중복 이벤트를 처리하지 않습니다. 앱이 응답하지 않으면 Slack은 이벤트를 세 번 다시 시도합니다. 적절하게 처리하지 않으면 재시도로 인해 앱에서 중복되거나 일관되지 않은 응답이 발생할 수 있습니다. 이는 나쁜 사용자 경험으로 이어집니다.

오픈 소스 경량 내구성 실행 라이브러리인 DBOS Python을 사용하여 이 문제를 해결하는 방법은 다음과 같습니다. 기성 AI/RAG 기반 Slack 앱 데모(LlamaIndex의 llamabot)에서 시작하여 가볍게 수정되고 주석이 달린 기능을 사용하여 각 수신 메시지가 DBOS 워크플로를 시작하도록 했습니다.

메시지 발송 코드는 간단합니다.

@slackapp.message()
def handle_message(request: BoltRequest) -> None:
    DBOS.logger.info(f"Received message: {request.body}")
    event_id = request.body["event_id"]
    # Use the unique event_id as an idempotency key to guarantee each message is processed exactly-once
    with SetWorkflowID(event_id):
        # Start the event processing workflow in the background then respond to Slack.
        # We can't wait for the workflow to finish because Slack expects the
        # endpoint to reply within 3 seconds.
        DBOS.start_workflow(message_workflow, request.body["event"])

1. 워크플로가 백그라운드에서 시작되므로 내 앱이 Slack에 빠르게 응답할 수 있습니다. DBOS 워크플로는 일단 시작되면 항상 완료될 때까지 실행됩니다(비동기적으로 실행되는 경우에도 마찬가지). 따라서 메시지는 항상 안정적으로 처리됩니다.

2. 메시지의 이벤트 ID를 워크플로의 멱등성 키로 사용하므로 DBOS는 이를 사용하여 각 메시지가 정확히 한 번 처리되도록 합니다.

제가 구축한 AI 기반 Slack 앱에 대한 자세한 내용은 이 GitHub 저장소에서 확인할 수 있습니다: https://github.com/dbos-inc/dbos-demo-apps/tree/main/python/llamabot

README에는 Slack 작업 공간에서 이 앱을 직접 사용하는 방법에 대한 자세한 지침이 포함되어 있습니다.

일반적으로 안정적인 애플리케이션을 어떻게 구축하시나요? 이 앱에 대한 피드백이 있나요? 꼭 알려주세요!

위 내용은 안정적인 Slack 앱 구축의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!