81~84일차) 2025-04-24 ~ 2025-04-29 [3. k8s 팀 프로젝트] - 이스티오

MSA에서 istio사용하는 이유

✅ MSA에서 Istio를 사용하는 이유

MSA는 마이크로서비스가 분산되고 수많은 네트워크 호출을 하게 됨.

👉 그걸 자동으로 통제, 보호, 관찰, 제어하기 위해 Istio 같은 Service Mesh가 필요함.

---

📦 MSA 환경의 공통 문제점

문제 예시

💬 서비스 간 통신 복잡도 증가	서비스 A → B → C → D 호출, 누가 실패하면 전체 영향
🔐 보안 이슈	서비스끼리 TLS 적용, 인증/인가가 복잡함
🧪 A/B 테스트, canary 배포 어려움	1%만 새 버전으로 보내야 하는데 라우팅 설정이 어렵다
🔍 가시성 부족	누가 누구에게 얼마나 요청했는지, 실패율은 얼마인지 알기 어려움
⚠️ 복원력 설정 없음	재시도, 타임아웃, Circuit Breaker를 개발자가 직접 구현해야 함

---

✅ 그래서 Istio가 해결해주는 것

영역 Istio가 해주는 일 개발자가 할 필요 없음

📡 트래픽 제어	경로 분기, weight 설정, A/B 테스트	X
🔁 복원력	재시도, 타임아웃, Circuit Breaker	X
🛡️ 보안	서비스 간 mTLS, 정책 기반 접근 제어	X
🔍 모니터링	Prometheus, Grafana, Jaeger 연동	X
⚙️ 배포 전략	Canary, Blue-Green, Header 기반 라우팅	X
🔒 정책 적용	특정 서비스끼리만 통신 허용 (AuthorizationPolicy)	X

---

🔁 개발자가 코드를 안 고치고도 가능한 예시

하고 싶은 일 Istio만으로 가능?

“v2 버전으로 10%만 보내자”	✅ VirtualService 설정만 하면 됨
“서비스 간 TLS 암호화 하자”	✅ PeerAuthentication 한 줄이면 됨
“이 요청 3번까지 재시도해줘”	✅ VirtualService에서 retries 설정
“운영중에 슬쩍 새 버전 배포하자”	✅ Canary 배포 100% 무중단 가능
“서비스 간 트래픽을 추적하고 싶다”	✅ Envoy + Jaeger 자동 트레이싱

마이크로서비스 아키텍처

시스템의 개별 기능을 서비스 단위로 잘라 서비스끼리 gRPC나 RESTful API 등으로 연계하여 시스템 전체를 구성하는 느슨한 결합 아키텍처

• 장점
  • 각 서비스 프로그래밍 언어나 프레임워크 등의 기술을 자유롭게 선정 가능
  • 서비스별로 개발 규모나 성능을 확장 가능
  • 서비스별로 독립적으로 업데이트가 가능하여 릴리스 사이클을 단축할 수 있고 장애 영향 범위를 해당 서비스에 한정할 수 있음
• 단점
  • 시스템을 여러 마이크로서비스로 적절하게 분리하기 어려움
  • 시스템 전체 모니터링 어려움 - 관측 가능성
• 마이크로서비스 간 문제 해결책
  • 서비스 매시

↔ 모놀리식 아키텍처

시스템 전체를 하나의 서비스로 만든 구성

 

쿠버네티스에 마이크로서비스 아키텍처로 구성된 시스템을 배포하는 경우,
한 개의 마이크로서비스를 한 개의 컨테이너 이미지로 개발하여 한 개의 디플로이먼트로 배포한다.

---

이스티오

서비스 매시를 구현하는 오픈 소스 소프트웨어

• 파드 간 통신 경로에 프록시를 놓고 트래픽 모니터링이나 트래픽 컨트롤
• 트래픽 시프팅 : 디플로이먼트에서 디플로이먼트로 트래픽을 전달할 때 유연하 게 목적지를 제어
  ex. 트래픽의 99%를 이전 이미지로 기동하고 있는 디플로이먼트에 전송하고 1%를 신규 디플로이먼트에 전송하여 서비스 환경에 단계적으로 적용하는 카나리 배포
• 서킷 브레이커 : 목적지 마이크로서비스에 문제가 있을 경우에는 접속을 차단하여 바로 출발지 마이크로서비스에 요청 에러를 반환
• 폴트 인젝션 : 의도적으로 요청을 지연시키거나 실패시키는 기능

서비스 매시

마이크로서비스 간에 매시 형태의 통신이나 그 경로를 제어하는 개념

---

🧭 왜 Istio를 사용하는가?

❓ 문제 상황 (Istio 도입 배경)

