Consul의 예를 사용하여 분산 시스템에서 서비스 검색. 알렉산더 시가체프

Consul을 예로 들어 Alexander Sigachev의 분산 시스템에서의 서비스 검색 보고서 사본을 읽어 보시기 바랍니다.

Service Discovery는 최소한의 비용으로 새로운 애플리케이션을 기존 환경에 연결할 수 있도록 만들어졌습니다. 서비스 검색을 사용하면 도커 컨테이너나 가상 서비스를 실행 중인 환경에서 최대한 분리할 수 있습니다.

모두를 환영합니다! 저는 Alexander Sigachev이고 Inventos에서 일합니다. 오늘은 Service Discovery와 같은 개념을 소개하겠습니다. Consul을 예로 들어 Service Discovery를 살펴보겠습니다.

Service Discovery는 어떤 문제를 해결합니까? Service Discovery는 최소한의 비용으로 새로운 애플리케이션을 기존 환경에 연결할 수 있도록 만들어졌습니다. 서비스 검색을 사용하면 도커 컨테이너나 가상 서비스를 실행 중인 환경에서 최대한 분리할 수 있습니다.

그것은 어떻게 생겼나요? 웹의 전형적인 예에서 이는 사용자의 요청을 수락하는 프런트 엔드입니다. 그런 다음 이를 백엔드로 라우팅합니다. 이 예시에서 이 부하 분산 장치는 두 백엔드의 균형을 조정합니다.

여기서는 애플리케이션의 세 번째 인스턴스를 시작하는 것을 볼 수 있습니다. 따라서 애플리케이션이 시작되면 Service Discovery에 등록됩니다. 서비스 검색은 로드 밸런서에 알립니다. 로드 밸런서는 구성을 자동으로 변경하고 새 백엔드가 작동됩니다. 이러한 방식으로 백엔드를 추가하거나 반대로 작업에서 제외할 수 있습니다.

Service Discovery로 편리하게 수행할 수 있는 또 다른 작업은 무엇입니까? 서비스 검색은 nginx 구성, 인증서 및 활성 백엔드 서버 목록을 저장할 수 있습니다.

Service Discovery를 사용하면 오류를 감지하고 감지할 수도 있습니다. 오류를 감지하기 위한 가능한 체계는 무엇입니까?

• 우리가 개발한 이 애플리케이션은 Service Discovery에 아직 작동 중임을 자동으로 알립니다.
• 서비스 검색은 애플리케이션의 가용성을 폴링합니다.
• 또는 애플리케이션의 가용성을 확인하고 서비스 검색에 모든 것이 정상이고 작동할 수 있음을 알리거나 반대로 모든 것이 좋지 않아 이 애플리케이션 인스턴스를 밸런싱에서 제외해야 함을 알리는 타사 스크립트나 애플리케이션을 사용합니다.

각 구성표는 우리가 사용하는 소프트웨어에 따라 사용될 수 있습니다. 예를 들어, 방금 새 프로젝트 개발을 시작한 다음 애플리케이션이 서비스 검색에 알릴 때 체계를 쉽게 제공할 수 있습니다. 또는 Service Discovery가 확인하고 있는 것을 연결할 수도 있습니다.

애플리케이션을 상속받았거나 다른 사람이 개발한 경우 핸들러를 작성할 때 세 번째 옵션이 적합하며 이 모든 것이 자동으로 작업에 포함됩니다.

이것은 하나의 예입니다. nginx 형태의 로드밸런서가 재부팅됩니다. 이는 Consul과 함께 제공되는 선택적 유틸리티입니다. 이것은 영사 템플릿입니다. 우리는 규칙을 설명합니다. 우리는 템플릿(Golang 템플릿 엔진)을 사용하고 있다고 말합니다. 이벤트가 발생하면 변경 사항이 발생했다는 알림이 다시 생성되고 "reload" 명령이 Service Discovery로 전송됩니다. 가장 간단한 예는 이벤트에 의해 nginx가 재구성되고 다시 시작되는 경우입니다.

영사는 무엇입니까?

• 우선 서비스 디스커버리(Service Discovery)입니다.

• 가용성 확인 메커니즘(상태 확인)이 있습니다.

• KV 스토어도 있습니다.

• 그리고 Multi Datacenter를 활용하는 능력을 기반으로 합니다.

