Service Mesh: 최신 기술에 대해 모든 소프트웨어 엔지니어가 알아야 할 사항

메모. 번역: 서비스 메시는 아직 러시아어로 안정적으로 번역되지 않는 현상입니다(2년 이상 전에 우리는 "서비스용 메시" 옵션을 제공했고, 조금 후에 일부 동료들이 "서비스 체" 조합을 적극적으로 홍보하기 시작했습니다) . 이 기술에 대한 끊임없는 이야기로 인해 마케팅 및 기술 구성 요소가 너무 밀접하게 얽혀 있는 상황이 발생했습니다. 원래 용어의 저자 중 한 사람이 작성한 이 훌륭한 자료는 엔지니어뿐만 아니라 엔지니어에게도 명확성을 제공하기 위한 것입니다.

만화 출처 세바스티안 카세레스

소개

백엔드 시스템 분야 어딘가에서 일하는 소프트웨어 엔지니어라면 지난 몇 년 동안 "서비스 메시"라는 용어가 이미 마음에 확고하게 자리 잡았을 것입니다. 이상한 우연 덕분에 이 문구는 점점 더 업계를 장악하고 있으며, 과대 광고 및 관련 판촉 제안은 눈덩이처럼 커져 언덕 아래로 날아가고 둔화될 기미를 보이지 않고 있습니다.

서비스 메시는 클라우드 네이티브 생태계의 어둡고 경향이 있는 물에서 태어났습니다. 불행히도 이것은 그것을 둘러싼 많은 논란이 "저칼로리 잡담"에서 기술적 용어를 사용하기 위해 노골적인 헛소리에 이르기까지 다양하다는 것을 의미합니다. 그러나 모든 노이즈를 필터링하면 서비스 메쉬가 매우 실제적이고 명확하며 중요한 기능을 가지고 있음을 알 수 있습니다.

이 게시물에서 나는 바로 그렇게 하려고 노력할 것입니다. 즉, 서비스 메시에 대한 정직하고 심층적인 엔지니어 지향 가이드를 제공하는 것입니다. 다음과 같은 질문에 답하겠습니다. "무슨 일이야?", - 뿐만 아니라 "무엇 때문에?"과 "왜 지금?". 마지막으로, (제 생각에는) 이 특정 기술이 그 자체로 흥미로운 이야기인 미친 과대 광고를 야기한 이유를 설명하려고 합니다.

Кто я?

모두 안녕! 내 이름은 윌리엄 모건. 나는 창조자 중 한 명입니다. 링커드 - 최초의 서비스 메쉬 프로젝트이자 용어 출현의 책임이 있는 프로젝트 서비스 메시 그런 식으로 (죄송합니다!). (참고 번역.: 그런데, 이 용어가 등장한 2,5년 이상 전에 우리는 이미 "라는 동일한 저자의 초기 자료를 번역했습니다.서비스 메시란 무엇이며 [마이크로서비스가 포함된 클라우드 애플리케이션의 경우] 서비스 메시가 필요한 이유는 무엇입니까?".) 나도 리드 부력의 Linkerd와 같은 멋진 서비스 메시를 구축하는 스타트업입니다. 잠수.

이 문제에 대해 제가 매우 편파적이고 주관적인 의견을 가지고 있다고 추측할 수 있습니다. 그러나 나는 편견을 최소한으로 유지하려고 노력할 것입니다(한 섹션을 제외하고: "서비스 메시에 대한 이야기가 왜 그렇게 많이 나오는 걸까요?",-그럼에도 불구하고 선입견을 공유하겠습니다). 저도 이 가이드가 최대한 객관적이 되도록 최선을 다하겠습니다. 구체적인 예에서는 다른 유형의 서비스 메시 구현에서 내가 알고 있는 차이점(있는 경우)을 지적하면서 주로 Linkerd의 경험에 의존할 것입니다.

좋아, 간식으로 넘어갈 시간이야.

서비스 메시란?

모든 과대 광고에도 불구하고 서비스 메시는 구조적으로 매우 단순합니다. 서비스 "옆"에 위치한 사용자 공간 프록시(나중에 "가까운"에 대해 조금 이야기하겠습니다)와 일련의 제어 프로세스입니다. 프록시는 집합적으로 호출됩니다. 데이터 평면, 제어 프로세스가 호출됩니다. 제어 평면. 데이터 플레인은 서비스 간의 호출을 가로채서 서비스와 "다르게" 수행합니다. 컨트롤 플레인은 각각 프록시의 동작을 조정하고 사용자에게 액세스를 제공합니다. 네트워크를 전체적으로 조작하고 측정할 수 있습니다.

이 프록시는 무엇입니까? 이것은 "계층 7 인식" 범주의 TCP 프록시입니다. (즉, OSI 모델의 7번째 계층을 "고려") HAProxy 및 NGINX와 같습니다. 원하는 대로 프록시를 선택할 수 있습니다. Linkerd는 복잡하지 않은 이름의 Rust 프록시를 사용합니다. 링커드 프록시. 서비스 메시용으로 특별히 컴파일했습니다. 다른 메시는 다른 프록시를 선호합니다(Envoy가 일반적인 선택임). 그러나 프록시를 선택하는 것은 구현의 문제일 뿐입니다.

