kt-event-marketing/design/backend/physical/physical-architecture.md

# KT 소상공인 이벤트 자동 생성 서비스 - 물리 아키텍처 설계서 (마스터 인덱스)

## 1. 개요

### 1.1 설계 목적
- KT 소상공인 이벤트 자동 생성 서비스의 Azure Cloud 기반 물리 아키텍처 설계
- 개발환경과 운영환경의 체계적인 아키텍처 분리 및 관리
- 환경별 특화 구성과 단계적 확장 전략 제시
- 7개 마이크로서비스의 효율적인 배포 및 운영 아키텍처 구성

### 1.2 아키텍처 분리 원칙
- **환경별 특화**: 개발환경과 운영환경의 목적에 맞는 최적화
- **단계적 발전**: 개발→운영 단계적 아키텍처 진화
- **비용 효율성**: 환경별 비용 최적화 전략
- **운영 단순성**: 환경별 복잡도 적정 수준 유지
- **확장성 고려**: 향후 확장 가능한 구조 설계

### 1.3 문서 구조
```
physical-architecture.md (마스터 인덱스)
├── physical-architecture-dev.md (개발환경)
├── physical-architecture-prod.md (운영환경)
├── physical-architecture-dev.mmd (개발환경 다이어그램)
├── physical-architecture-prod.mmd (운영환경 다이어그램)
├── network-dev.mmd (개발환경 네트워크 다이어그램)
└── network-prod.mmd (운영환경 네트워크 다이어그램)
```

### 1.4 참조 아키텍처
- **HighLevel아키텍처정의서**: design/high-level-architecture.md
- **논리아키텍처**: design/backend/logical/logical-architecture.md
- **아키텍처패턴**: design/pattern/architecture-pattern.md
- **API설계서**: design/backend/api/*.yaml
- **데이터설계서**: design/backend/database/database-design.md

## 2. 환경별 아키텍처 개요

### 2.1 환경별 특성 비교

| 구분 | 개발환경 | 운영환경 |
|------|----------|----------|
| **목적** | MVP 개발/검증/테스트 | 실제 서비스 운영 |
| **가용성** | 95% (09:00-18:00) | 99.9% (24/7) |
| **사용자** | 개발팀(10명) | 실사용자(1만~10만) |
| **확장성** | 고정 리소스 | Auto Scaling (2x~10x) |
| **보안** | 기본 수준 | 엔터프라이즈급 |
| **비용** | 최소화($200/월) | 최적화($3,500/월) |
| **복잡도** | 단순화 | 고도화 |
| **배포** | 수동/반자동 | 완전 자동화 |
| **모니터링** | 기본 메트릭 | 종합 관측성 |

### 2.2 환경별 세부 문서

#### 2.2.1 개발환경 아키텍처
📄 **[물리 아키텍처 설계서 - 개발환경](./physical-architecture-dev.md)**

**주요 특징:**
- **비용 최적화**: Basic SKU 리소스 활용으로 월 $200 이하
- **개발 편의성**: 복잡한 설정 최소화, 빠른 배포 (5분 이내)
- **단순한 보안**: 기본 Network Policy, JWT 검증
- **Pod 기반 백킹서비스**: PostgreSQL, Redis Pod으로 외부 의존성 제거

**핵심 구성:**
📊 **[개발환경 물리 아키텍처 다이어그램](./physical-architecture-dev.mmd)**
- NGINX Ingress → AKS Basic → Pod Services 구조
- 7개 애플리케이션 Pod + PostgreSQL Pod + Redis Pod 배치
- Single Zone 배포로 비용 최적화

📊 **[개발환경 네트워크 다이어그램](./network-dev.mmd)**
- VNet 단일 서브넷 구성 (10.0.0.0/16)
- External LoadBalancer를 통한 외부 접근
- Internal ClusterIP 서비스 간 통신

#### 2.2.2 운영환경 아키텍처
📄 **[물리 아키텍처 설계서 - 운영환경](./physical-architecture-prod.md)**

**주요 특징:**
- **고가용성**: Multi-Zone 배포, 자동 장애조치 (99.9% SLA)
- **확장성**: HPA 기반 자동 스케일링 (최대 10배 확장)
- **엔터프라이즈 보안**: 다층 보안, Private Endpoint, WAF
- **관리형 서비스**: Azure Database for PostgreSQL, Azure Cache for Redis

**핵심 구성:**
📊 **[운영환경 물리 아키텍처 다이어그램](./physical-architecture-prod.mmd)**
- Azure Front Door → App Gateway + WAF → AKS Premium 구조
- Multi-Zone Apps + Azure PostgreSQL Flexible + Azure Redis Premium 배치
- Reserved Instance로 30% 비용 절약

📊 **[운영환경 네트워크 다이어그램](./network-prod.mmd)**
- Multi-Subnet VNet 구성 (App/DB/Cache/Gateway 서브넷 분리)
- Private Endpoint를 통한 보안 통신
- WAF + Rate Limiting으로 보안 강화

### 2.3 핵심 아키텍처 결정사항

#### 2.3.1 공통 아키텍처 원칙
- **서비스 메시 제거**: Istio 대신 Kubernetes Network Policies 사용으로 복잡도 감소
- **선택적 비동기**: AI 일정 생성 등 장시간 작업만 비동기, 나머지는 동기 통신
- **캐시 우선**: Redis 캐시를 통한 성능 최적화 및 서비스 간 의존성 최소화
- **Managed Identity**: 키 없는 인증으로 보안 강화
- **다층 보안**: L1(Network) → L2(Gateway) → L3(Identity) → L4(Data)

#### 2.3.2 환경별 차별화 전략

**개발환경 최적화:**
- 개발 속도와 비용 효율성 우선
- Pod 기반 백킹서비스로 Azure 관리형 서비스 비용 절약
- 단순한 구성으로 운영 부담 최소화
- 기능 검증 중심의 최소 보안 설정

**운영환경 최적화:**
- 가용성과 확장성 우선 (99.9% SLA 달성)
- Azure 관리형 서비스로 운영 안정성 확보
- 엔터프라이즈급 보안 및 종합 모니터링
- 실사용자 대응 성능 최적화

## 3. 네트워크 아키텍처 비교

### 3.1 환경별 네트워크 전략

#### 3.1.1 환경별 네트워크 전략 비교

| 구성 요소 | 개발환경 | 운영환경 | 비교 |
|-----------|----------|----------|------|
| **인그레스** | NGINX Ingress | Azure App Gateway + WAF | 비용 vs 보안 |
| **네트워크** | Single VNet + 단일 서브넷 | Multi-Subnet VNet | 단순성 vs 격리 |
| **보안** | Basic Network Policy | WAF + Rate Limiting | 기본 vs 고급 |
| **접근** | Public LoadBalancer | Private Endpoint | 편의성 vs 보안 |
| **DNS** | ClusterIP 서비스 | Azure Private DNS | 내부 vs 통합 |
| **트래픽** | HTTP/HTTPS | HTTPS + TLS 1.3 | 기본 vs 강화 |

### 3.2 네트워크 보안 전략

#### 3.2.1 공통 보안 원칙
- **Network Policies**: Pod 간 통신 제어 및 마이크로서비스 간 격리
- **Managed Identity**: Azure AD 통합 인증으로 키 관리 부담 제거
- **Private Endpoints**: 운영환경에서 Azure 서비스 간 프라이빗 통신
- **TLS 암호화**: 모든 서비스 간 통신에 TLS 1.2 이상 적용

#### 3.2.2 환경별 보안 수준

| 보안 영역 | 개발환경 | 운영환경 | 강화 수준 |
|-----------|----------|----------|----------|
| **Network Policy** | 기본 Pod 격리 | 세밀한 서비스별 제어 | 5배 강화 |
| **시크릿 관리** | Kubernetes Secret | Azure Key Vault | 10배 강화 |
| **암호화** | TLS 1.2 | TLS 1.3 + Perfect Forward Secrecy | 2배 강화 |
| **웹 보안** | 없음 | WAF + DDoS Protection | 신규 도입 |

## 4. 데이터 아키텍처 비교

### 4.1 환경별 데이터 전략

#### 4.1.1 환경별 데이터 구성 비교

| 구분 | 개발환경 | 운영환경 | 성능 차이 |
|------|----------|----------|----------|
| **주 데이터베이스** | PostgreSQL 13 Pod | Azure Database for PostgreSQL Flexible | 3배 성능 향상 |
| **가용성** | Single Pod | Multi-Zone HA + 읽기 복제본 | 99.9% vs 95% |
| **백업** | 수동 스냅샷 | 자동 백업 (35일 보존) | 자동화 |
| **확장성** | 고정 리소스 | 자동 스케일링 | 10배 확장 |
| **비용** | $20/월 | $400/월 | 20배 차이 |

### 4.2 캐시 전략 비교

#### 4.2.1 다층 캐시 아키텍처

| 캐시 레벨 | 용도 | 개발환경 | 운영환경 |
|-----------|------|----------|----------|
| **L1 Application** | 메모리 캐시 | In-Memory (1GB) | In-Memory (4GB) |
| **L2 Distributed** | 분산 캐시 | Redis Pod | Azure Cache for Redis Premium |
| **성능** | 응답 시간 | 100ms | 50ms |
| **가용성** | 캐시 SLA | 95% | 99.9% |

#### 4.2.2 환경별 캐시 특성 비교

| 특성 | 개발환경 | 운영환경 | 개선 효과 |
|------|----------|----------|----------|
| **캐시 구성** | 단일 Redis Pod | Redis Cluster (Multi-Zone) | 고가용성 |
| **데이터 지속성** | 임시 저장 | 영구 저장 + 백업 | 데이터 안정성 |
| **성능 특성** | 기본 | Premium with RDB persistence | 2배 성능 향상 |
| **메모리** | 1GB | 6GB (P2 SKU) | 6배 확장 |

## 5. 보안 아키텍처 비교

### 5.1 다층 보안 아키텍처

#### 5.1.1 공통 보안 계층

| 보안 계층 | 보안 기술 | 적용 범위 | 보안 목적 |
|-----------|----------|----------|----------|
| **L1 Network** | Network Policies, NSG | Pod/서브넷 간 통신 | 네트워크 격리 |
| **L2 Gateway** | WAF, Rate Limiting | 외부 → 내부 트래픽 | 애플리케이션 보호 |
| **L3 Identity** | Azure AD, Managed Identity | 서비스 인증/인가 | ID 기반 보안 |
| **L4 Data** | TDE, 저장소 암호화 | 데이터 저장/전송 | 데이터 보호 |

### 5.2 환경별 보안 수준

#### 5.2.1 환경별 보안 수준 비교

| 보안 영역 | 개발환경 | 운영환경 | 강화 방안 |
|-----------|----------|----------|----------|
| **인증** | JWT 기본 검증 | Azure AD B2C + MFA | 다단계 인증 |
| **네트워크** | Basic Network Policy | Micro-segmentation | 세분화된 제어 |
| **시크릿** | K8s Secret | Azure Key Vault + HSM | 하드웨어 보안 |
| **암호화** | TLS 1.2 | TLS 1.3 + E2E 암호화 | 종단간 암호화 |

## 6. 모니터링 및 운영

### 6.1 환경별 모니터링 전략

#### 6.1.1 환경별 모니터링 도구 비교

| 모니터링 영역 | 개발환경 | 운영환경 | 커버리지 |
|---------------|----------|----------|----------|
| **모니터링 도구** | Kubernetes Dashboard | Azure Monitor + Application Insights | 기본 vs 종합 |
| **메트릭** | CPU, Memory | CPU, Memory, 비즈니스 메트릭 | 10배 확장 |
| **알림** | 없음 | 심각도별 알림 (5분 이내) | 신규 도입 |
| **로그 수집** | kubectl logs | 중앙집중식 Log Analytics | 통합 관리 |
| **APM** | 없음 | Application Insights | 성능 추적 |

### 6.2 CI/CD 및 배포 전략

#### 6.2.1 환경별 배포 방식 비교

| 배포 측면 | 개발환경 | 운영환경 | 자동화 수준 |
|-----------|----------|----------|-------------|
| **배포 방식** | kubectl apply | GitOps (ArgoCD) | 수동 vs 자동 |
| **자동화** | 부분 자동화 | 완전 자동화 | 5배 향상 |
| **테스트** | 단위 테스트 | 단위+통합+E2E 테스트 | 3배 확장 |
| **다운타임** | 허용 (30초) | Zero-downtime 배포 | 99.9% 개선 |
| **롤백** | 수동 | 자동 롤백 (2분 이내) | 완전 자동화 |

## 7. 비용 분석

### 7.1 환경별 비용 구조

#### 7.1.1 월간 비용 비교

| 구성 요소 | 개발환경 | 운영환경 | 비용 차이 |
|-----------|----------|----------|----------|
| **AKS 클러스터** | $30 (Basic) | $400 (Standard) | 13배 |
| **컴퓨팅 리소스** | $50 (B2s) | $800 (D4s_v3) | 16배 |
| **데이터베이스** | $20 (Pod) | $600 (Flexible) | 30배 |
| **캐시** | $0 (Pod) | $300 (Premium P2) | 신규 비용 |
| **네트워킹** | $10 | $150 (App Gateway) | 15배 |
| **스토리지** | $20 | $100 | 5배 |
| **모니터링** | $0 | $150 | 신규 비용 |
| **보안** | $0 | $100 (Key Vault) | 신규 비용 |
| **예비비(10%)** | $13 | $260 | - |
| **총 월간 비용** | **$143** | **$2,860** | **20배** |

#### 7.1.2 환경별 비용 최적화 전략 비교

| 최적화 영역 | 개발환경 | 운영환경 | 절약 효과 |
|-------------|----------|----------|----------|
| **컴퓨팅** | Spot Instance 활용 | Reserved Instance 1년 | 30% 절약 |
| **백킹서비스** | Pod 기반으로 무료 | 관리형 서비스 필요 | 운영비 vs 인건비 |
| **리소스 관리** | 고정 리소스 | Auto Scaling | 50% 활용률 개선 |

## 8. 전환 및 확장 계획

### 8.1 개발환경 → 운영환경 전환 체크리스트

| 카테고리 | 전환 작업 | 예상 시간 | 담당자 |
|----------|----------|----------|--------|
| **데이터 마이그레이션** | PostgreSQL Pod → Azure Database | 4시간 | Backend Dev |
| **설정 변경** | ConfigMap → Azure Key Vault | 2시간 | DevOps |
| **네트워크 구성** | NGINX → App Gateway + WAF | 6시간 | DevOps |
| **모니터링 설정** | Azure Monitor + Application Insights | 4시간 | DevOps |
| **보안 강화** | Private Endpoint + RBAC | 4시간 | Security |
| **성능 테스트** | 부하 테스트 및 튜닝 | 8시간 | QA + DevOps |
| **문서화** | 운영 가이드 작성 | 4시간 | Technical Writer |

### 8.2 단계별 확장 로드맵

| 단계 | 기간 | 핵심 목표 | 주요 작업 | 사용자 지원 | 가용성 |
|------|------|----------|----------|-------------|----------|
| **Phase 1** | 1-3개월 | MVP 검증 | 개발환경 구축, 기능 개발 | 100명 | 95% |
| **Phase 2** | 4-6개월 | 베타 런칭 | 운영환경 전환, 보안 강화 | 1,000명 | 99% |
| **Phase 3** | 7-12개월 | 상용 서비스 | 자동 스케일링, 성능 최적화 | 10,000명 | 99.9% |

## 9. 핵심 SLA 지표

### 9.1 환경별 서비스 수준 목표

| SLA 지표 | 개발환경 | 운영환경 | 개선 비율 |
|----------|----------|----------|----------|
| **가용성** | 95% (09:00-18:00) | 99.9% (24/7) | 50배 개선 |
| **응답시간** | <1초 (50%ile) | <500ms (95%ile) | 2배 개선 |
| **배포시간** | 10분 | 5분 (Zero-downtime) | 2배 개선 |
| **복구시간** | 30분 | 5분 (자동 복구) | 6배 개선 |
| **동시사용자** | 100명 | 10,000명 | 100배 확장 |
| **월간비용** | $143 | $2,860 | - |

---

## 결론

본 마스터 인덱스는 KT 소상공인 이벤트 자동 생성 서비스의 Azure 기반 물리 아키텍처를 환경별로 체계적으로 정리한 문서입니다.

**핵심 성과:**
- **비용 효율성**: 개발환경 월 $143로 초기 비용 최소화
- **확장성**: 운영환경에서 100배 사용자 확장 지원
- **안정성**: 99.9% SLA 달성을 위한 고가용성 아키텍처
- **보안**: 다층 보안으로 엔터프라이즈급 보안 수준 확보

**향후 계획:**
1. Phase 1에서 개발환경 기반 MVP 검증
2. Phase 2에서 운영환경 전환 및 베타 서비스
3. Phase 3에서 상용 서비스 및 성능 최적화

이를 통해 안정적이고 확장 가능한 AI 기반 이벤트 생성 서비스를 제공할 수 있습니다.