Spring - git fork를 이용한 mongodb 프로젝트(3 - 설계)

개요

우리는 지난 시간에 웹툰 추천 및 소개 서비스를 개발한다고 브레인스토밍을 하였고 결과는 다음과 같이 나왔다.

대략적인 서비스 기획안이지만 해당 프로젝트를 진행하는 과정에서 어떤 기능을 중심으로 무엇을 만들 것인지는 알 수 있다. 하지만 이것만으로는 무엇을 어떻게 개발해야 될지 대략적으로만 알 수 있을뿐 구체적인 내용은 알기가 어렵다. 띠라서 프로젝트 개발을 본격적으로 시작하기 전에 무엇을 어떻게 구현할 것인지 프로젝트 구조를 설계해 볼 예정이다.

프로젝트 개발 전 - 설계

설계를 하는 이유

우리는 지금부터 건축가다. 건물을 건축한다고 할때 가장 먼저 필요한 것은 설계도이다. 우리가 무엇을 어떻게 지을 것인지 설계도에 남긴다. 이 설계도는 이후에 인력(팀원)들이 보고 어떤 건물을 지을 것인지 이해하고 건축하는데 도움을 준다.

지금 우리(사실은 나?)는 교육사이트를 개발한다고 하였다. 하지만 이글을 읽는 사람들은 그래서 어떻게 만들건데? 라는 의문을 가지고 이 글을 읽게 될 것이다. 따라서 프로젝트를 시작할 때 가장 필요한 것은 설계도이다.

설계에 앞서 브레인스토밍한 내용을 목록화하면 내가 개발할 내용을 큰 영역과 작은 영역으로 보았을 경우 다음과 같다.

구현 기능 목록화

구현 기능

• 웹툰 검색
• 웹툰 추천
• 웹툰 소개

추천 같은 경우는 개인화를 진행하여 개인이 어떤 웹툰을 읽었는지 파악하고 이를 통해 좋아하는 장르, 분야를 파악하고 이 후 진행이 가능할 것 같기 때문에 ML을 통한 추천 시스템을 도입하거나 단순한 방법을 고려해봐야 될 것 같다. 예를 들면 개인이 가장 많이 본 장르 중 가장 인기있는 웹툰..? 을 추천 목록으로 보여준다던가.... 그래야 될 것 같다.

세부 기능 구현사항

추천

• ML(머신러닝)을 통한 개인 웹툰 추천 기능 도입
• 개인이 가장 많이본 웹툰 장르를 확인하여 해당 장르에서 보지 않은 인기웹툰 top 10 소개

소개

소개/검색과 같은 경우 소개는 어떤 방식의 검색을 통해 나온 결과물을 프론트로 보여줄 것인가이기 때문에 소개하려는 웹툰의 종류를 구체화하고 이를 검색 기능에 포함시키는 방향으로 진행해야 될 것 같다.

• 최신 업데이트 웹툰(신작 웹툰 리스트)
• 최근 조회수가 급등한 웹툰
• 비인기 웹툰(조회수가 적은 웹툰)
• 인기 웹툰(최다 조회수)

검색

웹툰 검색 기능을 구현하기 위해서는 어떤 기준으로 검색을 가능하게 만들 것인가가 가장 중요하다. 앞서 말한 소개기능 같은 경우에도 검색 기능을 토대로 프론트에서 웹툰을 단순히 보여주는 컨텐츠이기 때문에 검색 기능을 잘 만들어야 우리의 프로젝트가 좀 더 간결한 구조로 개발이 진행될 것 같다.

• 분류 (사이트, 웹툰명, 장르, 일자, 완결 여부, 무료 여부)
• 정렬 (업로드순, 인기순)

DB 설계

브레인스토밍을 한 내용을 구체적으로 목록화하고 기능을 세부적으로 확인하니 현재 우리가 백엔드로 구현할 부분은 검색 기능밖에 없었다! 프론트 개발이 필수적으로 필요할 것으로 보여 굉장히 현기증이 난다...

프론트에서 보여줄 내용이 있으면 이로인해 사전에 생각한 데이터 외에 추가적으로 필요할 경우 수정/추가가 필수적으로 발생한다. RDB일 경우 단순히 컬럼 추가만 하면 되는 상황일 경우에는 문제가 되지 않지만 데이터 수정 또는 관계 구조가 변경이 필요할 경우 DB가 변경되고 이로 인해 백엔드 로직이 변경되어야만 하는 대참사가 발생한다.

하지만 우리는? mongoDB를 사용하고 있기 때문에 좀 더 유연하게 생각하고 RDB 보다는 수정이 수월할 것으로 예상된다.

MongoDB

자 그럼 정리한 내용을 토대로 데이터베이스 설계를 해보겠다. 필자 또한 mongodb를 이용해 프로젝트를 처음하기 때문에 NoSQL스러운게 아닌 RDB스러운 설계를 할지도 모른다. (이럴거면 왜 mongoDB를 고수..?) 최대한 NoSQL스러운 설계를 해보도록 노력해보겠당!

가장 먼저 어떤 부분이 가장 중요할까?

어떤 정보를 담을까?

가장 먼저 어떤 정보를 담을지 선정하는 것이다. RDB에서는 대표적으로 ERD(Entity Relationship Diagram)라는 다이어그램을 그리면서 데이터 모델링을 수행해 DB 설계를 진행한다. 하지만 mongoDB는 관계형이 아니기 때문에 데이터 모델링간 고려해야 될 부분이 RDB와는 다르다 다음 사진을 보자.

