알림톡 개선

📌 기능 정의

문제점

• 채팅을 쳤을 때 API가 호출되는데 예약내역에 알림톡이 있을 때 이 알림톡을 취소하고 다시 예약을 걸 때 기존 예약시간으로 예약하지 않고 예약을 거는 시점의 시간을 예약하는 문제점이 발생합니다.

상황

• 보험사 직원 철수가 채팅방에서 오전 10시에 채팅 하나를 전송했다가 잘못 전송한 것을 인지하고 10시 01분이 도래하기 전 10시 00분 59초에 채팅방에 채팅을 올리게 됩니다. 원래 해당 알림톡은 10시 1분에 가상공업사에 전달 될 예정이었으나 도래하기 전에 채팅을 전송함으로써 기존알림이 취소 되고 10시 01분 59초 뒤에 알림이 가게 되었습니다. 그랬을 때 채팅방에 계속 채팅을 생성하게 될 경우 예정된 시간에 알림이 가지 못하는 문제점이 발생합니다.

🛠 설계 및 추가 기능

⚙️ 추가기능

• 가상 공업사가 하나의 메세지를 읽지 않았을 경우 해당 메세지의 내용이 보여지게 한다.
• 가상 공업사가 2개 이상의 메세지를 읽지 않았을 경우 읽지 않은 건수에 대해서 표시하게 한다.

⚙️ 모델링

🧰 도구 선정

CoolSms

특정 시점에 원하는 기능 을 수행

• 위에 적어놓은 부분이 1차적으로 가장 필요한 기능입니다. CoolSms에 돈을 내고 사용하고 있었기에 기존에 있는 CoolSms를 활용하여 특정 시점에 원하는 기능을 사용하는 것이 1차 선택지라고 생각되어 CoolSms의 예약 관련 API를 이용하여 위의 기능 을 구현하고자 하였습니다.

• CoolSms 관련 자료 수집 결과 예약 알림을 사용하는 기능이 존재했고 해당 기능은 언어별로 코드와 API를 제공하고 있었습니다. 아래 코드가 예약관련된 파이썬코드 전문이었고 해당 코드만으론 sms 기능에 국한된거지, 카카오톡 알림도 가능한거지 검증하는 과정이 필요했습니다.

if __name__ == '__main__':
    utc_offset_sec = time.altzone if time.localtime().tm_isdst else time.timezone
    utc_offset = datetime.timedelta(seconds=-utc_offset_sec)

    # 희망하시는 예약 날짜를 넣어주세요
    # datetime(년, 월, 일, 시, 분, 초)
    scheduledDate = datetime.datetime(2022, 2, 8, 0, 0, 0).replace(
        tzinfo=datetime.timezone(offset=utc_offset)).isoformat()
    data = {
        'scheduledDate': scheduledDate
    }

    # [INPUT_GROUP_ID] 에 그룹 아이디를 넣어주세요
    # ex) G4V20181005122748TESTTESTTESTTES
    res = message.post('/messages/v4/groups/[INPUT_GROUP_ID]/schedule', data=data)

• 검증 결과 특정 시점에 원하는 기능을 수행할 수 있었고 1차 선택지로 개발을 진행하기로 했습니다. 위 API에 어떻게 data를 담는지 궁금하실 수도 있으실 것 같아서 아래 형태의 데이터를 소개해드리겠습니다. 실질적으로 내용을 담아 특정 시간에 알림을 보내야 합니다. 이때 위 API data에는 아래의 형태가 들어가게 되고 messages 가 key로 []형태의 값을 갖고 있는데 'scheduledDate': scheduledDate 해당 형태를 data 부문에 추가해서 넣어 주시면 저희가 1차적으로 목표했던 원하는 시간에 알람을 보내는 기능을 수행할 수 있습니다.

data = {
	"scheduledDate": scheduledDate
    "messages": [
        {
            "to": params["phone"],
            "from": settings.SENDER,
            "kakaoOptions": {
                "pfId": "KA01PF220419030622998QL1fNO8mOEN",
                "templateId": "KA01TP22101204464856145zRAS7bWfv"
                if settings.SERVER_ENVIROMENT == "prod"
                else "KA01TP220721063111651MN94HDoefzd",
                "variables": {
                    "#{name}": params["name"],
                    "#{bookingDate}": params["date"],
                    "#{bookingTime}": params["time"],
                    "#{carNum}": params["car_number"],
                    "#{repairshopName}": params["agent_name"],
                    "#{repairshopLocation}": params["agent_location"],
                    "#{code}": cipher,
                },
            },
        },
    ]
}

