shared-dg05-dodari/kt-event-marketing

Fork 0

mirror of https://github.com/ktds-dg0501/kt-event-marketing.git synced 2025-12-06 20:06:23 +00:00

doyeon 92b4a6c824 backup파일 교체

2025-10-22 10:00:16 +09:00

20 KiB

Raw Blame History

KT AI 기반 소상공인 이벤트 자동 생성 서비스 - 클라우드 아키텍처 패턴 적용 방안 (MVP)

문서 정보

작성일: 2025-10-21
버전: 2.0 (MVP 집중)
적용 패턴: 4개 핵심 패턴
목표: 빠른 MVP 출시와 안정적 서비스 제공

1. 요구사항 분석

1.1 기능적 요구사항

User 서비스

회원가입/로그인 및 프로필 관리
사업자번호 검증 (국세청 API)

Event 서비스

이벤트 CRUD 및 상태 관리
이벤트 목적 선택 → AI 추천 → 콘텐츠 생성 → 배포 → 분석 플로우

AI 서비스

트렌드 분석 (업종/지역/시즌)
3가지 이벤트 기획안 자동 생성
Claude API/GPT-4 API 연동

Content 서비스

3가지 스타일 SNS 이미지 자동 생성
Stable Diffusion/DALL-E API 연동
플랫폼별 이미지 최적화 (Instagram, Naver, Kakao)

Distribution 서비스

다중 채널 동시 배포 (우리동네TV, 링고비즈, 지니TV, SNS)
7개 외부 API 연동

Participation 서비스

이벤트 참여 접수 및 당첨자 추첨

Analytics 서비스

실시간 성과 대시보드
채널별 성과 분석

1.2 비기능적 요구사항

성능 요구사항

AI 트렌드 분석 + 이벤트 추천: 10초 이내
SNS 이미지 생성: 5초 이내
대시보드 데이터 업데이트: 5분 간격
다중 채널 배포: 1분 이내

가용성 요구사항

시스템 가용성: 99% 이상 (MVP 목표)
외부 API 장애 시 서비스 지속 가능

확장성 요구사항

초기 사용자: 100명
동시 이벤트: 50개
캐시 히트율: 80% 이상

보안 요구사항

JWT 기반 인증/인가
API Gateway를 통한 중앙집중식 보안

1.3 외부 API 의존성

서비스	외부 API	용도	응답시간
User	국세청 사업자등록정보 진위확인 API	사업자번호 검증	2-3초
AI	Claude API / GPT-4 API	트렌드 분석 및 이벤트 추천	5-10초
Content	Stable Diffusion / DALL-E API	SNS 이미지 생성	3-5초
Distribution	우리동네TV API	영상 업로드 및 송출	1-2초
Distribution	링고비즈 API	연결음 업데이트	1초
Distribution	지니TV 광고 API	광고 등록	1-2초
Distribution	SNS API (Instagram, Naver, Kakao)	자동 포스팅	1-3초

1.4 기술적 도전과제

1. AI 응답 시간 관리 (🔴 Critical)

문제: AI API 응답이 10초 목표를 초과할 수 있음

Claude/GPT-4 API 응답 시간 변동성 (5-15초)
트렌드 분석 + 이벤트 추천 2단계 처리 필요

해결방안:

비동기 처리: Job 기반 처리로 응답 대기 시간 최소화
캐싱: 동일 조건(업종, 지역, 목적) 결과 Redis 캐싱 (24시간)
응답 시간 90% 단축 (캐시 히트 시)

2. 다중 외부 API 의존성 (🔴 Critical)

문제: 7개 외부 API 연동으로 인한 장애 전파 위험

각 API별 응답 시간 및 성공률 상이
하나의 API 장애가 전체 서비스 중단으로 이어질 수 있음

해결방안:

Circuit Breaker: 장애 API 자동 차단 및 Fallback 처리
독립적 처리: 채널별 배포 실패가 다른 채널에 영향 없음
자동 재시도: 일시적 오류 시 최대 3회 재시도

3. 이미지 생성 비용 및 시간 (🟡 Important)

문제: AI 이미지 생성 API 비용이 높고 시간 소요

이미지 1장당 생성 비용: $0.02-0.05
3가지 스타일 생성 시 비용 3배

해결방안:

