This commit is contained in:
hiondal
2025-09-09 01:12:14 +09:00
parent 7ec8a682c6
commit b489c73201
276 changed files with 43859 additions and 98 deletions
+100
View File
@@ -0,0 +1,100 @@
graph TB
%% 네트워크 구성
subgraph "Internet"
Internet[인터넷<br/>Public Network]
end
subgraph "Azure Virtual Network - phonebill-vnet-dev"
subgraph "Public Subnet - 10.0.1.0/24"
LB[Azure Load Balancer Basic<br/>Public IP<br/>80/443 포트]
Ingress[NGINX Ingress Controller<br/>10.0.1.10<br/>Internal Service]
end
subgraph "Application Subnet - 10.0.2.0/24"
Auth[Auth Service<br/>10.0.2.10:8080<br/>ClusterIP Service]
Bill[Bill-Inquiry Service<br/>10.0.2.11:8080<br/>ClusterIP Service]
Product[Product-Change Service<br/>10.0.2.12:8080<br/>ClusterIP Service]
end
subgraph "Data Subnet - 10.0.3.0/24"
PostgreSQL[PostgreSQL<br/>10.0.3.10:5432<br/>ClusterIP Service]
Redis[Redis<br/>10.0.3.11:6379<br/>ClusterIP Service]
end
subgraph "Management Subnet - 10.0.4.0/24"
K8sDashboard[Kubernetes Dashboard<br/>10.0.4.10<br/>개발용 모니터링]
end
end
subgraph "Azure Managed Services"
ServiceBus[Azure Service Bus Basic<br/>sb-phonebill-dev.servicebus.windows.net<br/>AMQP 5671, HTTPS 443]
ACR[Azure Container Registry<br/>phonebilldev.azurecr.io<br/>HTTPS 443]
end
subgraph "External Systems"
KOS[KOS-Order System<br/>On-premises<br/>HTTPS/VPN 연결]
MVNO[MVNO AP Server<br/>External System<br/>HTTPS API]
end
%% 네트워크 연결
Internet --> LB
LB --> Ingress
Ingress --> Auth
Ingress --> Bill
Ingress --> Product
Auth --> PostgreSQL
Auth --> Redis
Bill --> PostgreSQL
Bill --> Redis
Product --> PostgreSQL
Product --> Redis
Bill --> ServiceBus
Product --> ServiceBus
Auth -.-> ACR
Bill -.-> ACR
Product -.-> ACR
Bill --> KOS
Product --> KOS
MVNO --> LB
%% DNS 서비스
subgraph "DNS Resolution"
CoreDNS[CoreDNS<br/>Cluster DNS<br/>10.0.0.10]
end
Auth -.-> CoreDNS
Bill -.-> CoreDNS
Product -.-> CoreDNS
%% 네트워크 보안
subgraph "Network Security"
NSG[Network Security Group<br/>기본 보안 규칙<br/>개발환경 허용적 정책]
NetworkPolicy[Kubernetes Network Policy<br/>기본 허용 정책<br/>개발 편의성 우선]
end
%% 스타일링
classDef internet fill:#ffebee
classDef public fill:#e3f2fd
classDef application fill:#e8f5e8
classDef data fill:#fff3e0
classDef management fill:#f3e5f5
classDef managed fill:#fce4ec
classDef external fill:#e1f5fe
classDef security fill:#fff8e1
classDef dns fill:#f1f8e9
class Internet internet
class LB,Ingress public
class Auth,Bill,Product application
class PostgreSQL,Redis data
class K8sDashboard management
class ServiceBus,ACR managed
class KOS,MVNO external
class NSG,NetworkPolicy security
class CoreDNS dns
+149
View File
@@ -0,0 +1,149 @@
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor': '#ffffff', 'primaryTextColor': '#000000', 'primaryBorderColor': '#000000', 'lineColor': '#000000'}}}%%
graph TB
%% 인터넷 및 외부
subgraph "Internet & External"
Internet[🌐 Internet<br/>HTTPS Traffic]
KOS[🏢 KOS-Order System<br/>On-premises<br/>Private Connection]
end
%% Azure Edge Services
subgraph "Azure Edge (Global)"
AFD[☁️ Azure Front Door<br/>Entry Point: *.phonebill.com<br/>DDoS Protection Standard<br/>CDN + WAF Policy]
end
%% Azure Virtual Network
subgraph "Azure VNet (10.0.0.0/16) - Korea Central"
%% Gateway Subnet
subgraph "Gateway Subnet (10.0.4.0/24)"
AppGW[🛡️ Application Gateway<br/>Public IP: 20.194.xxx.xxx<br/>Private IP: 10.0.4.10<br/>Standard_v2 + WAF<br/>SSL Termination]
subgraph "WAF Configuration"
WAF[🔒 Web Application Firewall<br/>• OWASP CRS 3.2<br/>• Rate Limiting: 100/min<br/>• Prevention Mode<br/>• Custom Rules]
end
end
%% Application Subnet
subgraph "Application Subnet (10.0.1.0/24)"
subgraph "AKS Cluster Network"
LB[⚖️ Internal Load Balancer<br/>ClusterIP: 10.0.1.100<br/>Service Distribution]
subgraph "Pod Network (CNI)"
AuthSvc[🔐 Auth Service<br/>ClusterIP: 10.0.1.10<br/>Port: 8080<br/>Replicas: 3-10]
BillSvc[📊 Bill-Inquiry Service<br/>ClusterIP: 10.0.1.20<br/>Port: 8080<br/>Replicas: 3-15]
ProductSvc[🔄 Product-Change Service<br/>ClusterIP: 10.0.1.30<br/>Port: 8080<br/>Replicas: 2-8]
end
end
subgraph "Service Bus Private Endpoint"
SBEndpoint[📨 Service Bus PE<br/>10.0.1.200<br/>sb-phonebill-prod.servicebus.windows.net]
end
subgraph "Key Vault Private Endpoint"
KVEndpoint[🔑 Key Vault PE<br/>10.0.1.210<br/>kv-phonebill-prod.vault.azure.net]
end
end
%% Database Subnet
subgraph "Database Subnet (10.0.2.0/24)"
subgraph "PostgreSQL Private Endpoint"
PGEndpoint[🗃️ PostgreSQL PE<br/>10.0.2.10<br/>phonebill-prod.postgres.database.azure.com<br/>Port: 5432 (SSL required)]
end
subgraph "Read Replica Endpoints"
PGReplica[📚 Read Replica PE<br/>10.0.2.20<br/>phonebill-replica.postgres.database.azure.com<br/>Read-only Access]
end
end
%% Cache Subnet
subgraph "Cache Subnet (10.0.3.0/24)"
subgraph "Redis Private Endpoint"
RedisEndpoint[⚡ Redis Cache PE<br/>10.0.3.10<br/>phonebill-prod.redis.cache.windows.net<br/>Port: 6380 (SSL)<br/>Premium P2 Cluster]
end
end
end
%% Network Security Groups
subgraph "Network Security (NSG Rules)"
subgraph "Gateway NSG"
GatewayNSG[🔒 App Gateway NSG<br/>• Allow HTTPS (443) from Internet<br/>• Allow HTTP (80) from Internet<br/>• Allow GatewayManager<br/>• Deny All Other]
end
subgraph "Application NSG"
AppNSG[🔒 AKS NSG<br/>• Allow 80,443 from Gateway Subnet<br/>• Allow 5432 to Database Subnet<br/>• Allow 6380 to Cache Subnet<br/>• Allow 443 to Internet (KOS)<br/>• Allow Azure Services]
end
subgraph "Database NSG"
DBNSG[🔒 Database NSG<br/>• Allow 5432 from App Subnet<br/>• Deny All Other<br/>• Management from Azure]
end
end
%% Traffic Flow - Inbound
Internet ==> AFD
AFD ==> AppGW
AppGW ==> LB
LB ==> AuthSvc
LB ==> BillSvc
LB ==> ProductSvc
%% Service to Data Flow
AuthSvc --> PGEndpoint
BillSvc --> PGEndpoint
ProductSvc --> PGEndpoint
%% Read Replica Access
BillSvc -.-> PGReplica
%% Cache Access
AuthSvc --> RedisEndpoint
BillSvc --> RedisEndpoint
ProductSvc --> RedisEndpoint
%% Message Queue Access
BillSvc --> SBEndpoint
ProductSvc --> SBEndpoint
%% Security Access
AuthSvc --> KVEndpoint
BillSvc --> KVEndpoint
ProductSvc --> KVEndpoint
%% External System Access
BillSvc -.-> KOS
ProductSvc -.-> KOS
%% DNS Resolution
subgraph "Private DNS Zones"
DNS1[🌐 privatelink.postgres.database.azure.com<br/>PostgreSQL DNS Resolution]
DNS2[🌐 privatelink.redis.cache.windows.net<br/>Redis DNS Resolution]
DNS3[🌐 privatelink.servicebus.windows.net<br/>Service Bus DNS Resolution]
DNS4[🌐 privatelink.vaultcore.azure.net<br/>Key Vault DNS Resolution]
end
%% Network Policies
subgraph "Kubernetes Network Policies"
NetPol[📜 Network Policies<br/>• Default Deny All<br/>• Allow Ingress from App Gateway<br/>• Allow Egress to Data Services<br/>• Allow Egress to External (KOS)<br/>• Inter-service Communication Rules]
end
%% Monitoring & Logging
subgraph "Network Monitoring"
NetMon[📊 Network Monitoring<br/>• NSG Flow Logs<br/>• Application Gateway Logs<br/>• VNet Flow Logs<br/>• Connection Monitor]
end
%% 스타일링
classDef internetClass fill:#e3f2fd,stroke:#0277bd,stroke-width:2px
classDef azureEdgeClass fill:#e8f5e8,stroke:#388e3c,stroke-width:2px
classDef networkClass fill:#fff3e0,stroke:#f57c00,stroke-width:2px
classDef appClass fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef dataClass fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef securityClass fill:#ffebee,stroke:#d32f2f,stroke-width:2px
class Internet,KOS internetClass
class AFD azureEdgeClass
class AppGW,LB,NetMon networkClass
class AuthSvc,BillSvc,ProductSvc,SBEndpoint appClass
class PGEndpoint,RedisEndpoint,PGReplica dataClass
class GatewayNSG,AppNSG,DBNSG,WAF,KVEndpoint,NetPol securityClass
@@ -0,0 +1,526 @@
# 물리 아키텍처 설계서 - 개발환경
## 1. 개요
### 1.1 설계 목적
- 통신요금 관리 서비스의 **개발환경** 물리 아키텍처 설계
- MVP 단계의 빠른 개발과 검증을 위한 최소 구성
- 비용 효율성과 개발 편의성 우선
### 1.2 설계 원칙
- **MVP 우선**: 빠른 개발과 검증을 위한 최소 구성
- **비용 최적화**: Spot Instances, Pod 기반 백킹서비스 활용
- **개발 편의성**: 복잡한 설정 최소화, 빠른 배포
- **단순성**: 운영 복잡도 최소화
### 1.3 참조 아키텍처
- 마스터 아키텍처: design/backend/physical/physical-architecture.md
- HighLevel아키텍처정의서: design/high-level-architecture.md
- 논리아키텍처: design/backend/logical/logical-architecture.md
- 유저스토리: design/userstory.md
## 2. 개발환경 아키텍처 개요
### 2.1 환경 특성
- **목적**: 빠른 개발과 검증
- **사용자**: 개발팀 (5명)
- **가용성**: 95% (월 36시간 다운타임 허용)
- **확장성**: 제한적 (고정 리소스)
- **보안**: 기본 보안 (복잡한 보안 설정 최소화)
### 2.2 전체 아키텍처
📄 **[개발환경 물리 아키텍처 다이어그램](./physical-architecture-dev.mmd)**
**주요 구성 요소:**
- NGINX Ingress Controller → AKS 기본 클러스터
- 애플리케이션 Pod: Auth, Bill-Inquiry, Product-Change, KOS-Mock Service
- 백킹서비스 Pod: PostgreSQL (Local Storage), Redis (Memory Only)
## 3. 컴퓨팅 아키텍처
### 3.1 Azure Kubernetes Service (AKS) 구성
#### 3.1.1 클러스터 설정
| 설정 항목 | 값 | 설명 |
|-----------|----|---------|
| Kubernetes 버전 | 1.29 | 안정화된 최신 버전 |
| 서비스 계층 | Basic | 비용 최적화 |
| Network Plugin | Azure CNI | Azure 네이티브 네트워킹 |
| Network Policy | Kubernetes Network Policies | 기본 Pod 통신 제어 |
| Ingress Controller | NGINX Ingress Controller | 오픈소스 Ingress |
| DNS | CoreDNS | 클러스터 DNS |
#### 3.1.2 노드 풀 구성
| 설정 항목 | 값 | 설명 |
|-----------|----|---------|
| VM 크기 | Standard_B2s | 2 vCPU, 4GB RAM |
| 노드 수 | 2 | 고정 노드 수 |
| 자동 스케일링 | Disabled | 비용 절약을 위한 고정 크기 |
| 최대 Pod 수 | 30 | 노드당 최대 Pod |
| 가용 영역 | Zone-1 | 단일 영역 (비용 절약) |
| 가격 정책 | Spot Instance | 70% 비용 절약 |
### 3.2 서비스별 리소스 할당
#### 3.2.1 애플리케이션 서비스
| 서비스 | CPU Requests | Memory Requests | CPU Limits | Memory Limits | Replicas |
|--------|--------------|-----------------|------------|---------------|----------|
| Auth Service | 50m | 128Mi | 200m | 256Mi | 1 |
| Bill-Inquiry Service | 100m | 256Mi | 500m | 512Mi | 1 |
| Product-Change Service | 100m | 256Mi | 500m | 512Mi | 1 |
| KOS-Mock Service | 50m | 128Mi | 200m | 256Mi | 1 |
#### 3.2.2 백킹 서비스
| 서비스 | CPU Requests | Memory Requests | CPU Limits | Memory Limits | Storage |
|--------|--------------|-----------------|------------|---------------|---------|
| PostgreSQL | 500m | 1Gi | 1000m | 2Gi | 20GB (Azure Disk Standard) |
| Redis | 100m | 256Mi | 500m | 1Gi | Memory Only |
#### 3.2.3 스토리지 클래스 구성
| 스토리지 클래스 | 제공자 | 성능 | 용도 | 백업 정책 |
|----------------|--------|------|------|-----------|
| managed-standard | Azure Disk | Standard HDD | 개발용 데이터 저장 | 수동 백업 |
| managed-premium | Azure Disk | Premium SSD | 미사용 (비용 절약) | - |
## 4. 네트워크 아키텍처
### 4.1 네트워크 구성
#### 4.1.1 네트워크 토폴로지
📄 **[개발환경 네트워크 다이어그램](./network-dev.mmd)**
| 네트워크 구성요소 | 주소 대역 | 용도 | 특별 설정 |
|-----------------|----------|------|-----------|
| Virtual Network | phonebill-vnet-dev | 전체 네트워크 | Azure CNI 사용 |
| Public Subnet | 10.0.1.0/24 | Load Balancer, Ingress | 인터넷 연결 |
| Application Subnet | 10.0.2.0/24 | 애플리케이션 Pod | Private 통신 |
| Data Subnet | 10.0.3.0/24 | 데이터베이스, 캐시 | 제한적 접근 |
| Management Subnet | 10.0.4.0/24 | 모니터링, 관리 | 개발용 도구 |
#### 4.1.2 네트워크 보안
**기본 Network Policy:**
| 정책 유형 | 설정 | 설명 |
|-----------|------|---------|
| Default Policy | ALLOW_ALL_NAMESPACES | 개발 편의성을 위한 허용적 정책 |
| Complexity Level | Basic | 단순한 보안 구성 |
**Database 접근 제한:**
| 설정 항목 | 값 | 설명 |
|-----------|----|---------|
| 허용 대상 | Application Tier Pods | tier: application 레이블 |
| 프로토콜 | TCP | 데이터베이스 연결 |
| 포트 | 5432, 6379 | PostgreSQL, Redis 포트 |
### 4.2 서비스 디스커버리
| 서비스 | 내부 주소 | 포트 | 용도 |
|--------|-----------|------|------|
| Auth Service | auth-service.phonebill-dev.svc.cluster.local | 8080 | 사용자 인증 API |
| Bill-Inquiry Service | bill-inquiry-service.phonebill-dev.svc.cluster.local | 8080 | 요금 조회 API |
| Product-Change Service | product-change-service.phonebill-dev.svc.cluster.local | 8080 | 상품 변경 API |
| PostgreSQL | postgresql.phonebill-dev.svc.cluster.local | 5432 | 메인 데이터베이스 |
| Redis | redis.phonebill-dev.svc.cluster.local | 6379 | 캐시 서버 |
## 5. 데이터 아키텍처
### 5.1 데이터베이스 구성
#### 5.1.1 주 데이터베이스 Pod 구성
**기본 설정:**
| 설정 항목 | 값 | 설명 |
|-----------|----|---------|
| 컨테이너 이미지 | bitnami/postgresql:16 | 안정화된 PostgreSQL 16 |
| CPU 요청 | 500m | 기본 CPU 할당 |
| Memory 요청 | 1Gi | 기본 메모리 할당 |
| CPU 제한 | 1000m | 최대 CPU 사용량 |
| Memory 제한 | 2Gi | 최대 메모리 사용량 |
**스토리지 구성:**
| 설정 항목 | 값 | 설명 |
|-----------|----|---------|
| 스토리지 클래스 | managed-standard | Azure Disk Standard |
| 스토리지 크기 | 20Gi | 개발용 충분한 용량 |
| 마운트 경로 | /bitnami/postgresql | 데이터 저장 경로 |
| 백업 전략 | Azure Backup | 일일 자동 백업 |
**데이터베이스 설정값:**
| 설정 항목 | 값 | 설명 |
|-----------|----|---------|
| 최대 연결 수 | 100 | 동시 연결 제한 |
| Shared Buffers | 256MB | 공유 버퍼 크기 |
| Effective Cache Size | 1GB | 효과적 캐시 크기 |
| Work Memory | 4MB | 작업 메모리 |
#### 5.1.2 캐시 Pod 구성
**기본 설정:**
| 설정 항목 | 값 | 설명 |
|-----------|----|---------|
| 컨테이너 이미지 | bitnami/redis:7.2 | 최신 안정 Redis 버전 |
| CPU 요청 | 100m | 기본 CPU 할당 |
| Memory 요청 | 256Mi | 기본 메모리 할당 |
| CPU 제한 | 500m | 최대 CPU 사용량 |
| Memory 제한 | 1Gi | 최대 메모리 사용량 |
**메모리 설정:**
| 설정 항목 | 값 | 설명 |
|-----------|----|---------|
| 데이터 지속성 | Disabled | 개발용, 재시작 시 데이터 손실 허용 |
| 최대 메모리 | 512MB | 메모리 사용 제한 |
| 메모리 정책 | allkeys-lru | LRU 방식 캐시 제거 |
| TTL 설정 | 30분 | 기본 캐시 만료 시간 |
### 5.2 데이터 관리 전략
#### 5.2.1 데이터 초기화
**Kubernetes Job을 통한 데이터 초기화:**
- 데이터베이스 스키마 생성: auth, bill_inquiry, product_change 스키마
- 초기 사용자 데이터: 테스트 계정 생성 (admin, developer, tester)
- 기본 상품 데이터: KOS 연동을 위한 샘플 상품 정보
- 권한 설정: 개발팀용 기본 권한 설정
**실행 절차:**
```yaml
# 데이터 초기화 Job
apiVersion: batch/v1
kind: Job
metadata:
name: data-init-job
spec:
template:
spec:
containers:
- name: init-container
image: bitnami/postgresql:16
env:
- name: PGPASSWORD
valueFrom:
secretKeyRef:
name: postgresql-secret
key: postgres-password
command: ["/bin/bash"]
args:
- -c
- |
psql -h postgresql -U postgres -f /scripts/init-schema.sql
psql -h postgresql -U postgres -f /scripts/sample-data.sql
restartPolicy: OnFailure
```
**검증 방법:**
```bash
# 초기화 확인
kubectl exec -it postgresql-0 -- psql -U postgres -c "SELECT COUNT(*) FROM users;"
kubectl exec -it postgresql-0 -- psql -U postgres -c "SELECT COUNT(*) FROM products;"
```
#### 5.2.2 백업 전략
| 서비스 | 백업 방법 | 주기 | 보존 전략 | 참고사항 |
|--------|----------|------|-----------|----------|
| PostgreSQL | Azure Disk Snapshot | 일일 | 7일 보관 | 개발용 데이터 자동 백업 |
| Redis | 없음 | - | 메모리 전용 | 재시작 시 캐시 재구성 |
| Application Logs | Azure Monitor Logs | 실시간 | 14일 보관 | 디버깅용 로그 |
## 6. KOS-Mock 서비스
### 6.1 KOS-Mock 구성
#### 6.1.1 서비스 설정
**KOS-Mock 서비스 구성:**
| 설정 항목 | 값 | 설명 |
|-----------|----|---------|
| 컨테이너 이미지 | kos-mock:latest | 개발환경용 Mock 서비스 |
| 포트 | 8080 | HTTP REST API |
| 헬스체크 | /health | 서비스 상태 확인 |
| 데이터베이스 | PostgreSQL | Mock 데이터 저장 |
**제공 API:**
| API 경로 | 메소드 | 용도 | 응답 시간 |
|---------|--------|------|-----------|
| /api/v1/bill-inquiry | POST | 요금 조회 Mock | 100-500ms |
| /api/v1/product-change | POST | 상품 변경 Mock | 200-1000ms |
| /api/v1/customer-info | GET | 고객 정보 Mock | 50-200ms |
| /health | GET | 헬스 체크 | 10ms |
#### 6.1.2 Mock 데이터 설정
**Mock 응답 패턴:**
| 응답 타입 | 비율 | 지연시간 | 용도 |
|-----------|------|---------|------|
| 성공 응답 | 80% | 100-300ms | 정상 케이스 테스트 |
| 지연 응답 | 15% | 1-3초 | 타임아웃 테스트 |
| 오류 응답 | 5% | 100ms | 오류 처리 테스트 |
## 7. 보안 아키텍처
### 7.1 개발환경 보안 정책
#### 7.1.1 기본 보안 설정
**보안 계층별 설정값:**
| 계층 | 설정 | 수준 | 설명 |
|------|------|------|----------|
| L4 네트워크 보안 | Network Security Group | 기본 | 기본 Azure NSG 규칙 |
| L3 클러스터 보안 | Kubernetes RBAC | 기본 | 개발팀 전체 접근 권한 |
| L2 애플리케이션 보안 | JWT 인증 | 기본 | 개발용 고정 시크릿 |
| L1 데이터 보안 | TLS 1.2 | 기본 | Pod 간 암호화 통신 |
**관리 대상 시크릿:**
| 시크릿 이름 | 용도 | 순환 정책 | 저장 위치 |
|-------------|------|----------|----------|
| postgresql-secret | PostgreSQL 접근 | 수동 | Kubernetes Secret |
| redis-secret | Redis 접근 | 수동 | Kubernetes Secret |
| jwt-signing-key | JWT 토큰 서명 | 수동 | Kubernetes Secret |
| kos-mock-config | KOS-Mock 설정 | 수동 | Kubernetes ConfigMap |
#### 7.1.2 시크릿 관리
**시크릿 관리 전략:**
| 설정 항목 | 값 | 설명 |
|-----------|----|---------|
| 관리 방식 | Kubernetes Secrets | 기본 K8s 내장 방식 |
| 암호화 방식 | etcd 암호화 | 클러스터 레벨 암호화 |
| 접근 제어 | RBAC | 네임스페이스별 접근 제어 |
| 감사 로그 | Enabled | Secret 접근 로그 기록 |
### 7.2 Network Policies
#### 7.2.1 기본 정책
**Network Policy 설정:**
| 설정 항목 | 값 | 설명 |
|-----------|----|---------|
| Policy 이름 | dev-basic-policy | 개발환경 기본 정책 |
| Pod 선택자 | app=phonebill | 애플리케이션 Pod 대상 |
| Ingress 규칙 | 동일 네임스페이스 허용 | 개발환경 편의상 허용적 정책 |
| Egress 규칙 | 외부 시스템 허용 | KOS-Mock 서비스 접근 허용 |
## 8. 모니터링 및 로깅
### 8.1 기본 모니터링
#### 8.1.1 Kubernetes 기본 모니터링
**모니터링 스택 구성:**
| 구성요소 | 도구 | 상태 | 설명 |
|-----------|------|------|----------|
| 메트릭 서버 | Metrics Server | Enabled | 기본 리소스 메트릭 수집 |
| 대시보드 | Kubernetes Dashboard | Enabled | 웹 기반 클러스터 관리 |
| 로그 수집 | kubectl logs | Manual | 수동 로그 확인 |
**기본 알림 임계값:**
| 알림 유형 | 임계값 | 대응 방안 | 알림 대상 |
|-----------|----------|-----------|----------|
| Pod Crash Loop | 5회 연속 재시작 | 개발자 Slack 알림 | 개발팀 |
| Node Not Ready | 5분 이상 | 노드 상태 점검 | 인프라팀 |
| High Memory Usage | 85% 이상 | 리소스 할당 검토 | 개발팀 |
| Disk Usage | 80% 이상 | 스토리지 정리 | 인프라팀 |
#### 8.1.2 애플리케이션 모니터링
**헬스체크 설정:**
| 설정 항목 | 값 | 설명 |
|-----------|----|---------|
| Liveness Probe | /actuator/health/liveness | Spring Boot Actuator |
| Readiness Probe | /actuator/health/readiness | 트래픽 수신 준비 상태 |
| 체크 주기 | 30초 | 상태 확인 간격 |
| 타임아웃 | 5초 | 응답 대기 시간 |
**수집 메트릭 유형:**
| 메트릭 유형 | 도구 | 용도 | 보존 기간 |
|-----------|------|------|----------|
| JVM Metrics | Micrometer | 가상머신 성능 모니터링 | 7일 |
| HTTP Request Metrics | Micrometer | API 요청 통계 | 7일 |
| Database Pool Metrics | HikariCP | DB 연결 풀 상태 | 7일 |
| Custom Business Metrics | Micrometer | 비즈니스 지표 | 7일 |
### 8.2 로깅
#### 8.2.1 로그 수집
**로그 수집 방식:**
| 설정 항목 | 값 | 설명 |
|-----------|----|---------|
| 수집 방식 | stdout/stderr | 표준 출력으로 로그 전송 |
| 저장 방식 | Azure Container Logs | AKS 기본 로그 저장소 |
| 보존 기간 | 7일 | 개발환경 단기 보존 |
| 로그 형식 | JSON | 구조화된 로그 형식 |
**로그 레벨별 설정:**
| 로거 유형 | 레벨 | 설명 |
|-----------|------|----------|
| Root Logger | INFO | 전체 시스템 기본 레벨 |
| Application Logger | DEBUG | 개발용 상세 로그 |
| Database Logger | INFO | 데이터베이스 쿼리 로그 |
| External API Logger | DEBUG | 외부 시스템 연동 로그 |
## 9. 배포 관련 컴포넌트
| 컴포넌트 유형 | 컴포넌트 | 역할 | 설정 |
|--------------|----------|------|------|
| Container Registry | Azure Container Registry Basic | 이미지 저장소 | phonebilldev.azurecr.io |
| CI | GitHub Actions | 지속적 통합 | 코드 빌드, 테스트, 이미지 빌드 |
| CD | ArgoCD | GitOps 배포 | 자동 배포, 롤백 |
| 패키지 관리 | Helm | Kubernetes 패키지 관리 | values-dev.yaml 설정 |
| 환경별 설정 | ConfigMap | 환경 변수 관리 | 개발환경 전용 설정 |
| 시크릿 관리 | Kubernetes Secret | 민감 정보 관리 | DB 연결 정보 등 |
## 10. 비용 최적화
### 10.1 개발환경 비용 구조
#### 10.1.1 주요 비용 요소
| 구성요소 | 사양 | 월간 예상 비용 (USD) | 절약 방안 |
|----------|------|---------------------|-----------|
| AKS 클러스터 | 관리형 서비스 | $73 | 기본 서비스 계층 사용 |
| 노드 풀 (VM) | Standard_B2s × 2 | $60 | Spot Instance 적용 |
| Azure Disk | Standard 20GB × 2 | $5 | 개발용 최소 용량 |
| Load Balancer | Basic | $18 | 기본 계층 사용 |
| Container Registry | Basic | $5 | 개발용 기본 계층 |
| 네트워킹 | 데이터 전송 | $10 | 단일 리전 사용 |
| **총합** | | **$171** | **Spot Instance로 $42 절약 가능** |
#### 10.1.2 비용 절약 전략
**컴퓨팅 영역별 절약 방안:**
| 절약 방안 | 절약률 | 적용 방법 | 예상 절약 금액 |
|-----------|----------|----------|----------------|
| Spot Instances | 70% | 노드 풀에 Spot VM 사용 | $42/월 |
| 비업무시간 자동 종료 | 50% | 야간/주말 클러스터 스케일다운 | $30/월 |
| 리소스 Right-sizing | 20% | requests/limits 최적화 | $12/월 |
**스토리지 영역별 절약 방안:**
| 절약 방안 | 절약률 | 적용 방법 | 예상 절약 금액 |
|-----------|----------|----------|----------------|
| Standard Disk 사용 | 60% | Premium 대신 Standard 사용 | 이미 적용 |
| 스토리지 크기 최적화 | 30% | 사용량 모니터링 후 크기 조정 | $2/월 |
**네트워킹 영역별 절약 방안:**
| 절약 방안 | 절약률 | 적용 방법 | 예상 절약 금액 |
|-----------|----------|----------|----------------|
| Basic Load Balancer | 50% | Standard 대신 Basic 사용 | 이미 적용 |
| 단일 리전 배포 | 100% | 데이터 전송 비용 최소화 | $5/월 |
## 11. 개발환경 운영 가이드
### 11.1 일상 운영
#### 11.1.1 환경 시작/종료
**환경 시작 절차:**
```bash
# 클러스터 스케일업
az aks scale --resource-group phonebill-dev-rg --name phonebill-dev-aks --node-count 2
# 애플리케이션 시작
kubectl scale deployment auth-service --replicas=1
kubectl scale deployment bill-inquiry-service --replicas=1
kubectl scale deployment product-change-service --replicas=1
# 백킹 서비스 시작
kubectl scale statefulset postgresql --replicas=1
kubectl scale deployment redis --replicas=1
# 상태 확인
kubectl get pods -w
```
**환경 종료 절차 (야간/주말):**
```bash
# 애플리케이션 종료
kubectl scale deployment --replicas=0 --all
# 백킹 서비스는 데이터 보존을 위해 유지
# 클러스터 스케일다운 (비용 절약)
az aks scale --resource-group phonebill-dev-rg --name phonebill-dev-aks --node-count 1
```
#### 11.1.2 데이터 관리
**개발 데이터 초기화:**
```bash
# 데이터 초기화 Job 실행
kubectl apply -f k8s/jobs/data-init-job.yaml
# 초기화 진행 상황 확인
kubectl logs -f job/data-init-job
# 데이터 초기화 확인
kubectl exec -it postgresql-0 -- psql -U postgres -c "SELECT COUNT(*) FROM users;"
```
**개발 데이터 백업:**
```bash
# 데이터베이스 백업
kubectl exec postgresql-0 -- pg_dump -U postgres phonebill > backup-$(date +%Y%m%d).sql
# Azure Disk 스냅샷 생성
az snapshot create \
--resource-group phonebill-dev-rg \
--name postgresql-snapshot-$(date +%Y%m%d) \
--source postgresql-disk
```
**데이터 복원:**
```bash
# SQL 파일로부터 복원
kubectl exec -i postgresql-0 -- psql -U postgres phonebill < backup.sql
# 스냅샷으로부터 디스크 복원
az disk create \
--resource-group phonebill-dev-rg \
--name postgresql-restored-disk \
--source postgresql-snapshot-20250108
```
### 11.2 트러블슈팅
#### 11.2.1 일반적인 문제 해결
| 문제 유형 | 원인 | 해결방안 | 예방법 |
|-----------|------|----------|----------|
| Pod Pending | 리소스 부족 | 노드 추가 또는 리소스 조정 | 리소스 사용량 모니터링 |
| Database Connection Failed | PostgreSQL Pod 재시작 | Pod 로그 확인 및 재시작 | Health Check 강화 |
| Service Unavailable | Ingress 설정 오류 | Ingress 규칙 확인 및 수정 | 배포 전 설정 검증 |
| Out of Memory | 메모리 한계 초과 | Memory Limits 증대 | 메모리 사용 패턴 분석 |
| Disk Full | 로그 파일 과다 | 로그 정리 및 보존 정책 수정 | 로그 순환 정책 설정 |
**문제 해결 절차:**
```bash
# 1. Pod 상태 확인
kubectl get pods -o wide
kubectl describe pod <pod-name>
# 2. 로그 확인
kubectl logs <pod-name> --tail=50
# 3. 리소스 사용량 확인
kubectl top pods
kubectl top nodes
# 4. 서비스 연결 확인
kubectl get svc
kubectl describe svc <service-name>
# 5. 네트워크 정책 확인
kubectl get networkpolicy
kubectl describe networkpolicy <policy-name>
```
## 12. 개발환경 특성 요약
**핵심 설계 원칙**: 빠른 개발 > 비용 효율 > 단순성 > 실험성
**주요 제약사항**: 95% 가용성, 제한적 확장성, 기본 보안 수준
**최적화 목표**: 개발팀 생산성 향상, 빠른 피드백 루프, 비용 효율적 운영
이 개발환경은 **통신요금 관리 서비스의 빠른 MVP 개발과 검증**에 최적화되어 있으며, Azure의 관리형 서비스를 활용하여 운영 부담을 최소화하면서도 실제 운영환경과 유사한 아키텍처 패턴을 적용했습니다.
@@ -0,0 +1,72 @@
graph TB
%% 사용자 및 외부 시스템
subgraph "External"
User[사용자<br/>MVNO 고객]
MVNO[MVNO AP Server<br/>프론트엔드]
KOS[KOS-Order System<br/>통신사 백엔드]
end
%% Azure 클라우드 환경
subgraph "Azure Cloud - 개발환경"
subgraph "Azure Kubernetes Service (AKS)"
subgraph "Ingress Layer"
Ingress[NGINX Ingress Controller<br/>Azure Load Balancer Basic]
end
subgraph "Application Layer"
Auth[Auth Service Pod<br/>CPU: 50m-200m<br/>Memory: 128Mi-256Mi<br/>Replicas: 1]
Bill[Bill-Inquiry Service Pod<br/>CPU: 100m-500m<br/>Memory: 256Mi-512Mi<br/>Replicas: 1]
Product[Product-Change Service Pod<br/>CPU: 100m-500m<br/>Memory: 256Mi-512Mi<br/>Replicas: 1]
KOSMock[KOS-Mock Service Pod<br/>CPU: 50m-200m<br/>Memory: 128Mi-256Mi<br/>Replicas: 1]
end
subgraph "Data Layer"
PostgreSQL[PostgreSQL Pod<br/>bitnami/postgresql:16<br/>CPU: 500m-1000m<br/>Memory: 1Gi-2Gi<br/>Storage: 20GB hostPath]
Redis[Redis Pod<br/>bitnami/redis:7.2<br/>CPU: 100m-500m<br/>Memory: 256Mi-1Gi<br/>Memory Only]
end
end
subgraph "Container Registry"
ACR[Azure Container Registry<br/>Basic Tier<br/>phonebilldev.azurecr.io]
end
end
%% 연결 관계
User --> MVNO
MVNO --> Ingress
Ingress --> Auth
Ingress --> Bill
Ingress --> Product
Ingress --> KOSMock
Auth --> PostgreSQL
Bill --> PostgreSQL
Product --> PostgreSQL
KOSMock --> PostgreSQL
Auth --> Redis
Bill --> Redis
Product --> Redis
Bill --> KOSMock
Product --> KOSMock
ACR -.-> Auth
ACR -.-> Bill
ACR -.-> Product
ACR -.-> KOSMock
%% 스타일링
classDef external fill:#e1f5fe
classDef ingress fill:#f3e5f5
classDef application fill:#e8f5e8
classDef data fill:#fff3e0
classDef managed fill:#fce4ec
classDef registry fill:#f1f8e9
class User,MVNO,KOS external
class Ingress ingress
class Auth,Bill,Product,KOSMock application
class PostgreSQL,Redis data
class ACR registry
File diff suppressed because it is too large Load Diff
@@ -0,0 +1,116 @@
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor': '#ffffff', 'primaryTextColor': '#000000', 'primaryBorderColor': '#000000', 'lineColor': '#000000'}}}%%
graph TB
%% 사용자 및 외부 시스템
subgraph "External Systems"
User[👤 MVNO 사용자<br/>Peak 1,000 동시사용자]
KOS[🏢 KOS-Order System<br/>통신사 백엔드<br/>On-premises]
end
%% Azure Front Door
subgraph "Azure Edge"
AFD[🌐 Azure Front Door<br/>+ CDN<br/>Global Load Balancer<br/>DDoS Protection]
end
%% Azure Virtual Network
subgraph "Azure Virtual Network (10.0.0.0/16)"
%% Application Gateway Subnet
subgraph "Gateway Subnet (10.0.4.0/24)"
AppGW[🛡️ Application Gateway<br/>Standard_v2<br/>Multi-Zone<br/>+ WAF (OWASP)]
end
%% AKS Cluster
subgraph "Application Subnet (10.0.1.0/24)"
subgraph "AKS Premium Cluster"
subgraph "System Node Pool"
SysNodes[⚙️ System Nodes<br/>D2s_v3 × 3-5<br/>Multi-Zone]
end
subgraph "Application Node Pool"
AppNodes[🖥️ App Nodes<br/>D4s_v3 × 3-10<br/>Multi-Zone<br/>Auto-scaling]
subgraph "Microservices Pods"
AuthPod[🔐 Auth Service<br/>Replicas: 3-10<br/>200m CPU, 512Mi RAM]
BillPod[📊 Bill-Inquiry Service<br/>Replicas: 3-15<br/>500m CPU, 1Gi RAM]
ProductPod[🔄 Product-Change Service<br/>Replicas: 2-8<br/>300m CPU, 768Mi RAM]
KOSMockPod[🔧 KOS-Mock Service<br/>Replicas: 2-4<br/>200m CPU, 512Mi RAM]
end
end
end
end
%% Database Subnet
subgraph "Database Subnet (10.0.2.0/24)"
PG[🗃️ Azure PostgreSQL<br/>Flexible Server<br/>GeneralPurpose D4s_v3<br/>Zone Redundant HA<br/>256GB Premium SSD<br/>35일 백업]
ReadReplica[📚 Read Replicas<br/>D2s_v3<br/>Korea South + Central<br/>읽기 부하 분산]
end
%% Cache Subnet
subgraph "Cache Subnet (10.0.3.0/24)"
Redis[⚡ Azure Redis Cache<br/>Premium P2 (6GB)<br/>클러스터링 + 복제<br/>Zone Redundant<br/>Private Endpoint]
end
end
%% Azure 관리형 서비스
subgraph "Azure Managed Services"
KeyVault[🔑 Azure Key Vault<br/>Premium HSM<br/>암호화키 관리<br/>Private Endpoint]
Monitor[📊 Azure Monitor<br/>Log Analytics<br/>Application Insights<br/>Container Insights]
ACR[📦 Container Registry<br/>Premium Tier<br/>Geo-replication<br/>보안 스캔]
end
%% 트래픽 흐름
User --> AFD
AFD --> AppGW
AppGW --> AuthPod
AppGW --> BillPod
AppGW --> ProductPod
AppGW --> KOSMockPod
%% 서비스 간 통신
AuthPod --> PG
BillPod --> PG
ProductPod --> PG
KOSMockPod --> PG
AuthPod --> Redis
BillPod --> Redis
ProductPod --> Redis
%% KOS-Mock 연동 (외부 KOS 시스템 대체)
BillPod --> KOSMockPod
ProductPod --> KOSMockPod
%% 데이터베이스 복제
PG --> ReadReplica
%% 보안 및 키 관리
AuthPod --> KeyVault
BillPod --> KeyVault
ProductPod --> KeyVault
KOSMockPod --> KeyVault
%% 모니터링
AppNodes --> Monitor
PG --> Monitor
Redis --> Monitor
%% 컨테이너 이미지
AppNodes --> ACR
%% 스타일링
classDef userClass fill:#e1f5fe,stroke:#01579b,stroke-width:2px
classDef azureClass fill:#e8f5e8,stroke:#2e7d32,stroke-width:2px
classDef appClass fill:#fff3e0,stroke:#f57c00,stroke-width:2px
classDef dataClass fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef securityClass fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
class User,KOS userClass
class AFD,AppGW,SysNodes,AppNodes azureClass
class AuthPod,BillPod,ProductPod,KOSMockPod appClass
class PG,Redis,ReadReplica dataClass
class KeyVault,Monitor,ACR securityClass
@@ -0,0 +1,395 @@
# 물리 아키텍처 설계서 - 마스터 인덱스
## 1. 개요
### 1.1 설계 목적
- 통신요금 관리 서비스의 Azure Cloud 기반 통합 물리 아키텍처 설계 및 관리
- 개발환경과 운영환경의 체계적인 아키텍처 분리 및 단계적 진화 전략
- 환경별 특화 구성과 비용 효율적인 확장 로드맵 제시
- 전체 시스템의 거버넌스 체계 및 운영 가이드라인 정의
### 1.2 아키텍처 분리 원칙
- **환경별 특화**: 개발환경(MVP/비용 우선)과 운영환경(가용성/확장성 우선)의 목적에 맞는 최적화
- **단계적 발전**: 개발→운영 단계적 아키텍처 진화 및 기술적 성숙도 향상
- **비용 효율성**: 환경별 리소스 최적화를 통한 전체 TCO 최소화
- **운영 일관성**: 환경별 차이를 최소화한 일관된 배포 및 운영 절차
### 1.3 문서 구조
```
physical-architecture.md (마스터 인덱스)
├── physical-architecture-dev.md (개발환경)
└── physical-architecture-prod.md (운영환경)
```
### 1.4 참조 아키텍처
- HighLevel아키텍처정의서: design/high-level-architecture.md
- 논리아키텍처: design/backend/logical/logical-architecture.md
- 아키텍처패턴: design/pattern/architecture-pattern.md
- API설계서: design/backend/api/*.yaml
## 2. 환경별 아키텍처 개요
### 2.1 환경별 특성 비교
| 구분 | 개발환경 | 운영환경 |
|------|----------|----------|
| **목적** | MVP 개발/검증 | 실제 서비스 운영 |
| **가용성** | 95% (월 36시간 다운타임) | 99.9% (월 43분 다운타임) |
| **사용자** | 개발팀 (5명) | 실사용자 (Peak 1,000명) |
| **확장성** | 고정 리소스 | 자동 스케일링 (10배 확장) |
| **보안** | 기본 보안 | 엔터프라이즈급 다층 보안 |
| **비용** | 최소화 ($171/월) | 최적화 ($2,450/월) |
| **복잡도** | 단순 (운영 편의성) | 고도화 (안정성/성능) |
### 2.2 환경별 세부 문서
#### 2.2.1 개발환경 아키텍처
📄 **[물리 아키텍처 설계서 - 개발환경](./physical-architecture-dev.md)**
**주요 특징:**
- **비용 최적화**: Spot Instance, Pod 기반 백킹서비스 활용
- **개발 편의성**: 복잡한 설정 최소화, 빠른 배포
- **단순한 보안**: 기본 Network Policy, JWT 검증
- **Pod 기반 구성**: PostgreSQL/Redis Pod 배포
**핵심 구성:**
📄 **[개발환경 물리 아키텍처 다이어그램](./physical-architecture-dev.mmd)**
- NGINX Ingress → AKS Basic → Pod Services 구조
- Application Pods, PostgreSQL Pod, Redis Pod 배치
#### 2.2.2 운영환경 아키텍처
📄 **[물리 아키텍처 설계서 - 운영환경](./physical-architecture-prod.md)**
**주요 특징:**
- **고가용성**: Multi-Zone 배포, 자동 장애조치
- **확장성**: HPA 기반 자동 스케일링 (10배 확장)
- **엔터프라이즈 보안**: 다층 보안, Private Endpoint
- **관리형 서비스**: Azure Database, Cache for Redis
**핵심 구성:**
📄 **[운영환경 물리 아키텍처 다이어그램](./physical-architecture-prod.mmd)**
- Azure Front Door → App Gateway + WAF → AKS Premium 구조
- Multi-Zone Apps, Azure PostgreSQL, Azure Redis Premium 배치
### 2.3 핵심 아키텍처 결정사항
#### 2.3.1 공통 아키텍처 원칙
- **서비스 메시 제거**: Istio 대신 Kubernetes Network Policies 사용 (복잡도 최소화)
- **선택적 비동기**: 이력 처리만 비동기, 핵심 비즈니스 로직은 동기 통신
- **Managed Identity**: 키 없는 인증으로 보안 강화 및 운영 단순화
- **다층 보안**: L1(Network) → L2(Gateway) → L3(Identity) → L4(Data)
#### 2.3.2 환경별 차별화 전략
**개발환경 최적화:**
- 개발 속도와 비용 효율성 우선
- 단순한 구성으로 운영 부담 최소화
- Pod 기반 백킹서비스로 외부 의존성 제거
**운영환경 최적화:**
- 가용성과 확장성 우선
- Azure 관리형 서비스로 운영 안정성 확보
- 엔터프라이즈급 보안 및 종합적 모니터링
## 3. 네트워크 아키텍처 비교
### 3.1 환경별 네트워크 전략
#### 3.1.1 환경별 네트워크 전략 비교
| 구성 요소 | 개발환경 | 운영환경 | 비교 |
|-----------|----------|----------|------|
| **인그레스** | NGINX Ingress Controller | Azure Application Gateway + WAF | 운영환경에서 WAF 보안 강화 |
| **네트워크** | 단일 VNet 구성 | 다중 서브넷 (App/DB/Cache) | 운영환경에서 계층적 네트워크 분리 |
| **보안** | 기본 Network Policy | Private Endpoint, NSG 강화 | 운영환경에서 엔터프라이즈급 보안 |
| **접근** | 인터넷 직접 접근 허용 | Private Link 기반 보안 접근 | 운영환경에서 보안 접근 제한 |
### 3.2 네트워크 보안 전략
#### 3.2.1 공통 보안 원칙
- **Network Policies**: Pod 간 통신 제어 및 마이크로 세그먼테이션
- **Managed Identity**: 키 없는 인증으로 Azure 서비스 안전 접근
- **Private Endpoints**: Azure 서비스 보안 연결
- **TLS 암호화**: 모든 외부 통신 암호화
#### 3.2.2 환경별 보안 수준
| 보안 요소 | 개발환경 | 운영환경 | 보안 수준 |
|-----------|----------|----------|----------|
| **Network Policy** | 기본 (개발 편의성 고려) | 엄격한 적용 | 운영환경에서 강화 |
| **시크릿 관리** | Kubernetes Secrets | Azure Key Vault | 운영환경에서 HSM 보안 |
| **암호화** | HTTPS 인그레스 레벨 | End-to-End TLS 1.3 | 운영환경에서 완전 암호화 |
| **웹 보안** | - | WAF + DDoS 보호 | 운영환경 전용 |
## 4. 데이터 아키텍처 비교
### 4.1 환경별 데이터 전략
#### 4.1.1 환경별 데이터 구성 비교
| 데이터 서비스 | 개발환경 | 운영환경 | 가용성 | 비용 |
|-------------|----------|----------|---------|------|
| **PostgreSQL** | Kubernetes Pod + Azure Disk | Azure Database Flexible Server | 95% vs 99.9% | $0 vs $450/월 |
| **Redis** | Memory Only Pod | Azure Cache Premium (Cluster) | 단일 vs 클러스터 | $0 vs $250/월 |
| **백업** | 수동 (주 1회) | 자동 (35일 보존) | 로컬 vs 지역간 복제 | - |
| **데이터 지속성** | 재시작 시 손실 가능 | Zone Redundant | - | - |
### 4.2 캐시 전략 비교
#### 4.2.1 다층 캐시 아키텍처
| 캐시 계층 | 캐시 타입 | TTL | 개발환경 설정 | 운영환경 설정 | 용도 |
|----------|----------|-----|-------------|-------------|------|
| **L1_Application** | Caffeine Cache | 5분 | max_entries: 1000 | max_entries: 2000 | 애플리케이션 레벨 로컬 캐시 |
| **L2_Distributed** | Redis | 30분 | cluster_mode: false | cluster_mode: true | 분산 캐시, eviction_policy: allkeys-lru |
#### 4.2.2 환경별 캐시 특성 비교
| 캐시 특성 | 개발환경 | 운영환경 | 비고 |
|-----------|----------|----------|------|
| **Redis 구성** | 단일 Pod | Premium 클러스터 | 운영환경에서 고가용성 |
| **데이터 지속성** | 메모리 전용 | 지속성 백업 | 운영환경에서 데이터 보장 |
| **성능** | 기본 성능 | 최적화된 성능 | 운영환경에서 향상된 처리 능력 |
## 5. 보안 아키텍처 비교
### 5.1 다층 보안 아키텍처
#### 5.1.1 공통 보안 계층
| 보안 계층 | 보안 기술 | 적용 범위 | 보안 목적 |
|----------|----------|----------|----------|
| **L1_Network** | Kubernetes Network Policies | Pod-to-Pod 통신 제어 | 내부 네트워크 마이크로 세그먼테이션 |
| **L2_Gateway** | API Gateway JWT 검증 | 외부 요청 인증/인가 | API 레벨 인증 및 인가 제어 |
| **L3_Identity** | Azure Managed Identity | Azure 서비스 접근 | 클라우드 리소스 안전한 접근 |
| **L4_Data** | Private Link + Key Vault | 데이터 암호화 및 비밀 관리 | 엔드투엔드 데이터 보호 |
### 5.2 환경별 보안 수준
#### 5.2.1 환경별 보안 수준 비교
| 보안 영역 | 개발환경 | 운영환경 | 보안 강화 |
|-----------|----------|----------|----------|
| **인증** | JWT (고정 시크릿) | Azure AD + Managed Identity | 운영환경에서 엔터프라이즈 인증 |
| **네트워크** | 기본 Network Policy | 엄격한 Network Policy + Private Endpoint | 운영환경에서 네트워크 격리 강화 |
| **시크릿** | Kubernetes Secrets | Azure Key Vault (HSM) | 운영환경에서 하드웨어 보안 모듈 |
| **암호화** | HTTPS (인그레스 레벨) | End-to-End TLS 1.3 | 운영환경에서 전 구간 암호화 |
## 6. 모니터링 및 운영
### 6.1 환경별 모니터링 전략
#### 6.1.1 환경별 모니터링 도구 비교
| 모니터링 요소 | 개발환경 | 운영환경 | 기능 차이 |
|-------------|----------|----------|----------|
| **도구** | Kubernetes Dashboard, kubectl logs | Azure Monitor, Application Insights | 운영환경에서 전문 APM 도구 |
| **메트릭** | 기본 Pod/Node 메트릭 | 포괄적 APM, 비즈니스 메트릭 | 운영환경에서 비즈니스 인사이트 |
| **알림** | 기본 알림 (Pod 재시작) | 다단계 알림 (Teams 연동) | 운영환경에서 전문 알림 체계 |
| **로그** | 로컬 파일시스템 (7일) | Log Analytics (90일) | 운영환경에서 장기 보존 |
### 6.2 CI/CD 및 배포 전략
#### 6.2.1 환경별 배포 방식 비교
| 배포 요소 | 개발환경 | 운영환경 | 안정성 차이 |
|-----------|----------|----------|----------|
| **배포 방식** | Rolling Update | Blue-Green Deployment | 운영환경에서 무중단 배포 |
| **자동화** | develop 브랜치 자동 | tag 생성 + 수동 승인 | 운영환경에서 더 신중한 배포 |
| **테스트** | 기본 헬스체크 | 종합 품질 게이트 (80% 커버리지) | 운영환경에서 더 엄격한 테스트 |
| **다운타임** | 허용 (1-2분) | Zero Downtime | 운영환경에서 서비스 연속성 보장 |
## 7. 비용 분석
### 7.1 환경별 비용 구조
#### 7.1.1 월간 비용 비교 (USD)
```yaml
cost_comparison:
development:
total_cost: "$171"
components:
aks_nodes: "$73 (Spot Instance)"
azure_disk: "$5 (Standard 20GB)"
load_balancer: "$18 (Basic)"
service_bus: "$10 (Basic)"
container_registry: "$5 (Basic)"
networking: "$10 (Single Region)"
others: "$50"
optimization_strategies:
- spot_instances: "70% 절약"
- pod_based_services: "100% 절약"
- minimal_configuration: "비용 최소화"
production:
total_cost: "$2,450"
components:
aks_nodes: "$1,200 (Reserved Instance)"
postgresql: "$450 (Managed Service)"
redis: "$250 (Premium Cluster)"
application_gateway: "$150 (Standard_v2)"
service_bus: "$100 (Premium)"
load_balancer: "$50 (Standard)"
storage: "$100 (Premium SSD)"
networking: "$150 (Data Transfer)"
monitoring: "$100 (Log Analytics)"
optimization_strategies:
- reserved_instances: "30% 절약"
- auto_scaling: "동적 최적화"
- performance_tuning: "효율성 개선"
```
#### 7.1.2 환경별 비용 최적화 전략 비교
| 최적화 영역 | 개발환경 | 운영환경 | 절약 효과 |
|-------------|----------|----------|----------|
| **컴퓨팅 비용** | Spot Instances 사용 | Reserved Instances | 70% vs 30% 절약 |
| **백킹서비스** | Pod 기반 (무료) | 관리형 서비스 | 100% 절약 vs 안정성 |
| **리소스 관리** | 비업무시간 자동 종료 | 자동 스케일링 | 시간 절약 vs 효율성 |
| **사이징 전략** | 고정 리소스 | 성능 기반 적정 sizing | 단순 vs 최적화 |
## 8. 전환 및 확장 계획
### 8.1 개발환경 → 운영환경 전환 체크리스트
```yaml
migration_checklist:
data_migration:
- task: "개발 데이터 백업"
status: "☐"
priority: "높음"
method: "pg_dump 사용"
- task: "스키마 마이그레이션 스크립트"
status: "☐"
priority: "높음"
method: "Flyway/Liquibase 고려"
- task: "Azure Database 프로비저닝"
status: "☐"
priority: "높음"
method: "Flexible Server 구성"
configuration_changes:
- task: "환경 변수 분리"
status: "☐"
priority: "높음"
method: "ConfigMap/Secret 분리"
- task: "Azure Key Vault 설정"
status: "☐"
priority: "높음"
method: "HSM 보안 모듈"
- task: "Managed Identity 구성"
status: "☐"
priority: "높음"
method: "키 없는 인증"
monitoring_setup:
- task: "Azure Monitor 설정"
status: "☐"
priority: "중간"
method: "Log Analytics 연동"
- task: "알림 정책 수립"
status: "☐"
priority: "중간"
method: "Teams 연동"
- task: "대시보드 구축"
status: "☐"
priority: "낮음"
method: "Application Insights"
```
### 8.2 단계별 확장 로드맵
```yaml
expansion_roadmap:
phase_1:
duration: "현재-6개월"
focus: "안정화"
core_objectives:
- "개발환경 → 운영환경 전환"
- "기본 모니터링 및 알림 구축"
- "99.9% 가용성 달성"
key_deliverables:
- "운영환경 배포 완료"
- "CI/CD 파이프라인 구축"
- "기본 보안 정책 적용"
user_support: "1만 사용자"
availability: "99.9%"
phase_2:
duration: "6-12개월"
focus: "최적화"
core_objectives:
- "성능 최적화 및 비용 효율화"
- "고급 모니터링 (APM) 도입"
- "자동 스케일링 고도화"
key_deliverables:
- "캐시 전략 고도화"
- "성능 튜닝 완료"
- "비용 최적화 달성"
user_support: "10만 동시 사용자"
availability: "99.9%"
phase_3:
duration: "12-18개월"
focus: "글로벌 확장"
core_objectives:
- "다중 리전 배포"
- "글로벌 CDN 및 로드 밸런싱"
- "지역별 데이터 센터 구축"
key_deliverables:
- "Multi-Region 아키텍처"
- "글로벌 재해복구 체계"
- "지역별 성능 최적화"
user_support: "100만 사용자"
availability: "99.95%"
```
## 9. 핵심 SLA 지표
### 9.1 환경별 서비스 수준 목표
```yaml
sla_comparison:
metrics:
availability:
development: "95%"
production: "99.9%"
global_phase3: "99.95%"
response_time:
development: "< 10초"
production: "< 3초"
global_phase3: "< 2초"
deployment_time:
development: "30분"
production: "10분"
global_phase3: "5분"
recovery_time:
development: "수동 복구"
production: "< 30분"
global_phase3: "< 15분"
concurrent_users:
development: "개발팀 (5명)"
production: "1,000명"
global_phase3: "100,000명"
monthly_cost:
development: "$171"
production: "$2,450"
global_phase3: "$15,000+"
security_incidents:
development: "모니터링 없음"
production: "0건 목표"
global_phase3: "0건 목표"
```
이 마스터 물리 아키텍처 설계서는 **통신요금 관리 서비스**의 전체 아키텍처를 통합 관리하며, 개발환경에서 글로벌 서비스까지의 체계적인 진화 경로를 제시합니다. Azure 클라우드 기반으로 구축되어 비용 효율성과 확장성을 동시에 달성할 수 있도록 설계되었습니다.