1주차 : Istio 이해하기 (2)

구구달스 2025. 4. 9. 18:57

CloudNet@ 가시다님이 진행하는 Istio Hands-on Study [1기]

✅ Service Mesh 소개

서비스 메시(Service Mesh)란?

서비스 메시란 애플리케이션 간의 네트워크 통신을 대신 관리해주는 인프라입니다.
이를 통해 개발자는 복잡한 네트워크 코드를 작성하지 않고도 다양한 기능을 쉽게 사용할 수 있습니다.

📦 어떻게 동작하나요?

서비스 메시에는 두 가지 주요 구성 요소가 있습니다:

데이터 플레인 (Data Plane)
→ 실제 트래픽(요청/응답)을 전달하고, 감시하는 역할을 하는 프록시(Proxy) 들입니다.
모든 통신은 이 프록시를 통해 이루어집니다.
컨트롤 플레인 (Control Plane)
→ 데이터 플레인의 동작 방식을 설정하고 제어하는 중앙 제어 시스템입니다.

🌟 서비스 메시의 주요 기능

✅ 서비스 복원력: 실패 시 재시도, 타임아웃, 회로 차단기 등 제공
👀 관찰 가능성: 지연 시간, 오류율 등 트래픽 정보를 실시간으로 수집
🚦 트래픽 제어: 일부 트래픽만 새 버전으로 보내는 카나리 배포 가능
🔒 보안: 모든 통신에 대해 mTLS(상호 인증 암호화) 적용
📜 정책 적용: 통신 규칙을 설정하고 자동으로 적용

🧩 왜 사용하나요?

개발자는 네트워크 기능을 애플리케이션에 직접 구현할 필요 없음
다양한 언어, 프레임워크에서도 일관된 기능 제공
코드 변경 없이도 배포, 테스트, 운영을 안전하고 빠르게 수행 가능

✅ Istio Service Mesh 소개

⛵ Istio란 무엇인가요?

Istio는 Google, IBM, Lyft가 만든 오픈소스 서비스 메시입니다.
애플리케이션의 네트워크 통신을 자동으로 관리해주며, 시스템에 복원력과 관찰 가능성(모니터링 기능)을 더해줍니다.

🧱 Istio의 구성요소

데이터 플레인 (Data Plane)
→ 각 애플리케이션 옆에 배치되는 Envoy 프록시를 통해 모든 트래픽을 처리합니다.
컨트롤 플레인 (Control Plane)
→ 프록시 설정, 보안 관리, 정책 선언 등을 담당하는 중앙 제어 구성 요소입니다.

🚀 Istio의 주요 기능

✅ 프로그래밍 언어와 무관하게 자동으로 복원력 제공
(재시도, 타임아웃, 회로 차단기 등)
📡 관찰 가능성 향상
(메트릭 수집, 분산 추적, 로깅 등)
🎯 정교한 트래픽 제어
(카나리 배포, A/B 테스트, 점진적 롤아웃 등 가능)
🔒 보안 기본 탑재
- mTLS로 자동 트래픽 암호화
- 인증서 자동 발급/갱신
- 서비스 간 접근 제어 정책 설정 가능
📏 정책과 제한 설정
- 서비스 간 통신 제어
- 할당량(Quota), 속도 제한(Rate limiting) 등 지원

🌍 어디서 사용되나요?

원래는 Kubernetes 기반으로 만들어졌지만, VM, OpenShift 등 다양한 환경에서도 사용 가능합니다.
하이브리드 클라우드(공공 + 사설 클라우드 혼합) 환경에서도 유용합니다.

🧭 왜 Istio를 써야 하나요?

네트워크 관련 코드를 애플리케이션에 직접 작성할 필요 없음
언어/프레임워크 상관없이 일관된 기능 제공
운영/배포 자동화로 운영 복잡도 감소, 보안 향상
클라우드 환경에 맞는 강력하고 유연한 서비스 통신 관리

✅ Service Mesh vs. API Gateway

🧩 API 게이트웨이란?

주로 외부(공개) API를 위한 중앙 집중형 출입구 역할
주요 기능:
- 🔐 인증 및 보안
- 📊 사용량 제한, 할당량 관리
- 💵 API 요금제, 사용자 등록, 청구 등 연계
- 📈 메트릭 수집

🛠️ API 게이트웨이 사용 시 문제점

모든 서비스 트래픽이 API 게이트웨이를 거쳐야 하므로: → 요청이 두 번 이동(hop):
1. 게이트웨이로 이동
2. 실제 서비스로 이동
- 🌀 네트워크 병목 발생 가능
- 🐌 지연(latency) 증가
- 🔒 보안이 완전 자동화되지 않음 (앱이 일부 참여해야 함)
- ⚠️ 복원력 기능 부족 (ex. 재시도, 회로 차단기 등)

