nextrend 개발일지 (1)

최대 1 분 소요

nextrend(이하 nxt) 유지 보수를 한지 거의 2년이 다되어가는 시점에 이런 글을 쓰는게 참 아이러니하지만, 이렇게라도 남기지 않으면 했던 작업들이 희미해져갈 것만 같아서 일지를 써보려고 한다.
게을러 지는 걸 좀 막고 싶은 것도 있고
아무튼, 오늘 작업은 screening, edit, curation 부분의 로그를 남기기 위한 백엔드 모듈을 작성하는 것.

사실, mysql로 log DB를 통으로 쓰는 것이 조금 마음에 걸렸지만 찾아보니 일반적으로 general_log를 사용하여 모든 query를 저장하여 사용하는 다른 경우들보다는 부하가 적을 듯 싶어서 그냥 사용하기로 하였다. (nxt의 경우 한정된 사용자를 위한 서비스이기에, 사용자의 모든 로그를 저장하여 서비스 개선을 위한 목적이 아님. 문서 작업자의 작업량 로깅을 위한 전용 로깅..)

원래는 얄팍하게라도 알고 있던 ELK를 한번 적용해볼까도 싶었으나, ELK를 운용하는 것이 클라우드 서버에서 꽤 비용이 든다는 것과(현재 우리는 낮은 등급의 서버를 운용중) 적용했을 때 그 활용이 넓지 않아서 포기하기로 하였다.

아무튼, mysql의 table을 생성하는 것부터 고민을 시작했다. 모든 로그가 범용적으로 생성된 한 테이블에서 운용하느냐,, 여러개의 테이블을 함께 사용하느냐 하는 기본적인 문제였다. 여태껏의 서비스에서 범용적으로 운용하던 테이블은 모두 새로운 요구사항에 의해 엎어졌었으므로, 그냥 여러개의 테이블을 사용하기로 하였다.

원래 기술 블로그에는… 기술적인 이슈와 그에 대한 해결이 주가 되었으면 좋겠지만 아무래도 일반적인 구현은 그런 내용은 없고, 선택과 구현의 사유를 구구절절 말하는 것 밖에는 말할게 없나보다.

카테고리:

업데이트: