플랫폼에서 일어나는 모든 움직임 기록
‘로그’는 고객 신뢰와 긴밀하게 맞닿아
서비스에 갑자기 오류가 발생했을 때, 작업 데이터가 기록돼 있지 않으면 원인을 찾아 해결하는 데 어려움이 생긴다. 오류 발생 전, 사용자가 어떤 요청을 했는지도 알 수 없어 시스템 운영의 가시성도 떨어진다. 시스템의 동작 정보와 이벤트, 에러 등을 나타내는 데이터 ‘로그(Log)’가 중요한 이유다. 특히 데일리펀딩이 몸 담은 금융권에서 로깅(Logging) 작업은 서비스 신뢰와도 연관된다. 고객이 대출을 신청하고 실행까지 완료됐는데 그 데이터가 남아 있지 않다면 사실관계를 파악할 수 없으니 말이다.
데일리펀딩 IT실 인턴십 과제로 ‘로깅 레이어 프로젝트’를 하게 된 이유다. 로깅 레이어 작업은 사용자가 요청하고 서버가 응답하는 과정 사이사이에 발생하는 정보를 기록하는 것으로, 체계적이고 구조화된 형식을 구성하는 것이 특징이다. 레이어 작업을 해 두면 향후 서비스가 거대해졌을 때도 정보를 즉각 찾을 수 있다.
물론 로그는 이슈 상황에서만 필요한 게 아니다. 로그는 고객이 서비스를 이용하면서 남긴 발자국인 만큼 고객이 어떤 니즈가 있는지, 어떤 동선으로 움직이는지 파악하는 데 도움이 된다. 고객의 행동을 객관적인 기록으로 확인해 서비스를 먼저 개선하는 것. 이는 데일리펀딩이 그려 가는 미래 모습과 맞닿은 이야기라 인턴십 과제가 더욱 의미 깊다.
요청-응답 모두 기록하는 drf-api-logger
임시 데이터베이스 Redis 활용해 효율성 더해
로깅 레이어 작업의 첫 단계는 로그 라이브러리를 조사하는 것이었다. 로그 라이브러리 각각의 장단점은 물론, 데이터 관리 효율성과 데이터 저장 시점 등을 두루 고려해 총 2개의 라이브러리를 후보군으로 간추렸다. 그중에서 최종 선택된 것은 drf-api-logger 라이브러리로, 미들웨어 기반으로 동작해 요청과 응답 정보를 가로채 로깅할 수 있다는 게 구조적 장점이다. 다만 기본 동작은 응답 시점에 로그를 저장하는 방식이라 요청 단계에서 로그를 선 저장한 뒤 응답 단계에서 업데이트하는 방식으로 구조를 개선, 요구사항을 충족했다.
본격적으로 로깅 레이어 작업을 시작했을 때 가장 먼저 고려한 것은 서버 과부하 방지였다. 사용자의 요청이 들어왔을 때 정보를 추출해서 바로 데이터베이스에 저장하면, 그리고 그게 누적되면 서버는 굉장히 큰 부하를 받게 된다. 그래서 임시 데이터베이스 Redis를 활용하기로 결정했다. 이 Redis는 가볍고 접근이 빠르며 읽고 쓰기에 특화돼 성능 저하가 발생하지 않기 때문이다. Redis에는 사용자의 요청 내용과 정보가 비동기적으로 우선 저장되며, 용량이 초과됐거나 일정 시간이 지났을 경우 데이터베이스에 저장하도록 해 서버 운영의 효율성을 높였다.
