Enterprise Service Mesh를 만드는 이유는 무엇입니까?

Service Mesh는 마이크로서비스를 통합하고 클라우드 인프라로 마이그레이션하기 위한 잘 알려진 아키텍처 패턴입니다. 오늘날 클라우드 컨테이너 세계에서는 클라우드 컨테이너 없이는 매우 어렵습니다. 여러 오픈 소스 서비스 메시 구현이 이미 시장에 나와 있지만 그 기능, 신뢰성 및 보안이 항상 충분하지는 않습니다. 특히 전국의 대규모 금융 회사의 요구 사항에 있어서는 더욱 그렇습니다. 이것이 바로 우리 Sbertech가 Service Mesh를 맞춤화하기로 결정하고 Service Mesh의 장점과 단점, 이에 대해 무엇을 할 것인지에 대해 이야기하고 싶은 이유입니다.

클라우드 기술의 인기와 함께 Service Mesh 패턴의 인기가 높아지고 있습니다. 다양한 네트워크 서비스 간의 상호 작용을 단순화하는 전용 인프라 계층입니다. 최신 클라우드 애플리케이션은 수백 또는 수천 개의 서비스로 구성되며 각 서비스에는 수천 개의 복사본이 있을 수 있습니다.

이러한 서비스 간의 상호 작용과 관리는 Service Mesh의 핵심 작업입니다. 실제로 이는 중앙에서 관리되고 일련의 매우 유용한 기능을 수행하는 많은 프록시의 네트워크 모델입니다.

프록시 수준(데이터 평면)에서:

• 라우팅 및 트래픽 밸런싱 정책 할당 및 배포
• 키, 인증서, 토큰 배포
• 원격 측정 수집, 모니터링 지표 생성
• 보안 및 모니터링 인프라와의 통합

제어 영역 수준에서:

• 라우팅 및 트래픽 밸런싱 정책 적용
• 재시도 및 시간 초과 관리, "죽은" 노드 감지(회로 차단), 오류 주입 관리 및 기타 메커니즘을 통한 서비스 복원력 보장
• 통화 인증/승인
• 측정항목 삭제(관찰 가능성)

이 기술 개발에 관심이 있는 사용자의 범위는 소규모 신생 기업부터 PayPal과 같은 대규모 인터넷 기업에 이르기까지 매우 넓습니다.

기업 부문에 Service Mesh가 필요한 이유는 무엇입니까?

Service Mesh를 사용하면 많은 이점이 있습니다. 우선, 개발자에게는 매우 편리합니다. 코드 작성에 있어서 기술 플랫폼이 등장하다이는 전송 계층이 애플리케이션 로직과 완전히 분리되어 있기 때문에 클라우드 인프라로의 통합을 크게 단순화합니다.

또한, Service Mesh는 공급자와 소비자 간의 관계를 단순화합니다. 오늘날에는 특별한 통합 중개자 및 중재자(엔터프라이즈 서비스 버스)를 거치지 않고도 API 제공자와 소비자가 스스로 인터페이스와 계약에 동의하는 것이 훨씬 쉬워졌습니다. 이 접근 방식은 두 가지 지표에 큰 영향을 미칩니다. 새로운 기능을 시장에 출시하는 속도(시장 출시 시간)가 빨라지지만 동시에 통합이 독립적으로 수행되어야 하므로 솔루션 비용도 증가합니다. 비즈니스 기능 개발팀이 Service Mesh를 사용하면 여기서 균형을 유지하는 데 도움이 됩니다. 결과적으로 API 제공업체는 서비스의 애플리케이션 구성 요소에만 집중하고 이를 Service Mesh에 간단히 게시할 수 있습니다. API는 모든 클라이언트가 즉시 사용할 수 있게 되며 통합 품질은 프로덕션 준비가 되어 단일 작업이 필요하지 않습니다. 추가 코드 줄.

다음 장점은 Service Mesh를 사용하는 개발자는 비즈니스 기능에만 집중합니다. — 서비스의 기술적 구성 요소가 아닌 제품에 대한 것입니다. 예를 들어, 네트워크를 통해 서비스가 호출되는 상황에서 어딘가에서 연결 실패가 발생할 수 있다는 사실을 더 이상 생각할 필요가 없습니다. 또한 Service Mesh는 동일한 서비스 복사본 간의 트래픽 균형을 유지하는 데 도움이 됩니다. 복사본 중 하나가 "죽으면" 시스템은 모든 트래픽을 나머지 라이브 복사본으로 전환합니다.

서비스 메시 - 이는 분산 애플리케이션을 생성하기 위한 좋은 기반입니다., 내부 및 외부 서비스에 대한 호출 제공에 대한 세부 정보를 클라이언트에게 숨깁니다. Service Mesh를 사용하는 모든 애플리케이션은 네트워크와 서로 전송 수준에서 격리됩니다. 즉, 둘 사이에는 통신이 없습니다. 이 경우 개발자는 자신의 서비스에 대한 모든 권한을 갖습니다.

