Callbackers.com 개발 기록

2023. 10. 3.

개발 동기

명절에 아무런 목표 없이 흘러가기엔 너무나도 긴 연휴이다.

추석 연휴가 시작하기 직전에 갑자기 아이디어가 떠 올랐다.

사건 케이스

회사에서 제공된 카드는 일정한 그룹에서 공용으로 사용한다.

카드 내역 확인 및 잔고 확인을 위해 notion에서 table을 이용하여 관리하고 있었다.

하지만, 사용한 사람이 직접 추가하거나, 카드 내역을 볼 수 있는 내가 관리하는 방식이었다.

이 방식은, 누락이 자주 발생하여 누가 카드를 사용했는지 알수 없는 상황이 많이 발생했다. (영수증 첨부 필요 없음.)

이 문제가 계속 발생하여, 나는 해결 방법을 찾았다.

300원짜리 카드 사용 내역 문자 서비스를 가입하여, 문자가 오면, Slack으로 Webhook을 보낼 것이다.

이 간단한 케이스는 아이폰 단축어 - 자동화 부분을 이용하여 제작이 가능하다.

이러한 시스템을 중앙에서 집중 관리하여 처리하는게 어떨까 라는 생각이 들었다.

예시) 해당 문자는 각 그룹에 맞게 알림도 가지만, 전체 시스템 관리자에게도 같이 전송돼야한다. 등등

즉 클라이언트 레벨에서 callback을 고치는 것이 아니라, 중간 시스템을 UI를 통해서 output을 수정할 수 있는 시스템을 만들려고 한다.

우리의 서비스를 사용하고 작업이 완료되면, 사용자가 지정한 URL로 callback을 주는 시스템이 있다.

한 고객사가 callback이 오지 않는다고 문의가 왔다.

“callback을 전송” 까지의 로깅을 하는 입장에서 전송은 완료 된 것으로 파악 했지만, 상대 서버가 어떤 상태였는지는 확인하지 않는다. (callback 실패가 작업 실패로 처리되는 것을 원치 않는다.)

이러한 상황에서 해당 URL로 예시 Body를 이용하여 전송을 했을 때, 고객사의 PHP 웹 서버에서 에러가 발생하여 다음으로 넘어가지 않는 것을 확인하여 상황을 전달해드렸다.

이러한 부분은 놓치기 쉽고, 서로가 관리를 하지 않는 것이 대부분일 것으로 추측된디. (callback은 단순히 fire & forget)

중간 관리 시스템에서 Callback에 대한 로그를 남겨주고, URL 변경 output 변경 등을 중앙 시스템에서 하는 것이 어떨까?

한번은 더이상 지원되지 않는 Rule 에 의해 Slack 알람이 계속해서 발생하는 이슈가 있었다.

관리하는 시스템이 많고, 다른 자원으로 활용되는 경우도 있어 실제 어떤 서버에서 해당 알림을 요청했는지 찾기가 어려웠다.

이 이후로, Webhook 메시지에 발신자에 대한 정보도 넣는 것으로 Rule을 정했지만, 이미 적용된 시스템에서는 아직도 빠져있다.

컴파일 레벨의 관리체계까 아니기 떄문에, 해당 부분은 늘 누락이 있을 수 있다.

callback을 요청하는 중앙 시스템에서 요청자에 대해서 로깅 및 필터링, 더 나아가 해당 기준으로 분류가 되는 기능이 있으면 좋을까?

callbackers.com 이라는 도메인을 구매했다.

해당 시스템은 AWS 자격증을 딸 생각이 있기 때문에 AWS 시스템을 적극 활용해볼려고 Route53으로 구매를 완료했다.

현재 간단한 데모 구상은 다음과 같다.

Edge -> RabbitMQ -> Worker

Edge 의 수는 서비스의 규모에 따라 확장 가능하게 Lambda를 활용하면 어떨까 싶다.

RabbitMQ는 서비스가 커지면 Kafka로 갈 예정이다.

Edge는 단순히 DB에 접속 기록을 Insert 하는 bot이다.

DB와의 종속성을 없애기 위해, 모든 요청에 대해서 기록한다.

*.callbackers.com 으로 통한다. (e.g. mingkyme.callbackers.com)

Worker는 Edge에서 보낸 Queue 를 Consuming 하여 해당 DB row를 조회하여 기존에 정해진 Rule과 일치하는 것을 찾아, Rule에 맞게 동작한다.

현재는 패스스루, slack 만 연동하여 데모를 진행 중이다.