이러한 프록시 서버는 무엇을 합니까? 분명히 그들은 서비스에 대한 프록시 호출과 서비스로부터의 호출을 프록시합니다(엄밀히 말하면 수신 및 발신 호출을 모두 처리하는 프록시 및 리버스 프록시 역할을 함). 그리고 통화에 중점을 둔 기능 세트를 구현합니다. между 서비스. 서비스 간의 트래픽에 대한 이러한 초점은 API 게이트웨이 또는 인그레스 프록시(후자는 외부 세계에서 클러스터로 들어오는 호출에 초점을 맞춤)와 서비스 메시 프록시를 구별하는 것입니다. (메모. 번역: 이미 언급한 Envoy를 사용하는 기존 Kubernetes Ingress 컨트롤러를 비교하려면 다음을 참조하세요. 이 기사.)

그래서 우리는 데이터 평면을 알아냈습니다. 컨트롤 플레인은 더 간단합니다. 서비스 검색, TLS 인증서 발급, 메트릭 집계 등을 포함하여 데이터 플레인이 조정된 방식으로 작동하는 데 필요한 모든 메커니즘을 제공하는 구성 요소 집합입니다. 데이터 플레인은 컨트롤 플레인에 그것의 행동; 차례로 컨트롤 플레인은 데이터 플레인의 동작을 전체적으로 변경하고 추적할 수 있는 API를 제공합니다.

아래는 Linkerd의 컨트롤 플레인과 데이터 플레인의 다이어그램입니다. 보시다시피 컨트롤 플레인에는 프록시 서버에서 메트릭을 수집하는 Prometheus 인스턴스를 비롯한 여러 가지 구성 요소와 destination (서비스 검색), identity (인증 기관, CA) 및 public-api (웹 및 CLI용 끝점). 반대로 데이터 플레인은 애플리케이션 인스턴스 옆에 있는 간단한 linkerd-proxy입니다. 이것은 단지 논리도입니다. 실제 배포에서는 각 컨트롤 플레인 구성 요소의 복제본 XNUMX개와 데이터 플레인에 수백 또는 수천 개의 프록시가 있을 수 있습니다.

(이 다이어그램의 파란색 상자는 Kubernetes 포드의 경계를 나타냅니다. linkerd-proxy가 있는 컨테이너가 애플리케이션 컨테이너와 동일한 포드에 있음을 알 수 있습니다. 이 구성표는 사이드카 컨테이너.)

서비스 메시 아키텍처에는 몇 가지 중요한 의미가 있습니다. 첫째, 프록시의 역할은 서비스 간의 호출을 가로채는 것이므로 서비스 메시는 애플리케이션이 일련의 서비스용으로 빌드된 경우에만 의미가 있습니다. 망사 하나는 수 모놀리식과 함께 사용하지만 이것은 단일 프록시를 위해 분명히 중복되며 해당 기능이 요구되지 않을 것입니다.

또 다른 중요한 결과는 서비스 메시가 거대한 프록시 수. 실제로 Linkerd는 linkerd-proxy를 모든 서비스의 모든 인스턴스에 연결합니다(다른 구현에서는 모든 호스트/호스트/VM에 프록시를 추가합니다. 어쨌든 많습니다). 그 자체로 프록시를 적극적으로 사용하면 여러 가지 추가적인 문제가 발생합니다.

1. 데이터 플레인의 프록시는 빠른, 각 호출에 대해 클라이언트 측에서 하나, 서버 측에서 하나씩 프록시에 대한 몇 가지 호출이 있기 때문입니다.
2. 또한 프록시는 작은 и 경량. 각각은 메모리와 CPU 리소스를 소비하며 이 소비는 애플리케이션과 함께 선형적으로 증가합니다.
3. 많은 수의 프록시를 배포하고 업데이트하려면 메커니즘이 필요합니다. 수동으로 수행하는 것은 옵션이 아닙니다.

일반적으로 서비스 메시는 다음과 같습니다(최소한 조감도에서). 내부 서비스 간 트래픽으로 "무언가를 수행"하는 여러 사용자 공간 프록시를 배포하고 컨트롤 플레인을 사용하여 이를 모니터링하고 관리합니다.

"왜?"라는 질문을 할 때입니다.

서비스 메시란 무엇입니까?

서비스 메시라는 개념을 처음 접한 사람들에게는 다소 경외감이 들 수도 있습니다. 서비스 메시 설계는 애플리케이션 대기 시간을 증가시킬 뿐만 아니라 바싹 여위다 리소스 및 추가 할 것이다 인프라의 여러 가지 새로운 메커니즘. 먼저 서비스 메시를 설정한 다음 갑자기 수백(수천은 아니더라도) 프록시를 제공해야 합니다. 문제는 누가 이것을 위해 자원할 것인가입니다.

이 질문에 대한 대답은 두 부분으로 나뉩니다. 첫째, 생태계에서 발생하는 일부 변화로 인해 이러한 프록시 배포와 관련된 거래 비용을 크게 줄일 수 있습니다(자세한 내용은 나중에 설명).

둘째, 이러한 장치는 실제로 시스템에 추가 논리를 도입하는 좋은 방법입니다. 그리고 서비스 메쉬를 사용하여 많은 새로운 기능을 추가할 수 있을 뿐만 아니라 생태계를 방해하지 않고 수행할 수 있기 때문입니다. 실제로 전체 서비스 메시 모델은 다음 가정을 기반으로 합니다. ~을하다 개별 서비스, 트래픽 그들 사이에 기능을 추가하기에 이상적인 지점입니다.

