서비스 메시는 서비스가 애플리케이션 수명 주기 전반에 걸쳐 데이터와 일관성을 공유하며 서로 통신할 수 있도록 지원하는 사전 구성된 애플리케이션 서비스입니다. 서비스 메시는 컨테이너의 쓰기 가능한 얇은 계층을 사용하여 마이크로서비스를 관리하는 데 사용됩니다. 쉽게 설정하고 배포할 수 있도록 구축된 서비스 메시는 마이크로서비스의 가치를 실현하여 기업이 새로운 서비스를 쉽게 발견하고 API 제품으로 관리할 수 있도록 합니다.

서비스 메시를 구현하려면 디지털 시대에 맞는 현대적인 통합 전략이 있어야 합니다. 민첩해야 하고 혁신을 촉진해야 하며 비즈니스 요구 사항을 충족해야 합니다. 효율성도 중요하지만 최우선 순위는 아닙니다.

서비스 메시의 이점

마이크로서비스 기반 애플리케이션 표준화. 분산 애플리케이션의 동작은 지원하는 네트워크에 따라 다릅니다. 다양한 동작으로 인해 구성 관리 시스템에 문제가 발생할 수 있습니다. 서비스 메시는 조정자에 대한 고유한 데이터 센터의 번거로움을 줄여줍니다.

분산 애플리케이션의 동작 모니터링 및 개선. 우수한 서비스 메시는 요청이 많은 구성 요소를 가장 쉽게 액세스할 수 있는 애플리케이션 제어 평면의 위치에 배치하도록 설계되었습니다. 즉, 구성 요소는 원활하고 효율적으로 작동해야 합니다. 서비스 메시를 사용하면 데이터가 공유되므로 개발자는 다음 반복 단계에서 개선해야 할 사항을 확인할 수 있습니다.

복잡한 상호 작용에 대한 투명성이 향상되었습니다. 클라우드 네이티브 환경에서는 정보의 흐름을 따라가기가 어려운 경우가 많습니다. 서비스 메시는 중요한 애플리케이션 서비스가 제공되는 방식에 투명성을 제공하여 해당 서비스의 동작을 추적할 수 있도록 합니다.

암호화. 서비스 메시는 키, 인증서 및 TLS 구성을 관리하여 사용자가 실패하지 않는 지속적인 암호화를 보장합니다. 사용자는 더 이상 암호화를 구현하거나 인증서를 관리할 필요가 없습니다. 대신 이러한 책임은 앱 개발자에서 프레임워크 계층으로 넘어갑니다.

서비스 메시 아키텍처는 어떻게 작동합니까?

서비스 메시는 컨테이너와 함께 작동하는 경량화된 프록시 모음을 제공합니다. 각 프록시는 컨테이너 간에 발생하는 상호 작용에 대한 게이트웨이 역할을 합니다. 프록시는 서비스 메쉬를 통해 요청을 서비스하는 적절한 다운스트림 컨테이너로 이동하여 개별 서비스에서 서비스 간 통신을 제어하는 논리를 제거하고 인프라 계층으로 추상화합니다.

이를 위해 서비스 메시는 네트워크 프록시 모음으로 앱에 구축됩니다. 제어 평면의 컨트롤러는 프록시 간의 연결을 조정합니다. 컨트롤러는 제어 정책에 대한 액세스를 제공하고 컨테이너에서 지표를 수집합니다. 서비스 메시에서 요청은 자체 인프라 계층의 프록시를 통해 마이크로서비스 간에 라우팅됩니다. 이러한 이유로 서비스 메시를 구성하는 개별 프록시는 각 서비스 내에서가 아니라 각 서비스와 함께 실행되기 때문에 "사이드카"라고도 합니다. 이와 함께 각 서비스에서 분리된 이러한 "사이드카" 프록시는 메시 네트워크를 형성합니다.

서비스 메시의 구성 요소

서비스 발견

프록시는 마이크로서비스와 다른 애플리케이션 간의 통신을 위한 경로를 제공합니다. 새 복제본이 추가되거나 제거되면 검색이 동적으로 진행됩니다.

서비스 메시 라우팅

서비스 메시 경량 프록시에는 요청에 가장 적합한 경로를 제공하는 스마트 라우팅 메커니즘이 내장되어 있습니다. 라우팅은 서비스 간에 동적으로 수행됩니다.

서비스 메시 식별 가능성

최신 서비스 메시에는 제어 평면에 서비스 간 로깅, 추적 요청 및 응답 호출, 모니터링 및 경고를 지원하는 구성 요소가 배포되어 있습니다. 장애 패턴은 대시보드를 통해 감지됩니다.

서비스 메시 보안

서비스 메시는 서비스 간 통신의 인증, 권한 부여 및 암호화를 제공합니다.