CoolSms를 사용하면서 마주한 것들

GrouID

그룹 아이디에 대한 개념이 명확하지 않아 찾아본 결과 메세지를 발송 할 때의 트랜잭션으로서의 기능을 수행하는 대상이고 이를 메세지 전송 > 전송 결과로 들어가 아래와 같이 확인해 볼 수 있습니다. 여기서 트랜잭션이란 수행해야할 과업이 과업1, 과업2, 과업3 .. 과업100 가 있고 이를 수행하는데 있어 묶음으로 수행하여 반영하겠다는 의미입니다. 예를 들어 첩보영화에서 서버실에 침입해 중요한 자료를 받으려고 할 때 99%로에서 전원 끊기면 99% 받은게 아니라 원점입니다. 묶음으로 관리하기 때문입니다.

하나를 선택해서 json 형태의 response를 보면 _id 필드에 G4V20221018095137DS0WQ7OZWQ0IPHL 가 적혀있는데 해당 부문이 그룹아이디에 해당하는 부문이고 여러개를 클릭해 보면 각각마다 서로 다른 그룹아이디로 메세지가 관리되는 것을 알 수 있습니다. 즉 메세지마다 고유한 그룹아이디가 부여되는 것입니다.

{
  "_id": "G4V20221018095137DS0WQ7OZWQ0IPHL",
  "count": {
    "total": 1,
    "sentTotal": 1,
    "sentFailed": 0,
    "sentSuccess": 1,
    "sentPending": 0,
    "sentReplacement": 0,
    "refund": 0,
    "registeredFailed": 0,
    "registeredSuccess": 1
  },
  "countForCharge": {
    "sms": {},
    "lms": {
      "82": 1
    },
    "mms": {},
    "ata": {},
    "cta": {},
    "cti": {},
    "nsa": {},
    "rcs_sms": {},
    "rcs_lms": {},
    "rcs_mms": {},
    "rcs_tpl": {}
  },
  "balance": {
    "requested": 0,
    "replacement": 0,
    "refund": 0,
    "sum": 0
  },
  "point": {
    "requested": 50,
    "replacement": 0,
    "refund": 0,
    "sum": 50
  },
  "app": {
    "profit": {
      "sms": 0,
      "lms": 0,
      "mms": 0,
      "ata": 0,
      "cta": 0,
      "cti": 0,
      "nsa": 0,
      "rcs_sms": 0,
      "rcs_lms": 0,
      "rcs_mms": 0,
      "rcs_tpl": 0
    },
    "appId": null,
    "version": null
  },
  "serviceMethod": "MT",
  "sdkVersion": "sms-python 2.0.3",
  "osPlatform": "14.38.93.171|Darwin|Python 3.9.4|sms/2",
  "log": [
    {
      "createAt": "2022-10-18T00:51:37.200Z",
      "message": "[::ffff:127.0.0.6] 메시지 그룹이 생성되었습니다."
    },
    {
      "createAt": "2022-10-18T00:51:37.265Z",
      "message": "국가코드(82)의 장문문자(LMS) 1 건이 추가되었습니다."
    },
    {
      "createAt": "2022-10-18T00:51:37.422Z",
      "message": "메시지를 발송했습니다.",
      "oldBalance": 0,
      "newBalance": 0,
      "oldPoint": 74489,
      "newPoint": 74439,
      "totalPrice": 50
    }
  ],
  "status": "COMPLETE",
  "dateSent": "2022-10-18T00:51:37.422Z",
  "scheduledDate": null,
  "dateCompleted": "2022-10-18T00:51:50.855Z",
  "isRefunded": false,
  "flagUpdated": false,
  "prepaid": true,
  "strict": false,
  "masterAccountId": null,
  "allowDuplicates": false,
  "accountId": "21030220742796",
  "apiVersion": "2",
  "customFields": {
    "coolsmsGroupId": "R2Gx2hrUE7Ppm84k"
  },
  "hint": null,
  "groupId": "G4V20221018095137DS0WQ7OZWQ0IPHL",
  "price": {
    "82": {
      "sms": 20,
      "lms": 50,
      "mms": 120,
      "ata": 13,
      "cta": 19,
      "cti": 26,
      "nsa": 13,
      "rcs_lms": 40,
      "rcs_mms": 75,
      "rcs_sms": 15,
      "rcs_tpl": 12
    }
  },
  "dateCreated": "2022-10-18T00:51:37.202Z",
  "dateUpdated": "2022-10-18T00:51:50.855Z"
}

