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 개발환경 아키텍처
📄 물리 아키텍처 설계서 - 개발환경
주요 특징:
- 비용 최적화: Basic SKU 리소스 활용으로 월 $200 이하
- 개발 편의성: 복잡한 설정 최소화, 빠른 배포 (5분 이내)
- 단순한 보안: 기본 Network Policy, JWT 검증
- Pod 기반 백킹서비스: PostgreSQL, Redis Pod으로 외부 의존성 제거
핵심 구성:
📊 개발환경 물리 아키텍처 다이어그램
- NGINX Ingress → AKS Basic → Pod Services 구조
- 7개 애플리케이션 Pod + PostgreSQL Pod + Redis Pod 배치
- Single Zone 배포로 비용 최적화
📊 개발환경 네트워크 다이어그램
- VNet 단일 서브넷 구성 (10.0.0.0/16)
- External LoadBalancer를 통한 외부 접근
- Internal ClusterIP 서비스 간 통신
2.2.2 운영환경 아키텍처
📄 물리 아키텍처 설계서 - 운영환경
주요 특징:
- 고가용성: Multi-Zone 배포, 자동 장애조치 (99.9% SLA)
- 확장성: HPA 기반 자동 스케일링 (최대 10배 확장)
- 엔터프라이즈 보안: 다층 보안, Private Endpoint, WAF
- 관리형 서비스: Azure Database for PostgreSQL, Azure Cache for Redis
핵심 구성:
📊 운영환경 물리 아키텍처 다이어그램
- Azure Front Door → App Gateway + WAF → AKS Premium 구조
- Multi-Zone Apps + Azure PostgreSQL Flexible + Azure Redis Premium 배치
- Reserved Instance로 30% 비용 절약
📊 운영환경 네트워크 다이어그램
- 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 달성을 위한 고가용성 아키텍처
- 보안: 다층 보안으로 엔터프라이즈급 보안 수준 확보
향후 계획:
- Phase 1에서 개발환경 기반 MVP 검증
- Phase 2에서 운영환경 전환 및 베타 서비스
- Phase 3에서 상용 서비스 및 성능 최적화
이를 통해 안정적이고 확장 가능한 AI 기반 이벤트 생성 서비스를 제공할 수 있습니다.
3075a5d49f