최적화된 경험 제공

사용자는 서비스 메시를 생성할 때 개별 개인 및 양식의 워크플로에 맞게 앱의 디자인, 기능 및 기능을 조정하는 별도의 목적에 맞는 앱을 구축하려고 하게 됩니다. 이를 통해 설계, 개발 및 배포가 더 쉬운 특수 목적 애플리케이션을 만들 수 있습니다. 또한, 애플리케이션은 랩톱에서 실행되는 웹 기반 애플리케이션이든, 스마트폰의 모바일 앱이든, 기존 인터페이스이든 사용자가 작업을 수행할 때 선호하는 채널에 더 집중할 수 있습니다.

여러 기능과 경험을 지원하는 서비스 메시를 설계하려면 사용 중인 모든 애플리케이션에 대해 다양한 기능과 워크플로를 지원하는 유연한 백엔드가 필요합니다. 백엔드는 지속적인 경험을 제공해야 하므로 구현 시 최적화된 목적에 맞는 앱의 특정 요구 사항을 지원하도록 구성해야 합니다. 특정 유형의 백엔드인 프론트엔드용 백엔드(BFF라고도 함)는 이러한 최적화된 앱에 대한 사용자 지정 워크플로를 지원합니다. 서비스는 또한 특정 UX와 일치해야 합니다. 이 모델을 통해 개발 팀은 다른 앱이나 서비스에 영향을 주지 않고 새로운 개인이나 또는 장치를 지원하기 위해 새로운 프런트엔드를 신속하게 구현할 수 있습니다.

서비스 메시 사용 사례

블루-그린 배포

웹사이트, 특히 전자상거래를 위한 웹사이트의 경우 매 1초의 다운타임이 수익에 직접적인 영향을 미치게 됩니다. 블루-그린 배포를 사용하면 비용이 드는 서비스 중단 없이 애플리케이션에 대한 복잡한 업데이트를 수행할 수 있습니다. 블루-그린 배포에는 여러 유형이 있지만 모두 다음의 동일한 유형의 패턴을 따릅니다.

1. 웹사이트 블루는 실시간 트래픽으로 실행되고 있습니다.
2. 업데이트된 버전의 웹사이트(웹사이트 그린)는 트래픽이 웹사이트 블루로 계속 이동하는 동안 배포 및 테스트됩니다.
3. 배포가 수행되고 소량의 실시간 트래픽이 웹사이트 그린으로 전환됩니다(한편 모든 것이 올바르게 작동하는 것을 관찰해야 합니다).
4. 웹사이트 블루로 가는 트래픽 양이 감소함에 따라 웹사이트 그린으로 가는 트래픽 양이 점차 증가합니다. 이것은 모든 트래픽이 웹사이트 그린으로 갈 때까지 계속됩니다.
5. 웹사이트 블루가 중단되었습니다.

모든 것을 한 번에 업데이트하는 대신 새 사이트로 이동하는 트래픽을 점진적으로 늘리면 운영 팀은 변경 사항이 시스템 전체에 영향을 미치기 전에 롤백할 수 있습니다. 이는 업데이트되는 서비스가 다른 서비스와 복잡한 상호 종속성을 갖는 경우에 특히 유용합니다.

서비스 메시는 모든 서비스 간 트래픽을 제어하고 배포를 관리하고 전역 시스템 상태를 관찰할 수 있는 중앙 집중화된 위치를 제공하기 때문에 블루-그린 배포를 수행하는 데 특히 적합한 기술입니다.

커뮤니케이션 최적화

앱에 추가되는 모든 새 서비스 또는 컨테이너에서 실행 중인 기존 서비스의 새 인스턴스는 통신 환경을 복잡하게 만들고 새로운 실패 지점을 유발합니다. 복잡한 마이크로서비스 아키텍처 내에서 서비스 메시를 사용하지 않으면 문제가 발생한 위치를 찾기가 번거롭고 거의 불가능할 수 있습니다.

이는 서비스 메시가 서비스 간 통신의 모든 측면을 성능 지료로 캡처하기 때문입니다. 시간이 지남에 따라 서비스 메시에서 볼 수 있는 데이터를 서비스 간 통신 규칙에 적용할 수 있으므로 보다 효율적이고 안정적인 서비스 요청이 가능합니다.

예를 들어, 주어진 서비스가 실패하면 서비스 메시는 재시도가 성공하기까지 걸린 시간에 대한 데이터를 수집할 수 있습니다. 주어진 서비스의 실패 시간에 대한 데이터가 집계되면 해당 서비스를 재시도하기 전에 최적의 대기 시간을 결정하는 규칙을 작성하여 불필요한 재시도에 의해 시스템에 과부하가 걸리지 않도록 할 수 있습니다.