블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


Service Mesh

아키텍쳐 /대용량 아키텍쳐 | 2018.06.11 00:45 | Posted by 조대협

서비스 매쉬의 컨셉


기본 개념


MSA로 전환이 되면서, 내부 서비스간의 Orchestration 뿐 아니라, 

서비스 레지스트리, 중앙 로그 수집, 분산 트렌젝션 추적, 메세지 라우팅등 다양한 기능들이 필요하게되었는데,

이러한 구현은 ESB에서 근래에 API GW 등을 사용하는 접근으로 바뀌었지만, 적당한 솔루션이 없고, 중앙 집중화된 솔루션으로 인한 장애와 운영 복잡도에 따라 중앙 집중형이 아닌 Proxy 서버를 각 서비스 앞에 배치 시키는 형태의 접근 방법이 대두되고 있는데, 이를 service mesh라고 하며,

이에 대한 실 구현체로는 Isitio나 linkerd 와 같은 오픈 소스 프로젝트들이 진행되고 있다.


Service Mesh = Network Layer


서비스 매쉬는, TCP/IP위의 새로운 네트워크 레이어로 정의되기도 한다.

TCP L3/L4가 각 종단간의 머신(프로세스)를 연결하기 위한 메커니즘이라면 서비스 매쉬는 서비스간의 통신을 위한 메커니즘으로 볼 수 있다. 


아래 자료 참고 

The service mesh is a networking model that sits at a layer of abstraction above TCP/IP. It assumes that the underlying L3/L4 network is present and capable of delivering bytes from point to point. (It also assumes that this network, as with every other aspect of the environment, is unreliable; the service mesh must therefore also be capable of handling network failures.)

In some ways, the service mesh is analogous to TCP/IP. Just as the TCP stack abstracts the mechanics of reliably delivering bytes between network endpoints, the service mesh abstracts the mechanics of reliably delivering requests between services. Like TCP, the service mesh doesn’t care about the actual payload or how it’s encoded. The application has a high-level goal (“send something from A to B”), and the job of the service mesh, like that of TCP, is to accomplish this goal while handling any failures along the way.

Unlike TCP, the service mesh has a significant goal beyond “just make it work”: it provides a uniform, application-wide point for introducing visibility and control into the application runtime. The explicit goal of the service mesh is to move service communication out of the realm of the invisible, implied infrastructure, and into the role of a first-class member of the ecosystem—where it can be monitored, managed and controlled.

Isitio vs Linkerd

지원 하는 기능은 비슷한듯,분산로그 추적, 다이나믹 라우팅, 매트릭 수집 등. 그러나 구조적인 면에서 Isitio는 프록시를 Pod에 사이드 카로 배포하고 Linkerd는 K8s에서 Daemonset으로 배포해서 하나의 Pod가 노드의 모든 Pod의 메세지 라우팅을 담당하는 구조가 됨


정의 참고

https://www.thoughtworks.com/radar/techniques/service-mesh

https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/#_ga=2.36506144.1424840283.1528645558-1445170731.1528645558