This commit is contained in:
root
@@ -0,0 +1,383 @@
|
||||
# 다중 프로젝트 피드백 플랫폼의 ID 및 성능 설계
|
||||
|
||||
## 핵심 결론
|
||||
|
||||
현재 시스템은 프로젝트마다 작성 서버가 따로 있고, 각 서버가 중앙 관리 API를 통해 하나의 DB에 글을 저장하는 구조임.
|
||||
|
||||
이 구조에서는 중앙 DB가 번호를 발급하기를 기다리는 방식보다, **각 작성 서버가 글 ID를 먼저 만들고 중앙 API로 보내는 방식**이 적합함.
|
||||
|
||||
### 최종 권장안
|
||||
|
||||
1. **1순위: ULID 또는 UUID v7 선발급**
|
||||
- 프로젝트 작성 서버에서 ID를 먼저 생성함
|
||||
- 화면 ID, API ID, DB ID를 동일하게 사용할 수 있음
|
||||
- 네트워크 재시도에도 같은 글로 판단해 중복 등록을 막을 수 있음
|
||||
- 여러 서버에 별도 Worker 번호를 배정하지 않아도 됨
|
||||
|
||||
2. **숫자 ID가 반드시 필요할 때: Snowflake**
|
||||
- 여러 서버에서 숫자 ID를 선발급할 수 있음
|
||||
- ULID보다 저장 공간이 작음
|
||||
- 대신 Worker ID와 서버 시간 동기화 관리가 필요함
|
||||
|
||||
3. **기존 구조를 가장 적게 바꿀 때: BIGINT Auto Increment**
|
||||
- 구현과 인덱스 성능은 가장 단순함
|
||||
- 중앙 DB 의존성과 재시도 중복을 별도로 해결해야 함
|
||||
- 화면 ID와 DB ID가 달라질 수 있음
|
||||
|
||||
### 선택 기준 한눈에 보기
|
||||
|
||||
| 우선순위 | 선택 |
|
||||
|---|---|
|
||||
| 여러 작성 서버의 독립성, 재시도 중복 방지, ID 일치 | ULID / UUID v7 |
|
||||
| 숫자 ID, 분산 선발급, 높은 쓰기량 | Snowflake |
|
||||
| 변경 최소화, 단일 DB, 중앙 저장 완료 후 ID 발급 | BIGINT Auto Increment |
|
||||
|
||||
---
|
||||
|
||||
## 1. 현재 시스템 구조
|
||||
|
||||
```text
|
||||
[프로젝트 A 작성 서버] ─┐
|
||||
[프로젝트 B 작성 서버] ─┼─ API ─▶ [중앙 관리 서버] ─▶ [중앙 MySQL]
|
||||
[프로젝트 C 작성 서버] ─┘
|
||||
```
|
||||
|
||||
- 피드백 작성 페이지 서버는 프로젝트마다 별도로 운영함
|
||||
- 각 작성 서버가 중앙 관리 API를 호출함
|
||||
- 중앙 관리 서버가 피드백을 한곳에 저장하고 관리함
|
||||
- 향후 외부 Q&A 서버도 같은 API로 연결할 수 있음
|
||||
|
||||
여러 서버가 데이터를 만들고 하나의 서버가 모아 관리하는 **다중 발행자·단일 집계 구조**임.
|
||||
|
||||
## 2. 현재 구조에서 발생하는 문제
|
||||
|
||||
### 2.1 네트워크 재시도에 따른 중복 등록
|
||||
|
||||
```text
|
||||
1. 프로젝트 A가 중앙 API로 글을 전송함
|
||||
2. 중앙 서버는 저장했지만 응답이 네트워크 지연으로 늦어짐
|
||||
3. 프로젝트 A는 실패로 판단하고 같은 글을 다시 전송함
|
||||
4. 중앙 DB가 매번 새 번호를 발급하면 같은 글이 2건 저장됨
|
||||
```
|
||||
|
||||
작성 서버가 ID를 먼저 만들고 재시도할 때 같은 ID를 사용하면 중복을 막을 수 있음.
|
||||
|
||||
```text
|
||||
같은 글 + 같은 ID = 같은 요청
|
||||
```
|
||||
|
||||
중앙 API와 DB에는 해당 ID를 PK 또는 유일 키로 설정해야 함. 이를 멱등성(Idempotency)이라고 함.
|
||||
|
||||
### 2.2 중앙 DB 번호 발급 의존
|
||||
|
||||
Auto Increment 방식에서는 중앙 DB가 저장하면서 번호를 발급함.
|
||||
|
||||
- 작성 서버는 저장이 끝나야 글 번호를 알 수 있음
|
||||
- 여러 프로젝트의 등록 요청이 중앙 DB에 집중됨
|
||||
- 중앙 DB 또는 네트워크 장애가 번호 발급과 저장에 함께 영향을 줌
|
||||
- 비동기 전송과 재시도 처리가 복잡해짐
|
||||
|
||||
### 2.3 프로젝트 구분
|
||||
|
||||
중앙 목록에서 숫자만 표시하면 출처 프로젝트를 바로 알기 어려움.
|
||||
|
||||
```text
|
||||
PRJA_01K8A9V4N5J9F28D5G3H1A2B3C
|
||||
PRJB_01K8A9V4N5J9F28D5G3H1A2B3D
|
||||
```
|
||||
|
||||
화면 ID와 DB ID를 일치시키려면 위의 전체 식별자를 DB에 그대로 저장해야 함. 프로젝트 코드와 ULID를 분리 저장한 뒤 화면에서 조합하면 화면 ID와 DB ID가 달라질 수 있음.
|
||||
|
||||
## 3. 식별자 선택 기준
|
||||
|
||||
| 기준 | 확인할 내용 |
|
||||
|---|---|
|
||||
| 중복 방지 | 네트워크 재시도에도 같은 글로 인식되는지 |
|
||||
| 선발급 | 중앙 DB 저장 전에 작성 서버에서 ID를 만들 수 있는지 |
|
||||
| 분산 생성 | 여러 서버가 동시에 만들어도 충돌하지 않는지 |
|
||||
| 정렬 성능 | 시간 순 생성으로 B-Tree 인덱스에 유리한지 |
|
||||
| 저장 크기 | PK와 외래키 인덱스가 과도하게 커지지 않는지 |
|
||||
| 화면 가독성 | 사람이 읽고 프로젝트를 구분하기 쉬운지 |
|
||||
| 일관성 | DB, API, URL, 화면 ID가 같은지 |
|
||||
| 운영 난이도 | 서버별 추가 설정과 관리가 필요한지 |
|
||||
|
||||
## 4. 식별자 체계 7가지 비교
|
||||
|
||||
| 번호 | 방식 | 저장 스펙 | 인덱스 특성 | 장점 | 단점 | 적합한 환경 |
|
||||
|---:|---|---|---|---|---|---|
|
||||
| 1 | `INT AUTO_INCREMENT` | `INT` 4바이트 | 작고 빠름 | 구현이 가장 쉬움, 메모리 효율이 좋음 | 약 21억 개 한계, 중앙 DB 의존, 프로젝트 구분 어려움 | 소규모 단일 서버 |
|
||||
| 2 | `BIGINT AUTO_INCREMENT` | `BIGINT` 8바이트 | 순차 입력에 유리 | 번호 범위가 매우 큼, 구현이 쉬움 | 중앙 DB에서 번호 발급, 프로젝트 구분 어려움 | 단일 DB 기반 대용량 시스템 |
|
||||
| 3 | `BIGINT + 프로젝트 코드 조합` | DB는 `BIGINT` | 정수 인덱스 유지 | 저장 성능과 화면 식별성을 함께 확보 | 실제 ID와 화면 조합 ID가 달라질 수 있음 | 중앙 DB 구조와 운영 편의성을 함께 중시하는 경우 |
|
||||
| 4 | 비즈니스 문자열 직접 저장 | `VARCHAR` | 정수보다 큼 | DB만 봐도 프로젝트와 글을 구분 가능 | 문자열 인덱스 증가, 동시 채번 문제 | 트래픽이 적고 가독성이 중요한 경우 |
|
||||
| 5 | `ULID / UUID v7` | `BINARY(16)` 또는 문자열 | 시간 순 입력에 유리 | 서버별 선발급, 분산 생성, 재시도 멱등성에 적합 | 정수보다 크고 사람이 읽기 어려움 | 여러 프로젝트 서버가 API로 전송하는 구조 |
|
||||
| 6 | Snowflake | `BIGINT` 8바이트 | 시간 순 입력에 유리 | 분산 서버에서 숫자 ID를 선발급할 수 있음 | Worker ID와 시계 동기화 관리 필요 | 매우 높은 쓰기량의 분산 시스템 |
|
||||
| 7 | UUID v4 | UUID 또는 `VARCHAR(36)` | 랜덤 입력으로 페이지 분할 가능 | 생성이 쉽고 추측이 어려움 | 인덱스가 크고 랜덤 삽입으로 쓰기 효율이 낮아질 수 있음 | 보안상 추측 방지가 최우선인 경우 |
|
||||
|
||||
### 대략적인 PK 인덱스 크기
|
||||
|
||||
1,000만 건 기준의 대략적인 비교임. 실제 크기는 외래키, 보조 인덱스, 페이지 여유 공간에 따라 달라짐.
|
||||
|
||||
| 방식 | 대략적인 크기 |
|
||||
|---|---:|
|
||||
| `INT` | 약 200MB |
|
||||
| `BIGINT` | 약 400MB |
|
||||
| `BINARY(16)` | 약 800MB 이상 |
|
||||
| `VARCHAR(36)` UUID | 약 1~2GB 이상 |
|
||||
|
||||
## 5. 현재 시스템에 맞는 3가지 케이스
|
||||
|
||||
### Case 1. ULID 또는 UUID v7을 실제 글 ID로 사용
|
||||
|
||||
#### 구성
|
||||
|
||||
```text
|
||||
DB ID / API ID / 화면 ID:
|
||||
PRJA_01K8A9V4N5J9F28D5G3H1A2B3C
|
||||
```
|
||||
|
||||
- 각 프로젝트 작성 서버가 ID를 먼저 생성함
|
||||
- 글 데이터와 ID를 중앙 API로 전송함
|
||||
- 중앙 DB는 ID를 PK 또는 UNIQUE KEY로 확인함
|
||||
- 동일 ID의 재요청은 중복 저장하지 않음
|
||||
- 관리페이지는 전달받은 ID를 그대로 표시함
|
||||
|
||||
#### 장점
|
||||
|
||||
- 프로젝트 서버가 중앙 DB에 의존하지 않고 ID를 선발급할 수 있음
|
||||
- 네트워크 타임아웃 후 재시도해도 중복 등록을 막기 쉬움
|
||||
- 시간 순 ID라 UUID v4보다 B-Tree 인덱스에 유리함
|
||||
- 서버별 Worker ID를 배정할 필요가 없음
|
||||
- 화면 ID와 DB ID를 동일하게 유지할 수 있음
|
||||
|
||||
#### 단점
|
||||
|
||||
- `BIGINT`보다 PK와 외래키 인덱스가 큼
|
||||
- 사람이 숫자 하나로 기억하거나 구두 전달하기 어려움
|
||||
- 프로젝트 접두사를 포함하면 ID가 더 길어짐
|
||||
|
||||
#### 권장 저장 방식
|
||||
|
||||
화면 ID와 DB ID를 완전히 일치시켜야 하면 접두사와 ULID를 합친 전체 문자열을 `VARCHAR`에 저장함.
|
||||
|
||||
```text
|
||||
PRJA_01K8A9V4N5J9F28D5G3H1A2B3C
|
||||
```
|
||||
|
||||
DB 용량을 줄이기 위해 ULID를 `BINARY(16)`으로 분리 저장하면 화면에서 조합한 값과 DB의 실제 값이 달라질 수 있음.
|
||||
|
||||
### Case 2. Snowflake 숫자 ID 사용
|
||||
|
||||
#### 구성
|
||||
|
||||
```text
|
||||
DB ID / API ID / 화면 ID:
|
||||
178293849182394880
|
||||
```
|
||||
|
||||
Snowflake는 다음 값을 조합해 64비트 숫자를 생성함.
|
||||
|
||||
```text
|
||||
시간 정보 + Worker ID + 같은 시간 안의 순번
|
||||
```
|
||||
|
||||
#### 장점
|
||||
|
||||
- 여러 서버에서 중앙 DB 의존 없이 숫자 ID를 선발급할 수 있음
|
||||
- ULID보다 PK와 외래키 인덱스가 작음
|
||||
- 시간 순 정렬이 가능함
|
||||
- 화면 ID와 DB ID를 동일하게 유지할 수 있음
|
||||
|
||||
#### 단점
|
||||
|
||||
- 프로젝트와 서버마다 고유 Worker ID를 배정해야 함
|
||||
- 서버가 늘어나거나 컨테이너가 추가될 때 번호 관리가 필요함
|
||||
- Worker ID가 중복되면 ID 충돌이 발생함
|
||||
- 서버 시간 오차를 관리해야 함
|
||||
- 현재 등록량에서는 운영 복잡도가 성능 이점보다 클 수 있음
|
||||
|
||||
### Case 3. BIGINT Auto Increment + 프로젝트 코드 별도 표시
|
||||
|
||||
#### 구성
|
||||
|
||||
```text
|
||||
DB ID: 10492
|
||||
프로젝트: ABC
|
||||
채널: WEB
|
||||
화면 표시: ABC-WEB-10492
|
||||
```
|
||||
|
||||
- DB: `id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY`
|
||||
- 프로젝트와 채널은 별도 컬럼으로 저장함
|
||||
- 화면과 알림에서 프로젝트 코드와 숫자를 조합함
|
||||
|
||||
#### 장점
|
||||
|
||||
- 정수 PK와 외래키로 인덱스가 작음
|
||||
- 기존 구조를 가장 적게 변경함
|
||||
- 중앙 DB에서 구현하기 쉬움
|
||||
- 순차 입력으로 B-Tree 페이지 분할이 적음
|
||||
|
||||
#### 단점
|
||||
|
||||
- 중앙 DB에 저장되어야 ID를 알 수 있음
|
||||
- 재시도 중복을 막으려면 별도의 Idempotency Key가 필요함
|
||||
- 화면의 `ABC-WEB-10492`와 DB의 `10492`가 다름
|
||||
- 프로젝트별 번호가 1번부터 시작하지 않음
|
||||
|
||||
## 6. ULID와 Snowflake를 쉽게 비교
|
||||
|
||||
### Snowflake
|
||||
|
||||
각 지점에 번호표 기계를 설치하고 지점 번호를 미리 배정하는 방식임.
|
||||
|
||||
- 프로젝트 A 서버는 Worker ID 1
|
||||
- 프로젝트 B 서버는 Worker ID 2
|
||||
- 프로젝트 C 서버는 Worker ID 3
|
||||
|
||||
번호표가 작고 빠르지만 서버가 늘어날 때마다 번호를 관리해야 함. 서버 시계가 맞지 않으면 번호 발급에 문제가 생길 수 있음.
|
||||
|
||||
### ULID
|
||||
|
||||
각 지점이 별도 등록 없이 앱을 실행해 고유 번호표를 만드는 방식임.
|
||||
|
||||
- Worker ID를 따로 배정하지 않아도 됨
|
||||
- 여러 서버에서 동시에 생성해도 충돌 가능성이 매우 낮음
|
||||
- 네트워크가 끊겨 같은 글을 다시 보내도 같은 ID로 중복을 확인할 수 있음
|
||||
- 시간 순으로 생성되어 DB에 정리하기 쉬움
|
||||
|
||||
현재처럼 프로젝트별 작성 서버가 여러 곳에 나뉘어 있으면 관리할 설정이 적은 ULID가 운영 측면에서 유리함.
|
||||
|
||||
## 7. 피드백 테이블 인덱스 설계
|
||||
|
||||
### 주요 조회 조건
|
||||
|
||||
```sql
|
||||
WHERE channel_id = ?
|
||||
AND deleted_at IS NULL
|
||||
ORDER BY id DESC
|
||||
LIMIT 20
|
||||
```
|
||||
|
||||
### 기본 후보
|
||||
|
||||
```sql
|
||||
CREATE INDEX idx_feedbacks_channel_active_list
|
||||
ON feedbacks (channel_id, deleted_at, id DESC);
|
||||
```
|
||||
|
||||
`deleted_at`을 포함한 이유는 소프트 삭제된 글을 목록에서 제외하는 조건까지 인덱스 탐색 범위에 포함하기 위해서임.
|
||||
|
||||
다만 삭제된 글이 거의 없으면 다음 인덱스가 더 작고 효율적일 수도 있음.
|
||||
|
||||
```sql
|
||||
CREATE INDEX idx_feedbacks_channel_list
|
||||
ON feedbacks (channel_id, id DESC);
|
||||
```
|
||||
|
||||
두 방식 중 어느 쪽이 좋은지는 삭제 데이터 비율과 실제 실행 계획으로 확인해야 함.
|
||||
|
||||
### 미확인 피드백 조회
|
||||
|
||||
```sql
|
||||
CREATE INDEX idx_feedbacks_unread
|
||||
ON feedbacks (channel_id, admin_first_read_at, deleted_at);
|
||||
```
|
||||
|
||||
### JSON 내부 값 조회
|
||||
|
||||
`data` 내부의 `category`를 자주 검색한다면 생성 컬럼과 인덱스를 구성할 수 있음.
|
||||
|
||||
```sql
|
||||
ALTER TABLE feedbacks
|
||||
ADD COLUMN category VARCHAR(50)
|
||||
GENERATED ALWAYS AS (data->>'$.category') VIRTUAL;
|
||||
```
|
||||
|
||||
```sql
|
||||
CREATE INDEX idx_feedbacks_channel_category
|
||||
ON feedbacks (channel_id, category, id DESC);
|
||||
```
|
||||
|
||||
## 8. 5만 건 기준 메모리와 캐시
|
||||
|
||||
현재 523행의 데이터 용량이 약 `528.0 KiB`라면 다음과 같이 추정할 수 있음.
|
||||
|
||||
| 항목 | 예상 크기 |
|
||||
|---|---:|
|
||||
| 5만 건 데이터 | 약 50~70MB |
|
||||
| 복합 인덱스 2~3개 | 약 4~6MB |
|
||||
| 데이터와 인덱스 합계 | 약 80MB 미만 |
|
||||
|
||||
실제 크기는 JSON 또는 TEXT 데이터 길이, 인덱스 자료형, 보조 인덱스 수에 따라 달라짐.
|
||||
|
||||
### InnoDB Buffer Pool
|
||||
|
||||
```text
|
||||
[MySQL 데이터와 인덱스]
|
||||
│
|
||||
▼
|
||||
[InnoDB Buffer Pool 메모리 상주]
|
||||
│
|
||||
▼
|
||||
[반복 조회 시 디스크 접근 감소]
|
||||
```
|
||||
|
||||
Buffer Pool이 데이터와 인덱스보다 충분히 크면 자주 조회되는 페이지가 메모리에 상주할 수 있음. 다만 실제 상주율과 응답 시간은 서버 메모리, 설정, 실행 계획, 동시 접속자 수에 따라 달라짐.
|
||||
|
||||
### Redis 애플리케이션 캐시
|
||||
|
||||
```text
|
||||
[클라이언트]
|
||||
│
|
||||
▼
|
||||
[Redis 캐시] ── HIT ──▶ 캐시 결과 반환
|
||||
│
|
||||
MISS
|
||||
▼
|
||||
[중앙 API] ──▶ [MySQL] ──▶ Redis 갱신
|
||||
```
|
||||
|
||||
우선 캐싱할 대상:
|
||||
|
||||
- 프로젝트·채널별 최신 피드백 목록
|
||||
- 각 목록의 첫 페이지
|
||||
- 전체 피드백 수와 상태별 개수
|
||||
- 답변 대기·미확인 요약 정보
|
||||
|
||||
캐시 키 예시:
|
||||
|
||||
```text
|
||||
feedback:project:{project_id}:channel:{channel_id}:page:1
|
||||
```
|
||||
|
||||
새 글 등록, 수정, 삭제가 발생하면 관련 캐시를 삭제하거나 갱신해야 함.
|
||||
|
||||
| 방식 | 설명 |
|
||||
|---|---|
|
||||
| 즉시 삭제 | 변경 시 관련 캐시를 바로 삭제함 |
|
||||
| 짧은 TTL | 30초~1분 후 자동 만료함 |
|
||||
| 조합 | 첫 페이지는 즉시 삭제하고 나머지는 TTL을 사용함 |
|
||||
|
||||
## 9. 성능 점검 방법
|
||||
|
||||
인덱스를 적용하기 전에 실제 실행 계획을 확인해야 함.
|
||||
|
||||
```sql
|
||||
EXPLAIN ANALYZE
|
||||
SELECT *
|
||||
FROM feedbacks
|
||||
WHERE channel_id = 1
|
||||
AND deleted_at IS NULL
|
||||
ORDER BY id DESC
|
||||
LIMIT 20;
|
||||
```
|
||||
|
||||
다음 항목을 확인함.
|
||||
|
||||
- 예상한 인덱스가 선택되는지
|
||||
- `key`에 복합 인덱스가 표시되는지
|
||||
- `rows`가 과도하게 많지 않은지
|
||||
- 전체 테이블 스캔이 발생하지 않는지
|
||||
- `Using filesort` 또는 `Using temporary`가 발생하는지
|
||||
|
||||
인덱스 적용 전후의 실행 시간, 읽은 행 수, DB CPU와 디스크 I/O를 함께 비교해야 함.
|
||||
Reference in New Issue
Block a user