1. 서비스가 많아지며 복잡한 통신 구조가 발생
2. → 누가 누구랑 통신하는지 파악이 안 됨
3. 각 서비스에서 장애 대응이나 트래픽 제어를 직접 구현해야 함
4. → Retry, Timeout, Circuit Breaker 등
5. 버전 별 배포(Canary 등)이 어려움
6. → 신규 기능 테스트할 때 전체 사용자에게 영향
7. 서비스 간 인증/인가 및 보안 적용 어려움
8. → mTLS, 정책 기반 접근 제어 필요

---

📦 Istio 없는 환경 vs. Istio 사용하는 환경 비교

기능 Istio 미사용 (기본 K8s) Istio 사용

서비스 디스커버리	DNS 기반	+ 로드밸런싱, 커스텀 라우팅 가능
버전 분리 및 배포	수동으로 관리 (selector 교체 등)	가중치/조건 기반 라우팅으로 유연
보안 (mTLS)	직접 설정 필요	자동 적용
모니터링	앱 내 로깅, 별도 설정 필요	사이드카 자동 수집 + 시각화
트래픽 정책 제어	거의 불가능 (네트워크 플러그인 의존)	세분화된 정책 정의 가능
개발자 개입 정도	코드/CI 변경 많음	인프라 레벨에서 해결 가능

---

🎯 Istio의 목적과 기대 효과

기능 기대효과

사이드카 프록시	트래픽, 보안, 로깅 등을 앱 코드와 분리해서 처리
Traffic Routing (Canary, A/B)	신규 버전을 일부 사용자에게만 노출 가능
Circuit Breaker / Retry / Timeout	장애 전파 방지, 서비스 안정성 증가
mTLS 통신 암호화	파드 간 통신 보안 강화
Policy (AuthorizationPolicy 등)	네임스페이스, 서비스 레벨 접근 제어
Kiali / Jaeger	서비스 간 흐름 시각화, 트래픽 트레이싱

---

📘 실습 시나리오 예시

1. 사이드카 프록시 주입 실습

• 자동 주입 네임스페이스 설정 (istio-injection=enabled)
• 실제로 어떤 통신이 사이드카를 통해 흐르는지 확인 (Kiali에서 시각화)
  • 1-1. 🔁 마이크로서비스 확장

---

2. Canary 배포 시나리오

• v1, v2 두 버전의 서비스 배포
• VirtualService 설정으로 v2로 10%만 라우팅
• Gradual rollout 시나리오:
  • 10% → 30% → 100% 전환
  • 장애 발생 시 롤백 테스트

---

3. Circuit Breaker & Retry 구성

• DestinationRule로 CircuitBreaker 설정
• 강제로 v2 서비스 CPU를 100% 점유 → 응답 지연
• Retry 설정으로 재시도 여부 확인
• 브레이커가 발동되면 자동으로 실패처리

---

4. 서비스 트레이싱 (Jaeger)

• HTTP 요청 하나를 보낸 뒤, Jaeger에서 전체 요청 흐름 확인
• 호출 간 지연 시간, 실패 구간 등 파악

---

5. Kiali 대시보드 활용

• 실시간 서비스 맵 확인 (서비스 간 연결 상태, 트래픽 비율)
• 버전별 트래픽 분포 시각화
• Metric 기반 문제 탐지

---

✅ 서비스 메쉬 담당자가 달성할 목표

목표 설명

서비스 간 트래픽 흐름을 정책 기반으로 통제	VirtualService, DestinationRule
장애 발생 시 안정적으로 대응	Circuit Breaker, Retry
서비스 맵 시각화 및 트레이싱 가능	Kiali, Jaeger
보안 강화를 위한 mTLS 설정 실습	클러스터 내부 통신 암호화
버전 관리 및 롤백 전략 실습	Canary, A/B 테스팅 시나리오 구현

---

📂 발표나 문서화 포인트

• Istio 구성 아키텍처 다이어그램
• 트래픽 라우팅 YAML 설정 예시
• 장애 주입 전/후 Kiali 대시보드 비교
• Jaeger 스크린샷 (트랜잭션 흐름)
• 실습 결과 및 느낀점 정리

---

❓ 왜 10% → 30% → 100%로 점진적으로 올릴까?

🔥 핵심 이유: 리스크 최소화 & 문제 조기 탐지

---

📉 한번에 100% 배포 vs ✅ 점진적 배포 비교

항목 100% 배포 (빅뱅) Canary 배포

위험성	최고조 (문제 발생 시 전체 영향)	문제가 있어도 영향 범위가 작음
롤백	전체 롤백 → 다운타임 발생 가능	일부만 롤백, 서비스 계속 제공
디버깅	트래픽 쏟아지면 로그 추적 어려움	트래픽 적어 문제 원인 파악 쉬움
사용자 영향	모두에게 영향	일부만 테스트 대상
운영 피드백	없음 (도박)	실제 사용자 반응 기반 판단 가능