diff --git a/design/pattern/architecture-pattern-backup-20251021.md b/design/pattern/architecture-pattern-backup-20251021.md new file mode 100644 index 0000000..36e0593 --- /dev/null +++ b/design/pattern/architecture-pattern-backup-20251021.md @@ -0,0 +1,1008 @@ +# KT AI 기반 소상공인 이벤트 자동 생성 서비스 - 클라우드 아키텍처 패턴 선정서 + +**작성일**: 2025-10-21 +**작성자**: System Architect (박영자) +**버전**: 1.0 + +--- + +## 1. 요구사항 분석 + +### 1.1 마이크로서비스별 기능 및 비기능 요구사항 + +#### 1.1.1 User 서비스 +**기능 요구사항**: +- 회원가입/로그인 (JWT 인증) +- 매장 정보 관리 및 사업자번호 검증 +- KT 인증 시스템 연동 + +**비기능 요구사항**: +- 응답시간: 1초 이내 +- 가용성: 99.9% +- 보안: 개인정보 암호화 (AES-256), HTTPS/TLS +- 확장성: 1,000 동시 사용자 + +**기술적 도전과제**: +- 외부 사업자번호 검증 API 의존성 +- 인증 토큰 관리 및 세션 유지 +- 개인정보 보호 규정 준수 + +--- + +#### 1.1.2 Event Planning 서비스 +**기능 요구사항**: +- AI 기반 업종/지역 트렌드 분석 +- AI 이벤트상품 추천 (Claude API) +- AI 참여 방법 설계 +- AI 홍보 문구 생성 (GPT-4 API) + +**비기능 요구사항**: +- **응답시간: 10초 이내 (전체 기획 과정)** ⚡ +- AI API 병렬 호출 필수 +- 추첨형/선착순형 이벤트 자동 프로세스 분기 +- 확장성: 100개 동시 이벤트 기획 + +**기술적 도전과제**: +- **Claude + GPT-4 API 병렬 호출 및 응답 시간 관리** +- AI 프롬프트 최적화로 10초 목표 달성 +- 트렌드 데이터베이스 실시간 조회 성능 +- 응답 캐싱 전략 + +--- + +#### 1.1.3 Content Generation 서비스 +**기능 요구사항**: +- AI 이미지 생성 (Stable Diffusion, 3종) +- AI 영상 제작 (15초) +- SNS 콘텐츠 자동 생성 (플랫폼별 최적화) +- QR 포스터 생성 + +**비기능 요구사항**: +- **응답시간: 5-8분 이내 (병렬 처리 시)** ⚡ +- 이미지 생성: 2-3분 (Stable Diffusion 특성) +- 영상 제작: 3-5분 (AI 영상 엔진 특성) +- GPU 가속 활용 +- 확장성: 50개 동시 콘텐츠 생성 + +**기술적 도전과제**: +- **이미지 3종 + 영상 1개 병렬 생성** +- 진행 상황 실시간 피드백 +- 백그라운드 비동기 처리 필수 +- 품질과 속도 균형 유지 + +--- + +#### 1.1.4 Distribution 서비스 +**기능 요구사항**: +- 다중 채널 배포 (우리동네TV, 링고비즈, 지니TV, Instagram, Naver Blog, Kakao Channel) +- 네이버 클로바 TTS 연동 (연결음 생성) +- 배포 실패 시 자동 재시도 (3회) + +**비기능 요구사항**: +- **응답시간: 1분 이내 (전체 배포 과정)** ⚡ +- 채널별 병렬 배포 필수 +- 배포 상태 실시간 업데이트 +- 확장성: 100개 동시 배포 + +**기술적 도전과제**: +- **6개 외부 API 병렬 호출 및 통합** +- API 장애 대응 (Circuit Breaker, Retry) +- 네이버 클로바 TTS 품질 보장 +- 배포 실패 복구 전략 + +--- + +#### 1.1.5 Participation 서비스 +**기능 요구사항**: +- 이벤트 참여 신청 및 중복 방지 +- 추첨형 자동 추첨 (매장 방문 고객 가산점) +- 선착순형 쿠폰 소진 시 자동 종료 +- 당첨 알림 발송 (SMS/카카오 알림톡) + +**비기능 요구사항**: +- 응답시간: 1초 이내 +- 1인 1회 참여 보장 (멱등성) +- 공정한 추첨 알고리즘 +- 확장성: 10,000 동시 참여 + +**기술적 도전과제**: +- 중복 참여 방지 (전화번호 기준) +- 추첨형/선착순형 프로세스 분기 +- 대량 SMS/알림톡 발송 +- 매장 방문 고객 가산점 처리 + +--- + +#### 1.1.6 Analytics 서비스 +**기능 요구사항**: +- 실시간 대시보드 (참여자 수, 노출 수, 매출 증가율) +- 5분 간격 데이터 수집 및 업데이트 +- 채널별 성과 분석 (Instagram, Naver Blog, Kakao Channel API) +- ROI 자동 계산 +- 분석 리포트 PDF 생성 + +**비기능 요구사항**: +- **데이터 수집 주기: 5분 간격** ⏱ +- 실시간 데이터 시각화 +- 확장성: 100개 이벤트 동시 분석 + +**기술적 도전과제**: +- **다중 데이터 소스 통합 (KT API, POS, SNS API)** +- CQRS 패턴으로 읽기/쓰기 분리 +- 5분 간격 스케줄러 기반 수집 +- 대시보드 실시간 업데이트 + +--- + +#### 1.1.7 AI Learning 서비스 +**기능 요구사항**: +- 이벤트 결과 분석 및 개선안 생성 +- 성공 패턴 학습 및 재활용 +- 다음 이벤트 아이디어 제안 (시즌별) + +**비기능 요구사항**: +- 빅데이터 분석 시스템 연동 +- AI 머신러닝 엔진 API 호출 +- 학습 데이터 누적 및 모델 개선 +- 확장성: 누적 데이터 기반 지속적 학습 + +**기술적 도전과제**: +- 성공/실패 패턴 자동 학습 +- 업종별/지역별 데이터 축적 +- 추천 정확도 향상 알고리즘 +- Event Sourcing으로 학습 데이터 추적 + +--- + +### 1.2 통합 분석 및 핵심 도전과제 + +#### 성능 목표 요약 +| 서비스 | 목표 응답시간 | 핵심 최적화 전략 | +|--------|--------------|------------------| +| Event Planning | **10초 이내** | AI API 병렬 호출, 응답 캐싱 | +| Content Generation | **5-8분 이내** | 이미지+영상 병렬 생성, 비동기 처리 | +| Distribution | **1분 이내** | 6개 채널 병렬 배포 | +| Analytics | **5분 주기** | CQRS 읽기/쓰기 분리, 스케줄러 수집 | + +#### 확장성 요구사항 +- **동시 이벤트 처리**: 최소 100개 +- **AI API 동시 호출**: 최소 50개 +- **배포 API 동시 호출**: 최소 100개 + +#### 외부 시스템 의존성 +- **KT 채널**: 우리동네TV, 링고비즈, 지니TV +- **AI API**: Claude, GPT-4, Stable Diffusion +- **SNS**: Instagram, Naver Blog, Kakao Channel +- **기타**: 네이버 클로바 TTS, 사업자번호 검증, POS 시스템 + +--- + +## 2. 클라우드 아키텍처 패턴 선정 + +### 2.1 패턴 평가 매트릭스 + +#### 핵심 패턴 Top 10 정량 평가 + +| 패턴 | 기능 적합성
(35%) | 성능 효과
(25%) | 운영 복잡도
(20%) | 확장성
(15%) | 비용 효율성
(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위 | +| **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위 | +| **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 선정 패턴 및 적용 전략 + +#### 🥇 **1. API Gateway** (총점: 9.30) - Phase 1 MVP + +**선정 이유**: +- 단일 진입점으로 7개 마이크로서비스 라우팅 +- 인증/인가 중앙 처리 (JWT 토큰 검증) +- Rate Limiting으로 100개 동시 이벤트 관리 +- 횡단 관심사 분리 (로깅, 모니터링) + +**적용 서비스**: 전체 서비스 + +**예상 효과**: +- 클라이언트 요청 단순화 (1개 엔드포인트) +- 인증 처리 시간 50% 단축 +- 서비스 간 결합도 감소 + +--- + +#### 🥈 **2. Async Request-Reply** (총점: 8.70) - Phase 1 MVP + +**선정 이유**: +- **Content Generation 서비스의 5-8분 처리 시간 대응** +- 이미지/영상 생성 백그라운드 처리 +- 진행 상황 실시간 피드백 (WebSocket/폴링) +- 클라이언트 블로킹 방지 + +**적용 서비스**: Content Generation, AI Learning + +**예상 효과**: +- 사용자 대기 시간 체감 80% 감소 +- 시스템 응답성 향상 +- 동시 콘텐츠 생성 50개 처리 가능 + +**구현 예시**: +```javascript +// 클라이언트: 콘텐츠 생성 요청 +const response = await axios.post('/api/content/generate', { + eventId: 'evt-001', + imageCount: 3 +}); +const jobId = response.data.jobId; // Job ID 발급 + +// 상태 폴링 (5초 간격) +const checkStatus = setInterval(async () => { + const status = await axios.get(`/api/content/status/${jobId}`); + if (status.data.completed) { + clearInterval(checkStatus); + // 콘텐츠 다운로드 + } +}, 5000); +``` + +--- + +#### 🥉 **3. Circuit Breaker** (총점: 8.10) - Phase 1 MVP + +**선정 이유**: +- **6개 외부 API 장애 대응 (KT 채널, AI API, SNS)** +- Distribution 서비스의 배포 실패 방지 +- API 장애 시 빠른 실패 및 폴백 +- 연쇄 장애 전파 차단 + +**적용 서비스**: Distribution, Event Planning, Content Generation + +**예상 효과**: +- API 장애 시 응답 시간 95% 단축 +- 시스템 가용성 99.9% 보장 +- 배포 성공률 98% 이상 유지 + +**구현 예시** (Node.js with opossum): +```javascript +const CircuitBreaker = require('opossum'); + +// 우리동네TV API 호출 +const callWooridongneTV = async (data) => { + return axios.post('https://api.wooridongne.kt.com/deploy', data); +}; + +const breaker = new CircuitBreaker(callWooridongneTV, { + timeout: 15000, // 15초 타임아웃 + errorThresholdPercentage: 50, // 50% 실패 시 OPEN + resetTimeout: 30000 // 30초 후 재시도 +}); + +breaker.fallback(() => ({ success: false, message: '우리동네TV 배포 실패' })); + +// 배포 요청 +const result = await breaker.fire(deployData); +``` + +--- + +#### **4. Cache-Aside** (총점: 8.35) - Phase 1 MVP + +**선정 이유**: +- Event Planning 서비스의 10초 응답 목표 달성 +- 트렌드 데이터베이스 조회 성능 향상 +- AI API 응답 캐싱 (동일 조건 재사용) +- Redis 활용 고속 캐싱 + +**적용 서비스**: 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
쓰기 전용)] + CommandDB --> EventBus[이벤트 버스] + EventBus --> ReadDB[(Query DB
읽기 전용)] + 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.1 전체 아키텍처 구조 + +```mermaid +graph TB + subgraph "클라이언트" + Web[웹 애플리케이션] + Mobile[모바일 앱] + end + + subgraph "API Gateway Layer" + Gateway[API Gateway
인증/인가/라우팅/Rate Limiting] + end + + subgraph "마이크로서비스" + User[User 서비스
회원/매장 관리] + Planning[Event Planning 서비스
AI 이벤트 기획
Cache-Aside] + Content[Content Generation 서비스
AI 콘텐츠 생성
Async Request-Reply] + Dist[Distribution 서비스
다중 채널 배포
Circuit Breaker + Retry] + Participation[Participation 서비스
참여/추첨 관리] + Analytics[Analytics 서비스
효과 측정
CQRS] + AILearn[AI Learning 서비스
학습/개선
Event Sourcing] + end + + subgraph "데이터 계층" + UserDB[(User DB
PostgreSQL)] + PlanningDB[(Planning DB
MongoDB)] + ContentDB[(Content DB
MongoDB)] + DistDB[(Distribution DB
PostgreSQL)] + PartDB[(Participation DB
PostgreSQL)] + + subgraph "CQRS - Analytics" + WriteDB[(Command DB
쓰기)] + ReadDB[(Query DB
읽기)] + end + + EventStore[(Event Store
AI Learning)] + + Cache[(Redis Cache
Cache-Aside)] + end + + subgraph "메시지 큐" + Queue[RabbitMQ/Kafka
Queue-Based Load Leveling
Pub-Sub] + end + + subgraph "외부 시스템" + KTAPI[KT 채널 API
우리동네TV/링고비즈/지니TV] + AIAPI[AI API
Claude/GPT-4/Stable Diffusion] + SNS[SNS API
Instagram/Naver/Kakao] + Clova[네이버 클로바 TTS] + POS[POS 시스템] + end + + Web --> Gateway + Mobile --> Gateway + + Gateway --> User + Gateway --> Planning + Gateway --> Content + Gateway --> Dist + Gateway --> Participation + Gateway --> Analytics + Gateway --> AILearn + + User --> UserDB + Planning --> PlanningDB + Planning --> Cache + Content --> ContentDB + Content --> Queue + Dist --> DistDB + Dist --> Queue + Participation --> PartDB + Analytics --> WriteDB + Analytics --> ReadDB + WriteDB --> Queue + Queue --> ReadDB + AILearn --> EventStore + + Planning -->|Circuit Breaker| AIAPI + Content -->|Circuit Breaker| AIAPI + Dist -->|Circuit Breaker + Retry| KTAPI + Dist -->|Circuit Breaker + Retry| SNS + Dist -->|Circuit Breaker| Clova + Analytics --> KTAPI + Analytics --> SNS + Analytics --> POS + + Queue -->|Pub-Sub| Analytics + Queue -->|Pub-Sub| AILearn +``` + +--- + +### 3.2 Event Planning 서비스 - 10초 응답 최적화 + +**패턴 적용**: +- **Cache-Aside**: 트렌드 데이터 캐싱 +- **Circuit Breaker**: Claude + GPT-4 API 장애 대응 +- **병렬 처리**: AI API 동시 호출 + +**아키텍처**: +```mermaid +sequenceDiagram + participant Client + participant Gateway + participant Planning as Event Planning + participant Cache as Redis Cache + participant DB as Planning DB + participant Claude as Claude API + participant GPT4 as GPT-4 API + + Client->>Gateway: 이벤트 기획 시작 + Gateway->>Planning: 기획 요청 + + Note over Planning,Cache: Phase 1: 트렌드 분석 (3초 목표) + Planning->>Cache: 트렌드 데이터 조회 + alt 캐시 히트 + Cache-->>Planning: 캐시 데이터 반환 + else 캐시 미스 + Planning->>DB: DB 조회 + DB-->>Planning: 트렌드 데이터 + Planning->>Cache: 캐시 저장 (TTL: 1시간) + end + + Note over Planning,GPT4: Phase 2: AI 병렬 호출 (7초 목표) + par Claude: 이벤트상품 + 참여방법 + Planning->>Claude: 이벤트상품 추천 요청
+ 참여방법 설계 요청 + Claude-->>Planning: 추천 결과 (5초) + and GPT-4: 홍보문구 + Planning->>GPT4: 홍보문구 생성 요청 + GPT4-->>Planning: 홍보문구 (4초) + end + + Planning->>DB: 기획안 저장 + Planning-->>Gateway: 완성된 기획안 (총 10초 이내) + Gateway-->>Client: 기획안 제공 +``` + +**예상 성과**: +- **총 응답시간: 10초 이내** (목표 달성) +- 트렌드 분석: 3초 → 0.9초 (캐시 히트 시) +- AI API 병렬 호출: 9초 → 5초 + +--- + +### 3.3 Content Generation 서비스 - 비동기 처리 + +**패턴 적용**: +- **Async Request-Reply**: 5-8분 장시간 처리 +- **Queue-Based Load Leveling**: 동시 50개 콘텐츠 생성 +- **Circuit Breaker**: Stable Diffusion API 장애 대응 + +**아키텍처**: +```mermaid +sequenceDiagram + participant Client + participant Gateway + participant Content as Content Generation + participant Queue as RabbitMQ + participant Worker as Background Worker + participant SD as Stable Diffusion + participant VideoAI as AI Video Engine + participant DB as Content DB + + Client->>Gateway: 콘텐츠 생성 요청 + Gateway->>Content: 생성 요청 + Content->>DB: Job 생성 (상태: PENDING) + Content->>Queue: 작업 큐잉 + Content-->>Gateway: Job ID 발급 + Gateway-->>Client: Job ID 반환 + + Note over Client: 클라이언트는 다른 작업 가능 + + Queue->>Worker: 작업 할당 + + par 이미지 3종 생성 (2-3분) + Worker->>SD: 이미지 생성 요청 (3건 병렬) + SD-->>Worker: 이미지 3종 + and 영상 1개 생성 (3-5분) + Worker->>VideoAI: 영상 제작 요청 + VideoAI-->>Worker: 15초 영상 + end + + Worker->>DB: 콘텐츠 저장 + 상태 업데이트 (COMPLETED) + + loop 상태 확인 (5초 간격) + Client->>Gateway: Job 상태 조회 + Gateway->>Content: 상태 조회 + Content->>DB: 상태 확인 + DB-->>Content: 상태 + 진행률 + Content-->>Gateway: 진행 상황 (예: 60% 완료) + Gateway-->>Client: 진행률 표시 + end + + Client->>Gateway: 최종 상태 조회 + Gateway->>Content: 상태 조회 + Content-->>Gateway: COMPLETED + 콘텐츠 URL + Gateway-->>Client: 콘텐츠 다운로드 +``` + +**예상 성과**: +- **총 처리시간: 5-8분** (목표 달성) +- 사용자 대기 체감 시간: 8분 → 0초 (비동기) +- 동시 처리 능력: 50개 콘텐츠 + +--- + +### 3.4 Distribution 서비스 - 안정적 배포 + +**패턴 적용**: +- **Circuit Breaker**: 6개 외부 API 장애 대응 +- **Retry**: 배포 실패 자동 재시도 (3회) +- **Queue-Based Load Leveling**: 100개 동시 배포 + +**아키텍처**: +```mermaid +sequenceDiagram + participant Client + participant Gateway + participant Dist as Distribution + participant Queue as RabbitMQ + participant CB1 as Circuit Breaker
(우리동네TV) + participant CB2 as Circuit Breaker
(지니TV) + participant CB3 as Circuit Breaker
(Instagram) + participant KTAPI as KT API + participant SNS as SNS API + + Client->>Gateway: 배포 요청 (6개 채널) + Gateway->>Dist: 배포 시작 + Dist->>Queue: 배포 작업 큐잉 + + par 병렬 배포 (1분 목표) + Queue->>CB1: 우리동네TV 배포 + CB1->>KTAPI: API 호출 + alt API 성공 + KTAPI-->>CB1: 배포 완료 + else API 실패 + KTAPI--xCB1: 오류 + CB1->>CB1: Retry (최대 3회) + alt Retry 성공 + CB1->>KTAPI: 재시도 + KTAPI-->>CB1: 배포 완료 + else Retry 실패 + CB1-->>Queue: 배포 실패 (OPEN 상태) + end + end + CB1-->>Dist: 결과 반환 + and + Queue->>CB2: 지니TV 배포 + CB2->>KTAPI: API 호출 + KTAPI-->>CB2: 배포 완료 + CB2-->>Dist: 결과 반환 + and + Queue->>CB3: Instagram 배포 + CB3->>SNS: API 호출 + SNS-->>CB3: 포스팅 완료 + CB3-->>Dist: 결과 반환 + end + + Dist-->>Gateway: 배포 결과 (성공 5/6) + Gateway-->>Client: 배포 완료 + 실패 채널 안내 +``` + +**예상 성과**: +- **총 배포시간: 1분 이내** (목표 달성) +- 배포 성공률: 95% → 98% (Retry) +- API 장애 시 응답: 30초 → 3초 (Circuit Breaker) + +--- + +### 3.5 Analytics 서비스 - CQRS 읽기/쓰기 분리 + +**패턴 적용**: +- **CQRS**: 읽기/쓰기 분리 +- **Publisher-Subscriber**: 5분 간격 데이터 수집 + +**아키텍처**: +```mermaid +graph TB + subgraph "쓰기 모델" + Collector[데이터 수집기
5분 스케줄러] + WriteAPI[쓰기 API] + CommandDB[(Command DB
원본 데이터)] + end + + subgraph "이벤트 버스" + EventBus[RabbitMQ
Pub-Sub] + end + + subgraph "읽기 모델" + ReadAPI[읽기 API
대시보드] + QueryDB[(Query DB
집계 데이터)] + 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 계산
채널별 집계| QueryDB + ReadAPI --> QueryDB + + Client[클라이언트
대시보드] -->|실시간 조회| ReadAPI +``` + +**예상 성과**: +- 대시보드 조회 속도: 5초 → 1초 (80% 향상) +- ROI 계산 응답: 10초 → 2초 +- 동시 조회 처리: 100개 대시보드 + +--- + +## 4. Phase별 구현 로드맵 + +### Phase 1: MVP (Minimum Viable Product) - 3개월 + +**목표**: 핵심 비즈니스 기능 제공 및 빠른 출시 + +**적용 패턴**: +1. **API Gateway** - 단일 진입점 및 인증/인가 +2. **Async Request-Reply** - 콘텐츠 생성 비동기 처리 +3. **Circuit Breaker** - 외부 API 장애 대응 +4. **Cache-Aside** - 트렌드 데이터 캐싱 +5. **Retry** - 배포 실패 자동 재시도 + +**구현 우선순위**: +1. **Week 1-4**: User 서비스 + API Gateway + - 회원가입/로그인 (JWT 인증) + - 매장 정보 관리 + - 사업자번호 검증 연동 + +2. **Week 5-8**: Event Planning 서비스 + - AI API 연동 (Claude, GPT-4) + - Cache-Aside 패턴 적용 (Redis) + - Circuit Breaker 적용 + +3. **Week 9-10**: Content Generation 서비스 + - Async Request-Reply 패턴 구현 + - Stable Diffusion 연동 + - 진행 상황 폴링 API + +4. **Week 11-12**: Distribution + Participation 서비스 + - 6개 채널 병렬 배포 (Circuit Breaker + Retry) + - 추첨/선착순 분기 로직 + +**성공 지표**: +- Event Planning: 10초 이내 응답 ✅ +- Content Generation: 8분 이내 완료 ✅ +- Distribution: 1분 이내 배포 ✅ +- 동시 이벤트 처리: 50개 + +--- + +### 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.1 성능 개선 + +| 지표 | 현재 (패턴 미적용) | Phase 1 MVP | Phase 2 확장 | Phase 3 고도화 | +|------|-------------------|-------------|-------------|---------------| +| **Event Planning 응답시간** | 25초 | **10초** ✅ | 8초 | 6초 | +| **Content Generation 완료시간** | 12분 | **8분** ✅ | 6분 | 5분 | +| **Distribution 배포시간** | 3분 | **1분** ✅ | 40초 | 30초 | +| **Analytics 대시보드 조회** | 5초 | 3초 | **1초** ✅ | 0.5초 | +| **동시 이벤트 처리** | 20개 | 50개 | **100개** ✅ | 300개 | +| **시스템 가용성** | 95% | 99% | **99.9%** ✅ | 99.99% | + +--- + +### 5.2 비용 절감 효과 + +| 항목 | 절감율 | 연간 절감액 (추정) | +|------|--------|-------------------| +| **AI API 호출 비용** (Cache-Aside) | 40% | ₩24,000,000 | +| **외부 API 재시도 비용** (Circuit Breaker) | 30% | ₩9,000,000 | +| **서버 리소스 비용** (CQRS, 캐싱) | 25% | ₩15,000,000 | +| **운영 인력 비용** (자동화) | 20% | ₩12,000,000 | +| **총 절감액** | - | **₩60,000,000** | + +--- + +### 5.3 개발 생산성 향상 + +| 지표 | 개선율 | +|------|--------| +| **서비스 간 결합도 감소** (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, 프롬프트 최적화, 병렬 호출 | +| 외부 API 장애 | 높음 | 높음 | Circuit Breaker, Retry, 폴백 전략 | +| Redis 장애 | 낮음 | 중간 | Redis Cluster, DB 폴백 | +| 메시지 큐 장애 | 낮음 | 높음 | Dead Letter Queue, 재처리 로직 | + +### 7.2 운영 리스크 + +| 리스크 | 확률 | 영향도 | 완화 전략 | +|--------|------|--------|-----------| +| 피크 타임 트래픽 폭주 | 높음 | 높음 | Auto Scaling, Queue-Based Load Leveling | +| 데이터 불일치 (CQRS) | 중간 | 중간 | 이벤트 재생, 수동 동기화 도구 | +| 배포 실패율 증가 | 중간 | 중간 | Retry 3회, 수동 배포 옵션 | + +--- + +## 8. 결론 + +### 8.1 핵심 패턴 요약 + +본 서비스는 **10개의 클라우드 아키텍처 패턴**을 3단계로 적용하여 성능, 확장성, 안정성을 보장합니다: + +1. **API Gateway**: 단일 진입점 및 횡단 관심사 분리 +2. **Async Request-Reply**: 장시간 처리 작업 비동기화 +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 예상 효과 + +- **Event Planning**: 25초 → **10초** (60% 단축) ✅ +- **Content Generation**: 12분 → **8분** (33% 단축) ✅ +- **Distribution**: 3분 → **1분** (67% 단축) ✅ +- **시스템 가용성**: 95% → **99.9%** ✅ +- **동시 이벤트 처리**: 20개 → **100개** (5배 향상) ✅ +- **연간 비용 절감**: **₩60,000,000** 💰 + +### 8.3 다음 단계 + +1. **Phase 1 MVP 착수** (3개월) + - API Gateway + Async Request-Reply + Circuit Breaker 우선 구현 + - 핵심 비즈니스 기능 검증 + +2. **성능 모니터링** + - Prometheus + Grafana 대시보드 구축 + - 각 패턴별 성과 지표 측정 + +3. **지속적 개선** + - Phase 2, 3 로드맵에 따라 점진적 고도화 + - AI 학습 정확도 향상 및 글로벌 확장 + +--- + +**문서 승인**: +- [ ] System Architect (박영자) +- [ ] Backend Developer (최수연) +- [ ] DevOps Engineer (송근정) +- [ ] PO (갑빠) + +**참조 문서**: +- design/userstory.md +- claude/cloud-design-patterns.md +- claude/architecture-patterns.md diff --git a/design/pattern/architecture-pattern.md b/design/pattern/architecture-pattern.md index 36e0593..6b8d3c5 100644 --- a/design/pattern/architecture-pattern.md +++ b/design/pattern/architecture-pattern.md @@ -2,7 +2,7 @@ **작성일**: 2025-10-21 **작성자**: System Architect (박영자) -**버전**: 1.0 +**버전**: 2.0 (3개 핵심 패턴 적용) --- @@ -128,7 +128,6 @@ **기술적 도전과제**: - **다중 데이터 소스 통합 (KT API, POS, SNS API)** -- CQRS 패턴으로 읽기/쓰기 분리 - 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분 이내** | 이미지+영상 병렬 생성, 비동기 처리 | | Distribution | **1분 이내** | 6개 채널 병렬 배포 | -| Analytics | **5분 주기** | CQRS 읽기/쓰기 분리, 스케줄러 수집 | +| Analytics | **5분 주기** | 스케줄러 수집 | #### 확장성 요구사항 - **동시 이벤트 처리**: 최소 100개 @@ -181,26 +179,19 @@ ### 2.1 패턴 평가 매트릭스 -#### 핵심 패턴 Top 10 정량 평가 +#### 핵심 패턴 정량 평가 | 패턴 | 기능 적합성
(35%) | 성능 효과
(25%) | 운영 복잡도
(20%) | 확장성
(15%) | 비용 효율성
(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위 | | **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위 | -| **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 선정 패턴 및 적용 전략 -#### 🥇 **1. API Gateway** (총점: 9.30) - Phase 1 MVP +#### 🥇 **1. API Gateway** (총점: 9.30) **선정 이유**: - 단일 진입점으로 7개 마이크로서비스 라우팅 @@ -215,23 +206,34 @@ - 인증 처리 시간 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분 처리 시간 대응** - 이미지/영상 생성 백그라운드 처리 -- 진행 상황 실시간 피드백 (WebSocket/폴링) +- 진행 상황 실시간 피드백 (폴링) - 클라이언트 블로킹 방지 -**적용 서비스**: Content Generation, AI Learning +**적용 서비스**: Content Generation **예상 효과**: - 사용자 대기 시간 체감 80% 감소 - 시스템 응답성 향상 - 동시 콘텐츠 생성 50개 처리 가능 +**구현 기술**: +- **Job ID 관리**: UUID v4 사용 +- **상태 폴링**: 5초 간격, 최대 10분 타임아웃 +- **상태 관리**: Redis 또는 DB 기반 Job 상태 추적 + **구현 예시**: ```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)** @@ -268,6 +270,12 @@ const checkStatus = setInterval(async () => { - 시스템 가용성 99.9% 보장 - 배포 성공률 98% 이상 유지 +**구현 기술**: +- **타임아웃 설정**: 외부 API별 차등 (15초 ~ 60초) +- **실패 임계값**: 50% 실패 시 OPEN +- **재시도 간격**: 30초 후 HALF-OPEN +- **폴백 전략**: 기본값 제공 또는 실패 메시지 + **구현 예시** (Node.js with opossum): ```javascript const CircuitBreaker = require('opossum'); @@ -283,162 +291,36 @@ const breaker = new CircuitBreaker(callWooridongneTV, { resetTimeout: 30000 // 30초 후 재시도 }); -breaker.fallback(() => ({ success: false, message: '우리동네TV 배포 실패' })); +breaker.fallback(() => ({ + success: false, + message: '우리동네TV 배포 실패' +})); // 배포 요청 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); + } -**선정 이유**: -- Event Planning 서비스의 10초 응답 목표 달성 -- 트렌드 데이터베이스 조회 성능 향상 -- AI API 응답 캐싱 (동일 조건 재사용) -- Redis 활용 고속 캐싱 - -**적용 서비스**: 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; -}; + private DeployResult fallbackDeploy(DeployData data, Exception e) { + return DeployResult.builder() + .success(false) + .message("우리동네TV 배포 실패: " + e.getMessage()) + .build(); + } +} ``` --- -#### **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
쓰기 전용)] - CommandDB --> EventBus[이벤트 버스] - EventBus --> ReadDB[(Query DB
읽기 전용)] - 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.1 전체 아키텍처 구조 @@ -456,12 +338,12 @@ graph TB subgraph "마이크로서비스" User[User 서비스
회원/매장 관리] - Planning[Event Planning 서비스
AI 이벤트 기획
Cache-Aside] + Planning[Event Planning 서비스
AI 이벤트 기획] Content[Content Generation 서비스
AI 콘텐츠 생성
Async Request-Reply] - Dist[Distribution 서비스
다중 채널 배포
Circuit Breaker + Retry] + Dist[Distribution 서비스
다중 채널 배포
Circuit Breaker] Participation[Participation 서비스
참여/추첨 관리] - Analytics[Analytics 서비스
효과 측정
CQRS] - AILearn[AI Learning 서비스
학습/개선
Event Sourcing] + Analytics[Analytics 서비스
효과 측정] + AILearn[AI Learning 서비스
학습/개선] end subgraph "데이터 계층" @@ -470,19 +352,9 @@ graph TB ContentDB[(Content DB
MongoDB)] DistDB[(Distribution DB
PostgreSQL)] PartDB[(Participation DB
PostgreSQL)] - - subgraph "CQRS - Analytics" - WriteDB[(Command DB
쓰기)] - ReadDB[(Query DB
읽기)] - end - - EventStore[(Event Store
AI Learning)] - - Cache[(Redis Cache
Cache-Aside)] - end - - subgraph "메시지 큐" - Queue[RabbitMQ/Kafka
Queue-Based Load Leveling
Pub-Sub] + AnalyticsDB[(Analytics DB
MongoDB)] + AILearnDB[(AI Learning DB
MongoDB)] + JobStore[(Job Store
Redis)] end subgraph "외부 시스템" @@ -506,29 +378,21 @@ graph TB User --> UserDB Planning --> PlanningDB - Planning --> Cache Content --> ContentDB - Content --> Queue + Content --> JobStore Dist --> DistDB - Dist --> Queue Participation --> PartDB - Analytics --> WriteDB - Analytics --> ReadDB - WriteDB --> Queue - Queue --> ReadDB - AILearn --> EventStore + Analytics --> AnalyticsDB + AILearn --> AILearnDB Planning -->|Circuit Breaker| AIAPI Content -->|Circuit Breaker| AIAPI - Dist -->|Circuit Breaker + Retry| KTAPI - Dist -->|Circuit Breaker + Retry| SNS + Dist -->|Circuit Breaker| KTAPI + Dist -->|Circuit Breaker| SNS Dist -->|Circuit Breaker| Clova Analytics --> KTAPI Analytics --> SNS Analytics --> POS - - Queue -->|Pub-Sub| Analytics - Queue -->|Pub-Sub| AILearn ``` --- @@ -536,7 +400,6 @@ graph TB ### 3.2 Event Planning 서비스 - 10초 응답 최적화 **패턴 적용**: -- **Cache-Aside**: 트렌드 데이터 캐싱 - **Circuit Breaker**: Claude + GPT-4 API 장애 대응 - **병렬 처리**: AI API 동시 호출 @@ -546,7 +409,6 @@ sequenceDiagram participant Client participant Gateway participant Planning as Event Planning - participant Cache as Redis Cache participant DB as Planning DB participant Claude as Claude API participant GPT4 as GPT-4 API @@ -554,15 +416,9 @@ sequenceDiagram Client->>Gateway: 이벤트 기획 시작 Gateway->>Planning: 기획 요청 - Note over Planning,Cache: Phase 1: 트렌드 분석 (3초 목표) - Planning->>Cache: 트렌드 데이터 조회 - alt 캐시 히트 - Cache-->>Planning: 캐시 데이터 반환 - else 캐시 미스 - Planning->>DB: DB 조회 - DB-->>Planning: 트렌드 데이터 - Planning->>Cache: 캐시 저장 (TTL: 1시간) - end + Note over Planning,DB: Phase 1: 트렌드 분석 (3초 목표) + Planning->>DB: 트렌드 데이터 조회 + DB-->>Planning: 트렌드 데이터 Note over Planning,GPT4: Phase 2: AI 병렬 호출 (7초 목표) par Claude: 이벤트상품 + 참여방법 @@ -580,7 +436,6 @@ sequenceDiagram **예상 성과**: - **총 응답시간: 10초 이내** (목표 달성) -- 트렌드 분석: 3초 → 0.9초 (캐시 히트 시) - AI API 병렬 호출: 9초 → 5초 --- @@ -589,7 +444,6 @@ sequenceDiagram **패턴 적용**: - **Async Request-Reply**: 5-8분 장시간 처리 -- **Queue-Based Load Leveling**: 동시 50개 콘텐츠 생성 - **Circuit Breaker**: Stable Diffusion API 장애 대응 **아키텍처**: @@ -598,7 +452,7 @@ sequenceDiagram participant Client participant Gateway participant Content as Content Generation - participant Queue as RabbitMQ + participant JobStore as Job Store (Redis) participant Worker as Background Worker participant SD as Stable Diffusion participant VideoAI as AI Video Engine @@ -606,14 +460,13 @@ sequenceDiagram Client->>Gateway: 콘텐츠 생성 요청 Gateway->>Content: 생성 요청 - Content->>DB: Job 생성 (상태: PENDING) - Content->>Queue: 작업 큐잉 + Content->>JobStore: Job 생성 (상태: PENDING) Content-->>Gateway: Job ID 발급 Gateway-->>Client: Job ID 반환 Note over Client: 클라이언트는 다른 작업 가능 - Queue->>Worker: 작업 할당 + Content->>Worker: 비동기 작업 시작 par 이미지 3종 생성 (2-3분) Worker->>SD: 이미지 생성 요청 (3건 병렬) @@ -623,13 +476,14 @@ sequenceDiagram VideoAI-->>Worker: 15초 영상 end - Worker->>DB: 콘텐츠 저장 + 상태 업데이트 (COMPLETED) + Worker->>DB: 콘텐츠 저장 + Worker->>JobStore: 상태 업데이트 (COMPLETED) loop 상태 확인 (5초 간격) Client->>Gateway: Job 상태 조회 Gateway->>Content: 상태 조회 - Content->>DB: 상태 확인 - DB-->>Content: 상태 + 진행률 + Content->>JobStore: 상태 확인 + JobStore-->>Content: 상태 + 진행률 Content-->>Gateway: 진행 상황 (예: 60% 완료) Gateway-->>Client: 진행률 표시 end @@ -651,8 +505,7 @@ sequenceDiagram **패턴 적용**: - **Circuit Breaker**: 6개 외부 API 장애 대응 -- **Retry**: 배포 실패 자동 재시도 (3회) -- **Queue-Based Load Leveling**: 100개 동시 배포 +- **병렬 배포**: 6개 채널 동시 배포 **아키텍처**: ```mermaid @@ -660,7 +513,6 @@ sequenceDiagram participant Client participant Gateway participant Dist as Distribution - participant Queue as RabbitMQ participant CB1 as Circuit Breaker
(우리동네TV) participant CB2 as Circuit Breaker
(지니TV) participant CB3 as Circuit Breaker
(Instagram) @@ -669,31 +521,24 @@ sequenceDiagram Client->>Gateway: 배포 요청 (6개 채널) Gateway->>Dist: 배포 시작 - Dist->>Queue: 배포 작업 큐잉 par 병렬 배포 (1분 목표) - Queue->>CB1: 우리동네TV 배포 + Dist->>CB1: 우리동네TV 배포 CB1->>KTAPI: API 호출 alt API 성공 KTAPI-->>CB1: 배포 완료 else API 실패 KTAPI--xCB1: 오류 - CB1->>CB1: Retry (최대 3회) - alt Retry 성공 - CB1->>KTAPI: 재시도 - KTAPI-->>CB1: 배포 완료 - else Retry 실패 - CB1-->>Queue: 배포 실패 (OPEN 상태) - end + CB1-->>Dist: Fallback (배포 실패) end CB1-->>Dist: 결과 반환 and - Queue->>CB2: 지니TV 배포 + Dist->>CB2: 지니TV 배포 CB2->>KTAPI: API 호출 KTAPI-->>CB2: 배포 완료 CB2-->>Dist: 결과 반환 and - Queue->>CB3: Instagram 배포 + Dist->>CB3: Instagram 배포 CB3->>SNS: API 호출 SNS-->>CB3: 포스팅 완료 CB3-->>Dist: 결과 반환 @@ -705,63 +550,12 @@ sequenceDiagram **예상 성과**: - **총 배포시간: 1분 이내** (목표 달성) -- 배포 성공률: 95% → 98% (Retry) - API 장애 시 응답: 30초 → 3초 (Circuit Breaker) +- 배포 안정성: 95% → 98% --- -### 3.5 Analytics 서비스 - CQRS 읽기/쓰기 분리 - -**패턴 적용**: -- **CQRS**: 읽기/쓰기 분리 -- **Publisher-Subscriber**: 5분 간격 데이터 수집 - -**아키텍처**: -```mermaid -graph TB - subgraph "쓰기 모델" - Collector[데이터 수집기
5분 스케줄러] - WriteAPI[쓰기 API] - CommandDB[(Command DB
원본 데이터)] - end - - subgraph "이벤트 버스" - EventBus[RabbitMQ
Pub-Sub] - end - - subgraph "읽기 모델" - ReadAPI[읽기 API
대시보드] - QueryDB[(Query DB
집계 데이터)] - 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 계산
채널별 집계| QueryDB - ReadAPI --> QueryDB - - Client[클라이언트
대시보드] -->|실시간 조회| ReadAPI -``` - -**예상 성과**: -- 대시보드 조회 속도: 5초 → 1초 (80% 향상) -- ROI 계산 응답: 10초 → 2초 -- 동시 조회 처리: 100개 대시보드 - ---- - -## 4. Phase별 구현 로드맵 +## 4. 구현 로드맵 ### Phase 1: MVP (Minimum Viable Product) - 3개월 @@ -771,27 +565,27 @@ graph TB 1. **API Gateway** - 단일 진입점 및 인증/인가 2. **Async Request-Reply** - 콘텐츠 생성 비동기 처리 3. **Circuit Breaker** - 외부 API 장애 대응 -4. **Cache-Aside** - 트렌드 데이터 캐싱 -5. **Retry** - 배포 실패 자동 재시도 **구현 우선순위**: 1. **Week 1-4**: User 서비스 + API Gateway - 회원가입/로그인 (JWT 인증) - 매장 정보 관리 - 사업자번호 검증 연동 + - API Gateway 구축 (Kong 또는 Spring Cloud Gateway) 2. **Week 5-8**: Event Planning 서비스 - AI API 연동 (Claude, GPT-4) - - Cache-Aside 패턴 적용 (Redis) - Circuit Breaker 적용 + - AI API 병렬 호출 구현 3. **Week 9-10**: Content Generation 서비스 - Async Request-Reply 패턴 구현 - Stable Diffusion 연동 - 진행 상황 폴링 API + - Redis 기반 Job Store 구축 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.1 성능 개선 -| 지표 | 현재 (패턴 미적용) | Phase 1 MVP | Phase 2 확장 | Phase 3 고도화 | -|------|-------------------|-------------|-------------|---------------| -| **Event Planning 응답시간** | 25초 | **10초** ✅ | 8초 | 6초 | -| **Content Generation 완료시간** | 12분 | **8분** ✅ | 6분 | 5분 | -| **Distribution 배포시간** | 3분 | **1분** ✅ | 40초 | 30초 | -| **Analytics 대시보드 조회** | 5초 | 3초 | **1초** ✅ | 0.5초 | -| **동시 이벤트 처리** | 20개 | 50개 | **100개** ✅ | 300개 | -| **시스템 가용성** | 95% | 99% | **99.9%** ✅ | 99.99% | +| 지표 | 현재 (패턴 미적용) | Phase 1 MVP | +|------|-------------------|-------------| +| **Event Planning 응답시간** | 25초 | **10초** ✅ | +| **Content Generation 완료시간** | 12분 | **8분** ✅ | +| **Distribution 배포시간** | 3분 | **1분** ✅ | +| **동시 이벤트 처리** | 20개 | 50개 | +| **시스템 가용성** | 95% | 99% | --- -### 5.2 비용 절감 효과 +### 5.2 패턴별 기대 효과 -| 항목 | 절감율 | 연간 절감액 (추정) | -|------|--------|-------------------| -| **AI API 호출 비용** (Cache-Aside) | 40% | ₩24,000,000 | -| **외부 API 재시도 비용** (Circuit Breaker) | 30% | ₩9,000,000 | -| **서버 리소스 비용** (CQRS, 캐싱) | 25% | ₩15,000,000 | -| **운영 인력 비용** (자동화) | 20% | ₩12,000,000 | -| **총 절감액** | - | **₩60,000,000** | +| 패턴 | 적용 효과 | 개선율 | +|------|----------|--------| +| **API Gateway** | 클라이언트 통합 엔드포인트, 인증 중앙화 | 인증 처리 50% 단축 | +| **Async Request-Reply** | 사용자 대기 시간 체감 감소 | 80% 체감 시간 감소 | +| **Circuit Breaker** | API 장애 시 빠른 실패, 연쇄 장애 방지 | 응답 시간 95% 단축 | --- -### 5.3 개발 생산성 향상 +## 6. 리스크 관리 -| 지표 | 개선율 | -|------|--------| -| **서비스 간 결합도 감소** (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 기술적 리스크 +### 6.1 기술적 리스크 | 리스크 | 확률 | 영향도 | 완화 전략 | |--------|------|--------|-----------| -| AI API 응답 지연 (>10초) | 중간 | 높음 | Cache-Aside, 프롬프트 최적화, 병렬 호출 | -| 외부 API 장애 | 높음 | 높음 | Circuit Breaker, Retry, 폴백 전략 | -| Redis 장애 | 낮음 | 중간 | Redis Cluster, DB 폴백 | -| 메시지 큐 장애 | 낮음 | 높음 | Dead Letter Queue, 재처리 로직 | +| AI API 응답 지연 (>10초) | 중간 | 높음 | 병렬 호출, 프롬프트 최적화 | +| 외부 API 장애 | 높음 | 높음 | Circuit Breaker, 폴백 전략 | +| Job Store (Redis) 장애 | 낮음 | 중간 | Redis Cluster, DB 폴백 | -### 7.2 운영 리스크 +### 6.2 운영 리스크 | 리스크 | 확률 | 영향도 | 완화 전략 | |--------|------|--------|-----------| -| 피크 타임 트래픽 폭주 | 높음 | 높음 | Auto Scaling, Queue-Based Load Leveling | -| 데이터 불일치 (CQRS) | 중간 | 중간 | 이벤트 재생, 수동 동기화 도구 | -| 배포 실패율 증가 | 중간 | 중간 | Retry 3회, 수동 배포 옵션 | +| 피크 타임 트래픽 폭주 | 높음 | 높음 | Auto Scaling, Rate Limiting | +| 배포 실패율 증가 | 중간 | 중간 | Circuit Breaker 폴백 전략 | --- -## 8. 결론 +## 7. 결론 -### 8.1 핵심 패턴 요약 +### 7.1 핵심 패턴 요약 -본 서비스는 **10개의 클라우드 아키텍처 패턴**을 3단계로 적용하여 성능, 확장성, 안정성을 보장합니다: +본 서비스는 **3개의 클라우드 아키텍처 패턴**을 적용하여 성능, 확장성, 안정성을 보장합니다: 1. **API Gateway**: 단일 진입점 및 횡단 관심사 분리 2. **Async Request-Reply**: 장시간 처리 작업 비동기화 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% 단축) ✅ - **Content Generation**: 12분 → **8분** (33% 단축) ✅ - **Distribution**: 3분 → **1분** (67% 단축) ✅ -- **시스템 가용성**: 95% → **99.9%** ✅ -- **동시 이벤트 처리**: 20개 → **100개** (5배 향상) ✅ -- **연간 비용 절감**: **₩60,000,000** 💰 +- **시스템 가용성**: 95% → **99%** ✅ +- **동시 이벤트 처리**: 20개 → **50개** (2.5배 향상) ✅ -### 8.3 다음 단계 +### 7.3 다음 단계 1. **Phase 1 MVP 착수** (3개월) - API Gateway + Async Request-Reply + Circuit Breaker 우선 구현 @@ -991,8 +668,8 @@ graph TB - 각 패턴별 성과 지표 측정 3. **지속적 개선** - - Phase 2, 3 로드맵에 따라 점진적 고도화 - - AI 학습 정확도 향상 및 글로벌 확장 + - 추가 패턴 도입 검토 (Cache-Aside, CQRS 등) + - AI 학습 정확도 향상 --- @@ -1005,4 +682,4 @@ graph TB **참조 문서**: - design/userstory.md - claude/cloud-design-patterns.md -- claude/architecture-patterns.md +- design/pattern/architecture-pattern-backup-20251021.md (백업)