이용자분들에게 감사할 따름이다. 모두가 알리미를 차단하게 되는 날을 기원하며 업데이트 로그를 올린다.
업데이트 목적
1. 사용자 & 관리자 편의 기능 추가
마감 이전 알림 기능이나, 사용자 맞춤 필터를 추가하면 좀 더 사용자들에게 유용한 프로그램이 되지 않을까? 또, 개인화된 기능이 필요해보였다. 지금은 인기있는 공고를 모두 보내주고 있는데, 내가 개발직군이면서 기획직의 공고를 받을 필요는 없다. 따라서 개인의 기호에 따라 조금 더 최적화된 공고를 보내줄 필요가 있다.
또, 관리자가 gcp로 들어가지 않고도 관리자 기능을 활용할 수 있으면 좋을 것이라 판단했다.
그리고... 내가 이 프로그램을 더 잘 활용해야 할 이유가 생겼다. 업데이트하기 딱 좋은 시점이었다
2. 메시징 api 속도 개선
이전에 텔레그램 봇 최적화와 관련해서 쓴 글에서의 속도의 상한을 구하긴 했지만, 메시지의 수가 많다보니 런타임이 길어지는 것을 막을 수는 없었다. 다른 플랫폼을 이용하거나, 메시지를 보내는 방식을 변경해서 속도를 개선해야 했다.
3. 서버 성능 개선
검색기능도 추가하고 기능들을 추가하기 위해서 근본적인 서버의 성능을 개선해야 한다. 아키텍쳐를 개선하면 만족스러운 서버가 될 것같다. 현재처럼 잠깐 떴다 내려가는 서버보다는 이용료를 조금 더 내더라도 늘 떠있는 서버로 발전할 필요가 있다. JVM, GC, 비동기IO등 적극적으로 최적화해보고 싶은 것이 너무나도 많다. 근본적으로 서버이용료가 별 차이가 없었다. 데이터베이스 또한 orm을 활용해서 기본적인 쿼리를 자동화하여 생산성을 높일 수 있을 것이라 생각했다.
4. 레거시 개선
6달 전에 짠 코드를 보니 싹 갈아엎고 싶어졌다. 역할책임이 제대로 분배가 되어있지 않을 뿐더러, 구조 자체가 너무 절차지향적이었다. 그때는 나름 만족했던 코드였던 것 같지만 지금 내가 리뷰어였다면 대대적인 리팩토링을 요구했을 것이다
업데이트 내용 (서비스 관점)
1. 공고 화이트리스팅(완료)
특정 단어를 포함하는 공고만 받을 수 있다
/whitelist add 개발 - 개발이라는 단어를 포함하는 공고만 받기
/whitelist remove 개발 - 화이트리스트에서 개발이라는 단어 빼기
2. 공고 블랙리스팅(완료)
특정 단어를 포함하는 공고를 받지 않을 수 있다
/blacklist add 개발 - 개발이라는 단어를 포함하는 공고는 받지 않는다
/blacklist remove 개발 - 블랙리스트에서 개발이라는 단어 빼기
3. 마감 이전 알림(개발중)
특정 공고가 마감되기 일 전에 알림을 받을 수 있다
/alarm add 문구 - 문구라는 단어를 포함하는 공고를 알람으로 등록
/alarm remove 문구 - 문구라는 단어를 포함하는 공고를 알람에서 제거
4. 공고 검색(완료)
입력한 단어로 마감되지 않은 공고들을 검색하게 해준다
/search 컴퓨터 - 컴퓨터라는 단어를 포함하는 공고 검색
업데이트 내용 (개발자 측면)
1. 서버 구조 개선(완료)
Look aside cache구조를 이용해서 데이터베이스 접근을 줄였다. 캐시 알고리즘은 LRU를 활용했으며 데이터가 일정 크기 이상 커졌을 때는 레디스를 이용해서 최적화할 예정이다. 그 전까지는 지금의 구조가 네트워크를 타지 않기 때문에 더 나은 성능을 보장한다.
2. 언어 변경 & orm 도입(완료)
객체지향을 좀 더 잘 활용해보기 위해 자바로 이전했다. 파이썬도 좋지만 아직 배울 것이 많은 초보의 입장에서 레퍼런스가 비교적 더 많고 조금 더 흥미가 있는 자바를 선택하기로 했다. 장고의 orm도 좋지만, jpa와 jpql의 맛을 본이상 조금 더 깊게 경험해볼 필요가 있다.
3. 관리자에 특화된 서비스도입(완료)
공지를 이제 텔레그램 상에서 바로 보낼 수 있다. gcp 인스턴스에 로그인하는 것도 그닥 귀찮지는 않았지만 이제 더욱 편하게 공지를 할 수 있다.
사용자 증감여부도 텔레그램 상에서 바로 볼 수 있다. 이제 gcp 인스턴스에 로그인해서 사용자가 얼마나 되는지 보지 않아도 된다.
4. 관리자용 봇 추가(완료)
봇이 속도가 너무 빨라서 제제를 당했거나 원인모를 에러에 의해 동작을 멈추었을 때를 대비하여 관리자용 봇을 만들었다. 봇이 timeout을 당했을 경우에는 해당 봇을 통해서 에러현황을 알려줄 수 없기 때문이다. 이렇게 함으로 관리자와 일반 사용자의 권한 분리 또한 자연스럽게 할 수 있게 됐다.
5. 실시간 메시지 처리(완료)
실시간으로 메시지를 받아서 처리해줄 수 있는 기능을 추가했다. 이 기능을 추가함으로서 채용정보 알리미는 배치성 서버가 아닌 진짜 서버의 기능을 할 수 있게 됐다.
업데이트를 통해 배운 점
1. 텔레그램 라이브러리가 랜덤확률로 NPE가 뜬다.(이슈, 완료)
깃헙 이슈로 남겼고 조금은 개발이 늦어지게 됐지만 확실하게 하고 넘어갈 필요가 있다. 레포의 컨트리뷰터가 된다면 더 좋을 것 같다.
메시징파트에서 에러 코드가 아니라 null을 리턴하는 케이스가 있어서 디펜던시의 일부를 직접구현하여 해결하기로 하였다.
2. 아직 NoSQL을 캐시 이외에는 적용하지 않아도 된다(완료)
전문검색 기능을 활용하기 위해 공고를 NoSQL로 이전하려 했으나, 퍼포먼스 논문을 읽어보니 MySQL도 나쁘지 않다는 생각이 들었다(관련 논문).
3. 메시지를 버퍼쓰듯이 모아서 성능을 향상시킬 수 있다(완료)
근본적인 속도에는 한계가 있기 때문에 공고를 낱개의 메시지로 보내기보다는 여러개를 모아서 보내기로 했다. 그런데...! 4096 character가 넘어가면 보내지지 않는다고 한다. 100개의 채용정보를 1줄로 보내면 메시지가 날아가지 않고, 100개의 공고를 다 모아서 보내면 읽기에도 좋지 않다. 일정한 주기로 끊어야 하고, 고민 끝에 50개 단위로 끊기로 했다. 많다는 느낌이 있지만 어차피 필터링을 적용하기 때문에 일반적인 사용자들은 50개보다는 훨씬 적은 양의 메시지를 받게 될 것이다.
4. 메시지 속도 테스트/부하 테스트는 낮은 속도부터 시작하는 것이 좋다(완료)
메시지 테스트를 다 끝내고 면접을 준비해야 하는데 30분이 넘는 정지를 연속으로 먹었다. 속도를 제대로 측정해야 하는데, 무턱대고 높은 속도부터 시작하기보다는 낮은 속도부터 하는 것이 더 좋을 것같다. 실시간 데이터스트림을 다루는 논문에서도 부하테스트는 낮은 속도부터 하는 것이 좋다고 언급하고 있다
이후 업데이트 예정인 기능
마이너 업데이트 내용이 될 기능들이다
사용자 관점
- 기업 평점 기반 필터(5월 개발예정)
- 검색어 보정(5월 개발예정)
- 사용자들의 메시지에 단계를 나누어서 로그(일정 트래픽 도달시 업데이트)
개발자 관점
- 엘라스틱 서치로 검색 캐싱(일정 트래픽 도달시 업데이트)
- 모니터링 로직/툴 추가(일정 트래픽 도달시 업데이트)