예약 취소

import json
from src.lib import message

'''
예약 발송 취소 예제, 이미 예약 발송이 설정되어 있어야 합니다. 
'''
if __name__ == '__main__':
    # [INPUT_GROUP_ID] 에 그룹 아이디를 넣어주세요
    # ex) G4V20181005122748TESTTESTTESTTES
    res = message.delete('/messages/v4/groups/[INPUT_GROUP_ID]/schedule', data=None)
    print(json.dumps(json.loads(res.text), indent=2, ensure_ascii=False))

• 예약 취소코드를 보면 [INPUT_GROUP_ID]에 그룹아이디를 넣어서 기존 진행했던 예약을 취소하시는 것을 알 수 있습니다. 이를 통해 예약을 걸고 취소하는 기능을 사용하기 위해선 1)API요청을 통해 그룹아이디를 발급받고 이를 관리하여 예약 API 또는예약 취소 API를 호출해야 한다는 것을 알 수 있습니다.

방향성

저희가 필요로 했던 기능, 1) 원하는 시간에 예약을 하는 기능, 2) 기존 예약을 취소하는 기능 2가지 모두 충족하고 있었기 때문에 CoolSms를 활용한 1차 개발을 완료하게 되었습니다.

문제점, GroupID의 잦은 발급으로 인한 로그 확인의 어려움

원하는 기능의 API를 제공했기에 개발을 진행할 수 있었으나 해당 API는 누군가가 채팅을 쳤을 때 동작하는 API로 채팅 전송이 방아쇠 역할을 담당합니다. 이는 API가 잦게 호출 될 수 있다는 것을 의미합니다. 만일 여러 채팅방에서 여러 건의 채팅이 생성 될 경우 예약 관련해서 담당하는 기능이 여러번 호출될 수 있다는 것을 의미하고 이는 계속해서 그룹아이디를 발급 받아야 하는 결과를 낳고 CoolSmS 홈페이지 메세지 로그에 정상 발송건과 혼재되면서 확인하는데 어려움을 초래합니다.

현재 Backend에서 호출되고 있는 API

path(
    "chat/<int:parts_req_id>/create/<int:match_id>",
    views.MatchChatCreateView.as_view(),
    name="match_chat_create_view",
)

CoolSms Log 내역

🧰 도구 재선정

선택의 어려움

생각하고 어떤 도구를 선정하는 작업은 쉽지 않았습니다. 각각의 도구를 사용해 본 경험이 없는 상태에서 사용 설명서만을 보고 문제에 적절한 도구를 선택하여 일을 진행해야 됐기 때문이었습니다.

내장 모듈

파이썬에선 시간을 조작하는 time, threading 모듈을 지원합니다. 해당 모듈을 사용 할 경우 주기적으로 원하는 기능을 수행할 수 있지만, 원하는 시간대에 특정 기능을 활성화시키기 위한 단서를 찾을 수 없었습니다.

sched

외부 모듈인 sched 또한 내장모듈과 마찬가지로 저희가 원하는 시간에 특정 기능을 한번 호출하기 위한 기능을 사용하기 위한 단서를 찾을 수 없었습니다.

django-apscheduler, Celery

위 2개의 앱은 파이썬 진영에서 제공하는 외부앱입니다. 해당 앱들을 사용하는 이유는 주기적으로 그리고 일정한 간격으로 어떤 일을 수행하고 싶을 때 위의 앱을 사용합니다. 위에서 제시한 모듈의 확장팩 느낌으로 기능이 디테일하고 다양합니다.

그렇다면 저희가 해결하고 싶은 부분 -:> 원하는 시간에 예약을 걸고 취소 하는 기능이 있는지 파악해야 했습니다. 채팅을 치는 행위 자체가 주기적인 성격을 띄지 않기 때문입니다.

현재 백엔드 쪽에서 Celery와 django-apscheduler가 설치되어 있습니다. 저의 첫번째 선택은 django-apscheduler 였습니다. 필요한 기능만을 사용하고 싶었고 조금 더 확장팩 느낌인 Celery의 도입은 이후의 순위라고 생각하였기 때문입니다. 그리고 다행히 원하는 시간에 예약을 걸고 취소 하는 기능을 발견할 수 있었습니다.

django-apscheduler 이해하기 위해 필요한 4개의 개념

• triggers
  언제 특정한 기능을 수행할 지를 알려주는 역할을 담당합니다. 촬영장에서 슬레이트와 같은 역할이다.

