Service Mesh의 간단한 개념

Istio를 이해하기 위해선 먼저 Service Mesh란 무엇인지에 대해 먼저 알고있어야 합니다.

 

참고 자료: What is a Service Mesh?

 

마이크로서비스, MSA가 등장하면서 도커, 쿠버네티스, 서비스 메시라는 개념이 나타났습니다.

도커

• 패키징 문제 해결
• 애플리케이션과 런타임 종속성을 컨테이너로 패키징
  • 어디에서나 실행될 수 있는 대체가능한 단위 생성

쿠버네티스

• 도커 이미지를 컨테이너 서비스로 올렸을 때,
• 그 수가 많을 경우 이들을 매핑하고 관리(=오케스트레이션)하는 도구

서비스 메시

• 마이크로서비스 간 통신을 제어/보안/관찰할 수 있도록 도와주는 인프라 계층
• To manage connections between services, a service mesh provides new features like monitoring, logging, tracing, and traffic control.
  • 서비스 간 통신을 관리하기 위해 서비스 메시는 모니터링, 로깅, 추적, 트래픽 관리와 같은 기능을 제공합니다.
• It's independent of each service's code, which allows it to work across network boundaries and with multiple service management systems.
  • 서비스 메시는 서비스의 코드와는 독립적이어서 네트워크 경계에서 동작하고, 다른 여러 서비스 관리 시스템들과 같이 동작할 수 있습니다.

그렇다면 이런 서비스 메시는 왜 필요한 걸까요?

서비스 메시의 필요성

 

Different teams may build individual microservices and choose their coding languages and tools.

서로다른 팀들은 서로다른 마이크로서비스를 만들게 될거고, 그 과정에서 그들만의 코딩 언어와 도구들을 선택하게 될 것입니다. 

However, the microservices must communicate for the application code to work correctly.

그러나, 각각의 마이크로서비스들은 애플리케이션이 잘 동작하기 위해 서로 통신해야만 합니다.

 

Developers must monitor and optimize the application across services, but it's hard to gain visibility due to the system's distributed nature.

개발자들은 서비스 전반에 걸쳐 애플리케이션을 모니터링하고 최적화해야 하지만, 시스템의 분산 구조로 인해 시스템을 전체적으로 살펴보기(기시성)가 힘듭니다.

As application scale, it becomes more complex to manage communications.

애플리케이션은 날이 갈수록 커지기 때문에, 통신을 관리하기는 갈수록 복잡해지고 있습니다.

 

따라서 서비스 간 통신을 단순화하고 통합해서 관리하기 쉽게 만들어주는 서비스 메시가 필요한 것입니다.