728x90
반응형
👉 마이크로서비스 환경에서 서비스 간 통신을 일관되게 관리·보안·관찰하기 위한 인프라 계층이야.
애플리케이션 코드 수정 없이
- 트래픽 제어
- 보안(mTLS)
- 모니터링
- 장애 제어
를 해주는 게 핵심이야.
한 줄 요약
Istio = “마이크로서비스 간 네트워크를 대신 관리해주는 똑똑한 중간 관리자”
왜 Service Mesh가 필요한가?
마이크로서비스가 늘어나면 이런 문제가 생겨 👇
- 서비스 간 호출이 복잡해짐
- 장애가 어디서 발생했는지 알기 어려움
- 인증/암호화 로직을 서비스마다 구현해야 함
- 트래픽 분산, Canary 배포가 어려움
👉 Istio는 이걸 앱 코드 밖에서 해결해줘.
Istio 핵심 구조
1️⃣ Data Plane (Envoy Proxy)
- 각 Pod 옆에 Sidecar로 붙음
- 모든 서비스 트래픽을 대신 처리
- 실제 통신 담당
[Service A] → [Envoy] → [Envoy] → [Service B]2️⃣ Control Plane (Istiod)
- Envoy 설정 중앙 관리
- 인증서 발급 (mTLS)
- 트래픽 정책 전달
Istio가 해주는 핵심 기능
🔐 1. 보안 (Security)
- mTLS 자동 적용
- 서비스 간 인증/암호화
- Zero Trust 네트워크 구현
앱 개발자는 보안 코드 신경 안 써도 됨
🚦 2. 트래픽 관리
- Canary 배포
- Blue/Green 배포
- A/B 테스트
- 비율 기반 라우팅
예:
v1 → 90%
v2 → 10%📊 3. 관측성 (Observability)
- 트래픽 흐름 시각화
- 에러율, 지연시간, 호출 관계
- Prometheus / Grafana / Kiali 연동
👉 “어디 서비스가 병목인지” 바로 보임
🛑 4. 장애 제어 (Resilience)
- Retry
- Timeout
- Circuit Breaker
- Rate Limit
👉 장애 전파 방지
Kubernetes랑 뭐가 달라?
구분KubernetesIstio
| 역할 | 컨테이너 오케스트레이션 | 서비스 간 통신 관리 |
| 네트워크 | 기본 L4 | L7 (HTTP/gRPC) |
| 트래픽 제어 | 제한적 | 매우 정교 |
| 보안 | 기본 TLS | mTLS 자동 |
👉 K8s 위에 Istio를 얹어서 사용
언제 Istio를 쓰는 게 좋을까?
✅ 이런 경우에 적합
- 마이크로서비스 수가 많다
- 서비스 간 호출이 복잡하다
- 무중단 배포가 중요하다
- 보안 요구사항이 높다
- 트래픽 가시성이 필요하다
❌ 이런 경우엔 과함
- 서비스 2~3개
- 단순한 REST 구조
- 운영 인력이 부족함
장점 / 단점
👍 장점
- 코드 수정 거의 없음
- 강력한 보안
- 운영 자동화
- 트래픽 제어 자유도 높음
👎 단점
- 러닝커브 높음
- 리소스 사용 증가
- 운영 복잡도 증가
한 줄 결론
Istio는 “마이크로서비스가 커질수록 반드시 필요해지는 네트워크 운영 플랫폼”이다.
728x90
반응형