• job stores
  언제 특정한 기능을 하기로 했는지에 대한 여러 Jobs를 저장하고 있는 공간입니다. 기본 저장공간을 사용 할 경우 memory로 관리되고 scheduler는 해당 공간을 서로 공유하지 않고 독립적으로 갖고 있습니다.

• executors
  job store에 저장된 Job 들을 쓰레드 또는 프로세스 풀에 던져주는 역할을 합니다. 즉 저장공간에 쌓인 일감들이 실행되어야 할 시점이 왔을 때 대기조에 있는 일꾼들에게 일을 전달 해주는 것입니다.

• schedulers
  위의 작업들, Job에 대한 트리거 지정, Job의 저장, Job의 실행등을 관장하는 역할을 담당합니다. 저와 같은 앱개발자는 schedulers를 통해 위의 주체들과 소통하는 것입니다.

선정 과정

위의 4가지 개체를 선정하는 작업이 필요합니다. 기본적으로 예제 코드가 있어 예제코드를 통해 해당 개체들을 지정하는 방법으로 코드를 작성해 나갔습니다.

scheduler ---> BackgroundScheduler

스케줄러의 경우 django-apscheduler는 여러개의 스케줄러를 제공합니다. 저희는 여러개의 채팅방이 생성 될 경우 채팅방 각각을 담당하는 독립적인 scheduler가 필요하므로 BackgroundScheduler를 선택하였습니다. 보통 많이 선택합니다.

job store ---> MemoryJobStore

• you need to determine whether you need job persistence or not

실행 할 일을 저장 할지 말지를 결정해야 했는데 설계 특성상 예약이 걸려있는지 걸려있지 않은지가 분기점이 되어 로직을 수행하므로 Memory에 저장되어 있는 job 하나만 필요하므로 이 또한 기본으로 설정합니다.

trigger --> date

트리거의 종류에는 3가지 트리거가 있는데 date 트리거가 저희의 목적인 특정 시점에 원하는 잡실행 의 기능을 제공해주고 있었습니다. 🤩

💡 이로서 앞으로의 개발 방향에 희망이 생겼습니다.

🛠 Trouble Shooting

설계 후 선택한 도구를 통해서 개발을 진행했을 때 마주한 문제점들을 나열하고 어떤 방식으로 해결하였지 그 과정에 대해서 나누고자합니다.

스케줄 메타

스케줄을 돌리기 위해선 아래의 순서를 따라서 잡을 실행합니다. 스케줄을 돌린 이후에는 설정 값을 동적으로 바꿀 수 없습니다.
스케줄러 생성 ---> 실행 할 잡 추가 ---> 잡 실행

scheduler = BackgroundScheduler()
scheduler.add_job(함수, 트리거 유형, 트리거 값, 함수인자)
scheduler.start()

Scheduler 상태

• STATE_STOPPED(0)
• STATE_RUNNING(1)
• STATE_PAUSED(2)

Job 제거

Scheduler 덮어쓰는 문제

현재 호출되고 있는 API형태는 다음과 같습니다. API를 호출할 때마다 MatchChatCreateView라는 클래스의 인스턴스가 매번 생성되기 때문에 여러개의 채팅방에서 채팅이 올라오게 될 경우 해당 클래스로부터 새로 인스턴스를 만들게 됩니다. 예상 작동 로직의 경우 각각의 채팅방마다 하나의 스케줄러 인스턴스를 계속해서 사용해야 했습니다.

만약 이전에 스케줄러를 만든 것을 기억하지 못한다면 여러개의 채팅 방에서 채팅이 올라올 때마다 새로 인스턴스를 호출하는 결과를 낳게 됩니다.

따라서 해당 API가 호출될 때 채팅방마다 고유의 스케줄러 인스턴스를 매칭해주기 위해선 채팅방의 고유아이디를 생성자 변수로 스케줄러를 생성하여 아무리 많은 API가 호출되더라도 채팅방 별로 오직 하나의 스케줄러만 생성하게 조정해주어야 하는 작업이 필요했습니다.

이에 클래스 변수를 두고 key: value 형태로 저장하는 자료구조를 택하여 key: 채팅방 아이디로 value: scheduler_instance로 저장하여 후에 요청이 왔을 경우 빠르게 매칭을 통해 본래의 스케줄러를 찾아 갈 수 있도록 하여 해당 문제를 해결하였다.

참고 페이지

APScheduler docs
An elegant way to run periodic tasks in python
RLock
Python with statement