예를 들어 Linkerd(대부분의 메시에서와 마찬가지로) 기능은 주로 HTTP/2 및 gRPC*를 비롯한 HTTP 호출에 중점을 둡니다. 기능은 매우 풍부합니다. 세 가지 클래스로 나눌 수 있습니다.

1. 관련 기능 신뢰성. 재시도 요청, 시간 초과, 카나리아 방식(트래픽 분할/리디렉션) 등
2. 관련 기능 모니터링. 각 서비스 또는 개별 목적지에 대한 성공률, 지연 및 요청량 집계 서비스의 토폴로지 맵 구축 등
3. 관련 기능 보안. 상호 TLS, 액세스 제어 등

* Linkerd의 관점에서 볼 때 gRPC는 HTTP/2와 실질적으로 다르지 않습니다. 단지 페이로드에서 protobuf를 사용합니다. 개발자의 관점에서 이 두 가지는 물론 다릅니다.

이러한 메커니즘의 대부분은 요청 수준에서 작동합니다(따라서 "L7 프록시"). 예를 들어 Foo 서비스가 Bar 서비스에 대한 HTTP 호출을 수행하는 경우 Foo 측의 linkerd-proxy는 지능적으로 부하를 분산하고 관찰된 대기 시간을 기반으로 Foo에서 Bar 인스턴스로 호출을 라우팅할 수 있습니다. 필요한 경우 요청을 반복할 수 있습니다(그리고 멱등성인 경우). 그는 응답 코드와 시간 초과 등을 기록할 수 있습니다. 마찬가지로 Bar 측의 linkerd-proxy는 요청이 허용되지 않거나 요청 제한을 초과하는 경우 요청을 거부할 수 있습니다. 그 부분의 지연 등을 고칠 수 있습니다.

프록시는 연결 수준에서도 "무언가를 수행"할 수 있습니다. 예를 들어 Foo 측의 linkerd-proxy는 TLS 연결을 시작할 수 있고 Bar 측의 linkerd-proxy는 연결을 종료할 수 있으며 양쪽 모두 서로의 TLS 인증서*를 확인할 수 있습니다. 이것은 서비스 간의 암호화를 제공할 뿐만 아니라 서비스를 식별하는 암호학적으로 안전한 방법도 제공합니다. Foo와 Bar는 자신이 말하는 사람임을 "증명"할 수 있습니다.

* "Friend of a friend"는 클라이언트의 인증서도 확인됨을 의미합니다(상호 TLS). 예를 들어 "클래식" TLS에서는 브라우저와 서버 사이에서 일반적으로 한쪽(서버)의 인증서만 확인됩니다.

요청 수준에서 작동하든 연결 수준에서 작동하든 모든 서비스 메시 기능이 운영 성격. Linkerd는 JSON 조각에 필드를 추가하거나 protobuf를 변경하는 것과 같이 페이로드의 의미 체계를 변환할 수 없습니다. 나중에 ESB와 미들웨어에 대해 이야기할 때 이 중요한 기능에 대해 이야기하겠습니다.

이것은 서비스 메시가 제공하는 기능 세트입니다. 문제가 발생합니다. 애플리케이션에서 직접 구현하지 않는 이유는 무엇입니까? 그리고 프록시를 엉망으로 만드는 이유는 무엇입니까?

서비스 메시가 좋은 이유

서비스 메시의 기능은 매력적이지만 주요 가치는 실제로 기능에 있지 않습니다. 결국 우리는 할 수있다 애플리케이션에서 직접 구현합니다(나중에 이것이 서비스 메시의 기원임을 알게 될 것입니다). 한 문장으로 표현하면 서비스 메시의 가치는 다음과 같습니다. 일관되고 스택 전체에 적용되며 애플리케이션 코드에 구애받지 않는 방식으로 최신 서버 소프트웨어를 실행하는 데 중요한 기능을 제공합니다..

이 제안을 분석해 봅시다.

«최신 서버 소프트웨어 실행에 중요한 기능". 외부 세계의 요청을 수락하고 짧은 시간 내에 응답하는 공용 인터넷에 연결된 트랜잭션 서버 응용 프로그램(예: 웹 응용 프로그램, API 서버 및 기타 대부분의 최신 응용 프로그램)을 구축하는 경우 서로 동기적으로 상호 작용하는 일련의 서비스로 구현하고 이 소프트웨어를 지속적으로 업그레이드하고 새로운 기능을 추가하며 수정 프로세스 중에 이 시스템을 작동 상태로 유지해야 하는 경우 - 이 경우, 축하합니다. 최신 서버 소프트웨어를 만들고 있습니다. 그리고 위에 나열된 모든 훌륭한 기능은 실제로 귀하에게 중요한 것으로 판명되었습니다. 응용 프로그램은 신뢰할 수 있고 안전해야 하며 수행 중인 작업을 볼 수 있어야 합니다. 서비스 메시가 해결하는 데 도움이 되는 것은 바로 이러한 질문입니다.

(좋아요, 이 접근 방식이 서버 소프트웨어를 구축하는 현대적인 방식이라는 제 확신은 이전 단락에 스며들었습니다. 다른 사람들은 위의 정의에 속하지 않는 모놀리식, "반응형 마이크로 서비스" 및 기타 항목을 개발하는 것을 선호합니다. 이 사람들은 아마도 의견이 있을 것입니다. 그것은 내 것과 다르고 차례로 "잘못"이라고 생각합니다. 어쨌든 서비스 메시는 그들에게별로 유용하지 않습니다).

«전체 스택에 대한 균일성". 서비스 메시가 제공하는 기능은 중요한 것만이 아닙니다. 어떤 언어로 작성되었는지, 어떤 프레임워크를 사용하는지, 누가 작성했는지, 어떻게 배포되었는지, 개발 및 사용의 다른 모든 미묘함에 관계없이 애플리케이션의 모든 서비스에 적용됩니다.

«애플리케이션 코드 독립적". 마지막으로 서비스 메시는 전체 스택에서 일관된 기능을 제공할 뿐만 아니라 애플리케이션을 편집할 필요가 없는 방식으로 제공합니다. 구성, 업데이트, 운영, 유지 관리 등의 작업을 포함하여 서비스 메시 기능의 기본 기반은 순전히 플랫폼 수준에 있으며 애플리케이션과 독립적입니다. 서비스 메시에 영향을 주지 않고 애플리케이션을 변경할 수 있습니다. 결과적으로 서비스 메시는 애플리케이션 개입 없이 변경될 수 있습니다.

요컨대, 서비스 메시는 중요한 기능을 제공할 뿐만 아니라 전역적이고 균일하며 애플리케이션 독립적인 방식으로 제공합니다. 따라서 서비스 메시의 기능은 서비스 코드(예: 각 서비스에 포함된 라이브러리)에서 구현될 수 있지만 이 접근 방식은 서비스 메쉬.

프록시를 추가하기만 하면 됩니다! 조만간 이러한 프록시를 추가하는 것과 관련된 운영 비용을 살펴볼 것이라고 약속합니다. 하지만 먼저 이 독립에 대한 생각을 멈추고 다양한 관점에서 살펴봅시다. 사람들.

서비스 메시는 누구에게 도움이 됩니까?

불편하더라도 기술이 생태계의 중요한 부분이 되려면 사람들에게 받아들여져야 합니다. 그렇다면 누가 서비스 메시에 관심이 있을까요? 누가 그것을 사용함으로써 이익을 얻습니까?

최신 서버 소프트웨어를 개발하는 경우 팀을 그룹으로 대략 상상할 수 있습니다. 서비스 소유자비즈니스 로직을 함께 개발하고 구현하는 사람 플랫폼 소유자이러한 서비스가 실행되는 내부 플랫폼 개발에 참여합니다. 소규모 조직에서는 같은 사람일 수 있지만 회사가 성장함에 따라 이러한 역할이 더욱 두드러지고 하위 역할로 나뉘는 경향이 있습니다. 마이크로서비스의 조직적 영향 등) 명사. 하지만 지금은 이러한 설명을 당연하게 여기겠습니다.

이러한 관점에서 서비스 메시의 확실한 수혜자는 플랫폼의 소유자입니다. 결국 플랫폼 팀의 궁극적인 목표는 서비스 소유자가 비즈니스 논리를 구현할 수 있는 내부 플랫폼을 만들고 운영의 암울한 세부 사항으로부터 최대한의 독립성을 보장하는 방식으로 수행하는 것입니다. 서비스 메시는 이 목표를 달성하는 데 중요한 기능을 제공할 뿐만 아니라 서비스 소유자에게 종속성을 부과하지 않는 방식으로 제공합니다.

간접적이긴 하지만 서비스 소유자도 혜택을 받습니다. 서비스 소유자의 목표는 비즈니스 프로세스의 논리를 구현하는 데 가능한 한 생산적이며 운영 문제에 대해 걱정할 필요가 적을수록 좋습니다. 예를 들어 재시도 정책이나 TLS를 시행하는 대신 비즈니스에만 집중하고 플랫폼이 나머지를 처리하기를 바랄 수 있습니다. 그들에게는 이것이 큰 이점입니다.

플랫폼 소유자와 서비스 소유자 간의 이러한 분할의 조직적 가치는 과대 평가할 수 없습니다. 나는 그녀가 기여한다고 생각한다 основной 서비스 메시의 가치에 기여합니다.

초기 Linkerd 팬이 서비스 메시를 선택한 이유를 설명했을 때 이 교훈을 얻었습니다. 다음은 몇 가지 세부 정보입니다. 한 대기업의 직원이 플랫폼을 Kubernetes로 마이그레이션했습니다. 애플리케이션은 민감한 정보를 다루기 때문에 클러스터의 모든 통신을 암호화하기를 원했습니다. 그러나 수백 개의 서비스와 수백 개의 개발 팀이 존재하여 상황이 복잡해졌습니다. 모든 사람에게 연락하여 그들의 계획에 TLS에 대한 지원을 포함시키도록 설득할 가능성은 전혀 만족스럽지 않았습니다. Linkerd를 설치하여 마이그레이션했습니다. 책임 (그의 관점에서 볼 때 불필요한 문제인) 개발자부터 이것이 최상위 우선 순위인 플랫포머에 이르기까지. 즉, Linkerd는 기술적인 문제가 아니라 조직적인 문제를 해결하고 있었습니다.

요컨대 서비스 메시는 기술적인 솔루션이 아니라 오히려 사회 기술 문제. (감사합니다 신디 스리다란 이 용어를 소개합니다.

서비스 메시가 모든 문제를 해결할 수 있습니까?

예. 내 말은, 아니!

위에서 설명한 세 가지 기능 클래스(신뢰성, 보안 및 관찰 가능성)를 살펴보면 서비스 메시가 이러한 문제에 대한 완전한 솔루션이 아님이 분명해집니다. Linkerd는 반복되는 요청을 보낼 수 있지만(그 요청이 멱등적임을 알고 있는 경우) 서비스가 최종적으로 중단된 경우 사용자에게 무엇을 반환할지에 대한 결정을 내릴 위치에 있지 않습니다. 이러한 결정은 응용 프로그램에서 내려야 합니다. Linkerd는 성공적인 요청에 대한 통계를 유지할 수 있지만 서비스를 조사하고 내부 메트릭을 제공할 수 없습니다. 애플리케이션에는 이러한 도구 키트가 있어야 합니다. 그리고 Linkerd는 mTLS를 호스팅할 수 있지만 본격적인 보안 솔루션에는 훨씬 더 많은 것이 필요합니다.

서비스 메시에서 제공하는 이러한 영역의 기능 중 일부는 다음과 관련됩니다. 플랫폼 기능. 이것은 다음과 같은 기능을 의미합니다.

1. 비즈니스 로직과 무관. Foo와 Bar 사이에 호출 히스토그램이 구성되는 방식은 이유 Foo는 Bar에게 전화를 겁니다.
2. 제대로 구현하기 어려움. Linkerd에서 재시도는 재시도 예산과 같은 모든 종류의 멋진 항목으로 매개 변수화됩니다. (재시도 예산), 그러한 것들의 구현에 대한 단순한 접근 방식은 반드시 소위 "요청의 눈사태"의 출현으로 이어질 것이기 때문입니다. (재시도 폭풍) 및 분산 시스템에 고유한 기타 문제.
3. 지속적으로 적용할 때 가장 효과적. TLS 메커니즘은 모든 곳에 적용되는 경우에만 의미가 있습니다.

이러한 기능은 프록시 계층(애플리케이션 계층이 아님)에서 구현되기 때문에 서비스 메시는 이를 플랫폼, 응용 프로그램이 아닙니다. 따라서 서비스가 어떤 언어로 작성되었는지, 어떤 프레임워크를 사용하는지, 누가 왜 서비스를 작성했는지는 중요하지 않습니다. 프록시는 이러한 모든 세부 사항 이상으로 작동하며 구성, 업데이트, 운영, 유지 관리 등의 작업을 포함하여 이 기능의 기본 기반은 전적으로 플랫폼 수준에 있습니다.

서비스 메시 기능의 예

요약하면 서비스 메시는 안정성, 관찰 가능성 또는 보안을 위한 완벽한 솔루션이 아닙니다. 이러한 영역의 범위는 서비스 소유자, Ops/SRE 팀 및 기타 회사 이해 관계자의 필수 참여를 의미합니다. 서비스 메시는 이러한 각 영역에 대한 플랫폼 수준의 "슬라이스"만 제공합니다.

서비스 메시가 지금 인기를 얻고 있는 이유는 무엇입니까?

아마 지금 궁금해하실 것입니다. 서비스 메시가 그렇게 좋다면 왜 XNUMX년 전에는 스택에 수백만 개의 프록시를 배포하지 않았을까요?

이 질문에 대한 진부한 대답이 있습니다. XNUMX년 전에는 모두가 모놀리스를 구축했고 아무도 서비스 메시가 필요하지 않았습니다. 이것은 사실이지만 제 생각에는 이 답변이 요점을 놓치고 있습니다. XNUMX년 전에도 대규모 시스템을 만드는 유망한 방법으로서 마이크로서비스의 개념이 Twitter, Facebook, Google 및 Netflix와 같은 회사에서 광범위하게 논의되고 적용되었습니다. 적어도 내가 접촉한 업계 일부에서는 마이크로서비스가 매우 어렵더라도 대규모 시스템을 구축하는 "올바른 방법"이라는 일반적인 인식이 있었습니다.

물론 XNUMX년 전에도 마이크로서비스를 활용하는 기업이 있었지만 서비스 메시를 형성하기 위해 가능한 모든 곳에 프록시를 붙이지 않았습니다. 그러나 자세히 살펴보면 유사한 작업을 수행했습니다. 이러한 회사 중 다수는 네트워킹을 위한 특수 내부 라이브러리(때때로 팻 클라이언트 라이브러리라고 함)의 사용을 의무화했습니다. 팻 클라이언트 라이브러리).

Netflix에는 Hysterix가 있었고 Google에는 Stubby가 있었고 Twitter에는 Finagle 라이브러리가 있었습니다. 예를 들어, Finagle은 Twitter의 모든 새 서비스에 필수입니다. 연결의 클라이언트와 서버 측을 모두 처리하여 반복되는 요청, 지원되는 요청 라우팅, 로드 밸런싱 및 측정을 허용했습니다. 서비스가 수행하는 작업에 관계없이 전체 Twitter 스택에서 일관된 안정성 및 관찰 가능성 계층을 제공했습니다. 물론 JVM 언어에서만 작동했고 전체 애플리케이션에 사용해야 하는 프로그래밍 모델을 기반으로 했다. 그러나 기능은 서비스 메시와 거의 동일했습니다. (실제로 Linkerd의 첫 번째 버전은 프록시 형식으로 래핑된 Finagle에 불과했습니다.)

따라서 XNUMX년 전에는 마이크로서비스뿐만 아니라 오늘날 서비스 메시가 해결하는 것과 동일한 문제를 해결하는 특별한 프로토 서비스 메시 라이브러리도 있었습니다. 그러나 당시에는 서비스 메시 자체가 존재하지 않았습니다. 그녀가 나타나기 전에 또 다른 변화가 있어야 했다.

그리고 이것이 지난 10년 동안 발생한 또 다른 변화에 숨겨진 더 깊은 답이 있는 곳입니다. 마이크로서비스 배포 비용이 급격히 감소했습니다. 위에서 언급한 XNUMX년 전 마이크로서비스를 사용했던 회사(Twitter, Netflix, Facebook, Google)는 거대한 규모와 막대한 자원을 가진 회사였습니다. 마이크로서비스를 기반으로 대규모 애플리케이션을 구축, 배포 및 운영할 수 있는 능력뿐만 아니라 필요성도 있었습니다. 모놀리식에서 마이크로서비스 접근 방식으로 이동하기 위해 Twitter 엔지니어가 쏟은 에너지와 노력은 놀랍습니다. (솔직히 효과가 있다는 사실도 그랬습니다.) 이러한 종류의 인프라 조작은 소규모 회사에서는 불가능했습니다.

현재로 넘어갑시다. 오늘날 마이크로서비스와 개발자의 비율이 5:1(또는 심지어 10:1), 또한 그들은 성공적으로 대처합니다! 5명으로 구성된 스타트업이 부담 없이 50개의 마이크로서비스를 운영할 수 있다면 구현 비용이 분명히 감소한 것입니다.

Monzo의 1500개 마이크로서비스 각 라인은 트래픽을 허용하는 규정된 네트워크 규칙입니다.

마이크로서비스 운영 비용의 극적인 감소는 단일 프로세스의 결과입니다. 컨테이너의 인기 증가 и 오케스트레이터. 이것은 서비스 메시의 출현에 기여한 것이 무엇인지에 대한 질문에 대한 정확한 답변입니다. 동일한 기술이 서비스 메시와 마이크로서비스를 모두 매력적으로 만들었습니다. 바로 Kubernetes와 Docker입니다.

왜? 글쎄, Docker는 하나의 큰 문제인 패키징 문제를 해결합니다. Docker는 애플리케이션과 해당 (비네트워크) 런타임 종속성을 컨테이너에 패키징함으로써 애플리케이션을 어디에서나 호스팅하고 실행할 수 있는 대체 가능한 단위로 바꿉니다. 동시에 작동을 크게 단순화합니다. 다국어 스택: 컨테이너는 실행의 원자 단위이므로 JVM, Node, Go, Python 또는 Ruby 애플리케이션 등 배포 및 운영 목적을 위해 내부에 무엇이 있는지는 중요하지 않습니다. 당신은 그것을 실행하고 그게 다입니다.

Kubernetes는 모든 것을 다음 단계로 끌어 올립니다. 이제 "실행 가능한 것"이 많이 있고 이를 실행하는 많은 시스템이 있으므로 서로 일치시킬 수 있는 도구가 필요합니다. 넓은 의미에서 Kubernetes에 많은 컨테이너와 많은 머신을 제공하고 서로 일치시킵니다(물론 이것은 동적이고 지속적으로 변화하는 프로세스입니다. Kubernetes는 이 모든 것을 고려합니다.)

일단 쿠버네티스가 설정되면 하나의 서비스를 배포하고 운영하는 데 걸리는 시간은 100개의 서비스를 배포하고 운영하는 데 드는 비용과 크게 다르지 않습니다(사실 XNUMX개의 서비스는 거의 동일합니다). 다국어 구현을 장려하는 패키징 메커니즘으로 이 컨테이너에 추가하면 서비스 메시가 매우 적합한 환경인 여러 언어로 작성된 마이크로서비스로 구현된 수많은 새 애플리케이션이 있습니다.

그래서 우리는 왜 서비스 메시라는 개념이 지금 대중화되었는지에 대한 질문에 대한 답을 얻습니다. 쿠버네티스가 서비스에 제공하는 균일성은 서비스 메시가 직면한 운영 작업에 직접 적용됩니다. 프록시를 컨테이너에 패키징하고 Kubernetes에 가능할 때마다 프록시를 고정하는 작업을 맡기면 짜잔! 결과적으로 Kubernetes가 배포의 모든 메커니즘을 제어하는 ​​동안 서비스 메시를 얻게 됩니다. (적어도 조감도에서. 물론 이 과정에는 많은 뉘앙스가 있습니다.)

요약하면 서비스 메시가 XNUMX년 전이 아니라 지금 인기를 얻은 이유는 Kubernetes와 Docker가 크게 증가했을 뿐만 아니라 필요 다국어 마이크로서비스 세트로 애플리케이션 구현을 단순화할 뿐만 아니라 소송 비용 사이드카 프록시 파크를 배포하고 유지하기 위한 메커니즘을 제공하여 운영을 위해.

서비스 메시에 대한 이야기가 많은 이유는 무엇입니까?

경고: 이 섹션에서는 모든 종류의 가정, 추측, 조작 및 내부 정보에 의지합니다.

"서비스 메시"를 검색하면 재활용된 저칼로리 콘텐츠, 이상한 프로젝트, 에코 챔버에 걸맞은 왜곡의 만화경이 ​​많이 나타납니다. 어떤 트렌디한 신기술이든 이런 것이 있지만 서비스 메시의 경우에는 특히 문제가 심각하다. 왜?

