[k8s] 단일 프로젝트 vs 마이크로서비스 비교

 

1️⃣ 들어가며

• Spring Boot 애플리케이션을 쿠버네티스(K8s) 위에 배포할 때
• 한 프로젝트 안에 여러 API를 만들지, 아니면 API별로 별도 프로젝트를 만들어야 할지 고민되는 상황
• 요청 분산, 스케일링, 장애 격리 측면에서 비교

---

2️⃣ 쿠버네티스 기본 구조

• Deployment: 애플리케이션 단위, 파드(Pod) 생성/관리
• Service: Deployment 내부 파드에 요청을 전달, 로드밸런싱
• Ingress + Nginx: 외부 요청을 Service로 라우팅하고, 여러 파드에 분산 처리

 

[요청흐름그림]

외부 요청 → Ingress(지도) → Nginx(트래픽 배분) → Service → 여러 파드

 

• Ingress: URL/도메인 규칙 관리
• Nginx: 파드 단위 로드밸런싱

---

3️⃣ 한 프로젝트 안에 여러 API (/users, /orders)

• Deployment 1개, 여러 파드
• 요청 흐름:

/users 요청 → Service → 파드1 or 파드2
/orders 요청 → Service → 파드1 or 파드2

 

• 장점
  • 구조 단순, 배포 쉬움
  • 작은 팀/서비스에 적합
• 단점
  • API별 독립 스케일 불가
  • /users 폭증 → /orders와 함께 전체 Deployment 스케일링
  • 장애 발생 시 전체 서비스에 영향

---

 

 

외부 요청 (/users, /orders)
       ↓
Ingress (URL 구분)
       ↓
Service (하나)
       ↓
Nginx → 파드1, 파드2, 파드3 (요청 단위로 분산)

 

---

4️⃣ API별로 별도 프로젝트 (마이크로서비스)

• /users Deployment, /orders Deployment 각각 생성
• 요청 흐름:

/users → Ingress → Service(users) → Nginx → user 파드1,2,3
/orders → Ingress → Service(orders) → Nginx → order 파드1,2,3

 

• 장점
  • API별 독립 스케일 가능
  • 장애 격리 가능
  • 리소스 효율적
• 단점
  • 관리 복잡도 ↑
  • 서비스간 통신, Config 관리 필요

---

5️⃣ Nginx vs Ingress 역할 정리

구성 요소역할

 

Ingress	URL/도메인 기반 라우팅 규칙 제공, 외부 요청 → Service 매핑
Nginx	실제 트래픽을 파드 단위로 분산 처리, 로드밸런싱

비유:

• Ingress = 지도 → “/users 요청은 Service1, /orders 요청은 Service2로 가라”
• Nginx = 교통 경찰 → “파드 1,2,3 중 한 곳으로 분산 처리”

---

6️⃣ 요청 단위 vs API별 독립 스케일

항목한 프로젝트별도 프로젝트

 

요청 단위 분산	파드 단위 ✅	파드 단위 ✅
API별 독립 스케일	❌	✅
장애 격리	❌	✅
리소스 효율	낮음	높음

💡 핵심: 파드 단위로 요청은 분산 처리되기 때문에 작은 트래픽에서는 단일 프로젝트도 충분

• 단, API별 트래픽 패턴이 다르고 독립 스케일링 필요하면 별도 프로젝트(마이크로서비스) 권장

---

7️⃣ 현업에서는?

규모/상황선택

 

소규모 서비스/스타트업	단일 프로젝트 + Deployment + Ingress + Nginx
중대형 서비스/기업	API별 프로젝트(마이크로서비스) + Deployment + Service + Ingress + Nginx

---

8️⃣ 결론

• 작은 서비스 → 한 프로젝트 안에 여러 API 만들어도 충분, 요청 단위로 파드에 분산 처리
• 큰 서비스 → API별로 분리해 마이크로서비스로 배포, 독립 스케일링 가능
• Nginx + Ingress 역할 이해 → 구조 설계가 쉬워지고, 트래픽 관리/로드밸런싱 명확