본문 바로가기

service mesh

(4)
Service Mesh 아키텍처 스타일 비교 이전 글에서 서비스 메시에 대해서 간략히 언급했었습니다. 서비스 메시가 무엇인지 아직 모르시는 분은 링크를 통해 읽어보세요. 본 글에서는 서비스 메시의 아키텍처 스타일에 대해서 얘기하고자 합니다. 우리가 이미 알고 있는 방법일 수 도 있습니다. Library 방식: 라이브러리로 필요 기능들이 제공되며, 애플리케이션의 코드 레벨로 사용되어야 합니다. (어찌 보면, 서비스 메시라고 할 순 없지만 서비스 메시를 구현하기 위한 대안? 으로 이해하시면 될 것 같습니다.) Node Agent 방식: Node Agent나 Daemon에 의해서 기능들이 제공됩니다. Sidecar 방식: 컨테이너내에 sidecar로 proxy가 적용되어 기능들이 제공됩니다. 이제 각각의 아키텍처 스타일에 대해 상세히 살펴 볼까요? 타입..
Service Mesh Architecture (서비스 메시 아키텍처) 마이크로 서비스는 소프트웨어 산업에 많은 영향을 주었습니다. Monolithic에서 마이크로 서비스 아키텍처로 전환하면 독립적으로 더 자주 애플리케이션을 배포 할 수 있습니다. 그러나 마이크로 서비스 아키텍처를 채택하는 것은 분산 시스템을 설계 할 때 발생하는 문제들을 가지고 있고 이 문제를 해결해야 한다는 것을 의미합니다. 분산 컴퓨팅의 오류를 살펴 볼까요? 네트워크는 신뢰할 수 있다. 지연 시간은 0이다. 네트워크 대역폭은 무한하다. 네트워크는 안전하다. Topology는 변하지 않는다. 관리자 한명이 모든 것을 처리한다. 데이터 전달 비용은 0이다. 동종 네트워크이다. 마이크로 서비스 아키텍처 사용시 네트워크에 대하여 종속성이 생깁니다. 이는 안정성에 문제를 유발합니다. 서비스 수가 증가하게 되면 ..
Istio / Envoy에서 OpenTracing 사용 하기 Sidecar Proxy는 코드 삽입없이 모니터링 데이터를 얻는 매우 간단한 방법을 제공한다. Tracing은 대규모 분산 시스템에서 가장 어려운 부분이기 때문에 Sidecar Pattern은 큰 이점으로 작용한다. Sidecar Proxy에서 Tracing을 하기 위해서는 Inbound에서 Outbound 요청으로 일부 Header를 전달해야 한다. Application단에서는 매우 간단하지만 전달받은 Header를 넘기는 로직을 처리하면 불편 할 수 있다. 비즈니스 레이어에서 Header를 전달하는 것을 조정한다고 상상해보면 Sidecar Pattern을 사용하는 이점이 없을 수 도 있다. Tracing은 Envoy만 사용 Header 전달이 기존 Application 코드에서는 아래처럼 작성된다. ..
Servie Mesh 알아 보기 지난 몇년간 Micro Service Architecture는 많이 발전되어 왔습니다. 그리고 현 시점에 몇 가지 새로운 개념과 패턴이 등장하고 있습니다. 이 중 “Service Mesh” 개념은 많은 인기를 얻고 있습니다. 본 글에서는 Service Mesh와 관련된 주요 개념에 대해서 설명합니다. Service Mesh의 등장 배경 현재까지 대부분의 사람들은 마이크로 서비스가 SOA/ESB와 같은 이전 아키텍처에서 가진 문제점들의 해답이라고 생각합니다. 그러나 실제 마이크로 서비스를 구현할 때, ESB가 지원하는 대부분의 기능들이 마이크로 서비스 수준에서 구현 가능하다는 것을 알 수 있습니다. 예를 들어서 여러 가지 다운 스트림 서비스를 호출하고 이 기능을 다른 서비스로 노출해야 하는 시나리오가 있습..