mongodb는 일반적으로 두가지 구조로 Document를 설계하는데 방식은 다음과 같다.

• Embedded 방식 : 관계를 갖는 데이터 집합을 단일 도큐먼트에 포함하여 저장하는 방식
• Reference 방식 : 도큐먼트에 관계를 갖는 다른 도큐먼트의 식별자를 참조키로 저장하여 필요시 애플리케이션에서 조인하는 방식

대충 봤을 때 Embedded 방식은 반정규화 한 테이블이고 Reference 방식은 관계형 db와 비슷한 구조인 것 같다.

mongodb 데이터 모델링에는 표준이 없는 것 같다. 아무리 확인해도 mongoDB guide만 있을 뿐 표준이라고 보이는것이 별도로 없었다. 하지만, 실 서비스에서 어떻게 사용할 것인지 기능 위주로 고려해 설계하는 방식이 가장 효율적인 것 같아 다음과 같은 기준으로 설계를 진행하도록 방향을 잡았다.

mongoDB의 document에 대한 개념은 조금 알게 되었고.. 데이터 모델링 과정 중 고려해야 될 내용은 추가적으로 무엇이 있을까?

DB 부하 방지

데이터 모델링간 고려해야 될 사항은 DB 과부하이다. 서비스를 많은 사람들이 이용할수록 발생하는 문제는 많은 트래픽을 감당하지 못할 경우 서비스가 다운되거나 느려지는 것이다. 일반적으로 트래픽같은 경우 client -> server에서 많은 요청이 발생할 경우 장애가 발생한다고 생각하는데 많은 요청이 발생할 경우 서버에서 business logic을 처리하는 도중 server->db 간 처리 과정에서 slow query 혹은 connection timeout으로 인해 발생한다. (물론 아닐 경우도 많다..)

이러한 문제는 곧 서비스의 신뢰성을 낮추고 결국 사용자들은 떠나가는 결과를 초래한다.

따라서 DB에 최대한 부하가 오지 않는 구조로 설계하는 것이 가장 이상적인 구조라고 생각한다. 보통 DB 부하는 read/write에서 발생하는데 한 번 곰곰이 생각해보겠다.

write/update/delete 발생 조건

• 특정 유저가 웹툰을 볼 때
• 새로운 웹툰이 등록
• 기존 웹툰이 수정/완료 될 때
• 기존 웹툰이 무료 -> 유료로 전환
• 연재 중인 웹툰이 완결되었을 때
• 연재중인 웹툰 작가가 웹툰을 업로드 했을 때

read 발생 조건

• 웹툰 검색
• 특정 유저가 웹툰을 읽을 때

다음과 같을 경우 가장 부하가 많이 발생하는 부분은 특정 유저가 웹툰을 읽으려고 시도할 때 발생한다. 따라서 해당 부분을 고려해서 부하가 최대한 발생하지 않도록 데이터 모델링을 진행해야 될 것이다.

결정

따라서 다음과 같은 방법으로 설계를 하면 어떨까..? 라는 생각을 해봤다. 우선 네이버 웹툰에서는 서비스에서 어떻게 웹툰을 목록화하는지 참고하였다.

메인 페이지

가장 앞에서 신규웹툰을 선보이고 각 요일별로 어떤 웹툰이 업로드 되는지를 알 수 있다. 조회수 순으로 웹툰을 보여주며 인기가 급상승중인 웹툰(조회수가 급격히 오르는 웹툰)은 오른쪽 '인기급상승 웹툰' 컨텐츠로 선보이고 있다.

웹툰 상세 페이지

웹툰은 다음과 같이 각 회차를 목록화하여 컨텐츠를 보여주고 있다.

다음 화면들을 보고 결과적으로 어떻게 db를 모델링할지 생각해봤고 결과는 다음과 같다.

나의 전략

• 웹툰 메인 페이지는 embedded 방식으로 설계한다.
• 웹툰은 이미지 기반의 데이터이기 때문에 한 웹툰의 컨텐츠 크기가 크다. 웹툰별로 나누어서 관리한다.

구조는 계층을 나누어 트리구조로 작성해보겠다.

master(main page)

• 사이트(사이트 명)
  - 일자(월 화 수 목 금 토 일)
  • 웹툰
    • 웹툰 메인 사진
    • 웹툰명
    • 장르
    • 조회수
    • 최신 업데이트 날짜(업로드 순)
    • 유료 여부
    • 완결 여부

webtoon

• 웹툰
  • 제목
  • 설명
  • 이미지
  • 순서/번호(id)
    • 제목
    • 업로드 일자
    • 콘텐츠
      - 사진(웹툰 사진)

user (계획)

• 사용자
  • id
  • password
  • 닉네임
  • 좋아하는 웹툰(list)

결론

오늘은 웹툰 추천 및 소개 서비스의 DB 구조를 설계해 보았다. 프로젝트 개발 전 DB 설계 뿐만 아니라 전반적인 시스템의 아키텍쳐 또한 설계를 하는 것이 일반적이지만 우리는 가장 먼저 api를 구현하는 것이기 때문에 해당 부분은 진행하지 않을 것이다.

DB 구조를 설계할 때에도 여러 부분을 고려해야 한다. 가장 시간이 많이 걸리는 부분이 설계인 이유는 설계를 제대로 하지 않을경우 코드가 복잡해지고 유지보수가 어려워지는 문제가 발생한다. 이 점을 생각하며 설계를 진행하길 바란다.