Service Mesh는 MSA 아키텍처 내 통신, 보안, 가시성, 장애 회복성 등을 고도화하기 위한 핵심 구성요소입니다. 아래 내용을 기반으로 실무 역량을 단계별로 정리해드립니다.
🔹 1. Service Mesh란?
정의
Service Mesh는 마이크로서비스 간의 통신 제어, 보안, 관측, 라우팅, 복구 로직을 표준화된 방식으로 처리하는 인프라 계층입니다. 각 서비스는 본래 비즈니스 로직만을 담당하고, 네트워크 기능은 Sidecar Proxy(예: Envoy)가 담당합니다.
구성
- Data Plane: 실제 트래픽 처리 담당. 각 서비스 옆에 붙는 **Sidecar Proxy(Envoy)**가 있음.
- Control Plane: 정책 관리, 서비스 디스커버리, 텔레메트리 수집 등을 수행. 대표적으로 Istio의 Pilot, Mixer, Citadel 등.
🔹 2. 주요 기능 및 실무 적용 포인트
| 트래픽 라우팅 | Canary, A/B 테스트, 버전 기반 라우팅 등 정밀 제어 | Blue/Green 배포, 회귀 테스트 |
| 보안(Zero Trust) | mTLS, 인증/인가, 정책 기반 접근 제어 | 내부 통신 암호화, 외부 접근 제한 |
| Telemetry | 지표 수집(Prometheus), 로그, 트레이싱(Jaeger) | 장애 추적, SLO 관리 |
| Circuit Breaker / Retry | 자동 재시도, 타임아웃, 회로 차단 | 장애 복원력 확보 |
| Rate Limiting / Quota | API 요청 제한, Abuse 방지 | 요금제 구간 처리, 인증 API 보호 |
🔹 3. 대표 Service Mesh 솔루션
| Istio | Kubernetes 기반 대표 솔루션 | 복잡하지만 풍부한 기능 |
| Linkerd | CNCF Graduated Mesh | 간결, 가벼움, 빠른 배포 |
| Consul Connect | HashiCorp 제공 | Consul과 연계된 Mesh |
| Kuma / Kong Mesh | Envoy 기반 간편 Mesh | 멀티 클러스터 지원 |
| AWS App Mesh | AWS 서비스 연동에 최적화 | EKS, ECS 통합 운영 가능 |
🔹 4. 실무 시나리오 기반 예시
✅ 시나리오 1: Canary 배포 시 모니터링 문제
문제: 신규 버전 배포 후 10% 트래픽만 보내고 테스트하고 싶음
Service Mesh 적용:
- VirtualService에서 weight 설정으로 v1:90%, v2:10% 분산
- Prometheus + Grafana로 실시간 latency, error rate 확인
→ 오류율이 높으면 v2 트래픽을 즉시 차단하여 롤백
✅ 시나리오 2: 내부 인증 및 mTLS 적용 실패
문제: 팀 간 서비스 호출에서 내부 인증 우회 시도 발견
Service Mesh 적용:
- PeerAuthentication으로 mTLS 강제
- AuthorizationPolicy로 경로별 RBAC 설정
→ 조직 간 최소 권한 원칙(Least Privilege) 적용 성공
✅ 시나리오 3: 장애 복구 전략의 일환으로 Circuit Breaker 설정
문제: 외부 DB 연동 API가 지연 → 전체 서비스 지연 전파
Service Mesh 적용:
- DestinationRule에 outlierDetection 설정
- 지정 횟수 초과 시 해당 인스턴스 격리
→ 회복 불가능 상태에서도 빠른 Failover 가능
🔹 5. TA 관점 정리: 아키텍처/보안/장애 복구 관점의 핵심 포인트
🧱 아키텍처 설계 관점
- Sidecar는 CPU/Mem 오버헤드를 고려해 프로파일링 및 HPA 설정 필요
- 다중 클러스터 또는 멀티테넌시 구성을 위한 Gateway 분리
🔐 보안 관점
- mTLS 인증서 주기적 롤링 자동화 (e.g., Istio Citadel or CA integration)
- 정밀한 RBAC 설정을 통한 내부 공격 최소화
🛠 장애 대응 관점
- 트래픽 분산, 자동 재시도, 시간초과 설정 등 장애 전파 차단 메커니즘
- Jaeger 기반 분산 트레이싱으로 마이크로서비스 간 호출 병목 탐지
🧠 Service Mesh 심화 문제집 – 문제·정답·해설 3단 구성
✅ NO.01 [객관식 / 하]
문제
Service Mesh의 Control Plane에서 주로 수행하는 기능은 무엇인가?
① 로드밸런싱 및 트래픽 암호화
② 서비스 간 통신을 위한 DNS 관리
③ 사이드카 프록시 설정 및 정책 배포
④ 인그레스 컨트롤러 관리
정답: ③
해설: Control Plane은 Sidecar 프록시에 대한 설정과 보안 정책, 트래픽 라우팅 등을 구성하여 분산 적용합니다.
✅ NO.02 [객관식 / 중]
문제
Istio에서 트래픽 분산 비율을 설정하는 리소스는?
① Gateway
② DestinationRule
③ ServiceEntry
④ VirtualService
정답: ④
해설: VirtualService는 트래픽 라우팅 정책을 정의하고, 버전별 분산 설정(weight 조정)도 담당합니다.
✅ NO.03 [단답형 / 중]
문제
Istio에서 mTLS 설정을 적용하는 커스텀 리소스는 무엇인가요? (정확한 객체명)
정답: PeerAuthentication
해설: PeerAuthentication은 서비스 간 통신 보안을 위해 mTLS 정책을 설정하는 리소스입니다.
✅ NO.04 [객관식 / 상]
문제
Envoy Proxy의 역할로 올바른 것은?
① Kubernetes Ingress Controller
② TCP/IP 레벨 트래픽 전송
③ Application Layer 로드밸런싱 및 TLS 종료
④ 컨트롤 플레인 리소스 저장소
정답: ③
해설: Envoy는 애플리케이션 계층의 프록시로, HTTP 로드밸런싱, TLS 종료, 트래픽 제어를 수행합니다.
✅ NO.05 [시나리오형 / 중]
문제
Canary 배포 중 v1에 90%, v2에 10% 트래픽을 전송하고자 한다. 이러한 구성을 위한 리소스는?
① ServiceEntry
② DestinationRule + VirtualService
③ Sidecar + WorkloadEntry
④ Gateway + AuthorizationPolicy
정답: ②
해설: VirtualService에서 트래픽 분산(weight 설정), DestinationRule에서 Subset을 정의해 Canary 전략이 구현됩니다.
✅ NO.06 [객관식 / 중]
문제
Service Mesh가 API Gateway와 중복되는 역할이 아닌 것은?
① 트래픽 라우팅
② 외부 인증 (e.g. OAuth)
③ TLS 종료
④ 서비스 내 동적 재시도
정답: ④
해설: 외부 인증은 API Gateway의 주 역할이며, Service Mesh는 서비스 간 재시도와 Circuit Breaker에 집중합니다.
✅ NO.07 [단답형 / 중]
문제
Istio에서 외부 서비스를 허용할 때 사용하는 리소스는?
정답: ServiceEntry
해설: 기본적으로 Istio는 클러스터 외부 트래픽을 차단하며, ServiceEntry를 통해 외부 서비스 접속을 허용합니다.
✅ NO.08 [객관식 / 상]
문제
아래 중 Circuit Breaker 설정 항목이 아닌 것은?
① maxConnections
② outlierDetection
③ connectionPool
④ allowOrigins
정답: ④
해설: allowOrigins는 CORS 설정에 쓰이며, Circuit Breaker와는 무관합니다.
✅ NO.09 [객관식 / 하]
문제
Sidecar가 배포되는 방식으로 올바른 것은?
① Kubernetes Node에 DaemonSet으로 배포됨
② 각 Pod 내부에 컨테이너로 삽입됨
③ 별도 VM에 공통 프록시로 배포됨
④ Control Plane에 배포되어 모든 Pod를 통제함
정답: ②
해설: Istio 등 Service Mesh는 Sidecar를 각 Pod에 주입하여 네트워크 트래픽을 통제합니다.
✅ NO.10 [객관식 / 중]
문제
Service Mesh가 장애 전파를 막기 위해 사용하는 대표적인 기술은?
① Static Routing
② Token Bucket
③ Circuit Breaker
④ Sticky Session
정답: ③
해설: Circuit Breaker는 비정상 응답이 지속되는 인스턴스를 격리해 장애 전파를 방지합니다.
✅ NO.11 [시나리오형 / 상]
문제
AP 서비스가 DB 호출 시 일부 인스턴스만 장애를 일으킨다. 전체 장애로 확산되는 것을 막고 싶을 때 설정할 수 있는 Envoy의 기능은?
① JWT Auth Filter
② Outlier Detection
③ AuthorizationPolicy
④ Headless Service
정답: ②
해설: Outlier Detection은 지연, 오류 비율이 높은 인스턴스를 자동으로 차단합니다.
✅ NO.12 [객관식 / 중]
문제
Istio Telemetry에 사용되는 도구가 아닌 것은?
① Prometheus
② Grafana
③ Jaeger
④ FluentBit
정답: ④
해설: FluentBit는 로그 수집 도구이며, Istio의 기본 Telemetry에는 포함되지 않습니다.
✅ NO.13 [객관식 / 중]
문제
Istio의 Gateway 리소스는 어떤 역할을 하는가?
① 외부 트래픽 수신 및 라우팅
② 내부 마이크로서비스 간 통신 설정
③ RBAC 정책 적용
④ 트래픽 거부 규칙 관리
정답: ①
해설: Gateway는 외부 트래픽을 수신하여 VirtualService와 연계해 내부로 라우팅합니다.
✅ NO.14 [객관식 / 상]
문제
Istio 인증 체계 중 mTLS를 통해 얻을 수 있는 보안 효과로 적절하지 않은 것은?
① 암호화된 서비스 간 통신
② 사용자 인증 기반 권한 부여
③ 신뢰된 서비스 간 상호 인증
④ 재전송 공격 방지
정답: ②
해설: mTLS는 서비스 간 인증을 다루며, 사용자 인증은 OAuth 등의 별도 메커니즘이 필요합니다.
✅ NO.15 [단답형 / 하]
문제
Envoy Proxy를 통해 트래픽 로그를 수집하는 대표적인 분석 도구는?
정답: Jaeger
해설: Jaeger는 분산 추적 도구로, Envoy에서 생성된 trace 정보를 수집하고 시각화합니다.
✅ NO.16 [객관식 / 상]
문제
Istio Control Plane의 구성 요소 중 정책 적용 및 트래픽 제어를 담당하는 것은?
① Pilot
② Mixer
③ Citadel
④ Galley
정답: ①
해설: Pilot은 Envoy에 라우팅 및 정책 구성을 전달하는 핵심 제어 컴포넌트입니다.
✅ NO.17 [객관식 / 중]
문제
서비스 간 요청 수 증가에 따른 성능 병목을 탐지하기 위한 핵심 요소는?
① Retry Count
② Distributed Tracing
③ Rate Limit
④ HPA Metric
정답: ②
해설: Distributed Tracing(Jaeger 등)은 요청 흐름을 시각화하여 병목 지점을 식별합니다.
✅ NO.18 [객관식 / 상]
문제
Kubernetes 외부 트래픽을 Ingress 없이 서비스로 라우팅하려면 필요한 Istio 리소스는?
① Sidecar
② AuthorizationPolicy
③ Gateway + VirtualService
④ PeerAuthentication
정답: ③
해설: Gateway는 외부 연결을 받고, VirtualService는 해당 트래픽의 내부 라우팅을 정의합니다.
✅ NO.19 [객관식 / 중]
문제
다중 클러스터(Multi-Cluster) 환경에서 Service Mesh를 구성할 때 필요한 조건은?
① 동일한 Kubeconfig
② 동일한 Mesh ID
③ 동일한 Pod CIDR
④ 동일한 RBAC 설정
정답: ②
해설: 동일한 Mesh ID를 사용해야 클러스터 간 서비스들이 같은 메시에 속함을 인식합니다.
✅ NO.20 [시나리오형 / 상]
문제
보안 정책 변경으로 모든 서비스 간 통신을 암호화해야 한다. 단, 일부 레거시 서비스는 TLS를 지원하지 않는다.
이 상황에서 단계적 적용을 위한 구성은?
① 전체 서비스에 PeerAuthentication strict 적용
② Mutual TLS를 permissive 모드로 설정
③ 레거시 서비스 격리 후 인증 제거
④ mTLS는 불가능하므로 Sidecar 제거
정답: ②
해설: permissive 모드는 mTLS와 비암호화 트래픽을 동시에 허용하여 점진적 이전이 가능합니다.
🧠 Service Mesh 암기카드 요약본 (20문항 대응)
| 01 | Control Plane | Sidecar 설정·정책 배포는 Control Plane이 담당한다. |
| 02 | VirtualService | 트래픽 비율 조정은 VirtualService의 weight로 설정한다. |
| 03 | PeerAuthentication | mTLS 설정 시 PeerAuthentication 리소스를 사용한다. |
| 04 | Envoy 역할 | Envoy는 TLS 종료와 L7 로드밸런싱을 처리하는 프록시다. |
| 05 | Canary 배포 | VirtualService + DestinationRule 조합으로 버전 분산 배포를 구현한다. |
| 06 | API Gateway vs Service Mesh | 재시도 등 내부 통신 로직은 Service Mesh 전용이다. |
| 07 | ServiceEntry | 외부 서비스 접근은 ServiceEntry로 허용한다. |
| 08 | Circuit Breaker | Circuit Breaker 설정은 outlierDetection, maxConnections 등이다. |
| 09 | Sidecar 구조 | Sidecar는 각 Pod 내 컨테이너로 주입되어 네트워크 트래픽을 제어한다. |
| 10 | 장애 복원력 | Circuit Breaker는 장애 인스턴스를 격리해 전체 장애 확산을 막는다. |
| 11 | Outlier Detection | Envoy의 Outlier Detection은 지연 응답 인스턴스를 자동 차단한다. |
| 12 | Telemetry 도구 | Jaeger, Prometheus, Grafana는 Istio Telemetry의 핵심 도구다. |
| 13 | Istio Gateway | Gateway는 외부 트래픽을 수신하고 내부로 연결하는 역할이다. |
| 14 | mTLS 한계 | mTLS는 서비스 간 인증이며 사용자 인증은 OAuth가 담당한다. |
| 15 | Jaeger | Jaeger는 분산 추적을 위한 트래픽 트레이싱 도구이다. |
| 16 | Pilot | Pilot은 Envoy에 라우팅/정책을 배포하는 제어 컴포넌트다. |
| 17 | Tracing | 서비스 병목 탐지는 Distributed Tracing이 필수다. |
| 18 | Gateway + VirtualService | Istio에서 외부 트래픽 진입은 Gateway + VirtualService가 구성된다. |
| 19 | Multi-Cluster 구성 | 동일한 Mesh ID가 다중 클러스터에서 통합된 메시를 구성한다. |
| 20 | permissive mTLS | mTLS를 점진 적용하려면 permissive 모드로 설정한다. |
'MSA Outer > Service Mesh' 카테고리의 다른 글
| Service Mesh vs API Gateway 차이점 (0) | 2025.05.09 |
|---|