이 모든 것이 무엇에 사용될 수 있습니까? KV 스토어에는 예제 구성을 저장할 수 있습니다. Health Checking 지역 서비스를 확인하고 알려드릴 수 있습니다. Multi Datacenter를 이용하여 서비스 맵을 구축할 수 있습니다. 예를 들어, Amazon은 여러 영역을 보유하고 가장 최적의 방식으로 트래픽을 라우팅하므로 데이터 센터 간에 불필요한 요청이 발생하지 않으며 로컬 트래픽과 별도로 요금이 부과되므로 지연 시간이 줄어듭니다.

Consul에서 사용되는 용어에 대해 조금 알아보겠습니다.

• Consul은 Go로 작성된 서비스입니다. Go 프로그램의 장점 중 하나는 방금 다운로드한 1개의 바이너리 파일입니다. 어디에서나 실행되며 종속성이 없습니다.
• 그런 다음 키를 사용하여 클라이언트 모드나 서버 모드에서 이 서비스를 시작할 수 있습니다.
• 또한 "데이터 센터" 속성을 사용하면 이 서버가 속한 데이터 센터에 대한 플래그를 설정할 수 있습니다.
• 합의 – 뗏목 프로토콜을 기반으로 합니다. 관심 있는 분이 계시다면 영사 웹사이트에서 이에 대한 자세한 내용을 읽어보실 수 있습니다. 이는 리더를 결정하고 어떤 돈이 유효하고 접근 가능한 것으로 간주되는지 결정할 수 있는 프로토콜입니다.
• 가십(Gossip)은 노드 간 상호 작용을 가능하게 하는 프로토콜입니다. 게다가 이 시스템은 분산되어 있습니다. 하나의 데이터 센터 내에서 모든 노드는 이웃 노드와 통신합니다. 그리고 이에 따라 현재 상태에 대한 정보가 서로에게 전송된다. 이것은 이웃 간의 험담이라고 말할 수 있습니다.
• LAN Gossip – 동일한 데이터 센터 내의 이웃 간의 로컬 데이터 교환.
• WAN Gossip - 두 데이터 센터 간에 정보를 동기화해야 할 때 사용됩니다. 서버로 표시된 노드 간에 정보가 흐릅니다.
• RPC – 서버의 클라이언트를 통해 요청을 실행할 수 있습니다.

RPC에 대한 설명입니다. Consul이 가상 머신이나 물리적 서버에서 클라이언트로 실행되고 있다고 가정해 보겠습니다. 현지에서 그에게 연락합니다. 그러면 로컬 클라이언트가 서버에 정보를 요청하고 동기화됩니다. 설정에 따라 로컬 캐시에서 정보를 검색하거나 리더, 서버 마스터와 동기화할 수 있습니다.

이 두 가지 계획에는 장단점이 있습니다. 로컬 캐시로 작업하면 속도가 빠릅니다. 서버에 저장된 데이터로 작업하는 경우 시간이 더 걸리지만 더 관련성이 높은 정보를 얻을 수 있습니다.

이것을 그래픽으로 묘사하면 이것이 사이트의 그림입니다. 우리는 세 명의 마스터가 실행되고 있음을 알 수 있습니다. 하나는 리더로서 별표로 표시됩니다. 이 예에는 UDP/TCP를 통해 로컬로 서로 정보를 교환하는 세 개의 클라이언트가 있습니다. 그리고 데이터 센터 간의 정보는 서버 간에 전송됩니다. 여기서 클라이언트는 로컬로 서로 상호 작용합니다.

Consul은 어떤 API를 제공하나요? 정보를 얻기 위해 Consul에는 두 가지 유형의 API가 있습니다.

이것이 DNS API입니다. 기본적으로 Consul은 포트 8600에서 실행됩니다. 요청 프록시를 구성하고 로컬 DNS를 통해 로컬 확인을 통해 액세스를 제공할 수 있습니다. 도메인별로 쿼리하고 이에 대한 응답으로 IP 주소 정보를 받을 수 있습니다.

HTTP API - 또는 포트 8500의 특정 서비스에 대한 정보를 로컬로 요청하고 JSON 응답, 서버의 IP, 호스트, 등록된 포트를 수신할 수 있습니다. 그리고 추가 정보는 토큰을 통해 전송될 수 있습니다.

Consul을 실행하려면 무엇이 필요합니까?

첫 번째 옵션인 개발자 모드에서는 이것이 개발자 모드라는 플래그를 나타냅니다. 에이전트는 서버로 시작됩니다. 그리고 전체 기능을 하나의 시스템에서 독립적으로 수행합니다. 편리하고 빠르며 처음 시작할 때 추가 설정이 거의 필요하지 않습니다.

두 번째 모드는 프로덕션 출시입니다. 여기서 시작이 조금 복잡해집니다. 영사 버전이 없다면 첫 번째 머신을 부트스트랩으로 가져와야 합니다. 즉, 리더의 책임을 맡게 될 이 머신입니다. 이를 발생시킨 다음 서버의 두 번째 인스턴스를 발생시켜 마스터가 있는 위치에 대한 정보를 전달합니다. 우리는 세 번째를 키웁니다. 세 대의 머신을 가동한 후 실행 중인 부트스트랩의 첫 번째 머신에서 일반 모드로 다시 시작합니다. 데이터가 동기화되었으며 초기 클러스터가 이미 실행 중입니다.

서버 모드에서는 XNUMX~XNUMX개의 인스턴스를 실행하는 것이 좋습니다. 이는 서버 수가 증가하면 서버 간의 정보 동기화 시간이 늘어나기 때문입니다. 쿼럼을 보장하려면 노드 수가 홀수여야 합니다.

건강검진은 어떻게 제공되나요? Consul 구성 디렉터리에 Json 형식으로 확인 규칙을 작성합니다. 첫 번째 옵션은 이 예에서 google.com 도메인의 가용성입니다. 그리고 우리는 이 검사를 30초 간격으로 수행해야 한다고 말합니다. 이 방법으로 노드가 외부 네트워크에 액세스할 수 있는지 확인합니다.

두 번째 옵션은 자신을 확인하는 것입니다. 일반 컬을 사용하여 10초 간격으로 지정된 포트에서 localhost를 호출합니다.

이러한 검사는 요약되어 서비스 검색으로 전송됩니다. 가용성에 따라 이러한 노드는 제외되거나 사용 가능하고 올바르게 작동하는 시스템 목록에 나타납니다.

Consul은 또한 별도의 플래그로 실행되어 컴퓨터에서 사용할 수 있는 UI 인터페이스를 제공합니다. 이를 통해 정보를 볼 수 있으며 일부 내용을 변경할 수도 있습니다.

이 예에서는 "서비스" 탭이 열려 있습니다. 세 가지 서비스가 실행되고 있는 것으로 표시되며 그 중 하나는 Consul입니다. 수행된 검사 수입니다. 그리고 기계가 위치한 세 개의 데이터 센터가 있습니다.

이는 노드 탭의 예입니다. 데이터 센터와 관련된 복합 이름이 있음을 알 수 있습니다. 또한 실행 중인 서비스도 표시됩니다. 즉, 설정된 태그가 없음을 알 수 있습니다. 이러한 추가 태그는 개발자가 추가 매개변수를 지정하는 데 사용할 수 있는 일부 정보를 제공할 수 있습니다.

디스크 상태 및 평균 부하에 대한 정보를 Consul에 전송할 수도 있습니다.

질문

질문: Docker 컨테이너가 있는데 Consul에서 어떻게 사용하나요?

답변: Docker 컨테이너에는 여러 가지 접근 방식이 있습니다. 가장 일반적인 방법 중 하나는 등록을 담당하는 타사 도커 컨테이너를 사용하는 것입니다. 시작 시 docker 소켓이 전달됩니다. 모든 컨테이너 등록 및 게시 취소 이벤트는 Consul에 기록됩니다.

질문: 그러면 Consul 자체가 Docker 컨테이너를 시작합니까?

대답: 아니요. 우리는 도커 컨테이너를 실행하고 있습니다. 그리고 구성할 때 우리는 그러한 소켓을 듣습니다. 이는 우리가 가지고 있는 위치와 항목에 대한 정보를 업로드할 때 인증서를 사용하여 작업하는 방법과 거의 동일합니다.

질문: Service Discovery에 연결하려는 Docker 컨테이너 내부에는 Consul에 데이터를 보낼 수 있는 일종의 로직이 있어야 한다는 것이 밝혀졌습니다.