글쎄, 그것은 부분적으로 내 잘못입니다. 저는 수많은 블로그 게시물과 이와 같은 기사를 통해 기회가 있을 때마다 Linkerd와 서비스 메시를 홍보하기 위해 최선을 다했습니다. 하지만 나는 그렇게 강력하지 않습니다. 이 질문에 답하려면 일반적인 상황에 대해 조금 이야기해야 합니다. 그리고 하나의 프로젝트를 언급하지 않고 그것에 대해 이야기하는 것은 불가능합니다. 이스 티오 Google, IBM 및 Lyft가 공동으로 개발한 오픈 소스 서비스 메시입니다.

(이 세 회사는 역할이 매우 다릅니다. Lyft의 참여는 이름만으로 제한되는 것 같습니다. 그들은 Envoy를 작성하지만 Istio를 사용하지 않거나 개발에 관여하지 않습니다. IBM은 Istio 개발에 참여하고 사용합니다. Google은 막대한 Istio 개발에 참여했지만 내가 아는 한 실제로 사용하지는 않습니다.)

Istio 프로젝트는 두 가지 측면에서 주목할 만합니다. 첫째, 특히 Google이 프로모션에 투입하는 막대한 마케팅 노력입니다. 나는 현재 서비스 메시 개념을 알고 있는 대부분의 사람들이 Istio 덕분에 그것에 대해 처음 알게 된 것으로 추정합니다. 두 번째 특징은 Istio가 얼마나 잘못 수신되었는지입니다. 이 문제에 있어서 나는 분명히 이해당사자이지만 가능한 한 객관적으로 유지하려고 노력하지만 여전히 도울 수는 없습니다. 표 매우 부정 태도, 매우 구체적이지는 않습니다(고유하지는 않지만: systemd가 떠오릅니다. 비교 수행되었다 이미 반복적으로...) 오픈 소스 프로젝트의 경우.

