mirror of
https://github.com/ktds-dg0501/kt-event-marketing.git
synced 2025-12-06 20:06:23 +00:00
3075a5d49f
✨ 주요 기능 - Azure 기반 물리아키텍처 설계 (개발환경/운영환경) - 7개 마이크로서비스 물리 구조 설계 - 네트워크 아키텍처 다이어그램 작성 (Mermaid) - 환경별 비교 분석 및 마스터 인덱스 문서 📁 생성 파일 - design/backend/physical/physical-architecture.md (마스터) - design/backend/physical/physical-architecture-dev.md (개발환경) - design/backend/physical/physical-architecture-prod.md (운영환경) - design/backend/physical/*.mmd (4개 Mermaid 다이어그램) 🎯 핵심 성과 - 비용 최적화: 개발환경 월 $143, 운영환경 월 $2,860 - 확장성: 개발환경 100명 → 운영환경 10,000명 (100배) - 가용성: 개발환경 95% → 운영환경 99.9% - 보안: 다층 보안 아키텍처 (L1~L4) 🛠️ 기술 스택 - Azure Kubernetes Service (AKS) - Azure Database for PostgreSQL Flexible - Azure Cache for Redis Premium - Azure Service Bus Premium - Application Gateway + WAF 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
316 lines
10 KiB
Markdown
316 lines
10 KiB
Markdown
# KT 이벤트 마케팅 서비스 데이터베이스 설계 통합 요약
|
|
|
|
## 📋 설계 개요
|
|
|
|
- **설계 대상**: 7개 서비스 데이터베이스 (공통 설계 원칙 준용)
|
|
- **설계 일시**: 2025-10-29
|
|
- **설계자**: Backend Developer (최수연 "아키텍처")
|
|
- **설계 원칙**: 데이터독립성원칙, 마이크로서비스 아키텍처
|
|
|
|
---
|
|
|
|
## ✅ 1. 서비스별 설계 완료 현황
|
|
|
|
| 서비스 | 아키텍처 | PostgreSQL | Redis | ERD | DDL | 문법검증 |
|
|
|--------|----------|------------|-------|-----|-----|----------|
|
|
| **user-service** | Layered | ✅ users, stores | ✅ JWT, blacklist | ✅ | ✅ | ✅ |
|
|
| **ai-service** | Clean | ❌ (Redis Only) | ✅ 추천, 상태, 트렌드 | ✅ | ✅ | ✅ |
|
|
| **analytics-service** | Layered | ✅ 통계 3테이블 | ✅ 대시보드, 분석 | ✅ | ✅ | ✅ |
|
|
| **content-service** | Clean | ✅ 콘텐츠 3테이블 | ✅ Job, 이미지, AI | ✅ | ✅ | ✅ |
|
|
| **distribution-service** | Layered | ✅ 배포상태 2테이블 | ✅ 배포상태, 채널 | ✅ | ✅ | ✅ |
|
|
| **event-service** | Clean | ✅ 이벤트 4테이블 | ✅ 세션, 초안, Job | ✅ | ✅ | ✅ |
|
|
| **participation-service** | Layered | ✅ 참여자 2테이블 | ✅ 세션, 추첨, 카운트 | ✅ | ✅ | ✅ |
|
|
|
|
**설계 완료율**: 100% (7/7 서비스)
|
|
|
|
---
|
|
|
|
## 🏗️ 2. 데이터베이스 아키텍처 개요
|
|
|
|
### 2.1 데이터독립성 원칙 준수
|
|
|
|
✅ **서비스별 독립 데이터베이스**
|
|
- 각 서비스는 자신만의 PostgreSQL 스키마 소유
|
|
- 서비스 간 직접 DB 조인 금지
|
|
- 데이터 참조는 API 또는 이벤트 기반
|
|
|
|
✅ **Redis 캐싱 전략**
|
|
- 타 서비스 데이터는 캐시로만 참조
|
|
- TTL 기반 데이터 신선도 관리
|
|
- 성능 최적화 및 DB 부하 분산
|
|
|
|
### 2.2 아키텍처 패턴별 데이터 설계
|
|
|
|
**Clean Architecture 서비스 (3개)**
|
|
- **ai-service**: Redis 기반 Stateless 설계
|
|
- **content-service**: 이미지 메타데이터 + CDN 연동
|
|
- **event-service**: 핵심 도메인, 상태 머신 최적화
|
|
|
|
**Layered Architecture 서비스 (4개)**
|
|
- **user-service**: 사용자/매장 관계, JWT 세션 관리
|
|
- **analytics-service**: 시계열 데이터, BRIN 인덱스 활용
|
|
- **distribution-service**: 다중 채널 배포 상태 추적
|
|
- **participation-service**: 참여자 관리, 중복 방지 메커니즘
|
|
|
|
---
|
|
|
|
## 📊 3. 테이블 및 데이터 구조 요약
|
|
|
|
### 3.1 PostgreSQL 테이블 통계
|
|
|
|
| 서비스 | 테이블 수 | 총 컬럼 수 | 인덱스 수 | 외래키 수 | 제약조건 수 |
|
|
|--------|-----------|------------|-----------|-----------|-------------|
|
|
| user-service | 2 | 21 | 5 | 1 | 8 |
|
|
| ai-service | 0 | 0 | 0 | 0 | 0 |
|
|
| analytics-service | 3 | 29 | 8 | 2 | 12 |
|
|
| content-service | 3 | 28 | 7 | 2 | 11 |
|
|
| distribution-service | 2 | 17 | 4 | 1 | 7 |
|
|
| event-service | 4 | 42 | 9 | 3 | 16 |
|
|
| participation-service | 2 | 20 | 6 | 1 | 9 |
|
|
| **총계** | **16** | **157** | **39** | **10** | **63** |
|
|
|
|
### 3.2 Redis 캐시 패턴 요약
|
|
|
|
| 서비스 | 캐시 패턴 수 | 주요 용도 | TTL 범위 |
|
|
|--------|-------------|-----------|----------|
|
|
| user-service | 2 | JWT 세션, 블랙리스트 | 1시간-7일 |
|
|
| ai-service | 3 | AI 추천, 작업상태, 트렌드 | 1시간-24시간 |
|
|
| analytics-service | 6 | 대시보드, 분석결과 | 1시간 |
|
|
| content-service | 3 | Job 상태, 이미지, AI 데이터 | 1시간-7일 |
|
|
| distribution-service | 2 | 배포 상태, 채널별 진행률 | 30분-1시간 |
|
|
| event-service | 3 | 세션, 초안, Job 상태 | 10분-1시간 |
|
|
| participation-service | 3 | 참여세션, 추첨결과, 카운트 | 5분-1시간 |
|
|
| **총계** | **22** | - | **5분-7일** |
|
|
|
|
---
|
|
|
|
## 🔗 4. 서비스 간 데이터 연동 패턴
|
|
|
|
### 4.1 동기 통신 (Feign Client)
|
|
|
|
```
|
|
Event Service → Content Service
|
|
├── 이미지 생성 요청
|
|
├── 이미지 상태 조회
|
|
└── 이미지 선택 정보 전달
|
|
```
|
|
|
|
### 4.2 비동기 통신 (Kafka)
|
|
|
|
```
|
|
Event Service → AI Service
|
|
├── AI 추천 생성 요청
|
|
└── 추천 결과 수신
|
|
|
|
Participation Service → Analytics Service
|
|
├── 참여자 등록 이벤트
|
|
└── 통계 데이터 업데이트
|
|
|
|
Distribution Service → Analytics Service
|
|
├── 배포 완료 이벤트
|
|
└── 채널별 성과 데이터 전달
|
|
```
|
|
|
|
### 4.3 캐시 기반 참조
|
|
|
|
```
|
|
Analytics Service → Redis Cache
|
|
├── Event 기본 정보 (TTL: 1시간)
|
|
├── User 프로필 정보 (TTL: 1시간)
|
|
└── 실시간 통계 갱신 (TTL: 5분)
|
|
```
|
|
|
|
---
|
|
|
|
## 🛡️ 5. 보안 및 성능 고려사항
|
|
|
|
### 5.1 데이터 보안
|
|
|
|
✅ **개인정보 보호**
|
|
- 전화번호, 이메일 마스킹 처리 가이드 제공
|
|
- JWT 기반 인증, 세션 무효화 메커니즘
|
|
- Redis 블랙리스트를 통한 토큰 보안 강화
|
|
|
|
✅ **데이터 무결성**
|
|
- CHECK 제약조건으로 비즈니스 규칙 강제
|
|
- UNIQUE 제약조건으로 중복 데이터 방지
|
|
- Foreign Key CASCADE로 참조 무결성 보장
|
|
|
|
### 5.2 성능 최적화
|
|
|
|
✅ **인덱스 전략 (39개 인덱스)**
|
|
- B-Tree 인덱스: 정확 매칭 및 범위 조회
|
|
- BRIN 인덱스: 시계열 데이터 (analytics-service)
|
|
- Partial 인덱스: 조건부 조회 최적화
|
|
- 복합 인덱스: 다중 컬럼 조회 패턴
|
|
|
|
✅ **캐시 전략 (22개 패턴)**
|
|
- Cache-Aside: 읽기 중심 캐싱
|
|
- Write-Through: 실시간 데이터 동기화
|
|
- TTL 관리: 데이터 신선도 보장
|
|
- 캐시 무효화: 이벤트 기반 자동 갱신
|
|
|
|
---
|
|
|
|
## 📈 6. 확장성 및 유지보수성
|
|
|
|
### 6.1 수평 확장 고려사항
|
|
|
|
✅ **샤딩 준비**
|
|
- user_id, event_id 기반 파티셔닝 가능
|
|
- 서비스별 독립 스케일링
|
|
- Redis Cluster 지원
|
|
|
|
✅ **읽기 복제본**
|
|
- 분석 쿼리는 읽기 전용 복제본 활용
|
|
- 마스터-슬레이브 분리로 성능 최적화
|
|
|
|
### 6.2 마이그레이션 전략
|
|
|
|
✅ **스키마 버전 관리**
|
|
- DDL 스크립트 버전별 관리
|
|
- 롤백 스크립트 제공
|
|
- 무중단 배포 지원
|
|
|
|
✅ **데이터 마이그레이션**
|
|
- 서비스별 독립 마이그레이션
|
|
- 점진적 데이터 이전 전략
|
|
|
|
---
|
|
|
|
## 🔍 7. 검증 완료 사항
|
|
|
|
### 7.1 클래스 설계와의 일치성
|
|
|
|
✅ **Entity 클래스 1:1 매핑 (100%)**
|
|
- 모든 Entity 클래스가 테이블과 정확히 매핑
|
|
- 필드명, 데이터 타입, 관계 정보 일치
|
|
- Enum 타입 CHECK 제약조건 적용
|
|
|
|
### 7.2 PlantUML 문법 검증
|
|
|
|
✅ **ERD 문법 검사 (7/7 통과)**
|
|
```
|
|
ai-service-erd.puml ✅ Syntax check passed!
|
|
analytics-service-erd.puml ✅ Syntax check passed!
|
|
content-service-erd.puml ✅ Syntax check passed!
|
|
distribution-service-erd.puml ✅ Syntax check passed!
|
|
event-service-erd.puml ✅ Syntax check passed!
|
|
participation-service-erd.puml ✅ Syntax check passed!
|
|
user-service-erd.puml ✅ Syntax check passed!
|
|
```
|
|
|
|
### 7.3 데이터독립성 원칙 검증
|
|
|
|
✅ **서비스별 독립성**
|
|
- 각 서비스만 자신의 데이터 소유
|
|
- 크로스 서비스 조인 없음
|
|
- API/이벤트 기반 데이터 교환
|
|
|
|
---
|
|
|
|
## 📁 8. 생성된 산출물
|
|
|
|
### 8.1 데이터설계서 (7개)
|
|
```
|
|
design/backend/database/
|
|
├── user-service.md (14KB)
|
|
├── ai-service.md (12KB)
|
|
├── analytics-service.md (18KB)
|
|
├── content-service.md (16KB)
|
|
├── distribution-service.md (13KB)
|
|
├── event-service.md (17KB)
|
|
├── participation-service.md (12KB)
|
|
└── integration-summary.md (이 문서)
|
|
```
|
|
|
|
### 8.2 ERD 다이어그램 (7개)
|
|
```
|
|
design/backend/database/
|
|
├── user-service-erd.puml
|
|
├── ai-service-erd.puml
|
|
├── analytics-service-erd.puml
|
|
├── content-service-erd.puml
|
|
├── distribution-service-erd.puml
|
|
├── event-service-erd.puml
|
|
└── participation-service-erd.puml
|
|
```
|
|
|
|
### 8.3 DDL 스크립트 (7개)
|
|
```
|
|
design/backend/database/
|
|
├── user-service-schema.psql (12KB)
|
|
├── ai-service-schema.psql (4KB, Redis 설정)
|
|
├── analytics-service-schema.psql (16KB)
|
|
├── content-service-schema.psql (15KB)
|
|
├── distribution-service-schema.psql (11KB)
|
|
├── event-service-schema.psql (18KB)
|
|
└── participation-service-schema.psql (13KB)
|
|
```
|
|
|
|
---
|
|
|
|
## 🚀 9. 다음 단계
|
|
|
|
### 9.1 백엔드 개발 준비 완료
|
|
|
|
✅ **데이터베이스 설계 완료** (100%)
|
|
- 모든 서비스별 스키마 설계 완료
|
|
- ERD 및 DDL 스크립트 준비 완료
|
|
- 성능 최적화 전략 수립 완료
|
|
|
|
### 9.2 권장 개발 순서
|
|
|
|
1. **데이터베이스 설치 및 초기화**
|
|
- PostgreSQL 13+ 설치
|
|
- Redis 7+ 설치
|
|
- DDL 스크립트 실행
|
|
|
|
2. **공통 컴포넌트 개발**
|
|
- BaseTimeEntity, ApiResponse 구현
|
|
- ErrorCode, ValidationUtil 구현
|
|
|
|
3. **서비스별 개발 (우선순위)**
|
|
1. **user-service**: 인증 기반 서비스
|
|
2. **event-service**: 핵심 도메인 서비스
|
|
3. **content-service**: 이미지 생성 서비스
|
|
4. **ai-service**: AI 추천 서비스
|
|
5. **participation-service**: 참여자 관리
|
|
6. **distribution-service**: 배포 서비스
|
|
7. **analytics-service**: 분석 서비스
|
|
|
|
4. **통합 테스트 및 배포**
|
|
- API 통합 테스트
|
|
- 성능 테스트 및 최적화
|
|
- 프로덕션 배포
|
|
|
|
---
|
|
|
|
## 📊 10. 최종 결론
|
|
|
|
### ✅ 설계 성과
|
|
|
|
**완성도**: 100% (7/7 서비스 설계 완료)
|
|
**품질**: ERD 문법 검증 100% 통과, Entity 매핑 100% 일치
|
|
**성능**: 39개 인덱스, 22개 캐시 패턴으로 최적화
|
|
**확장성**: 마이크로서비스 아키텍처, 수평 확장 지원
|
|
**보안**: 개인정보 보호, 데이터 무결성 보장
|
|
|
|
### 🎯 핵심 강점
|
|
|
|
1. **데이터독립성**: 서비스별 완전한 데이터 격리
|
|
2. **성능 최적화**: 체계적인 인덱스 및 캐시 전략
|
|
3. **확장성**: 서비스별 독립 스케일링 지원
|
|
4. **유지보수성**: 명확한 데이터 모델과 문서화
|
|
5. **개발 효율성**: 실행 가능한 DDL 스크립트 제공
|
|
|
|
### 🚀 백엔드 개발 착수 준비 완료
|
|
|
|
KT 이벤트 마케팅 서비스의 데이터베이스 설계가 **완료**되어, 즉시 백엔드 개발에 착수할 수 있습니다.
|
|
|
|
---
|
|
|
|
**문서 작성자**: Backend Developer (최수연 "아키텍처")
|
|
**작성일**: 2025-10-29
|
|
**문서 버전**: v1.0
|
|
**검토 상태**: ✅ 완료 |