답변: 그렇지 않습니다. 시작되면 환경 변수를 통해 변수를 전달합니다. 서비스 이름, 서비스 포트를 가정해 보겠습니다. 등록부는 이 정보를 듣고 이를 Consul에 입력합니다.

질문: UI에 관해 또 다른 질문이 있습니다. 예를 들어 프로덕션 서버에 UI를 배포했습니다. 보안은 어떻습니까? 데이터는 어디에 저장되나요? 어떻게든 데이터를 축적하는 것이 가능합니까?

답변: UI에는 데이터베이스와 서비스 검색의 데이터가 있습니다. 우리는 설정에서 비밀번호를 직접 설정했습니다.

질문: 이 내용을 인터넷에 게시할 수 있나요?

답변: 기본적으로 Consul은 localhost에서 시작됩니다. 인터넷에 게시하려면 일종의 프록시를 설치해야 합니다. 우리는 자체 안전 규칙에 대한 책임이 있습니다.

질문: 기본적으로 과거 데이터를 제공합니까? 건강검진에 대한 통계를 보는 것은 흥미롭습니다. 서버가 자주 실패하는 경우 문제를 진단할 수도 있습니다.

답변: 거기에 수표 세부정보가 있는지 잘 모르겠습니다.

질문: 현재 상태는 역학만큼 중요하지 않습니다.

답변: 분석을 위해 – 그렇습니다.

질문: Consul docker에 Service Discovery를 사용하지 않는 것이 더 낫습니까?

답변: 사용을 권장하지 않습니다. 보고서의 목적은 그러한 개념이 무엇인지 소개하는 것입니다. 제 생각에는 역사적으로 첫 번째 버전이 나왔습니다. 이제 이 모든 것을 내부에 포함하는 Kubernetes와 같은 더 완전한 솔루션이 이미 있습니다. Kubernetes Service Discovery의 일부로 Etcd보다 열등합니다. 하지만 나는 영사만큼 익숙하지 않습니다. 그래서 Consul을 예로 들어 Service Discovery를 만들어 보기로 했습니다.

질문: 리더 서버를 사용하는 방식은 전체적으로 애플리케이션 시작 속도를 늦추지 않습니까? 그리고 이 지도자가 거짓말을 하고 있다면 영사는 어떻게 새로운 지도자를 결정합니까?

답변: 전체 프로토콜이 설명되어 있습니다. 관심이 있으시면 읽어보실 수 있습니다.

질문: Consul은 우리를 위한 완전한 서버 역할을 하며 모든 요청이 이를 통해 전달됩니까?

답변: 본격적인 서버 역할을 하는 것이 아니라 특정 영역을 대신합니다. 일반적으로 service.consul로 끝납니다. 그런 다음 논리적으로 진행합니다. 우리는 프로덕션에서 도메인 이름을 사용하지 않고 DNS를 사용하여 작업하는 경우 일반적으로 서버 캐싱 뒤에 숨겨져 있는 내부 인프라를 사용합니다.

질문: 즉, 데이터베이스에 액세스하려면 어떤 경우에도 Consul을 끌어와 이 데이터베이스를 먼저 찾아야 합니다. 그렇죠?

대답: 그렇습니다. DNS를 사용하여 작업하는 경우 DNS 이름을 사용할 때 Consul이 없는 것과 동일하게 작동합니다. 일반적으로 최신 응용 프로그램은 모든 요청에서 도메인 이름을 가져오지 않습니다. 연결을 설치하면 모든 것이 작동하고 가까운 시일 내에 실제로 사용하지 않기 때문입니다. 연결이 끊어지면 그렇습니다. 기지가 어디에 있는지 다시 묻고 그곳으로 이동합니다.

Hashicorp 제품 채팅 — Hashicorp 사용자 채팅: Consul, Nomad, Terraform

PS 건강검진 관련. Consul은 Kubernetes와 마찬가지로 코드 상태를 기반으로 서비스의 생존 가능성 상태를 확인하기 위해 동일한 시스템을 사용합니다.

200 OK for healthy
503 Service Unavailable for unhealthy

출처 :
https://www.consul.io/docs/agent/checks.html
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
https://thoslin.github.io/microservice-health-check-in-kubernetes/

출처 : habr.com