## 공통 전제
* 환경: **온프렘(baremetal), 내부망, 외부 관리형 서비스 사용 어려움**
* 목표: **MVP 빠르게 출시 + 운영 표준화 + 향후 확장 가능**
* 공통 컴포넌트(향후 공통 운영 기반):
* **Keycloak** (인증)
* **Gateway** (라우팅/인증 1차 필터)
* **로그/모니터링** (ELK, Prometheus+Grafana)
* 배포 자동화: **CI/CD 기반 빠른 배포**
* 인가(Authorization) 정책:
* 인증: Keycloak + Gateway에서 1차 검증
* 인가: **각 Microservice에서 수행** (서비스별 세부 권한/정책 유연성 확보)
---
# 1안) Kubernetes 기반 “운영형 MSA 플랫폼” 도입 (정석)
## 핵심 요약
* K8s를 “플랫폼”으로 삼고, **GitOps(ArgoCD)** 기반으로 배포/운영 표준을 만든다.
* 내부망 baremetal에서 외부 LB는 **MetalLB**, 트래픽 진입은 **Ingress Controller + Gateway** 조합 권장.
## 구성 요소
* 트래픽 경로: `MetalLB → Ingress → Spring Cloud Gateway → Microservices`
* 인증: Keycloak
* 배포: ArgoCD (GitOps)
* 관측성:
* 로깅: ELK
* 모니터링: Prometheus + Grafana
* DB: **K8s 외부(별도 baremetal/VM)** 권장 (DB는 플랫폼 이벤트와 분리)
## 장점
* 운영 표준화: 배포/롤백/환경 일관성(GitOps)
* 장애 대응: HPA/PDB/헬스체크 등 K8s 기본 체력 활용
* 확장성: 서비스가 늘어도 “플랫폼 위에서 같은 방식”으로 관리
* Ingress 도입으로 TLS/라우팅/인증서 운영(추후 cert-manager) 정돈 가능
## 단점/리스크
* 초기 진입장벽(학습/클러스터 운영)
* baremetal 스토리지/네트워킹 설계가 중요(특히 상태ful)
* 플랫폼 구축 자체가 초기 일정에 부담이 될 수 있음
## 도입 추천 상황
* “처음부터 운영형으로 가야 한다”
* 서비스 개수가 빠르게 늘어날 가능성이 크다
* 배포/운영을 팀 표준으로 강하게 묶고 싶다
### 1안 Mermaid 아키텍처
```mermaid
flowchart LR
U["Internal Users / Clients"] --> LB["MetalLB - LoadBalancer IP"]
LB --> ING["Ingress Controller (NGINX or HAProxy)"]
ING --> GW["Spring Cloud Gateway"]
GW --> US["User Service"]
GW --> CRM["CRM Service"]
US --> DBU["User DB - external baremetal"]
CRM --> DBC["CRM DB - external baremetal"]
GW <-- "OIDC" --> KC["Keycloak - Identity Provider"]
US <-- "JWT / JWKS" --> KC
CRM <-- "JWT / JWKS" --> KC
subgraph OBS["Observability"]
ELK["ELK Stack"]
PROM["Prometheus"]
GRAF["Grafana"]
end
GW --> ELK
US --> ELK
CRM --> ELK
GW --> PROM
US --> PROM
CRM --> PROM
PROM --> GRAF
subgraph GITOPS["GitOps Deployment"]
GIT["Git Repository"]
ARGO["Argo CD"]
end
GIT --> ARGO
ARGO --> ING
ARGO --> GW
ARGO --> US
ARGO --> CRM
ARGO --> KC
ARGO --> ELK
ARGO --> PROM
ARGO --> GRAF
```
---
# 2안) Docker-Compose 기반 “MVP 우선” 도입 (점진적 전환)
## 핵심 요약
* 처음부터 K8s 플랫폼을 구축하지 않고,
* **microservice 분리 + CI/CD로 빠른 배포**를 먼저 달성한다.
* 추후 운영 복잡도가 커지거나 서비스가 늘면 1안(K8s)로 단계적 전환한다.
## 구성 요소
* 트래픽 경로: `Reverse Proxy(Nginx/HAProxy) → Gateway → Microservices`
* 인증: Keycloak (compose로 같이 띄우거나 별도 서버로 분리)
* 배포: CI/CD로 서버에 배포(blue/green은 옵션), docker-compose up/down
* 관측성: ELK / Prometheus+Grafana를 compose로 먼저 묶어서 표준화
* DB: **외부 baremetal 서버** (서비스 컨테이너와 분리)
## 장점
* 빠른 MVP: 인프라 구축 시간 최소화
* 팀 학습 부담 낮음: docker-compose 운영 경험으로 시작
* MSA의 핵심 가치(서비스 분리/독립 배포)부터 확보 가능
## 단점/리스크
* 서버 단위 운영(스케일, 장애 복구, 자원 격리)이 K8s보다 수동적
* 서비스가 늘수록 compose 운영이 누적 부담(네트워크/배포/버전관리)
* 멀티 노드 확장/오케스트레이션이 필요해지면 결국 K8s로 가게 됨
## 도입 추천 상황
* “일단 빨리 만들고, 시장/내부 검증 먼저”
* 팀이 K8s 운영 경험이 충분치 않거나, 구축 리드타임이 부담
* 서비스 1~3개로 시작하며 트래픽이 크지 않음
### 2안 Mermaid 아키텍처
```mermaid
flowchart LR
U["Internal Users / Clients"] --> RP["Reverse Proxy (Nginx or HAProxy)"]
RP --> GW["Spring Cloud Gateway"]
GW --> US["User Service"]
GW --> CRM["CRM Service"]
US --> DBU["User DB - external baremetal"]
CRM --> DBC["CRM DB - external baremetal"]
GW <-- "OIDC" --> KC["Keycloak"]
US <-- "JWT / JWKS" --> KC
CRM <-- "JWT / JWKS" --> KC
subgraph OBS["Observability (docker-compose)"]
ELK["ELK Stack"]
PROM["Prometheus"]
GRAF["Grafana"]
end
GW --> ELK
US --> ELK
CRM --> ELK
GW --> PROM
US --> PROM
CRM --> PROM
PROM --> GRAF
subgraph DELIVERY["CI / CD Pipeline"]
DEV["Developer"]
CI["CI - Build & Test"]
CD["CD - Deploy"]
end
DEV --> CI --> CD
CD --> RP
CD --> GW
CD --> US
CD --> CRM
CD --> KC
CD --> ELK
CD --> PROM
CD --> GRAF
```
---
# 1안 vs 2안 비교 (회의용 요약)
| 구분 | 1안: K8s 플랫폼 | 2안: Compose MVP |
| -------- | ------------- | ------------------- |
| 목표 | 운영형 표준 + 확장성 | 출시 속도 + 학습 부담 최소 |
| 배포 | ArgoCD GitOps | CI/CD + compose 재기동 |
| 확장/복구 | 자동화 강함 | 수동/스크립트 중심 |
| 초기 리드타임 | 큼 | 작음 |
| 서비스 증가 시 | 잘 버팀 | 운영 부담이 급격히 증가 |
| 추천 시점 | 장기 운영 확정 | 빠른 검증 단계 |
---
# 권장 로드맵 (실행 전략)
## Phase 0: 공통 원칙 확정 (둘 다 공통)
* 인증/인가 원칙: “인증 중앙화(Keycloak) + 인가 분산(서비스)”
* 트래픽 단일 진입점: Gateway 유지
* 관측성 표준: traceId/requestId 헤더 전파, 로그 포맷(JSON) 통일
* DB는 외부 baremetal로 분리(서비스/플랫폼과 장애 도메인 분리)
## Phase 1: 2안으로 빠른 MVP
* User Service 먼저 배포
* CI/CD로 “빌드→배포→롤백” 루틴 확립
* ELK/Prom/Grafana 묶어서 기본 운영 시야 확보
## Phase 2: 전환 조건이 되면 1안으로 마이그레이션
* 서비스 수 증가, 팀/운영 요구 증가, HA 필요
* GitOps, 표준 배포, 멀티 노드 확장 필요성 발생
* 전환 시: compose에서 쓰던 컨테이너/설정들을 Helm/Kustomize로 이관