(실제로 Istio는 복잡성과 UX뿐만 아니라 성능에도 문제가 있는 것 같습니다. Linkerd 성능 평가타사에서 실시한 결과 Istio의 tail Latency가 Linkerd보다 100배 이상 높은 상황과 리소스가 부족한 상황에서 Linkerd가 계속해서 성공적으로 작동하다가 Istio가 완전히 작동을 멈춘 상황을 전문가가 발견했습니다.

왜 이런 일이 발생했는지에 대한 내 이론은 차치하고, 서비스 메시를 둘러싼 비규모의 과대 광고는 Google의 개입 때문이라고 생각합니다. 즉, 다음 세 가지 요소의 조합입니다.

1. Google의 Istio에 대한 강박적인 프로모션
2. 프로젝트에 대한 적절한 비 승인, 비판적 태도;
3. 최근 쿠버네티스의 인기가 하늘을 찌르고 있습니다. 그 기억은 여전히 ​​생생합니다.

함께, 이러한 요인들은 합리적인 판단 능력이 약해지고 기괴한 다양한 튤립 매니아.

Linkerd의 관점에서 이것은… 혼합된 축복이라고 설명하겠습니다. Linkerd가 처음 등장한 2016년에는 그렇지 않았고 프로젝트에 대한 사람들의 관심을 끌기가 정말 어려웠습니다. 이제 그런 문제는 없습니다! 그러나 나쁜 소식은 오늘날 서비스 메시 상황이 너무 혼란스러워 어떤 프로젝트가 실제로 서비스 메시 범주에 속하는지 파악하는 것이 거의 불가능하다는 것입니다(어떤 것이 특정 사용 사례에 가장 적합한지 파악하는 것은 말할 것도 없습니다). 이것은 확실히 모든 사람에게 방해가 됩니다(확실히 어떤 경우에는 Istio 또는 다른 프로젝트가 Linkerd보다 낫습니다.

Linkerd 측에서 우리의 전략은 소음을 무시하고 커뮤니티의 실제 문제를 해결하는 데 계속 집중하며 기본적으로 과대 광고가 가라앉을 때까지 기다리는 것이었습니다. 결국 과대 광고는 가라앉고 우리는 평화롭게 계속 일할 수 있습니다.

그때까지 우리 모두는 인내해야 합니다.

겸손한 소프트웨어 엔지니어인 나에게 서비스 메시가 유용할까요?

다음 설문지가 이 질문에 답하는 데 도움이 될 것입니다.

비즈니스 로직의 구현을 독점적으로 처리합니까? 이 경우 서비스 메시가 유용하지 않습니다. 즉, 물론 관심이 있을 수 있지만 이상적으로는 서비스 메시가 환경의 어떤 것에도 직접적인 영향을 미치지 않아야 합니다. 당신이 지불하는 일을 계속하십시오.

Kubernetes를 사용하는 회사에서 플랫폼을 유지하고 있습니까? 예, 이 경우에는 서비스 메시가 필요합니다(물론 모놀리식 또는 일괄 처리를 실행하기 위해 K8을 사용하지 않는 경우 - K8이 필요한 이유를 묻고 싶습니다). 대부분의 경우 다른 사람들이 작성한 많은 마이크로 서비스가 있는 상황에 처하게 될 것입니다. 그것들은 모두 서로 상호 작용하고 복잡한 런타임 종속성에 묶여 있으므로 이 모든 것을 처리할 방법을 찾아야 합니다. Kubernetes를 사용하면 "스스로" 서비스 메시를 선택할 수 있습니다. 이렇게 하려면 기능과 기능을 숙지하고 사용 가능한 프로젝트가 자신에게 적합한지 여부에 대한 질문에 답하십시오(Linkerd로 조사를 시작하는 것이 좋습니다).

Kubernetes를 사용하지 않고 마이크로서비스를 사용하는 회사를 위해 플랫폼을 실행하고 있습니까? 이 경우 서비스 메시가 유용하지만 그 사용은 사소하지 않습니다. 물론 당신은 할 수 흉내 내다 많은 프록시를 호스팅하여 서비스 메시를 만들 수 있지만 Kubernetes의 중요한 이점은 바로 배포 모델입니다. 이러한 프록시를 수동으로 유지 관리하려면 훨씬 더 많은 시간, 노력 및 비용이 필요합니다.

모놀리식으로 작업하는 회사에서 플랫폼을 담당하고 있습니까? 이 경우 서비스 메시가 필요하지 않을 수 있습니다. 상호 작용 패턴이 잘 정의되고 거의 변경되지 않는 모놀리식(또는 모놀리식 모음)으로 작업하는 경우 서비스 메시가 제공할 수 있는 것이 거의 없습니다. 그러니 그냥 무시하고 나쁜 꿈처럼 사라지길 바랄 수 있습니다...

결론

아마도 서비스 메시는 여전히 "세계에서 가장 과장된 기술"이라고 불려서는 안 될 것입니다. 이 모호한 영예는 아마도 비트코인이나 AI에 속할 것입니다. 아마도 그녀는 상위 XNUMX위 안에 들 것입니다. 그러나 소음과 소음의 계층을 뚫고 나가면 서비스 메시가 Kubernetes에서 애플리케이션을 만드는 사람들에게 실질적인 이점을 제공한다는 것이 분명해집니다.

Linkerd를 사용해 보고 싶습니다. Kubernetes 클러스터(또는 랩톱의 Minikube)에 설치 약 60초 소요그리고 당신은 내가 말하는 것을 직접 볼 수 있습니다.

자주하는 질문

- 서비스 메쉬를 무시하면 사라지나요?
- 당신을 실망시켜야만 ​​합니다. 서비스 메시는 오랫동안 우리와 함께했습니다.

— 하지만 서비스 메시를 사용하고 싶지 않습니다!
- 글쎄, 그럴 필요 없어! 위의 설문지를 읽고 최소한 기본 사항에 익숙해져야 하는지 확인하십시오.

— 새 소스를 곁들인 좋은 ESB/미들웨어 아닌가요?
- 서비스 메시는 시맨틱이 아닌 운영 논리를 다룹니다. 이게 최대 단점이었어요 엔터프라이즈 서비스 버스(ESB). 이 분리를 유지하면 서비스 메시가 동일한 운명을 피하는 데 도움이 됩니다.

- 서비스 메시는 API 게이트웨이와 어떻게 다릅니까?
이 주제에 대한 기사가 백만 개 있습니다. 그냥 구글.

Envoy는 서비스 메시입니까?
- 아니요, Envoy는 서비스 메시가 아니라 프록시 서버입니다. 이것은 서비스 메시를 구성하는 데 사용할 수 있습니다(그리고 훨씬 더 - 범용 프록시입니다). 그러나 그 자체로는 서비스 메시가 아닙니다.

- 네트워크 서비스 메쉬 - 서비스 메쉬인가?
- 아니요. 이름에도 불구하고 이것은 서비스 메시가 아닙니다(마케팅의 경이로움이 마음에 드십니까?).

- 서비스 메시가 메시지 대기열을 기반으로 하는 반응형 비동기 시스템에 도움이 됩니까?
- 아니요, 서비스 메시는 도움이 되지 않습니다.

- 어떤 서비스 메시를 사용해야 하나요?
- 링커드, 생각할 필요가 없습니다.

- 기사가 짜증나! / 저자-비누에!
— 친구들이 이것을 확신할 수 있도록 모든 친구들에게 링크를 공유해주세요!

감사의 말

제목에서 짐작할 수 있듯이 이 기사는 Jay Kreps의 환상적인 논문에서 영감을 받았습니다.로그: 실시간 데이터의 통합 추상화에 대해 모든 소프트웨어 엔지니어가 알아야 할 사항". 저는 XNUMX년 전에 Linked In에서 인터뷰를 하다가 Jay를 만났고 그 이후로 Jay는 저에게 영감을 주었습니다.

나는 스스로를 "Linkerd 개발자"라고 부르고 싶지만 실제로는 프로젝트에서 README.md 파일의 관리자에 가깝습니다. 오늘 Linkerd에서 작업 대단히, 대단히, 대단히 много 이 프로젝트는 놀라운 기여자와 사용자 커뮤니티 없이는 불가능했을 것입니다.

그리고 마지막으로 Linkerd의 창시자에게 특별한 감사를 드립니다. 올리버 굴드 (프리머스 인터 파레스), 몇 년 전 저와 함께 서비스 메시에 대한 이 모든 소란에 곤두박질쳤습니다.

번역가의 추신

블로그에서도 읽어보세요.

• «서비스 메시란 무엇이며 [마이크로서비스가 포함된 클라우드 애플리케이션의 경우] 서비스 메시가 필요한 이유는 무엇입니까?";
• «Traefik 2.0: TCP 지원 및 새로운 웹 인터페이스로 서비스 메시 업데이트";
• «Maesh - Traefik 작성자의 Kubernetes용 새로운 단순 서비스 메시";
• «Istio를 사용한 마이크로서비스로 돌아갑니다. 1 부";
• «Conduit - Kubernetes용 경량 서비스 메시".

출처 : habr.com