[week2 tmi] Service Mesh & Istio

[seoyeon0201]

2주차: Docker & K8S

서비스 매쉬 & 이스티오

1. 배경
   ✔️ 쿠버네티스가 등장한 이후 최근 많은 기업이 MSA(Microservices Architecture)를 채택 => 하나의 애플리케이션에서 동작하는 모놀리식 아키텍처와 달리, MSA는 나누어진 서비스와 인스턴스 수만큼 관리 대상이 급격히 증가
   ✔️ 서비스 간 복잡한 연결 구조 때문에 장애 추적이 어렵고, 장애가 발생한 서비스로 인해 타 서비스를 호출하는 로직이 수행되지 않는 장애 전파 현상 발생

2. 서비스 메쉬 (Service Mesh)
   ⚡️ 서비스 메쉬 아키텍처는 MSA의 트래픽 문제를 보완하는 마이크로서비스 간 커뮤니케이션 인프라
   ⚡️ 마이크로서비스 간의 직접 통신을 하지 않게 되어 위의 문제 해결 가능
   ⚡️ 사이드카 패턴 : 모든 응용 프로그램 컨테이너에 사이드카 컨테이너를 추가하여 배포. 사이드카는 서비스에 들어오거나 나가는 모든 네트워크 트래픽 처리. 서비스가 타 서비스를 직접 호출하는 것이 아니라 프록시(proxy)를 통해 호출 => 대규모의 마이크로서비스 환경이더라도 별도 작업 없이 서비스 연결뿐만 아니라 로깅, 모니터링, 보안, 트래픽 제어 가능

3. 이스티오 (Istio)
   = 쿠버네티스 기반의 서비스 메쉬
   서비스 메쉬의 기본 아키텍처는 위에서 말한 바와 같이 서비스 간의 직접 호출이 아닌 사이드카 패턴의 프록시를 배치해 통신하는 것. 이러한 서비스 메쉬 기술의 대표적인 구현체가 이스티오

🔻 부하분산과 트래픽 관리
🔻 보안
🔻 모니터링

4. 서비스 메쉬 적용시 고려사항
   복잡성 + 사이드카 컨테이너 수 증가 + 기술력 미성숙

https://www.samsungsds.com/kr/insights/mesh.html