다음을 통해 공유

Service Mesh 통신 인프라

팁 (조언)

이 콘텐츠는 eBook, Architecting Cloud Native .NET Applications for Azure에서 발췌한 것으로, .NET Docs 또는 오프라인에서 읽을 수 있는 다운로드 가능한 무료 PDF로 제공됩니다.

PDF 다운로드

Azure eBook의 클라우드 네이티브 .NET 앱 커버 썸네일.

이 장 전체에서 마이크로 서비스 통신의 과제를 살펴보았습니다. 개발 팀은 백 엔드 서비스가 서로 통신하는 방식에 민감해야 한다고 말했습니다. 이상적으로는 서비스 간 통신이 적을수록 좋습니다. 그러나 백 엔드 서비스가 작업을 완료하기 위해 서로 의존하는 경우가 많기 때문에 회피가 항상 가능한 것은 아닙니다.

동기 HTTP 통신 및 비동기 메시징을 구현하기 위한 다양한 방법을 살펴보했습니다. 각 경우에서 개발자는 통신 코드를 구현하는 부담을 짊어집니다. 통신 코드는 복잡하고 시간이 많이 소요됩니다. 잘못된 결정으로 인해 심각한 성능 문제가 발생할 수 있습니다.

마이크로 서비스 통신에 대한 보다 현대적인 접근 방식은 서비스 메시라는 새로운 빠르게 진화하는 기술을 중심으로 합니다. 서비스 메시는 서비스 간 통신, 복원력, 그리고 많은 횡단 관심사를 처리할 수 있는 기능이 내장된 구성 가능한 인프라 계층입니다. 이러한 문제에 대한 책임을 마이크로 서비스에서 서비스 메시 계층으로 이동합니다. 통신은 마이크로서비스에서 분리되어 추상화됩니다.

서비스 메시의 핵심 구성 요소는 프록시입니다. 클라우드 네이티브 애플리케이션에서 프록시 인스턴스는 일반적으로 각 마이크로 서비스와 함께 배치됩니다. 별도의 프로세스에서 실행되는 동안 두 프로세스는 긴밀하게 연결되고 동일한 수명 주기를 공유합니다. 사이드카 패턴으로 알려진 이 방식은 그림 4-24에 나와 있습니다.

사이드카가 있는 서비스 메시

그림 4-24. 사이드카가 있는 서비스 메시

이전 그림에서는 각 마이크로 서비스와 함께 실행되는 프록시에 의해 메시지가 가로채는 방법을 확인합니다. 각 프록시는 마이크로 서비스와 관련된 트래픽 규칙을 사용하여 구성할 수 있습니다. 메시지를 이해하고 서비스 및 외부 세계에 걸쳐 메시지를 라우팅할 수 있습니다.

서비스 간 통신 관리와 함께 Service Mesh는 서비스 검색 및 부하 분산을 지원합니다.

일단 구성되면 서비스 메시는 매우 기능적입니다. 메시는 서비스 검색 엔드포인트에서 해당 인스턴스 풀을 검색합니다. 특정 서비스 인스턴스에 요청을 보내 결과의 대기 시간 및 응답 유형을 기록합니다. 최근 요청에 대해 관찰된 대기 시간을 포함하여 다양한 요인에 따라 빠른 응답을 반환할 가능성이 가장 큰 인스턴스를 선택합니다.

서비스 메시는 애플리케이션 수준에서 트래픽, 통신 및 네트워킹 문제를 관리합니다. 메시지와 요청을 이해합니다. 서비스 메시는 일반적으로 컨테이너 오케스트레이터와 통합됩니다. Kubernetes는 서비스 메시를 추가할 수 있는 확장 가능한 아키텍처를 지원합니다.

6장에서는 아키텍처 및 사용 가능한 오픈 소스 구현에 대한 논의를 포함하여 Service Mesh 기술에 대해 자세히 설명합니다.

요약

이 장에서는 클라우드 네이티브 통신 패턴에 대해 설명했습니다. 프런트 엔드 클라이언트가 백 엔드 마이크로 서비스와 통신하는 방법을 검토하여 시작했습니다. 그 과정에서 API 게이트웨이 플랫폼과 실시간 통신에 대해 이야기했습니다. 그런 다음 마이크로 서비스가 다른 백 엔드 서비스와 통신하는 방법을 살펴보았습니다. 서비스 전반에서 동기 HTTP 통신과 비동기 메시징을 모두 살펴보았습니다. 클라우드 네이티브 세계에서 예정된 기술인 gRPC를 다루었습니다. 마지막으로, 마이크로 서비스 통신을 간소화할 수 있는 Service Mesh라는 새롭고 빠르게 진화하는 기술을 도입했습니다.

클라우드 네이티브 시스템에서 통신을 구현하는 데 도움이 되는 관리되는 Azure 서비스에 특히 중점을 두였습니다.

다음으로 클라우드 네이티브 시스템의 분산 데이터와 이점과 과제로 이동합니다.

참고문헌

이전다음