04. DATABASE 설계 & AWS RDS 설정
💡 학습 목표
1️⃣ Database 설계 방법 이해
이번 챕터에서는 백엔드 서버의 핵심인 데이터베이스 설계 방식을 이해해고 직접 설계해 보는 실습을 진행해 보려고 한다!
Database 설계
서버 개발을 하다 보면 ERD라는 용어를 되게 자주 접하게 되는데, 데이터베이스의 설계 결과물을 바로 ERD 라고 부른다!
ERD 설계는 보통 개발 프로세스에서 기획과 디자인이 어느 정도 나오고, 서버 개발자들이 모여 데이터베이스의 큰 틀을 정해두며 시작하는 것 같다.
ERD는 실제 기능 구현을 할 때 굉장히 자주 수정되지만, 무엇보다 중요한 것은 모든 서버 개발자들이 동일한 DB 구조를 인지하고 있는 것이다! 🌟
요구사항
실습으로 도서 관리 앱 에 대한 요구사항을 바탕으로 DB를 설계해 보려고 한다.
👥 사용자 관련 요구사항
- 카카오 소셜 로그인을 구현할 예정
- 회원 탈퇴 기능이 필요함
- 이름, 닉네임, 전화번호, 성별이 필요함
📚 책 관련 요구사항
- 사용자가 책 여러 권을 대여할 수 있음
- 책은 하나의 카테고리가 있음
- 책은 제목, 설명에 대한 정보가 필요함
- 책 소개 페이지에 해시태그가 붙을 수 있고, 책 한 권에 해시태그 여러 개가, 해시태그 하나가 여러 책에 붙을 수 있음
- 사용자가 책 설명 페이지에서 책에 좋아요를 누를 수 있음
- 책 카테고리별로 현재 몇 개의 책이 있는지 집계가 필요함
🔔 알림 관련 요구사항
- 공지 관련 알림, 책 반납 시간 임박 알림, 마케팅 알림이 있을 수 있음
ERD
우선 위의 요구사항을 기반으로 설계한 데이터베이스는 아래와 같다!
각 엔티티를 설계하고 연관관계를 설정하는 과정을 정리해 보려고 한다.
엔티티 설계 규칙
- 테이블명과 column 명은 모두 소문자
- 단어 구분은 언더바를 이용 (ex.
book_category) - 기본키(PK)로 index를 따로 두는 것이 편함 (
book_id,member_id보다는id사용) - 기본키(PK) type은 bigint가 좋음 (서비스 확장 고려)
created_at,updated_at을 테이블마다 추가해 주는 것이 좋음
이를 고려해서 엔티티는 다음과 같이 설계할 수 있다.
엔티티 type 설정
타입은 PM에게 물어봐야 확실히 결정 가능하지만, 보통 길이가 짧은 문자는 varchar() 를 사용하고, 길이가 길다면 text 를 사용한다.
예를 들어, varchar(20) 은 한글 최대 20글자라고 생각할 수 있다.
member 테이블에서 gender 의 경우에는 여성/남성 중 하나이므로 boolean 값을 사용해도 되고, varchar 로 설정해서 문자로 사용해도 된다!
그리고 created_at 과 update_at 의 타입은 datetime(6) 으로 설정하여 밀리초 소수점 6자리까지 구분하는 것이 좋다.
밀리초까지 구분하는 이유는 최신순 정렬을 더 정밀하게 하기 위해서인데, 초 단위까지만 저장하면 같은 초인 경우에는 정렬이 잘 되지 않을 것이다.
(💡 MySQL에서는 6자리가 최대이다.)member table 설계에서 고려할 것
member 테이블에서는 status 와 inactive_date 를 추가하는 것이 좋다.
회원 탈퇴 및 게시글 삭제와 같은 기능을 구현할 때, HTTP Method 중 DELETE 를 사용하여 바로 삭제할 수 있지만, Hard Delete 방법은 지양해야 한다.
요구사항에 따라 다를 수 있지만, 보통 사용자와 같은 경우는 바로 삭제하면 위험한 경우가 있기 때문에 아래와 같은 방식으로 설계하는 것이 좋다!
status를 inactive (비활성) 상태로 두고, 일정 기간동안 비활성인 경우 삭제되도록 구현
위 방식은 Soft Delete 라고 하는데, 이는 정해진 시간에 자동으로 실행되는 프로세스인 batch 를 이용해서 구현할 수 있다.
예를 들어, 매일 지정된 시간에 member table을 검사하고 inactive된 이후 일정 기간이 지난다면 삭제되도록 할 수 있다.
그리고 Soft Delete는 HTTP Method 중 PATCH 이다.
연관관계 설정
위에서 정의한 요구사항을 다시 한 번 보면 연관관계를 위해 사용되는 표현들이 있다.
사용자가 책 여러 권을 대여, 책은 하나의 카테고리가 있음, 책 한 권에 해시태그 여러 개가, 해시태그 하나가 여러 책에 붙을 수 있음, •••
MySQL은 RDB (Relational Database) 기반이므로, 외래키를 이용하여 연관관계를 표시해야 한다.
1️⃣ book - member (대여)
요구사항에서 사용자가 책 여러 권을 대여 할 수 있으므로, 이때 사용자와 책은 N : M 관계 이다.
데이터베이스를 설계할 때, 다대다 관계는 보통 가운데에 매핑 테이블을 따로 두어 1 : N 관계 로 표시해 주는 것이 좋다.
새롭게 생성된 rent 테이블은 book 과 member 테이블의 기본키(PK)를 외래키(FK)로 가지고 각각과 1 : N 관계 를 가진다.
2️⃣ book - book_category
요구사항에서 책은 하나의 카테고리를 가짐 의 경우에는, 카테고리 하나 당 여러 종류의 책이 올 수 있으므로 카테고리와 책은 1 : N 관계 이다.
만약 책과 사용자의 경우처럼, 책 하나의 여러 종류의 카테고리가 올 수 있다면 가운데 매핑 테이블을 두어야 한다.
3️⃣ book - hash_tag
요구사항에서 책 한 권에 해시태그 여러 개가, 해시태그 하나가 여러 책에 붙을 수 있음 으로 정의했으므로, 책과 해시태그의 관계는 N : M 관계 이다.
따라서 두 테이블 사이에 book_hash_tag 매핑 테이블을 두어 설계했다.
4️⃣ book - member (좋아요)
요구사항 사용자가 책 설명 페이지에서 책에 좋아요를 누를 수 있음 을 분석해 보면, 한 종류의 책에 사용자 여러 명이 좋아요를 누를 수 있고, 한 사용자가 여러 책에 좋아요를 누를 수 있으므로 이는 N : M 관계 이다.
따라서 두 테이블 사이에 book_likes 매핑 테이블을 두어 설계했다.
알림 기능 구현
알림 기능은 요구사항에 따라 구현 방법이 다르다.
공지 사항에 대한 알림은 알림 터치 시 해당 공지 사항으로 이동이 되고, 마케팅 알림의 경우 터치 시 해당 마케팅으로 이동이 된다.
위와 같은 요구사항의 경우에는 3가지 설계 방법이 있다.
-
슈퍼 타입과 서브 타입의 구성
-
하나의 alarm 테이블에서 dtype으로 구분
-
여러 alarm 테이블로 나누기
좋아요 집계 기능 구현
좋아요의 수를 집계하는 기능은 여러 방식으로 구현할 수 있다.
예를 들어, book 테이블에 likes 를 두어 수를 셀 수도 있지만, 이런 경우에는 집계에 대한 조건이 생겼을 때 대응하기가 어렵다. (ex. 차단하면 좋아요 수 세지 않음)
따라서 보통 집계 기능을 구현할 때는 순수 DML 연산으로 book_likes 테이블에서 해당 책 아이디를 가진 것이 몇 개인지 직접 count 하는 것이 좋다!
RDS 사용하기
데이터베이스도 EC2처럼 외부 리소스를 빌려 사용하는 것이 좋기 때문에, AWS의 RDS 를 설정해서 사용해 볼 것이다!
RDS를 사용하면 더 유연하게 데이터베이스를 사용할 수 있다.
subnet 추가 생성
RDS를 VPC의 서브넷에 배치하기 위해서는 2개의 Public Subnet 이 필요하다!
RDS 설정
서브넷 그룹 생성
데이터베이스를 원하는 VPC의 Public Subnet에 배치하기 위한 DB Subnet 을 생성해야 한다.
데이터베이스 생성
데이터베이스 생성 방식을 표준 생성, 엔진 유형을 MySQL로 하여 데이터베이스를 생성한다.
마스터 사용자 이름을 root로 설정했다.
앞서 생성한 DB 서브넷 그룹을 선택하고, Public Access를 선택한다.
RDS는 인바운드 규칙으로 3360 포트가 열려있어야 한다!
이렇게 하면 RDS가 생성된다. 🤗
RDS 원격 접속
RDS 원격 접속은 DataGrip을 이용하면 편하다.
원격 접속을 위해서는 앞서 생성한 RDS의 엔드포인트 주소를 복사하여, Host 부분에 입력해야 한다.
입력 후, 연결이 성공하면 아래와 같이 뜬다!
최용욱님의 [UMC Server Workbook]을 기반으로 작성했습니다.