🔧 서비스 메시의 차별점

프록시(예: Envoy)가 각 서비스 옆에 설치되어 트래픽을 직접 처리
➕ 추가 홉(hop) 없이 바로 연결, 네트워크 효율 ↑
🛡️ 앱의 참여 없이도 끝단 간 보안(mTLS) 가능
🧠 각 애플리케이션에 맞춘 맞춤형 설정 가능
🧭 점점 API 게이트웨이 기능도 서비스 메시에서 흡수 중

💡 결론: 무엇이 다를까?

항목	API 게이트웨이	서비스 메시
위치	중앙 (엣지 또는 내부)	분산 (앱 옆)
주 용도	외부 API 관리	내부 서비스 통신 관리
구조	중앙 집중형	분산형
보안	앱이 참여 필요	자동, 투명한 mTLS
복원력 기능	제한적	강력함 (재시도, 회로 차단 등)
미래 방향	별도 시스템 필요	메시 안에서 통합 가능성 ↑

✅ Istio는 마이크로서비스가 아니어도 쓸 수 있나요?

🔧 Istio는 이런 환경에서도 잘 작동해요

🧱 기존 모놀리식(일체형) 애플리케이션
- Istio 프록시를 옆에 배치하면 자동으로 트래픽을 처리해줍니다
- 애플리케이션 수정 없이도 메트릭 수집, 정책 적용 가능
🏗️ 레거시/기존 시스템
- 클라우드 환경뿐 아니라 온프레미스(내부 서버) 에도 적용 가능
- 하이브리드 클라우드 환경에서 유용함
- 예: "클라우드 앱은 내부 시스템에 접근 금지" 같은 정책 가능

✅ Istio는 분산 시스템에서 어떤 역할을 하나요?

📌 Istio의 역할

🔗 서비스 간 연결 관리
→ 복잡한 네트워크 로직을 애플리케이션 밖에서 처리
🛡️ 보안 기능 제공
→ mTLS, 인증 토큰 검증, 통신 암호화 등
🚦 트래픽 제어
→ 버전 분기, 조건별 라우팅, A/B 테스트
📊 관측 및 정책 적용
→ 요청 수, 지연 시간, 실패율 등 메트릭 수집 및 정책 실행

❌ Istio가 하지 않는 일

🔄 배포 자동화	CI/CD 도구 아님 (코드 배포는 담당하지 않음)
🧠 비즈니스 로직	어떤 서비스 호출할지, 데이터 조합 등은 애플리케이션 책임
🔀 서비스 오케스트레이션	데이터 변환, 규칙 처리, 로직 흐름 제어는 하지 않음

🧱 Istio의 위치

"배포 플랫폼"과 "애플리케이션 코드" 사이의 연결 담당자

개발자는 비즈니스 코드에 집중
운영자는 네트워크 보안과 트래픽 제어에 집중

💡 핵심 요약

Istio는 네트워크와 보안, 트래픽 정책을 자동으로 관리해주는 도구
복잡한 분산 환경에서도 쉽고 안정적으로 서비스 운영 가능!

🎯 Application (애플리케이션)	- 콘텐츠 변환 - 호출 순서 및 오케스트레이션 - 데이터 분리/통합 - 콘텐츠 기반 라우팅
🔗 Service Mesh (서비스 메시)	- 네트워크 복원력 - mTLS 보안 - 네트워크 메트릭 수집 - 로드 밸런싱 및 서비스 검색
⚙️ Deployment Platform (배포 플랫폼)	- 인스턴스 배치 - 자동 확장 - 리소스 관리 - 작업 스케줄링 및 상태 점검

애플리케이션은 업무 로직, 서비스 메시는 네트워크 제어, 배포 플랫폼은 리소스와 인프라 관리를 담당

✅ Service Mesh 의 단점

🔍 복잡한 디버깅
- 서비스 메시에는 프록시(예: Envoy)가 요청 경로에 추가되어 문제 해결이 어려워질 수 있습니다.
- 익숙하지 않다면 이 프록시는 블랙박스처럼 느껴질 수 있습니다.
🧩 테넌시(서비스 분리) 문제
- 메시 내 많은 서비스가 얽히면, 하나의 설정 실수로 여러 서비스가 영향을 받을 수 있습니다.
- 철저한 정책 및 자동화 없이는 위험합니다.
⚙️ 운영 복잡성 증가
- 서비스 메시가 추가되면 네트워크와 보안, 정책 설정 등 운영할 것이 많아져 복잡해집니다.
- 기존 팀과 프로세스에 잘 녹여내는 것이 중요합니다.
📘 학습 곡선
- 설정과 사용법이 어렵고 새로운 개념이 많아 학습이 필요합니다.
- 조직 전체가 서비스 메시 개념을 이해해야 효과적으로 활용할 수 있습니다.

저작자표시 (새창열림)