주목해야 할 점은 서비스 메시 환경에서 분산 애플리케이션을 업데이트하는 것이 더 쉬워졌습니다. 예를 들어 블루/그린 배포에서는 두 개의 애플리케이션 환경을 설치할 수 있으며 그 중 하나는 업데이트되지 않고 대기 모드에 있습니다. 릴리스에 실패할 경우 이전 버전으로 롤백하는 작업은 Service Mesh가 잘 수행하는 역할인 특수 라우터에 의해 수행됩니다.. 새 버전을 테스트하려면 다음을 사용할 수 있습니다. 카나리아 릴리스 — 클라이언트 파일럿 그룹의 트래픽 또는 요청 중 10%만 새 버전으로 전환합니다. 주요 트래픽은 이전 버전으로 이동하며 중단되는 일이 없습니다.

또한 Service Mesh는 실시간 SLA 제어를 제공합니다.. 분산 프록시 시스템에서는 클라이언트 중 하나가 할당된 할당량을 초과해도 서비스가 실패하는 것을 허용하지 않습니다. API 처리량이 제한되면 누구도 대량의 트랜잭션으로 이를 압도할 수 없습니다. Service Mesh는 서비스 앞에 서서 불필요한 트래픽을 허용하지 않습니다. 단순히 통합 계층에서 반격할 뿐이고, 서비스 자체는 이를 인지하지 못한 채 계속 작동할 것입니다.

회사가 통합 솔루션 개발 비용을 절감하려는 경우 Service Mesh는 다음과 같은 도움도 줍니다. 상용 제품에서 오픈 소스 버전으로 전환할 수 있습니다.. 우리의 Enterprise Service Mesh는 오픈 소스 버전의 Service Mesh를 기반으로 합니다.

또 다른 장점 - 완전한 단일 통합 서비스 세트의 가용성. 모든 통합은 이 미들웨어를 통해 이루어지기 때문에 회사의 비즈니스 핵심을 구성하는 애플리케이션 간의 모든 통합 트래픽과 연결을 관리할 수 있습니다. 매우 편안합니다.

그리고 마침내 Service Mesh는 회사가 동적 인프라로 전환하도록 권장합니다. 이제 많은 사람들이 컨테이너화를 모색하고 있습니다. 모놀리스를 마이크로서비스로 자르고 이 모든 것을 아름답게 구현하는 것에 대한 주제가 점점 커지고 있습니다. 그러나 수년 동안 생산되어 온 시스템을 새로운 플랫폼으로 이전하려고 하면 즉시 여러 가지 문제에 직면하게 됩니다. 모든 것을 컨테이너에 넣고 플랫폼에 배포하는 것은 쉽지 않습니다. 그리고 이러한 분산 구성 요소의 구현, 동기화 및 상호 작용은 또 다른 매우 복잡한 주제입니다. 그들은 어떻게 서로 소통할 것인가? 연속적인 실패가 발생합니까? Service Mesh를 사용하면 이러한 문제 중 일부를 해결하고 네트워크 교환 논리를 잊어버릴 수 있다는 사실로 인해 이전 아키텍처에서 새 아키텍처로 쉽게 마이그레이션할 수 있습니다.

서비스 메시 사용자 정의가 필요한 이유는 무엇입니까?

우리 회사에는 수백 개의 시스템과 모듈이 공존하고 있으며 런타임 부하가 매우 높습니다. 따라서 한 시스템이 다른 시스템을 호출하고 응답을 받는 간단한 패턴만으로는 충분하지 않습니다. 프로덕션 환경에서는 더 많은 것을 원하기 때문입니다. 엔터프라이즈 서비스 메시에서 또 무엇이 필요합니까?

이벤트 처리 서비스

실시간 이벤트 처리, 즉 고객의 행동을 실시간으로 분석하고 즉시 관련 제안을 제공할 수 있는 시스템을 만들어야 한다고 상상해 봅시다. 유사한 기능을 구현하려면 다음을 사용하십시오. 이벤트 중심 아키텍처(EDA)라고 불리는 아키텍처 패턴. 현재 서비스 메시 중 어느 것도 이러한 패턴을 기본적으로 지원하지 않지만 이는 특히 은행의 경우 매우 중요합니다!

원격 프로시저 호출(RPC)이 모든 버전의 Service Mesh에서 지원되지만 EDA와 친숙하지 않다는 것은 매우 이상합니다. Service Mesh는 일종의 현대적인 분산 통합이고 EDA는 고객 경험 측면에서 독특한 작업을 수행할 수 있게 해주는 매우 관련성이 높은 아키텍처 패턴이기 때문입니다.

우리의 Enterprise Service Mesh는 이 문제를 해결해야 합니다. 또한 다양한 필터와 템플릿을 사용하여 보장된 전달, 스트리밍 및 복잡한 이벤트 처리의 구현을 보고 싶습니다.

파일 전송 서비스

EDA 외에도 파일을 전송할 수 있으면 좋을 것입니다. 기업 규모에서는 파일 통합만 가능한 경우가 많습니다. 특히 ETL(Extract, Transform, Load) 아키텍처 패턴이 사용됩니다. 일반적으로 모든 사람은 파일을 독점적으로 교환합니다. 빅 데이터가 사용되므로 별도의 요청을 푸시하는 것은 비현실적입니다. Enterprise Service Mesh에서 기본적으로 파일 전송을 지원하는 기능은 비즈니스에 필요한 유연성을 제공합니다.