캐싱: 동일 이벤트 정보 이미지 재사용
비용 90% 절감 (캐시 히트 시)

4. 실시간 대시보드 성능 (🟡 Important)

문제: 다중 데이터 소스 통합으로 인한 응답 지연

7개 외부 API + 내부 서비스 데이터 통합
복잡한 차트 및 계산 로직

해결방안:

캐싱: Redis를 통한 5분 간격 데이터 캐싱
응답 시간 80% 단축

2. 패턴 선정 및 평가

2.1 MVP 핵심 패턴 (4개)

패턴	적용 목적	주요 효과
Cache-Aside	AI 응답 시간 단축 및 비용 절감	응답 시간 90% 단축, 비용 90% 절감
API Gateway	중앙집중식 보안 및 라우팅	개발 복잡도 감소, 보안 강화
Asynchronous Request-Reply	장시간 작업 응답 시간 개선	사용자 대기 시간 제거
Circuit Breaker (Optional)	외부 API 장애 격리	가용성 95% → 99% 개선

2.2 정량적 평가 매트릭스

평가 기준:

기능 적합성 (35%): 요구사항 직접 해결 능력
성능 효과 (25%): 응답시간 및 처리량 개선
운영 복잡도 (20%): 구현 및 운영 용이성
확장성 (15%): 미래 요구사항 대응력
비용 효율성 (5%): 개발/운영 비용 대비 효과

패턴	기능 적합성 (35%)	성능 효과 (25%)	운영 복잡도 (20%)	확장성 (15%)	비용 효율성 (5%)	총점	우선순위
Cache-Aside	10 × 0.35 = 3.5	10 × 0.25 = 2.5	8 × 0.20 = 1.6	9 × 0.15 = 1.35	10 × 0.05 = 0.5	9.45	🔴 Critical
API Gateway	9 × 0.35 = 3.15	7 × 0.25 = 1.75	9 × 0.20 = 1.8	9 × 0.15 = 1.35	8 × 0.05 = 0.4	8.45	🔴 Critical
Asynchronous Request-Reply	9 × 0.35 = 3.15	9 × 0.25 = 2.25	7 × 0.20 = 1.4	8 × 0.15 = 1.2	8 × 0.05 = 0.4	8.40	🔴 Critical
Circuit Breaker	8 × 0.35 = 2.8	8 × 0.25 = 2.0	9 × 0.20 = 1.8	9 × 0.15 = 1.35	7 × 0.05 = 0.35	8.30	🟡 Optional

2.3 패턴별 상세 분석

2.3.1 Cache-Aside (9.45점) - 🔴 Critical

적용 대상:

AI 서비스: 트렌드 분석 결과, 이벤트 추천 결과
Content 서비스: 생성된 SNS 이미지
User 서비스: 사업자번호 검증 결과

구현 방식:

1. 요청 수신 → 캐시 확인 (Redis GET)
2. 캐시 HIT: 즉시 반환 (응답 시간 0.1초)
3. 캐시 MISS:
   - 외부 API 호출 (응답 시간 5-10초)
   - 결과를 캐시에 저장 (Redis SET, TTL 24시간)
   - 결과 반환

기대 효과:

응답 시간: 10초 → 0.1초 (99% 개선, 캐시 히트 시)
비용 절감: AI API 호출 90% 감소 → 월 $2,000 → $200 (90% 절감)
캐시 히트율: 80% (동일 업종/지역 이벤트 반복 요청)

운영 고려사항:

Redis 메모리 관리: 최대 2GB (약 10,000개 캐시 항목)
TTL 정책: 24시간 (트렌드 변화 반영)
캐시 무효화: 수동 무효화 API 제공

2.3.2 API Gateway (8.45점) - 🔴 Critical

적용 대상:

전체 마이크로서비스 (User, Event, AI, Content, Distribution, Participation, Analytics)

주요 기능:

인증/인가: JWT 토큰 검증 (모든 요청)
라우팅: URL 기반 서비스 라우팅
Rate Limiting: API 호출 제한 (사용자당 100 req/min)
로깅: 중앙집중식 접근 로그

구현 방식:

Client → API Gateway (Kong/AWS API Gateway)
         ├─ /api/users/* → User Service
         ├─ /api/events/* → Event Service
         ├─ /api/ai/* → AI Service
         ├─ /api/content/* → Content Service
         ├─ /api/distribution/* → Distribution Service
         ├─ /api/participation/* → Participation Service
         └─ /api/analytics/* → Analytics Service

기대 효과:

개발 생산성: 각 서비스에서 인증 로직 제거 → 개발 시간 30% 단축
보안 강화: 중앙집중식 보안 정책 관리
운영 효율: 통합 모니터링 및 로깅

2.3.3 Asynchronous Request-Reply (8.40점) - 🔴 Critical

적용 대상:

AI 서비스: 트렌드 분석 및 이벤트 추천 (10초 소요)
Content 서비스: SNS 이미지 생성 (5초 소요)

구현 방식:

1. 클라이언트 요청 → Job ID 즉시 반환 (응답 시간 0.1초)
2. 백그라운드 처리:
   - AI API 호출 및 결과 생성 (10초)
   - 결과를 DB 저장
3. 클라이언트 폴링:
   - 5초 간격으로 Job 상태 확인 (GET /jobs/{id})
   - 완료 시 결과 수신

기대 효과:

사용자 경험: 대기 화면에서 진행 상황 표시 → 이탈률 감소
서버 부하: 동기 대기 제거 → 동시 처리 가능 요청 5배 증가

운영 고려사항:

Job 상태 저장: Redis (TTL 1시간)
폴링 간격: 5초 (UX 고려)
Job 만료: 1시간 후 자동 삭제

2.3.4 Circuit Breaker (8.30점) - 🟡 Optional

적용 대상:

모든 외부 API 연동 지점 (7개 API)

동작 방식:

1. Closed (정상):
   - 외부 API 정상 호출
   - 실패율 5% 미만

2. Open (차단):
   - 실패율 5% 초과 시 Circuit Open
   - 모든 요청 즉시 실패 (Fallback 처리)
   - 30초 대기

3. Half-Open (테스트):
   - 30초 후 1개 요청 시도
   - 성공 시 Closed로 전환
   - 실패 시 Open 유지

Fallback 전략:

AI 서비스: 캐시된 이전 추천 결과 제공 + 안내 메시지
Distribution 서비스: 해당 채널 배포 스킵 + 알림
User 서비스: 사업자번호 검증 스킵 (수동 확인으로 대체)

기대 효과:

가용성: 95% → 99% (외부 API 장애 격리)
장애 복구: 자동 복구 시간 5분 → 30초

3. 서비스별 패턴 적용 설계

3.1 전체 아키텍처 (MVP)

graph TB
    subgraph "클라이언트"
        Client[Web/Mobile App]
    end

    subgraph "API Gateway Layer"
        Gateway[API Gateway<br/>인증, 라우팅, Rate Limiting]
    end

    subgraph "마이크로서비스"
        UserSvc[User Service<br/>회원관리]
        EventSvc[Event Service<br/>이벤트 관리]
        AISvc[AI Service<br/>트렌드 분석, 추천]
        ContentSvc[Content Service<br/>이미지 생성]
        DistSvc[Distribution Service<br/>다중 채널 배포]
        PartSvc[Participation Service<br/>참여자 관리]
        AnalSvc[Analytics Service<br/>성과 분석]
    end

    subgraph "Cache Layer"
        Redis[(Redis Cache<br/>Cache-Aside)]
    end

    subgraph "외부 API (Circuit Breaker 적용)"
        TaxAPI[국세청 API]
        ClaudeAPI[Claude API]
        SDAPI[Stable Diffusion]
        UriAPI[우리동네TV API]
        RingoAPI[링고비즈 API]
        GenieAPI[지니TV API]
        SNSAPI[SNS API]
    end

    Client -->|HTTPS| Gateway
    Gateway --> UserSvc
    Gateway --> EventSvc
    Gateway --> AISvc
    Gateway --> ContentSvc
    Gateway --> DistSvc
    Gateway --> PartSvc
    Gateway --> AnalSvc

    UserSvc -.->|Cache-Aside| Redis
    AISvc -.->|Cache-Aside| Redis
    ContentSvc -.->|Cache-Aside| Redis

    UserSvc -->|Circuit Breaker| TaxAPI
    AISvc -->|Circuit Breaker| ClaudeAPI
    ContentSvc -->|Circuit Breaker| SDAPI
    DistSvc -->|Circuit Breaker| UriAPI
    DistSvc -->|Circuit Breaker| RingoAPI
    DistSvc -->|Circuit Breaker| GenieAPI
    DistSvc -->|Circuit Breaker| SNSAPI

    style Gateway fill:#e1f5ff
    style Redis fill:#ffe1e1
    style AISvc fill:#fff4e1
    style ContentSvc fill:#fff4e1

3.2 AI Service - Asynchronous Request-Reply 패턴

sequenceDiagram
    participant Client as 클라이언트
    participant API as API Gateway
    participant Event as Event Service
    participant AI as AI Service
    participant Cache as Redis Cache
    participant Claude as Claude API

    Client->>API: POST /api/ai/recommendations<br/>(업종, 지역, 목적)
    API->>Event: 이벤트 추천 요청
    Event->>AI: 추천 요청

    AI->>Cache: GET cached_result
    alt Cache HIT
        Cache-->>AI: 캐시된 결과
        AI-->>Event: 즉시 반환 (0.1초)
        Event-->>API: 결과
        API-->>Client: 결과 (Total: 0.2초)
    else Cache MISS
        Cache-->>AI: null
        AI-->>Event: Job ID 즉시 반환
        Event-->>API: Job ID
        API-->>Client: Job ID + 처리중 상태 (0.1초)

        AI->>Claude: 비동기 AI 호출
        Note over AI,Claude: 백그라운드 처리 (10초)
        Claude-->>AI: 추천 결과
        AI->>Cache: SET result (TTL 24h)
        AI->>AI: Job 상태 = 완료

        loop 폴링 (5초 간격)
            Client->>API: GET /api/jobs/{id}
            API->>Event: Job 상태 확인
            Event->>AI: Job 상태
            alt 완료
                AI-->>Event: 결과
                Event-->>API: 결과
                API-->>Client: 최종 결과
            else 진행중
                AI-->>Event: 진행중
                Event-->>API: 진행중
                API-->>Client: 진행 상황 (예: 70%)
            end
        end
    end

3.3 Distribution Service - Circuit Breaker 패턴

graph TB
    subgraph "Distribution Service"
        DistCtrl[Distribution Controller]
        CB_Uri[Circuit Breaker<br/>우리동네TV]
        CB_Ringo[Circuit Breaker<br/>링고비즈]
        CB_Genie[Circuit Breaker<br/>지니TV]
        CB_SNS[Circuit Breaker<br/>SNS]
    end

    subgraph "외부 API"
        UriAPI[우리동네TV API]
        RingoAPI[링고비즈 API]
        GenieAPI[지니TV API]
        SNSAPI[SNS API]
    end

    DistCtrl --> CB_Uri
    DistCtrl --> CB_Ringo
    DistCtrl --> CB_Genie
    DistCtrl --> CB_SNS

    CB_Uri -->|실패율 < 5%<br/>Closed| UriAPI
    CB_Uri -.->|실패율 >= 5%<br/>Open, Fallback| Fallback_Uri[배포 스킵<br/>+ 알림]

    CB_Ringo -->|실패율 < 5%<br/>Closed| RingoAPI
    CB_Ringo -.->|실패율 >= 5%<br/>Open, Fallback| Fallback_Ringo[배포 스킵<br/>+ 알림]

    CB_Genie -->|실패율 < 5%<br/>Closed| GenieAPI
    CB_Genie -.->|실패율 >= 5%<br/>Open, Fallback| Fallback_Genie[배포 스킵<br/>+ 알림]

    CB_SNS -->|실패율 < 5%<br/>Closed| SNSAPI
    CB_SNS -.->|실패율 >= 5%<br/>Open, Fallback| Fallback_SNS[배포 스킵<br/>+ 알림]

    style CB_Uri fill:#ffe1e1
    style CB_Ringo fill:#ffe1e1
    style CB_Genie fill:#ffe1e1
    style CB_SNS fill:#ffe1e1

4. MVP 구현 로드맵

4.1 단일 Phase MVP 전략

목표: 빠른 출시와 안정적 서비스 제공

기간: 12주

목표 지표:

사용자: 100명
동시 이벤트: 50개
시스템 가용성: 99%
AI 응답 시간: 10초 이내 (캐시 미스), 0.1초 (캐시 히트)

4.2 구현 순서 및 일정

주차	작업 내용	패턴 적용	완료 기준
1-2주	인프라 구축	API Gateway	- Kong/AWS API Gateway 설정 - Redis 클러스터 구축 - JWT 인증 구현
3-4주	User/Event 서비스	Cache-Aside	- 회원가입/로그인 완료 - 사업자번호 검증 캐싱 - 이벤트 CRUD 완료
5-6주	AI 서비스	Asynchronous Request-Reply Cache-Aside	- Claude API 연동 - Job 기반 비동기 처리 - AI 결과 캐싱 (24시간 TTL)
7-8주	Content 서비스	Asynchronous Request-Reply Cache-Aside	- Stable Diffusion 연동 - 이미지 생성 Job 처리 - 이미지 캐싱 및 CDN
9-10주	Distribution 서비스	Circuit Breaker	- 7개 외부 API 연동 - 각 API별 Circuit Breaker - Fallback 전략 구현
11주	Participation/Analytics	Cache-Aside	- 참여자 관리 및 추첨 - 대시보드 데이터 캐싱
12주	테스트 및 출시	전체 패턴 검증	- 부하 테스트 (100명) - 장애 시나리오 테스트 - MVP 출시

4.3 기술 스택

백엔드:

Spring Boot 3.2 (Java 17) / Node.js 20
Redis 7.2 (Cache)
PostgreSQL 15 (주 DB)
RabbitMQ / Kafka (비동기 처리, Optional)

프론트엔드:

React 18 + TypeScript 5
Next.js 14 (SSR)
Zustand (상태관리)
React Query (서버 상태 관리)

인프라:

Docker + Kubernetes
Kong API Gateway / AWS API Gateway
Resilience4j (Circuit Breaker)
Prometheus + Grafana (모니터링)

외부 API:

Claude API / GPT-4 API
Stable Diffusion API
국세청 사업자등록정보 진위확인 API
우리동네TV, 링고비즈, 지니TV, SNS API

5. 예상 성과

5.1 성능 개선

항목	Before	After	개선율
AI 응답 시간 (캐시 히트)	10초	0.1초	99% 개선
AI 응답 시간 (캐시 미스)	10초	10초	-
이미지 생성 시간 (캐시 히트)	5초	0.1초	98% 개선
대시보드 로딩 시간	3초	0.5초	83% 개선

5.2 비용 절감

AI API 비용 절감 (캐시 히트율 80% 가정):

Before: 1,000 요청/일 × $0.02 = $20/일 = $600/월
After: 200 요청/일 × $0.02 = $4/일 = $120/월
절감액: $480/월 (80% 절감)

이미지 생성 비용 절감 (캐시 히트율 80% 가정):

Before: 500 이미지/일 × $0.04 = $20/일 = $600/월
After: 100 이미지/일 × $0.04 = $4/일 = $120/월
절감액: $480/월 (80% 절감)

총 비용 절감:

Before: $1,200/월
After: $240/월
총 절감액: $960/월 (80% 절감)

5.3 가용성 개선

지표	Before	After	개선
시스템 가용성	95%	99%	+4%p
외부 API 장애 시 서비스 지속	❌ 불가	✅ 가능 (Fallback)	-
장애 자동 복구 시간	5분 (수동)	30초 (자동)	90% 단축

5.4 개발 생산성

항목	효과
API Gateway	각 서비스 인증 로직 제거 → 개발 시간 30% 단축
Cache-Aside	반복 API 호출 제거 → 테스트 시간 50% 단축
Circuit Breaker	장애 처리 로직 자동화 → 예외 처리 코드 40% 감소
Async Request-Reply	동시 처리 능력 5배 증가

6. 운영 고려사항

6.1 모니터링 지표

Cache-Aside:

캐시 히트율 (목표: 80% 이상)
Redis 메모리 사용률 (목표: 70% 이하)
캐시 응답 시간 (목표: 100ms 이하)

API Gateway:

요청 처리량 (TPS)
평균 응답 시간
인증 실패율

Circuit Breaker:

API별 실패율
Circuit 상태 (Closed/Open/Half-Open)
Fallback 호출 횟수

Asynchronous Request-Reply:

Job 처리 시간
동시 Job 수
Job 완료율

6.2 알람 임계값

지표	Warning	Critical
캐시 히트율	< 70%	< 50%
Redis 메모리	> 80%	> 90%
API 응답 시간	> 500ms	> 1000ms
Circuit Breaker Open	1개	3개 이상
시스템 가용성	< 99%	< 95%

6.3 장애 대응 절차

Circuit Breaker Open 발생 시:

알람 수신 (Slack/Email)
해당 외부 API 상태 확인
Fallback 전략 동작 확인
30초 후 자동 복구 확인
복구 실패 시 수동 개입

캐시 장애 시:

Redis 클러스터 상태 확인
Failover 자동 수행 (Sentinel)
캐시 미스로 전환 (성능 저하 허용)
긴급 Redis 복구

7. 체크리스트

7.1 패턴 적용 완료 확인

Cache-Aside: AI 결과, 이미지, 사업자번호 검증 캐싱 완료
API Gateway: 인증, 라우팅, Rate Limiting 구현 완료
Asynchronous Request-Reply: AI 및 이미지 생성 Job 처리 완료
Circuit Breaker: 7개 외부 API에 Circuit Breaker 및 Fallback 적용 완료

7.2 성능 목표 달성 확인

AI 응답 시간: 10초 이내 (캐시 미스), 0.1초 (캐시 히트)
캐시 히트율: 80% 이상
시스템 가용성: 99% 이상
비용 절감: 월 $960 (80%)

7.3 운영 준비 완료 확인

모니터링 대시보드 구축 (Prometheus + Grafana)
알람 설정 완료 (Slack/Email)
장애 대응 매뉴얼 작성
부하 테스트 완료 (100명)

8. 다음 단계 (Phase 2 이후)

MVP 이후 확장 계획 (선택 사항):

Retry 패턴: 일시적 오류 자동 재시도 (현재는 Circuit Breaker로 커버)
Queue-Based Load Leveling: 트래픽 폭증 시 부하 분산
Saga 패턴: 복잡한 분산 트랜잭션 관리 (이벤트 생성 플로우)
CQRS: 읽기/쓰기 분리로 대시보드 성능 최적화
Event Sourcing: 이벤트 변경 이력 추적 및 감사

20 KiB Raw Blame History Unescape Escape

KT AI 기반 소상공인 이벤트 자동 생성 서비스 - 클라우드 아키텍처 패턴 적용 방안 (MVP)

문서 정보

1. 요구사항 분석

1.1 기능적 요구사항

1.2 비기능적 요구사항

1.3 외부 API 의존성

1.4 기술적 도전과제

1. AI 응답 시간 관리 (🔴 Critical)

2. 다중 외부 API 의존성 (🔴 Critical)

3. 이미지 생성 비용 및 시간 (🟡 Important)

4. 실시간 대시보드 성능 (🟡 Important)

2. 패턴 선정 및 평가

2.1 MVP 핵심 패턴 (4개)

2.2 정량적 평가 매트릭스

2.3 패턴별 상세 분석

2.3.1 Cache-Aside (9.45점) - 🔴 Critical

2.3.2 API Gateway (8.45점) - 🔴 Critical

2.3.3 Asynchronous Request-Reply (8.40점) - 🔴 Critical

2.3.4 Circuit Breaker (8.30점) - 🟡 Optional

3. 서비스별 패턴 적용 설계

3.1 전체 아키텍처 (MVP)

3.2 AI Service - Asynchronous Request-Reply 패턴

3.3 Distribution Service - Circuit Breaker 패턴

4. MVP 구현 로드맵

4.1 단일 Phase MVP 전략

4.2 구현 순서 및 일정

4.3 기술 스택

5. 예상 성과

5.1 성능 개선

5.2 비용 절감

5.3 가용성 개선

5.4 개발 생산성

6. 운영 고려사항

6.1 모니터링 지표

6.2 알람 임계값

6.3 장애 대응 절차

7. 체크리스트

7.1 패턴 적용 완료 확인

7.2 성능 목표 달성 확인

7.3 운영 준비 완료 확인

8. 다음 단계 (Phase 2 이후)

참고 문서

20 KiB

Raw Blame History