Service Mesh Architecture (서비스 메시 아키텍처)

 

마이크로 서비스는 소프트웨어 산업에 많은 영향을 주었습니다. Monolithic에서 마이크로 서비스 아키텍처로 전환하면 독립적으로 더 자주 애플리케이션을 배포 할 수 있습니다.

그러나 마이크로 서비스 아키텍처를 채택하는 것은 분산 시스템을 설계 할 때 발생하는 문제들을 가지고 있고 이 문제를 해결해야 한다는 것을 의미합니다.

분산 컴퓨팅의 오류를 살펴 볼까요?

  • 네트워크는 신뢰할 수 있다.
  • 지연 시간은 0이다.
  • 네트워크 대역폭은 무한하다.
  • 네트워크는 안전하다.
  • Topology는 변하지 않는다.
  • 관리자 한명이 모든 것을 처리한다.
  • 데이터 전달 비용은 0이다.
  • 동종 네트워크이다.

마이크로 서비스 아키텍처 사용시 네트워크에 대하여 종속성이 생깁니다. 이는 안정성에 문제를 유발합니다. 서비스 수가 증가하게 되면 각 서비스간 상호 작용을 처리하고, 상태를 모니터링하고, 로깅 및 측정을 수행하고, 여러 장애 지점을 체크하는 등의 작업을 수행해야 합니다. 서비스간 통신을 신뢰할 수 있도록 각 서비스에는 위에서 언급한 것들을 처리하는 공통 기능이 필요합니다. 그러나 다양한 언어로 작성된 수많은 마이크로 서비스를 사용해야 한다면 많은 노력을 해야 합니다.

서비스 메시란 무엇인가?

image

서비스 메시는 MSA에서 서비스 간 통신을 처리하는 인프라 레이어(통신에 대한 기본 베이스)로 정의할 수 있습니다. 서비스 메시는 MSA와 관련된 복잡성을 줄이고 아래와 같은 기능을 제공합니다.

  • Load Balancing
  • Service Discovery
  • Health check
  • Authentication
  • Traffic management and routing
  • Circuit breaking and failover policy
  • Security
  • Metrics and telemetry
  • Fault injection

서비스 메시가 필요한 이유?

MSA에서 서비스간 통신 처리는 쉽지 않습니다. 위에서 언급한 Service discovery, Load balancing과 같은 기능을 제공하기 위해서는 Fat library에 의존하게 됩니다. Netflix는 Hystrix, Eureka등 자체 라이브러리를 만들었습니다.

그러나 이러한 구성 요소는 애플리케이션의 코드내에서 구성해야 합니다.

사용하는 Language에 따라 구현 방식도 다릅니다. Fat Library가 version up 될때마다 애플리케이션에 반영 후 테스트하고 배포해야 합니다. 그리고 애플케이션의 비즈니스 코드와 MSA 통신을 위한 코드가 혼합되는 문제가 발생합니다. 이는 긴밀한 결합이고 전반적으로 애플리케이션의 복잡성을 증가시킵니다. 코드에 혼합되기 때문에 개발자는 매커니즘과 구성 방법등을 이해해야합니다. 그렇지 않으면 문제가 발생 했을때에 해결할 수 없기 때문입니다.

이러한 이유는 서비스 메시가 나오게 된 계기가 됩니다. 위에서 언급한 복잡성을 애플리케이션에서 분리하여 Service Proxy에 주입하여 처리 할 수 있습니다. Service Proxy는 Traffic management, Circuit break, Service discovery, Authentication, Monitoring, Security등과 같은 기능을 제공합니다. 따라서 애플리케이션 관점에서는 비즈니스 기능만 구현하면 됩니다. 비즈니스 기능을 개발하는 개발자들이 매커니즘과 구성 방법을 이해할 필요도 없고요.

서비스 메시의 도입으로 명확하게 책임을 분리할 수 있습니다. 개발자들의 삶은 더 편안해지게 됩니다. 문제가 발생할 경우 개발자는 애플리케이션의 문제인지 네트워크의 문제인지에 따라서 근본적인 원인을 쉽게 식별할 수 있게 됩니다.

서비스 메시가 구현되는 방식은?

서비스 메시를 적용하기 위해서는 마이크로 서비스와 함께 Proxy를 배포해야 합니다. 이를 Side car pattern이라고 합니다.

사이드카는 애플리케이션에서 복잡성을 제거하고 Service discovery, Traffic management, Load balancing, Circuit break등과 같은 기능을 처리 합니다.

Lyft의 Envoy는 Cloud Native Application을 위해 설계된 가장 인기 있는 Open source proxy입니다. Envoy는 모든 마이크로 서비스와 함께 실행되며 플랫폼에 상관없이 필요한 기능을 제공합니다. 서비스에 대한 모든 트래픽은 Envoy proxy를 통해 흐르게 됩니다.

Istio란 무엇인가?

image

Istio는 마이크로 서비스를 연결, 관리, 보호하기 위한 플랫폼 입니다. Kubernetes 커뮤니티에서 인기가 많고 널리 채택되고 있습니다.

Istio는 Intelligent Routing, Load balancing, Service discovery, policy enforcement(정책 시행), in-depth telemetry(심층적인 원격 측정), circuit breaking과 재시도 기능, 로깅, 모니터링등과 같은 MSA에 필요한 기능을 제공합니다.

Istio는 현재 시점에서 서비스 메시를 가장 잘 구현한 것 중 하나입니다. Istio외에 linkerd, conduit이 존재합니다. 위에서 언급된 기능에 대한 지식이 없이도 마이크로 서비스를 배포 할 수 있습니다.

현재 시장에서는 Monolithic 서비스를 마이크로 서비스로 분리하는 작업을 진행중입니다. 이는 더 많은 서비스를 관리해야 한다는 입장이기도 하고 이는 부담으로 다가올 수 있습니다. 서비스 메시는 이러한 상황에서 애플리케이션에 코드 주입없이 복잡성을 제거해줍니다.

MSA로의 전환을 생각한다면 서비스 메시도 고려해보세요.

참고:

  • https://dzone.com/articles/the-rise-of-service-mesh-architecture

잠깐, 글이 유익했나요?

Buy Me A Coffee