shared-dg05-dodari/kt-event-marketing
7
0
Fork 0
mirror of https://github.com/ktds-dg0501/kt-event-marketing.git synced 2025-12-06 12:46:23 +00:00
Code Issues Packages Projects Releases Wiki Activity

클라우드 아키텍처 패턴 선정서 작성 완료

Browse Source 
- 3개 핵심 패턴으로 간소화 (API Gateway, Async Request-Reply, Circuit Breaker)
- 기존 10개 패턴 문서 백업 (architecture-pattern-backup-20251021.md)
- 버전 2.0으로 업데이트
- Phase 1 MVP 중심 3개월 로드맵 작성
- 서비스별 패턴 적용 설계 및 시퀀스 다이어그램 작성
- 성과 지표 및 리스크 관리 방안 정리

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
sunmingLee 2025-10-21 11:33:22 +09:00
parent c1ce688aa9
commit b66ae9357c
2 changed files with 1117 additions and 432 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1008
design/pattern/architecture-pattern-backup-20251021.md Normal file
View File

File diff suppressed because it is too large Load Diff

541
design/pattern/architecture-pattern.md
View File

@ -2,7 +2,7 @@
**작성일**: 2025-10-21 **작성일**: 2025-10-21
**작성자**: System Architect (박영자) **작성자**: System Architect (박영자)
**버전**: 1.0 **버전**: 2.0 (3개 핵심 패턴 적용)
--- ---
@ -128,7 +128,6 @@
**기술적 도전과제**: **기술적 도전과제**:
- **다중 데이터 소스 통합 (KT API, POS, SNS API)** - **다중 데이터 소스 통합 (KT API, POS, SNS API)**
- CQRS 패턴으로 읽기/쓰기 분리
- 5분 간격 스케줄러 기반 수집 - 5분 간격 스케줄러 기반 수집
- 대시보드 실시간 업데이트 - 대시보드 실시간 업데이트
@ -150,7 +149,6 @@
- 성공/실패 패턴 자동 학습 - 성공/실패 패턴 자동 학습
- 업종별/지역별 데이터 축적 - 업종별/지역별 데이터 축적
- 추천 정확도 향상 알고리즘 - 추천 정확도 향상 알고리즘
- Event Sourcing으로 학습 데이터 추적
--- ---
@ -159,10 +157,10 @@
#### 성능 목표 요약 #### 성능 목표 요약
| 서비스 | 목표 응답시간 | 핵심 최적화 전략 | | 서비스 | 목표 응답시간 | 핵심 최적화 전략 |
|--------|--------------|------------------| |--------|--------------|------------------|
| Event Planning | **10초 이내** | AI API 병렬 호출, 응답 캐싱 | | Event Planning | **10초 이내** | AI API 병렬 호출 |
| Content Generation | **5-8분 이내** | 이미지+영상 병렬 생성, 비동기 처리 | | Content Generation | **5-8분 이내** | 이미지+영상 병렬 생성, 비동기 처리 |
| Distribution | **1분 이내** | 6개 채널 병렬 배포 | | Distribution | **1분 이내** | 6개 채널 병렬 배포 |
| Analytics | **5분 주기** | CQRS 읽기/쓰기 분리, 스케줄러 수집 | | Analytics | **5분 주기** | 스케줄러 수집 |
#### 확장성 요구사항 #### 확장성 요구사항
- **동시 이벤트 처리**: 최소 100개 - **동시 이벤트 처리**: 최소 100개
@ -181,26 +179,19 @@
### 2.1 패턴 평가 매트릭스 ### 2.1 패턴 평가 매트릭스
#### 핵심 패턴 Top 10 정량 평가 #### 핵심 패턴 정량 평가
| 패턴 | 기능 적합성<br/>(35%) | 성능 효과<br/>(25%) | 운영 복잡도<br/>(20%) | 확장성<br/>(15%) | 비용 효율성<br/>(5%) | **총점** | **우선순위** | | 패턴 | 기능 적합성<br/>(35%) | 성능 효과<br/>(25%) | 운영 복잡도<br/>(20%) | 확장성<br/>(15%) | 비용 효율성<br/>(5%) | **총점** | **우선순위** |
|------|:---:|:---:|:---:|:---:|:---:|:---:|:---:| |------|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
| **API Gateway** | 10 × 0.35 = 3.5 | 9 × 0.25 = 2.25 | 9 × 0.20 = 1.8 | 9 × 0.15 = 1.35 | 8 × 0.05 = 0.4 | **9.30** | 🥇 1위 | | **API Gateway** | 10 × 0.35 = 3.5 | 9 × 0.25 = 2.25 | 9 × 0.20 = 1.8 | 9 × 0.15 = 1.35 | 8 × 0.05 = 0.4 | **9.30** | 🥇 1위 |
| **Async Request-Reply** | 10 × 0.35 = 3.5 | 9 × 0.25 = 2.25 | 7 × 0.20 = 1.4 | 8 × 0.15 = 1.2 | 7 × 0.05 = 0.35 | **8.70** | 🥈 2위 | | **Async Request-Reply** | 10 × 0.35 = 3.5 | 9 × 0.25 = 2.25 | 7 × 0.20 = 1.4 | 8 × 0.15 = 1.2 | 7 × 0.05 = 0.35 | **8.70** | 🥈 2위 |
| **Circuit Breaker** | 9 × 0.35 = 3.15 | 7 × 0.25 = 1.75 | 8 × 0.20 = 1.6 | 8 × 0.15 = 1.2 | 8 × 0.05 = 0.4 | **8.10** | 🥉 3위 | | **Circuit Breaker** | 9 × 0.35 = 3.15 | 7 × 0.25 = 1.75 | 8 × 0.20 = 1.6 | 8 × 0.15 = 1.2 | 8 × 0.05 = 0.4 | **8.10** | 🥉 3위 |
| **CQRS** | 9 × 0.35 = 3.15 | 9 × 0.25 = 2.25 | 5 × 0.20 = 1.0 | 8 × 0.15 = 1.2 | 6 × 0.05 = 0.3 | **7.90** | 4위 |
| **Cache-Aside** | 8 × 0.35 = 2.8 | 9 × 0.25 = 2.25 | 9 × 0.20 = 1.8 | 7 × 0.15 = 1.05 | 9 × 0.05 = 0.45 | **8.35** | 5위 |
| **Event Sourcing** | 9 × 0.35 = 3.15 | 7 × 0.25 = 1.75 | 4 × 0.20 = 0.8 | 9 × 0.15 = 1.35 | 5 × 0.05 = 0.25 | **7.30** | 6위 |
| **Queue-Based Load Leveling** | 8 × 0.35 = 2.8 | 8 × 0.25 = 2.0 | 7 × 0.20 = 1.4 | 9 × 0.15 = 1.35 | 7 × 0.05 = 0.35 | **7.90** | 7위 |
| **Retry** | 7 × 0.35 = 2.45 | 6 × 0.25 = 1.5 | 9 × 0.20 = 1.8 | 6 × 0.15 = 0.9 | 9 × 0.05 = 0.45 | **7.10** | 8위 |
| **Publisher-Subscriber** | 8 × 0.35 = 2.8 | 7 × 0.25 = 1.75 | 6 × 0.20 = 1.2 | 8 × 0.15 = 1.2 | 7 × 0.05 = 0.35 | **7.30** | 9위 |
| **Choreography** | 7 × 0.35 = 2.45 | 6 × 0.25 = 1.5 | 5 × 0.20 = 1.0 | 8 × 0.15 = 1.2 | 6 × 0.05 = 0.3 | **6.45** | 10위 |
--- ---
### 2.2 선정 패턴 및 적용 전략 ### 2.2 선정 패턴 및 적용 전략
#### 🥇 **1. API Gateway** (총점: 9.30) - Phase 1 MVP #### 🥇 **1. API Gateway** (총점: 9.30)
**선정 이유**: **선정 이유**:
- 단일 진입점으로 7개 마이크로서비스 라우팅 - 단일 진입점으로 7개 마이크로서비스 라우팅
@ -215,23 +206,34 @@
- 인증 처리 시간 50% 단축 - 인증 처리 시간 50% 단축
- 서비스 간 결합도 감소 - 서비스 간 결합도 감소
**구현 기술**:
- **기술 스택**: Kong, AWS API Gateway, Spring Cloud Gateway
- **Rate Limiting**: 사용자당 1분 100 요청
- **JWT 토큰**: 만료 시간 1시간, Refresh Token 7일
- **로깅**: 모든 요청/응답 로그 저장 (CloudWatch, ELK)
--- ---
#### 🥈 **2. Async Request-Reply** (총점: 8.70) - Phase 1 MVP #### 🥈 **2. Async Request-Reply** (총점: 8.70)
**선정 이유**: **선정 이유**:
- **Content Generation 서비스의 5-8분 처리 시간 대응** - **Content Generation 서비스의 5-8분 처리 시간 대응**
- 이미지/영상 생성 백그라운드 처리 - 이미지/영상 생성 백그라운드 처리
- 진행 상황 실시간 피드백 (WebSocket/폴링) - 진행 상황 실시간 피드백 (폴링)
- 클라이언트 블로킹 방지 - 클라이언트 블로킹 방지
**적용 서비스**: Content Generation, AI Learning **적용 서비스**: Content Generation
**예상 효과**: **예상 효과**:
- 사용자 대기 시간 체감 80% 감소 - 사용자 대기 시간 체감 80% 감소
- 시스템 응답성 향상 - 시스템 응답성 향상
- 동시 콘텐츠 생성 50개 처리 가능 - 동시 콘텐츠 생성 50개 처리 가능
**구현 기술**:
- **Job ID 관리**: UUID v4 사용
- **상태 폴링**: 5초 간격, 최대 10분 타임아웃
- **상태 관리**: Redis 또는 DB 기반 Job 상태 추적
**구현 예시**: **구현 예시**:
```javascript ```javascript
// 클라이언트: 콘텐츠 생성 요청 // 클라이언트: 콘텐츠 생성 요청
@ -253,7 +255,7 @@ const checkStatus = setInterval(async () => {
--- ---
#### 🥉 **3. Circuit Breaker** (총점: 8.10) - Phase 1 MVP #### 🥉 **3. Circuit Breaker** (총점: 8.10)
**선정 이유**: **선정 이유**:
- **6개 외부 API 장애 대응 (KT 채널, AI API, SNS)** - **6개 외부 API 장애 대응 (KT 채널, AI API, SNS)**
@ -268,6 +270,12 @@ const checkStatus = setInterval(async () => {
- 시스템 가용성 99.9% 보장 - 시스템 가용성 99.9% 보장
- 배포 성공률 98% 이상 유지 - 배포 성공률 98% 이상 유지
**구현 기술**:
- **타임아웃 설정**: 외부 API별 차등 (15초 ~ 60초)
- **실패 임계값**: 50% 실패 시 OPEN
- **재시도 간격**: 30초 후 HALF-OPEN
- **폴백 전략**: 기본값 제공 또는 실패 메시지
**구현 예시** (Node.js with opossum): **구현 예시** (Node.js with opossum):
```javascript ```javascript
const CircuitBreaker = require('opossum'); const CircuitBreaker = require('opossum');
@ -283,162 +291,36 @@ const breaker = new CircuitBreaker(callWooridongneTV, {
resetTimeout: 30000 // 30초 후 재시도 resetTimeout: 30000 // 30초 후 재시도
}); });
breaker.fallback(() => ({ success: false, message: '우리동네TV 배포 실패' })); breaker.fallback(() => ({
success: false,
message: '우리동네TV 배포 실패'
}));
// 배포 요청 // 배포 요청
const result = await breaker.fire(deployData); const result = await breaker.fire(deployData);
``` ```
--- **Spring Boot 예시** (Resilience4j):
```java
@Service
public class DistributionService {
#### **4. Cache-Aside** (총점: 8.35) - Phase 1 MVP @CircuitBreaker(name = "wooridongneTV", fallbackMethod = "fallbackDeploy")
public DeployResult deployToWooridongneTV(DeployData data) {
return wooridongneAPI.deploy(data);
}
**선정 이유**: private DeployResult fallbackDeploy(DeployData data, Exception e) {
- Event Planning 서비스의 10초 응답 목표 달성 return DeployResult.builder()
- 트렌드 데이터베이스 조회 성능 향상 .success(false)
- AI API 응답 캐싱 (동일 조건 재사용) .message("우리동네TV 배포 실패: " + e.getMessage())
- Redis 활용 고속 캐싱 .build();
}
**적용 서비스**: Event Planning, Analytics }
**예상 효과**:
- 트렌드 분석 응답 시간 70% 단축 (3초 → 0.9초)
- AI API 호출 횟수 40% 감소
- 비용 절감 (AI API 사용량 감소)
**구현 예시**:
```javascript
// 트렌드 데이터 조회 (캐시 우선)
const getTrendData = async (industry, region) => {
const cacheKey = `trend:${industry}:${region}`;
// 1. 캐시 조회
let data = await redis.get(cacheKey);
if (data) {
return JSON.parse(data); // 캐시 히트
}
// 2. DB 조회
data = await db.query('SELECT * FROM trends WHERE industry = ? AND region = ?', [industry, region]);
// 3. 캐시 저장 (TTL: 1시간)
await redis.setex(cacheKey, 3600, JSON.stringify(data));
return data;
};
``` ```
--- ---
#### **5. CQRS** (총점: 7.90) - Phase 2 확장
**선정 이유**:
- **Analytics 서비스의 읽기/쓰기 분리**
- 실시간 대시보드 조회 성능 최적화
- 5분 간격 데이터 수집과 실시간 조회 분리
- 읽기 전용 DB로 복잡한 집계 쿼리 처리
**적용 서비스**: Analytics
**예상 효과**:
- 대시보드 조회 속도 80% 향상
- 쓰기 작업 영향 없이 읽기 확장 가능
- 복잡한 ROI 계산 성능 개선
**아키텍처**:
```mermaid
graph LR
Client[클라이언트] --> ReadAPI[읽기 API]
Client --> WriteAPI[쓰기 API]
WriteAPI --> CommandDB[(Command DB<br/>쓰기 전용)]
CommandDB --> EventBus[이벤트 버스]
EventBus --> ReadDB[(Query DB<br/>읽기 전용)]
ReadAPI --> ReadDB
```
---
#### **6. Event Sourcing** (총점: 7.30) - Phase 3 고도화
**선정 이유**:
- AI Learning 서비스의 학습 데이터 추적
- 이벤트 전체 이력 저장 및 재생
- 감사 추적 (Audit Trail) 요구사항 충족
- 성공/실패 패턴 분석 정확도 향상
**적용 서비스**: AI Learning, Participation
**예상 효과**:
- AI 학습 정확도 30% 향상
- 데이터 멱등성 100% 보장
- 과거 데이터 재분석 가능
---
#### **7. Queue-Based Load Leveling** (총점: 7.90) - Phase 2 확장
**선정 이유**:
- Distribution 서비스의 배포 요청 급증 대응
- 100개 동시 배포 요청 큐잉 처리
- 백엔드 서비스 부하 평준화
- 배포 실패 재시도 관리
**적용 서비스**: Distribution, Content Generation
**예상 효과**:
- 피크 타임 안정성 99.9% 유지
- 배포 성공률 98% 이상
- 시스템 과부하 방지
---
#### **8. Retry** (총점: 7.10) - Phase 1 MVP
**선정 이유**:
- Distribution 서비스의 배포 실패 자동 재시도 (3회)
- 외부 API 일시적 오류 복구
- Circuit Breaker와 조합 사용
**적용 서비스**: Distribution, Event Planning
**예상 효과**:
- 배포 성공률 15% 향상
- 일시적 네트워크 오류 자동 복구
---
#### **9. Publisher-Subscriber** (총점: 7.30) - Phase 2 확장
**선정 이유**:
- 이벤트 완료 시 다중 서비스 알림 (Analytics, AI Learning)
- 서비스 간 결합도 감소
- 비동기 이벤트 처리
**적용 서비스**: 전체 서비스 (이벤트 기반 통신)
**예상 효과**:
- 서비스 간 결합도 70% 감소
- 새로운 서비스 추가 용이성
---
#### **10. Choreography** (총점: 6.45) - Phase 3 고도화
**선정 이유**:
- Saga 패턴 대안으로 중앙 조정자 없는 워크플로
- Event Planning → Content Generation → Distribution 자율 조정
- 확장성 및 유연성 향상
**적용 서비스**: 이벤트 생성 워크플로
**예상 효과**:
- 워크플로 확장성 향상
- 중앙 병목 현상 제거
---
## 3. 서비스별 패턴 적용 설계 ## 3. 서비스별 패턴 적용 설계
### 3.1 전체 아키텍처 구조 ### 3.1 전체 아키텍처 구조
@ -456,12 +338,12 @@ graph TB
subgraph "마이크로서비스" subgraph "마이크로서비스"
User[User 서비스<br/>회원/매장 관리] User[User 서비스<br/>회원/매장 관리]
Planning[Event Planning 서비스<br/>AI 이벤트 기획<br/>Cache-Aside] Planning[Event Planning 서비스<br/>AI 이벤트 기획]
Content[Content Generation 서비스<br/>AI 콘텐츠 생성<br/>Async Request-Reply] Content[Content Generation 서비스<br/>AI 콘텐츠 생성<br/>Async Request-Reply]
Dist[Distribution 서비스<br/>다중 채널 배포<br/>Circuit Breaker + Retry] Dist[Distribution 서비스<br/>다중 채널 배포<br/>Circuit Breaker]
Participation[Participation 서비스<br/>참여/추첨 관리] Participation[Participation 서비스<br/>참여/추첨 관리]
Analytics[Analytics 서비스<br/>효과 측정<br/>CQRS] Analytics[Analytics 서비스<br/>효과 측정]
AILearn[AI Learning 서비스<br/>학습/개선<br/>Event Sourcing] AILearn[AI Learning 서비스<br/>학습/개선]
end end
subgraph "데이터 계층" subgraph "데이터 계층"
@ -470,19 +352,9 @@ graph TB
ContentDB[(Content DB<br/>MongoDB)] ContentDB[(Content DB<br/>MongoDB)]
DistDB[(Distribution DB<br/>PostgreSQL)] DistDB[(Distribution DB<br/>PostgreSQL)]
PartDB[(Participation DB<br/>PostgreSQL)] PartDB[(Participation DB<br/>PostgreSQL)]
AnalyticsDB[(Analytics DB<br/>MongoDB)]
subgraph "CQRS - Analytics" AILearnDB[(AI Learning DB<br/>MongoDB)]
WriteDB[(Command DB<br/>쓰기)] JobStore[(Job Store<br/>Redis)]
ReadDB[(Query DB<br/>읽기)]
end
EventStore[(Event Store<br/>AI Learning)]
Cache[(Redis Cache<br/>Cache-Aside)]
end
subgraph "메시지 큐"
Queue[RabbitMQ/Kafka<br/>Queue-Based Load Leveling<br/>Pub-Sub]
end end
subgraph "외부 시스템" subgraph "외부 시스템"
@ -506,29 +378,21 @@ graph TB
User --> UserDB User --> UserDB
Planning --> PlanningDB Planning --> PlanningDB
Planning --> Cache
Content --> ContentDB Content --> ContentDB
Content --> Queue Content --> JobStore
Dist --> DistDB Dist --> DistDB
Dist --> Queue
Participation --> PartDB Participation --> PartDB
Analytics --> WriteDB Analytics --> AnalyticsDB
Analytics --> ReadDB AILearn --> AILearnDB
WriteDB --> Queue
Queue --> ReadDB
AILearn --> EventStore
Planning -->|Circuit Breaker| AIAPI Planning -->|Circuit Breaker| AIAPI
Content -->|Circuit Breaker| AIAPI Content -->|Circuit Breaker| AIAPI
Dist -->|Circuit Breaker + Retry| KTAPI Dist -->|Circuit Breaker| KTAPI
Dist -->|Circuit Breaker + Retry| SNS Dist -->|Circuit Breaker| SNS
Dist -->|Circuit Breaker| Clova Dist -->|Circuit Breaker| Clova
Analytics --> KTAPI Analytics --> KTAPI
Analytics --> SNS Analytics --> SNS
Analytics --> POS Analytics --> POS
Queue -->|Pub-Sub| Analytics
Queue -->|Pub-Sub| AILearn
``` ```
--- ---
@ -536,7 +400,6 @@ graph TB
### 3.2 Event Planning 서비스 - 10초 응답 최적화 ### 3.2 Event Planning 서비스 - 10초 응답 최적화
**패턴 적용**: **패턴 적용**:
- **Cache-Aside**: 트렌드 데이터 캐싱
- **Circuit Breaker**: Claude + GPT-4 API 장애 대응 - **Circuit Breaker**: Claude + GPT-4 API 장애 대응
- **병렬 처리**: AI API 동시 호출 - **병렬 처리**: AI API 동시 호출
@ -546,7 +409,6 @@ sequenceDiagram
participant Client participant Client
participant Gateway participant Gateway
participant Planning as Event Planning participant Planning as Event Planning
participant Cache as Redis Cache
participant DB as Planning DB participant DB as Planning DB
participant Claude as Claude API participant Claude as Claude API
participant GPT4 as GPT-4 API participant GPT4 as GPT-4 API
@ -554,15 +416,9 @@ sequenceDiagram
Client->>Gateway: 이벤트 기획 시작 Client->>Gateway: 이벤트 기획 시작
Gateway->>Planning: 기획 요청 Gateway->>Planning: 기획 요청
Note over Planning,Cache: Phase 1: 트렌드 분석 (3초 목표) Note over Planning,DB: Phase 1: 트렌드 분석 (3초 목표)
Planning->>Cache: 트렌드 데이터 조회 Planning->>DB: 트렌드 데이터 조회
alt 캐시 히트 DB-->>Planning: 트렌드 데이터
Cache-->>Planning: 캐시 데이터 반환
else 캐시 미스
Planning->>DB: DB 조회
DB-->>Planning: 트렌드 데이터
Planning->>Cache: 캐시 저장 (TTL: 1시간)
end
Note over Planning,GPT4: Phase 2: AI 병렬 호출 (7초 목표) Note over Planning,GPT4: Phase 2: AI 병렬 호출 (7초 목표)
par Claude: 이벤트상품 + 참여방법 par Claude: 이벤트상품 + 참여방법
@ -580,7 +436,6 @@ sequenceDiagram
**예상 성과**: **예상 성과**:
- **총 응답시간: 10초 이내** (목표 달성) - **총 응답시간: 10초 이내** (목표 달성)
- 트렌드 분석: 3초 → 0.9초 (캐시 히트 시)
- AI API 병렬 호출: 9초 → 5초 - AI API 병렬 호출: 9초 → 5초
--- ---
@ -589,7 +444,6 @@ sequenceDiagram
**패턴 적용**: **패턴 적용**:
- **Async Request-Reply**: 5-8분 장시간 처리 - **Async Request-Reply**: 5-8분 장시간 처리
- **Queue-Based Load Leveling**: 동시 50개 콘텐츠 생성
- **Circuit Breaker**: Stable Diffusion API 장애 대응 - **Circuit Breaker**: Stable Diffusion API 장애 대응
**아키텍처**: **아키텍처**:
@ -598,7 +452,7 @@ sequenceDiagram
participant Client participant Client
participant Gateway participant Gateway
participant Content as Content Generation participant Content as Content Generation
participant Queue as RabbitMQ participant JobStore as Job Store (Redis)
participant Worker as Background Worker participant Worker as Background Worker
participant SD as Stable Diffusion participant SD as Stable Diffusion
participant VideoAI as AI Video Engine participant VideoAI as AI Video Engine
@ -606,14 +460,13 @@ sequenceDiagram
Client->>Gateway: 콘텐츠 생성 요청 Client->>Gateway: 콘텐츠 생성 요청
Gateway->>Content: 생성 요청 Gateway->>Content: 생성 요청
Content->>DB: Job 생성 (상태: PENDING) Content->>JobStore: Job 생성 (상태: PENDING)
Content->>Queue: 작업 큐잉
Content-->>Gateway: Job ID 발급 Content-->>Gateway: Job ID 발급
Gateway-->>Client: Job ID 반환 Gateway-->>Client: Job ID 반환
Note over Client: 클라이언트는 다른 작업 가능 Note over Client: 클라이언트는 다른 작업 가능
Queue->>Worker: 작업 할당 Content->>Worker: 비동기 작업 시작
par 이미지 3종 생성 (2-3분) par 이미지 3종 생성 (2-3분)
Worker->>SD: 이미지 생성 요청 (3건 병렬) Worker->>SD: 이미지 생성 요청 (3건 병렬)
@ -623,13 +476,14 @@ sequenceDiagram
VideoAI-->>Worker: 15초 영상 VideoAI-->>Worker: 15초 영상
end end
Worker->>DB: 콘텐츠 저장 + 상태 업데이트 (COMPLETED) Worker->>DB: 콘텐츠 저장
Worker->>JobStore: 상태 업데이트 (COMPLETED)
loop 상태 확인 (5초 간격) loop 상태 확인 (5초 간격)
Client->>Gateway: Job 상태 조회 Client->>Gateway: Job 상태 조회
Gateway->>Content: 상태 조회 Gateway->>Content: 상태 조회
Content->>DB: 상태 확인 Content->>JobStore: 상태 확인
DB-->>Content: 상태 + 진행률 JobStore-->>Content: 상태 + 진행률
Content-->>Gateway: 진행 상황 (예: 60% 완료) Content-->>Gateway: 진행 상황 (예: 60% 완료)
Gateway-->>Client: 진행률 표시 Gateway-->>Client: 진행률 표시
end end
@ -651,8 +505,7 @@ sequenceDiagram
**패턴 적용**: **패턴 적용**:
- **Circuit Breaker**: 6개 외부 API 장애 대응 - **Circuit Breaker**: 6개 외부 API 장애 대응
- **Retry**: 배포 실패 자동 재시도 (3회) - **병렬 배포**: 6개 채널 동시 배포
- **Queue-Based Load Leveling**: 100개 동시 배포
**아키텍처**: **아키텍처**:
```mermaid ```mermaid
@ -660,7 +513,6 @@ sequenceDiagram
participant Client participant Client
participant Gateway participant Gateway
participant Dist as Distribution participant Dist as Distribution
participant Queue as RabbitMQ
participant CB1 as Circuit Breaker<br/>(우리동네TV) participant CB1 as Circuit Breaker<br/>(우리동네TV)
participant CB2 as Circuit Breaker<br/>(지니TV) participant CB2 as Circuit Breaker<br/>(지니TV)
participant CB3 as Circuit Breaker<br/>(Instagram) participant CB3 as Circuit Breaker<br/>(Instagram)
@ -669,31 +521,24 @@ sequenceDiagram
Client->>Gateway: 배포 요청 (6개 채널) Client->>Gateway: 배포 요청 (6개 채널)
Gateway->>Dist: 배포 시작 Gateway->>Dist: 배포 시작
Dist->>Queue: 배포 작업 큐잉
par 병렬 배포 (1분 목표) par 병렬 배포 (1분 목표)
Queue->>CB1: 우리동네TV 배포 Dist->>CB1: 우리동네TV 배포
CB1->>KTAPI: API 호출 CB1->>KTAPI: API 호출
alt API 성공 alt API 성공
KTAPI-->>CB1: 배포 완료 KTAPI-->>CB1: 배포 완료
else API 실패 else API 실패
KTAPI--xCB1: 오류 KTAPI--xCB1: 오류
CB1->>CB1: Retry (최대 3회) CB1-->>Dist: Fallback (배포 실패)
alt Retry 성공
CB1->>KTAPI: 재시도
KTAPI-->>CB1: 배포 완료
else Retry 실패
CB1-->>Queue: 배포 실패 (OPEN 상태)
end
end end
CB1-->>Dist: 결과 반환 CB1-->>Dist: 결과 반환
and and
Queue->>CB2: 지니TV 배포 Dist->>CB2: 지니TV 배포
CB2->>KTAPI: API 호출 CB2->>KTAPI: API 호출
KTAPI-->>CB2: 배포 완료 KTAPI-->>CB2: 배포 완료
CB2-->>Dist: 결과 반환 CB2-->>Dist: 결과 반환
and and
Queue->>CB3: Instagram 배포 Dist->>CB3: Instagram 배포
CB3->>SNS: API 호출 CB3->>SNS: API 호출
SNS-->>CB3: 포스팅 완료 SNS-->>CB3: 포스팅 완료
CB3-->>Dist: 결과 반환 CB3-->>Dist: 결과 반환
@ -705,63 +550,12 @@ sequenceDiagram
**예상 성과**: **예상 성과**:
- **총 배포시간: 1분 이내** (목표 달성) - **총 배포시간: 1분 이내** (목표 달성)
- 배포 성공률: 95% → 98% (Retry)
- API 장애 시 응답: 30초 → 3초 (Circuit Breaker) - API 장애 시 응답: 30초 → 3초 (Circuit Breaker)
- 배포 안정성: 95% → 98%
--- ---
### 3.5 Analytics 서비스 - CQRS 읽기/쓰기 분리 ## 4. 구현 로드맵
**패턴 적용**:
- **CQRS**: 읽기/쓰기 분리
- **Publisher-Subscriber**: 5분 간격 데이터 수집
**아키텍처**:
```mermaid
graph TB
subgraph "쓰기 모델"
Collector[데이터 수집기<br/>5분 스케줄러]
WriteAPI[쓰기 API]
CommandDB[(Command DB<br/>원본 데이터)]
end
subgraph "이벤트 버스"
EventBus[RabbitMQ<br/>Pub-Sub]
end
subgraph "읽기 모델"
ReadAPI[읽기 API<br/>대시보드]
QueryDB[(Query DB<br/>집계 데이터)]
Aggregator[집계 프로세서]
end
subgraph "외부 데이터 소스"
KTAPI[KT API]
SNS[SNS API]
POS[POS]
end
Collector -->|5분마다| KTAPI
Collector -->|5분마다| SNS
Collector -->|5분마다| POS
Collector --> WriteAPI
WriteAPI --> CommandDB
CommandDB --> EventBus
EventBus --> Aggregator
Aggregator -->|ROI 계산<br/>채널별 집계| QueryDB
ReadAPI --> QueryDB
Client[클라이언트<br/>대시보드] -->|실시간 조회| ReadAPI
```
**예상 성과**:
- 대시보드 조회 속도: 5초 → 1초 (80% 향상)
- ROI 계산 응답: 10초 → 2초
- 동시 조회 처리: 100개 대시보드
---
## 4. Phase별 구현 로드맵
### Phase 1: MVP (Minimum Viable Product) - 3개월 ### Phase 1: MVP (Minimum Viable Product) - 3개월
@ -771,27 +565,27 @@ graph TB
1. **API Gateway** - 단일 진입점 및 인증/인가 1. **API Gateway** - 단일 진입점 및 인증/인가
2. **Async Request-Reply** - 콘텐츠 생성 비동기 처리 2. **Async Request-Reply** - 콘텐츠 생성 비동기 처리
3. **Circuit Breaker** - 외부 API 장애 대응 3. **Circuit Breaker** - 외부 API 장애 대응
4. **Cache-Aside** - 트렌드 데이터 캐싱
5. **Retry** - 배포 실패 자동 재시도
**구현 우선순위**: **구현 우선순위**:
1. **Week 1-4**: User 서비스 + API Gateway 1. **Week 1-4**: User 서비스 + API Gateway
- 회원가입/로그인 (JWT 인증) - 회원가입/로그인 (JWT 인증)
- 매장 정보 관리 - 매장 정보 관리
- 사업자번호 검증 연동 - 사업자번호 검증 연동
- API Gateway 구축 (Kong 또는 Spring Cloud Gateway)
2. **Week 5-8**: Event Planning 서비스 2. **Week 5-8**: Event Planning 서비스
- AI API 연동 (Claude, GPT-4) - AI API 연동 (Claude, GPT-4)
- Cache-Aside 패턴 적용 (Redis)
- Circuit Breaker 적용 - Circuit Breaker 적용
- AI API 병렬 호출 구현
3. **Week 9-10**: Content Generation 서비스 3. **Week 9-10**: Content Generation 서비스
- Async Request-Reply 패턴 구현 - Async Request-Reply 패턴 구현
- Stable Diffusion 연동 - Stable Diffusion 연동
- 진행 상황 폴링 API - 진행 상황 폴링 API
- Redis 기반 Job Store 구축
4. **Week 11-12**: Distribution + Participation 서비스 4. **Week 11-12**: Distribution + Participation 서비스
- 6개 채널 병렬 배포 (Circuit Breaker + Retry) - 6개 채널 병렬 배포 (Circuit Breaker)
- 추첨/선착순 분기 로직 - 추첨/선착순 분기 로직
**성공 지표**: **성공 지표**:
@ -802,185 +596,68 @@ graph TB
--- ---
### Phase 2: 확장 (Scale-up) - 3개월
**목표**: 성능 최적화 및 사용자 증가 대응
**추가 패턴**:
6. **CQRS** - Analytics 읽기/쓰기 분리
7. **Queue-Based Load Leveling** - 피크 타임 부하 평준화
8. **Publisher-Subscriber** - 서비스 간 이벤트 기반 통신
**구현 계획**:
1. **Week 1-4**: Analytics 서비스 CQRS 적용
- Command DB / Query DB 분리
- 5분 간격 데이터 수집 스케줄러
- 실시간 대시보드 최적화
2. **Week 5-8**: 메시지 큐 도입 (RabbitMQ/Kafka)
- Queue-Based Load Leveling 적용
- Publisher-Subscriber 패턴 구현
- 서비스 간 결합도 감소
3. **Week 9-12**: 성능 모니터링 및 최적화
- Auto Scaling 설정
- 로드 밸런싱 최적화
- 캐시 전략 개선
**성공 지표**:
- 동시 이벤트 처리: 100개 ✅
- 대시보드 조회 속도: 1초 이내 ✅
- 시스템 가용성: 99.9% ✅
---
### Phase 3: 고도화 (Advanced) - 6개월
**목표**: AI 학습 고도화 및 글로벌 확장
**추가 패턴**:
9. **Event Sourcing** - AI Learning 학습 데이터 추적
10. **Choreography** - 워크플로 자율 조정
**구현 계획**:
1. **Week 1-8**: AI Learning 서비스 고도화
- Event Sourcing 패턴 적용
- 성공/실패 패턴 학습 고도화
- 추천 정확도 30% 향상
2. **Week 9-16**: Choreography 패턴 적용
- Event Planning → Content → Distribution 자율 조정
- 중앙 조정자 제거
- 워크플로 확장성 향상
3. **Week 17-24**: 글로벌 확장 대비
- Geodes 패턴 (다중 지역 배포)
- Federated Identity (글로벌 인증)
**성공 지표**:
- AI 추천 정확도: 30% 향상 ✅
- 워크플로 확장성: 무제한 ✅
- 글로벌 지연 시간: 100ms 이내 ✅
---
## 5. 예상 성과 지표 ## 5. 예상 성과 지표
### 5.1 성능 개선 ### 5.1 성능 개선
| 지표 | 현재 (패턴 미적용) | Phase 1 MVP | Phase 2 확장 | Phase 3 고도화 | | 지표 | 현재 (패턴 미적용) | Phase 1 MVP |
|------|-------------------|-------------|-------------|---------------| |------|-------------------|-------------|
| **Event Planning 응답시간** | 25초 | **10초** ✅ | 8초 | 6초 | | **Event Planning 응답시간** | 25초 | **10초** ✅ |
| **Content Generation 완료시간** | 12분 | **8분** ✅ | 6분 | 5분 | | **Content Generation 완료시간** | 12분 | **8분** ✅ |
| **Distribution 배포시간** | 3분 | **1분** ✅ | 40초 | 30초 | | **Distribution 배포시간** | 3분 | **1분** ✅ |
| **Analytics 대시보드 조회** | 5초 | 3초 | **1초** ✅ | 0.5초 | | **동시 이벤트 처리** | 20개 | 50개 |
| **동시 이벤트 처리** | 20개 | 50개 | **100개** ✅ | 300개 | | **시스템 가용성** | 95% | 99% |
| **시스템 가용성** | 95% | 99% | **99.9%** ✅ | 99.99% |
--- ---
### 5.2 비용 절감 효과 ### 5.2 패턴별 기대 효과
| 항목 | 절감율 | 연간 절감액 (추정) | | 패턴 | 적용 효과 | 개선율 |
|------|--------|-------------------| |------|----------|--------|
| **AI API 호출 비용** (Cache-Aside) | 40% | ₩24,000,000 | | **API Gateway** | 클라이언트 통합 엔드포인트, 인증 중앙화 | 인증 처리 50% 단축 |
| **외부 API 재시도 비용** (Circuit Breaker) | 30% | ₩9,000,000 | | **Async Request-Reply** | 사용자 대기 시간 체감 감소 | 80% 체감 시간 감소 |
| **서버 리소스 비용** (CQRS, 캐싱) | 25% | ₩15,000,000 | | **Circuit Breaker** | API 장애 시 빠른 실패, 연쇄 장애 방지 | 응답 시간 95% 단축 |
| **운영 인력 비용** (자동화) | 20% | ₩12,000,000 |
| **총 절감액** | - | **₩60,000,000** |
--- ---
### 5.3 개발 생산성 향상 ## 6. 리스크 관리
| 지표 | 개선율 | ### 6.1 기술적 리스크
|------|--------|
| **서비스 간 결합도 감소** (Pub-Sub) | 70% |
| **장애 복구 시간** (Circuit Breaker) | 80% |
| **새 기능 개발 속도** (패턴 재사용) | 50% |
| **코드 재사용률** (Gateway, Sidecar) | 60% |
---
## 6. 구현 시 고려사항
### 6.1 API Gateway
- **기술 스택**: Kong, AWS API Gateway, Azure API Management
- **Rate Limiting**: 사용자당 1분 100 요청
- **JWT 토큰**: 만료 시간 1시간, Refresh Token 7일
- **로깅**: 모든 요청/응답 로그 저장 (CloudWatch, ELK)
### 6.2 Async Request-Reply
- **Job ID 관리**: UUID v4 사용
- **상태 폴링**: 5초 간격, 최대 10분 타임아웃
- **WebSocket 대안**: 실시간 진행 상황 푸시 (선택사항)
### 6.3 Circuit Breaker
- **타임아웃 설정**: 외부 API별 차등 (15초 ~ 60초)
- **실패 임계값**: 50% 실패 시 OPEN
- **재시도 간격**: 30초 후 HALF-OPEN
- **폴백 전략**: 캐시 데이터 반환 또는 기본값 제공
### 6.4 Cache-Aside
- **캐시 TTL**: 트렌드 데이터 1시간, AI 응답 30분
- **캐시 무효화**: 데이터 업데이트 시 자동 삭제
- **Redis Cluster**: 고가용성 보장
### 6.5 CQRS
- **DB 선택**: Command (PostgreSQL), Query (MongoDB)
- **동기화 지연**: 최대 5초
- **이벤트 버스**: RabbitMQ 또는 Kafka
---
## 7. 리스크 관리
### 7.1 기술적 리스크
| 리스크 | 확률 | 영향도 | 완화 전략 | | 리스크 | 확률 | 영향도 | 완화 전략 |
|--------|------|--------|-----------| |--------|------|--------|-----------|
| AI API 응답 지연 (>10초) | 중간 | 높음 | Cache-Aside, 프롬프트 최적화, 병렬 호출 | | AI API 응답 지연 (>10초) | 중간 | 높음 | 병렬 호출, 프롬프트 최적화 |
| 외부 API 장애 | 높음 | 높음 | Circuit Breaker, Retry, 폴백 전략 | | 외부 API 장애 | 높음 | 높음 | Circuit Breaker, 폴백 전략 |
| Redis 장애 | 낮음 | 중간 | Redis Cluster, DB 폴백 | | Job Store (Redis) 장애 | 낮음 | 중간 | Redis Cluster, DB 폴백 |
| 메시지 큐 장애 | 낮음 | 높음 | Dead Letter Queue, 재처리 로직 |
### 7.2 운영 리스크 ### 6.2 운영 리스크
| 리스크 | 확률 | 영향도 | 완화 전략 | | 리스크 | 확률 | 영향도 | 완화 전략 |
|--------|------|--------|-----------| |--------|------|--------|-----------|
| 피크 타임 트래픽 폭주 | 높음 | 높음 | Auto Scaling, Queue-Based Load Leveling | | 피크 타임 트래픽 폭주 | 높음 | 높음 | Auto Scaling, Rate Limiting |
| 데이터 불일치 (CQRS) | 중간 | 중간 | 이벤트 재생, 수동 동기화 도구 | | 배포 실패율 증가 | 중간 | 중간 | Circuit Breaker 폴백 전략 |
| 배포 실패율 증가 | 중간 | 중간 | Retry 3회, 수동 배포 옵션 |
--- ---
## 8. 결론 ## 7. 결론
### 8.1 핵심 패턴 요약 ### 7.1 핵심 패턴 요약
본 서비스는 **10개의 클라우드 아키텍처 패턴**을 3단계로 적용하여 성능, 확장성, 안정성을 보장합니다: 본 서비스는 **3개의 클라우드 아키텍처 패턴**을 적용하여 성능, 확장성, 안정성을 보장합니다:
1. **API Gateway**: 단일 진입점 및 횡단 관심사 분리 1. **API Gateway**: 단일 진입점 및 횡단 관심사 분리
2. **Async Request-Reply**: 장시간 처리 작업 비동기화 2. **Async Request-Reply**: 장시간 처리 작업 비동기화
3. **Circuit Breaker**: 외부 API 장애 대응 3. **Circuit Breaker**: 외부 API 장애 대응
4. **Cache-Aside**: 응답 시간 단축
5. **CQRS**: 읽기/쓰기 분리로 조회 성능 최적화
6. **Event Sourcing**: AI 학습 데이터 추적
7. **Queue-Based Load Leveling**: 부하 평준화
8. **Retry**: 일시적 오류 자동 복구
9. **Publisher-Subscriber**: 서비스 간 결합도 감소
10. **Choreography**: 워크플로 자율 조정
### 8.2 예상 효과 ### 7.2 예상 효과
- **Event Planning**: 25초 → **10초** (60% 단축) ✅ - **Event Planning**: 25초 → **10초** (60% 단축) ✅
- **Content Generation**: 12분 → **8분** (33% 단축) ✅ - **Content Generation**: 12분 → **8분** (33% 단축) ✅
- **Distribution**: 3분 → **1분** (67% 단축) ✅ - **Distribution**: 3분 → **1분** (67% 단축) ✅
- **시스템 가용성**: 95% → **99.9%** ✅ - **시스템 가용성**: 95% → **99%** ✅
- **동시 이벤트 처리**: 20개 → **100개** (5배 향상) ✅ - **동시 이벤트 처리**: 20개 → **50개** (2.5배 향상) ✅
- **연간 비용 절감**: **₩60,000,000** 💰
### 8.3 다음 단계 ### 7.3 다음 단계
1. **Phase 1 MVP 착수** (3개월) 1. **Phase 1 MVP 착수** (3개월)
- API Gateway + Async Request-Reply + Circuit Breaker 우선 구현 - API Gateway + Async Request-Reply + Circuit Breaker 우선 구현
@ -991,8 +668,8 @@ graph TB
- 각 패턴별 성과 지표 측정 - 각 패턴별 성과 지표 측정
3. **지속적 개선** 3. **지속적 개선**
- Phase 2, 3 로드맵에 따라 점진적 고도화 - 추가 패턴 도입 검토 (Cache-Aside, CQRS 등)
- AI 학습 정확도 향상 및 글로벌 확장 - AI 학습 정확도 향상
--- ---
@ -1005,4 +682,4 @@ graph TB
**참조 문서**: **참조 문서**:
- design/userstory.md - design/userstory.md
- claude/cloud-design-patterns.md - claude/cloud-design-patterns.md
- claude/architecture-patterns.md - design/pattern/architecture-pattern-backup-20251021.md (백업)