삽으로 밥떠먹기

시각화 수업 기말 프로젝트로 Clickstream 을 분석 및 시각화하는 프로젝트를 진행하기로 했고, 그 번째 단계로 로그를 모으기 위한 시스템(?)을 요 몇 일 짜고 있다.

처음에는 로그 수집 및 분석 하면 소위 말하는 ELK (Elasticsearch + Logstash + Kibana) 스택을 사용한다고해서 이를 따르기로 했지만 따져보니 그대로 따르기에는 문제가 많았다. 시각화 수업인만큼 좀 독특한 시각화를 해야하니 Kibana 대신 직접 상황에 잘 맞는 시각화를 해야하고, 또 이런 클릭 데이터를 다루었던 논문들을 보니 클러스터링 정도는 기본으로 깔고 가는데 그 용도로는 Elasticsearch 역시 적합하지 않았다. 그래서 결국 Logstash 만 남아서

클릭을 수집하는 js 클라이언트 → Node 로 만든 Endpoint → Redis 채널 → Logstash → S3 의 txt (→ 크고 아름다운 분석툴?)

의 시스템을 만들기로 했고, 기왕 공부하는 김에 도커공부도 해서 싹 이어놓았는데(사실 공부를 위해서라기 보다는 시간을 아끼기 위해서. Logstash 를 그냥 어떻게 깔아야할지 감도 안잡힘), 다 해놓고보니 결정적인 문제가 있었다.

Logstash 가 로그를 처리하는 기본 단위는 128 개, 또 S3 에 올리는 파일 단위는 2MB 이고 만약 도중에 시스템이 꺼질 경우 아직 다음 단계로 넘어가지 않은, 아직 버퍼에 있는 데이터는 다 날라간다(AFAIK). 하지만 지금은 사람이 많이 쓰는 서비스에 바로 적용하는 것이 아니니 데이터가 적고 귀할 수 밖에 없어서 중간에 다 날라가는 것이 너무 치명적이다-0-. 결국 Endpoint 에서 Redis 로 갈 필요도 없이 그냥 몽고 DB 에 넣어 놓기로했고, 쌓인 데이터를 나중에 랩탑에 전부 다운 받아서 조작하더라도 아무런 문제가 없을 것 같다. 그래도 혹시(!) 나중에 데이터가 많아지면 어떻게 해야할지 약간이나마 감을 잡았다는 점에서 위안을 삼기로(물론 그 때는 그 때 나름의 어려움과 깨달음이 있겠지만)

p.s) 도커는 분명 훌륭한 툴인데, CI 하는 문화나 습관이 자리잡혀 있지 않으면 인스톨러 이상의 기능을 하기 힘들어 보인다. 근데 CI 를 잘하려면 테스트를 꼼꼼히 짜는 문화나 습관이 우선되야하고 이쯤되면 더이상 툴의 문제가 아니게 된다. 결국 진리의 잘놈잘(잘팀잘) ! p.s2) 흔히들 pure function 이 유지, 보수에 적합하다고 하는데 컨테이너에 올라가는 코드도 마찬가지인 것 같다. 아주 간단한 예로 세션이 컨테이너의 메모리에 저장되면 나중에 롤링 업데이트를 하더라도 누군가는 중간에 접속이 끊길텐데, 세션 컨테이너를 외부에 두면 이런 일을 막을 수 있다(express-session 의 경우 기본 스토리지 사용을 공식적으로 비추한다)