오케스트레이션 서비스

대규모 조직에는 거의 항상 다양한 제품을 만드는 다양한 팀이 있습니다. 예를 들어 은행에서는 어떤 팀은 예금 업무를 하고, 다른 팀은 대출 상품 업무를 하는데, 그런 경우가 꽤 많습니다. 이들은 제품을 만들고 API를 개발하여 다른 사람들에게 제공하는 다양한 사람, 다양한 팀입니다. 그리고 이러한 서비스를 구성하고 일련의 API를 순차적으로 호출하기 위한 복잡한 논리를 구현해야 하는 경우가 매우 많습니다. 이 문제를 해결하려면 이 모든 복합 로직(여러 API 호출, 요청 경로 설명 등)을 단순화하는 통합 계층의 솔루션이 필요합니다. 이는 Enterprise Service Mesh의 오케스트레이션 서비스입니다.

AI와 ML

마이크로서비스가 단일 통합 계층을 통해 통신할 때 Service Mesh는 자연스럽게 각 서비스 호출에 대한 모든 것을 알고 있습니다. 우리는 누가 누구에게, 언제, 얼마나 오랫동안, 몇 번이나 전화했는지 등 원격 측정을 수집합니다. 이러한 서비스가 수십만 개, 호출이 수십억 개이면 이 모든 것이 축적되어 빅데이터가 형성됩니다. 이 데이터는 AI, 머신러닝 등을 이용해 분석할 수 있고, 분석 결과를 바탕으로 유용한 작업을 수행할 수 있습니다. Service Mesh에 통합된 이 모든 네트워크 트래픽과 애플리케이션 호출에 대한 제어를 적어도 부분적으로 인공 지능에 넘겨주는 것이 적절할 것입니다.

API 게이트웨이 서비스

일반적으로 서비스 메시에는 신뢰할 수 있는 경계 내에서 서로 통신하는 프록시와 서비스가 있습니다. 그러나 외부 거래 상대방도 있습니다. 이 소비자 그룹에 노출되는 API에 대한 요구 사항은 훨씬 더 엄격합니다. 우리는 이 작업을 두 가지 주요 부분으로 나눕니다.

• Безопасность. DDOS, 프로토콜, 애플리케이션, 운영 체제 등과 관련된 문제.
• 규모. 클라이언트에 제공해야 하는 API 수가 수천 또는 수십만 개에 달할 경우 이러한 API 세트에 대한 일종의 관리 도구가 필요합니다. API가 작동하는지 여부, 상태, 트래픽 흐름, 통계 등을 지속적으로 모니터링해야 합니다. API 게이트웨이는 전체 프로세스를 관리 가능하고 안전하게 만드는 동시에 이 작업을 처리해야 합니다. 이 구성 요소 덕분에 Enterprise Service Mesh는 내부 및 외부 API를 모두 쉽게 게시하는 방법을 배웁니다.

특정 프로토콜 및 데이터 형식에 대한 지원 서비스(AS 게이트웨이)

현재 대부분의 Service Mesh 솔루션은 기본적으로 HTTP 및 HTTP2 트래픽에서만 작동하거나 TCP/IP 수준의 축소 모드에서만 작동할 수 있습니다. Enterprise Service Mesh는 매우 구체적인 다른 많은 데이터 전송 프로토콜과 함께 등장하고 있습니다. 일부 시스템은 메시지 브로커를 사용할 수 있고 다른 시스템은 데이터베이스 수준에서 통합됩니다. 회사에 SAP가 있는 경우 자체 통합 시스템을 사용할 수도 있습니다. 게다가 이 모든 것이 작동하며 비즈니스의 중요한 부분입니다.

“기존 서비스를 버리고 Service Mesh를 사용할 수 있는 새로운 시스템을 만들자”라고만 말할 수는 없습니다. 모든 기존 시스템을 새 시스템(마이크로서비스 아키텍처)과 연결하려면 Service Mesh를 사용할 수 있는 시스템에 일종의 어댑터, 중개자, 게이트웨이가 필요합니다. 동의합니다. 서비스와 함께 상자에 들어 있으면 좋을 것입니다. AC 게이트웨이는 모든 통합 옵션을 지원할 수 있습니다. Enterprise Service Mesh를 설치하기만 하면 필요한 모든 프로토콜과 상호 작용할 준비가 되었다고 상상해 보십시오. 이 접근 방식은 우리에게 매우 중요합니다.

이것은 대략 우리가 Service Mesh(Enterprise Service Mesh)의 기업 버전을 상상하는 방식입니다. 설명된 사용자 정의는 이미 만들어진 통합 플랫폼의 오픈 소스 버전을 사용하려고 할 때 발생하는 대부분의 문제를 해결합니다. 불과 몇 년 전에 소개된 Service Mesh 아키텍처는 계속 발전하고 있으며 우리는 그 개발에 기여할 수 있게 되어 기쁩니다. 우리의 경험이 귀하에게 도움이 되기를 바랍니다.

출처 : habr.com