들어가며
방문자 수 저장 및 조회 기능을 구현을 완료했습니다. 이번 편에서는 이를 기술적으로 구현하기 위한 과정과 구현 내용을 기술할 것입니다!
<br>
1. DB 스키마
총 세 개의 테이블을 사용했습니다.
access_log
이 테이블은 사용자의 접근 기록을 저장하는 테이블입니다.
- visitor_id : 방문자를 식별하는 uuid 입니다.
- visitor_hash : 방문자의 ip와 ua를 단방향 암호화 한 것입니다.
- referer : 어느 경로에서 블로그로 접속했는지 확인하는 속성입니다.
- os_type : 사용자가 접속한 os명 입니다.
- browser_type : 사용자가 사용한 브라우저 명입니다.
- page_url : 블로그의 어떤 페이지에 접근했는지 경로를 담는 속성입니다.
daily_visitor_key
이 테이블은 해당 일에 어떤 visitor_id가 접속했는지 확인하고 해당 일에 새롭게 방문한 방문자라면 저장하는 테이블입니다. 이 테이블은 추후 redis로 변경할 수 있습니다.
- visit_date : 방문자가 접속한 날짜입니다.
- visitor_id : 방문자의 토큰입니다.
daily_visit
이 테이블은 해당 일에 몇 명의 방문자가 방문했는지 카운트하는 메서드입니다. 속성이 간단하므로 설명은 생략하도록 하겠습니다.
<br>
2. 스키마를 왜 이렇게 설계했어?
사실 방문자 기능은 access_log 테이블 하나로 충분히 만들 수 있습니다. 하지만, 이 테이블은 하루에도 적게는 수십, 많게는 수만개까지 데이터가 쌓일 수 있습니다. 따라서 방문자 조회 성능을 고려하여 접근 기록만 저장하는 access_log, 하루에 방문하는 방문자의 중복 여부를 확인하는 daily_visitor_key, daily_visitor_key를 기반으로 방문자 수를 집계하는 daily_visitor 테이블로 나누었습니다.
특히 위에서 언급한 바와 같이 daily_visitor_key는 해당 방문자가 해당일에 방문을 했는지(중복 방문 카운트 제거 목적)를 확인하기 위해 존재하는 테이블입니다. 따라서 인메모리 db로 교체하여 성능을 측정해볼 계획입니다.
<br>
3. 새롭게 생각해보게 된 주제
개인정보를 절대 함부로 수집하지마
이번 기능을 만들면서 개인정보의 수집 범위에 대해 알게되었습니다. 단순하게 ip를 수집하게되면 사용자의 개인정보를 저장하게 되니, 자칫 잘못하면 접속자의 패턴을 분석하는것이 아니라 사용자를 식별하게 됩니다. 따라서 이런 문제를 제거하기 위해, 사용자의 정보를 의도적으로 변조 혹은 유실시켜 의도적으로 사용자를 특정 짓지 못하도록 했습니다. 이에 관해 k-익명성, l-다양성, t-근접성 방법론들이 있지만, 이는 추후에 학습해보도록 하겠습니다.
테이블도 역할을 나눌 수 있다
저는 지금까지 테이블은 도메인 단위로 나누었습니다. 그리고 다대다인 경우에만 중간에 테이블을 나누기만 했는데, 이번 기능을 만들면서 하나의 정보를 담더라도 테이블도 성능을 고려하여 역할별로 테이블을 나누는 방법도 고려할 수 있게 되었습니다.