1. Intro
회사에 들어와 간단한 OJT를 마치고 바로, UMS(Unified Messaging System) 서비스 업무를 맡게 되었습니다. 사내의 UMS는 설계와 개발까지 1분기도 되지 않은 짧은 시간에 개발되어 유지보수 및 개선사항이 많다고 전달받았습니다. 프로젝트 Repository를 살펴보니 개발되어 있던 UMS 서비스는 아직 개발적으로 개선되어야 할 사항과 더불어, 연관 부서를 위한 이용 가이드 등이 부족하였고, 그 밖의 여러 개선 사항이 눈에 띄어 유지보수를 진행했습니다.
As-Is
UMS를 이용하여 App Push, KAKAO, Email 과 같은 메시지를 발송하고 로그를 확인하는 과정에서 문제 없이 잘 동작하였습니다. 그러나 대용량 메시지를 발송하거나 시스템 메시지 추가 및 운영 등, 시스템에 대한 여러 개선사항들이 눈에 띄었습니다. 문제점을 개선하기에 앞서, 이 문서에서는 발송된 메시지 확인 및 재가공 이슈에 대한 개선을 통해 여러 복합적인 이슈를 처리해보고자 했던 내용을 다루고자 합니다.
2. UMS
사내에서는 UMS를 활용하는 여러 Internal Service와 팀이 있습니다. 마케팅팀에서 고객 대상으로 이벤트 메시지를 발송하거나, 시스템 배치를 이용하여 정기 및 일괄 메시지 발송을 보내기도 합니다. 또한 실시간 서비스를 위해 Core G/W 등에서 여러 형태의 메시지를 Signal로 발송하고 발송예약을 할 수 있습니다.
메시지의 내용은 protocol, contract, user, title, message, status, error 등 고객에게 전달하고자 하는 내용과 함께 전송 상태 등의 여러 정보를 저장합니다. 메시지를 발송하게 되면 각 protocol별, 메시지 별로 메시지 상태를 확인할 수 있으며, 만약 실패했을 경우를 고려하여 에러 내용 또한 저장하게 됩니다. 발생할 수 있는 이슈의 예시는 다음과 같습니다.
UMS Issues
메시지 발송 시 protocol 및 vendor 별로 다양한 이슈가 발생할 수 있습니다.
•
연결된 서비스 vendor 이슈 ( 벤더사 서비스 에러 이슈 )
•
KAKAO 메시지 발송 실패 이슈 ( 발송 불가, 친구 미등록 등 )
•
App Push 메시지 발송 실패 이슈 ( Device Token 만료 등 )
•
대량 메시지 발송 실패 이슈 (Queue 등록 후 timeout 시 task 미할당 이슈)
UMS에서는 메시지 발송 및 발송 상태를 관리하면서, 다양한 이슈를 확인할 수 있었습니다. 이러한 이슈 해결을 위한 개발 요구사항 및 기타 필요한 조치가 어떤 것이 있는지 확인해보고자 하였습니다. 또한 서비스 품질 향상을 위한 이슈 및 개발 요구사항을 수집하기 위해 에러 내용을 수집이 가능하도록 개선하보고자 하였습니다.
3. Issues
Get messages
UMS를 운영 및 유지보수 하며, 가장 먼저 필요해보였던 내용은 메시지 발송 여부 확인을 위한 기능이었습니다. 메시지를 생성하고 메시지 발송 상태를 저장하게 되는데, 기존 메시지를 조회하는 API의 경우 created_at 기준으로 순차적으로 조회하는 기능이 전부였습니다. 한 달 평균 약 300만 개의 메시지가 누적되는 시스템에서 순차적으로 조회하는 것은 비효율적이라고 판단하여 개선 요구사항에 포함하였습니다.
Parse messages
조회된 메시지의 내용이 확인할 수 있다고 하여도, 메시지 재발송, 발송 대상자 확인, 메시지 발송 성공 및 실패 여부 검색, 실패 원인 식별 등의 이슈를 효율적으로 관리 및 확인하는 기능이 필요하였습니다. 이러한 기능적 요구사항은 UMS 자체의 기능으로 개선하는 방법도 있지만, 별도의 요청을 날리는 자동화 스크립트를 개발하는 방향으로 잡았습니다. 이에 대한 자세한 이유는 4. 개선 방향에서 추가로 설명하도록 하겠습니다.
Test messages
새로운 메시지 내용이 추가되거나, 템플릿 등을 추가하여 테스트를 수행하고자 할 때 테스트 코드가 없어 업무 시간을 불필요하게 소모하는 이슈가 있었습니다. 이러한 이슈를 해결하기 위해서는 자동화된 테스트 코드가 필요합니다. 또한 운영계, 개발계 및 기타 로컬에서 테스트를 하기 위해 자동화 스크립트를 개발하고 관리하는 방법이 보다 효율적이라 판단하였습니다.
4. Solves
Get messages
메시지 조회 API에서 조회하고자 하는 메시지의 필터링을 적용하였습니다. 순차적으로 조회하는 API의 적절한 필터링을 통해 원하는 메시지만 조회할 수 있도록 하기 위해 다음과 같은 필터를 추가하였습니다.
•
생성일
•
메시지 프로토콜
•
발송 상태
•
메시지 정보
•
에러 상태
Parse messages
메시지 발송 실패 케이스 확인 및 에러 내용 스크립트를 작성하였고, 이와 더불어 추가로 메시지 발송용 파라미터를 생성하는 스크립트를 작성하였습니다.
•
메시지 발송용 파라미터 생성
◦
유저, 프로토콜, 메시지 정보를 이용한 발송 요청 payload 생성
◦
데이터 생성 시 재사용 가능한 함수, 클래스 생성
•
메시지 발송 실패 케이스 확인 및 에러 내용 수집
◦
데이터 확인 시 재사용 가능한 함수, 클래스 생성
Test messages
메시지 발송용 파라미터를 생성하는 스크립트를 이용하여 원하는 대상(발송 대상)을 골라 자동으로 발송 요청을 날릴 수 있는 스크립트를 작성하였습니다. 로컬, 개발계, 운영계를 구분하여 테스트가 가능하도록 개발하였습니다.
5. On-boarding
위와 같은 이슈를 해결함과 동시에 추가로 개선하고자 했던 이슈는 바로 온보딩(On-boarding)이었습니다. 업무상 개발 및 이슈 처리가 많아, 팀에 새롭게 합류한 동료를 위한 서비스 설명 및 개발 프로세스에 대한 가이드가 부족하였습니다. 여러 시스템의 이해가 필요하지만, 특히 내부에서 Backend 개발자분들이 기본적으로 다루는 Batch 시스템에 대한 이해를 돕고자 위의 여러 이슈를 해결함과 동시에 Batch에 쓰이는 스크립트와 비슷하게 개발하여 가이드가 가능하도록 하였습니다.
Jenkins & Batch
Jenkins의 Execute shell 기능을 이용하여 리눅스 Shell을 실행하듯 서비스 배치를 구동하게 됩니다. 특정 repository 내에 batch용 스크립트를 관리하고 이를 docker로 구동하여 스크립트 실행 및 로깅을 수행합니다.
REPOSITORY=registry.example.com/some-repository
TAG=dev
docker run -i --rm \
$REPOSITORY:$TAG \
python3 /scripts/some/directory/script.py \
--argument-one ARG1 \
--argument-two ARG2 \
-v DEBUG
Bash
복사
Scripts
온보딩을 수행하기 위해서는 기존 jenkins의 batch용 repository의 코드 구성을 이해할 수 있도록 개발하는 것이 좋을 것이라 판단하였습니다. 때문에 효율적인 코드 개발을 위해 common, exceptions 및 서비스별 direcotory를 구분하여 어떻게 통신하는지 고려하여, 이번 이슈 처리를 위한 repository를 개발 및 배포하였습니다.
tester/
──────────────────────────────────
└── common/
└── __init__.py
└── utils.py
└── exceptions/
└── __init__.py
└── service_exceptions.py
└── system_exceptions.py
└── managers/
└── fep_manager.py
└── ums_manager.py
──────────────────────────────────
└── scripts/
└── fep/
└── cache_updater.py
└── ums/
└── renewal_contracts.py
└── expired_contracts.py
.
.
.
Bash
복사
6. Conclusion
운영 이슈 해결과 더불어 서비스 개선을 위한 개발 요구사항 수집을 위해 UMS의 발송 메시지 조회 API에 필터링을 추가하여 원하는 메시지를 조회할 수 있도록 수정하였습니다. 개선된 메시지 조회 API를 통해 운영 이슈 처리시간을 효율적으로 개선하고자 자동화 스크립트를 개발하였고, 또한 테스트 수행 시간을 효과적으로 감소할 수 있도록 스크립트를 추가로 개발하였습니다. 이러한 코드를 개발함에 있어서 신규 개발자 합류 시 간단한 온보딩을 위한 시스템 가이드 및 코드 가이드를 고려하여 자동화 스크립트를 배포하고자 하였습니다.
위와 같은 개선 사항을 통해 다음과 같은 효과를 보았습니다.
1.
서비스 개선을 위한 개발 요구사항 수집
2.
운영 이슈 처리 및 이슈 처리 시간을 효과적으로 감소
3.
테스트 수행 시간을 효과적으로 감소
4.
새로 합류한 Backend 개발자가 기본적으로 다루게 될 배치 시스템에 대한 이해와 코드 개발 가이드 효과
7. Review
시스템을 운용하면서 불필요한 업무 시간이 소요되고, 여러 운영 및 시스템 이슈를 경험하며 업무 과정에서 발생하는 다양한 문제를 해결하고자 하였습니다. 개발자는 어떠한 사회 혹은 고객의 니즈를 파악하고, 문제를 해결하는 것을 목표로 한다는 걸 잘 알고 있었습니다만, 이번 사이드 프로젝트를 통해 그러한 문제 해결 이라는 목표와 일부 일치하면서도 조금은 다른 색다른 경험이었습니다. 개발로 문제를 해결함에 있어서 회사의 서비스 및 솔루션 뿐만 아니라 함께 업무를 보는 팀과 및 타 부서의 업무 효율을 위한 문제 해결 또한 다른 관점의 고객이며 니즈가 될 수 있다는 점입니다.
이번 사이드 프로젝트를 통해 개발자 문화에서 익히 코드로 말하는 개발자 라는 것이 어떤 것인지 조금이나마 체험할 수 있었습니다. 또한 함께 이슈를 처리하는 팀원과 여러 업무를 보는 타 부서의 동료들 역시 또 다른 니즈를 가진 고객일 수 있다는 것을 느꼈습니다.