서비스 그리드 점화 - 재부팅

26월 XNUMX일에 우리는 Apache Ignite GreenSource 모임을 개최했습니다. 여기서 오픈 소스 프로젝트 기여자들은 다음과 같이 말했습니다. 아파치 이그나이트. 이 커뮤니티의 삶에서 중요한 사건은 구성 요소의 구조 조정이었습니다. 서비스 그리드 점화를 사용하면 사용자 지정 마이크로서비스를 Ignite 클러스터에 직접 배포할 수 있습니다. 그는 밋업에서 이 어려운 과정에 대해 이야기했습니다. 뱌체슬라프 다라두르, 소프트웨어 엔지니어이자 Apache Ignite 기고자로서 XNUMX년 넘게 활동하고 있습니다.

Apache Ignite의 일반적인 내용부터 시작해 보겠습니다. 이는 SQL, 트랜잭션 및 캐싱을 지원하는 분산 키/값 저장소인 데이터베이스입니다. 또한 Ignite를 사용하면 사용자 지정 서비스를 Ignite 클러스터에 직접 배포할 수 있습니다. 개발자는 분산 데이터 구조, 메시징, 스트리밍, 컴퓨팅 및 데이터 그리드 등 Ignite가 제공하는 모든 도구에 액세스할 수 있습니다. 예를 들어, Data Grid를 사용하면 데이터 저장을 위한 별도의 인프라를 관리해야 하는 문제가 발생하고 그에 따른 간접 비용이 사라집니다.

Service Grid API를 사용하면 배포 체계를 지정하고 그에 따라 서비스 자체를 구성에 지정하여 서비스를 배포할 수 있습니다.

일반적으로 배포 체계는 클러스터 노드에 배포되어야 하는 인스턴스 수를 나타냅니다. 일반적인 배포 방식에는 두 가지가 있습니다. 첫 번째는 클러스터 싱글톤입니다. 언제든지 사용자 서비스의 한 인스턴스를 클러스터에서 사용할 수 있도록 보장됩니다. 두 번째는 노드 싱글톤입니다. 서비스의 인스턴스 하나가 각 클러스터 노드에 배포됩니다.

사용자는 전체 클러스터의 서비스 인스턴스 수를 지정하고 적합한 노드를 필터링하기 위한 조건자를 정의할 수도 있습니다. 이 시나리오에서는 Service Grid 자체가 서비스 배포를 위한 최적의 배포를 계산합니다.

또한 Affinity Service와 같은 기능이 있습니다. 선호도는 키와 파티션의 관계 및 토폴로지의 노드와 당사자의 관계를 정의하는 기능입니다. 키를 사용하면 데이터가 저장되는 기본 노드를 확인할 수 있습니다. 이렇게 하면 자신의 서비스를 키 및 선호도 함수 캐시와 연결할 수 있습니다. Affinity 함수가 변경되면 자동 재배포가 발생합니다. 이렇게 하면 서비스가 항상 조작해야 하는 데이터 가까이에 위치하므로 정보 액세스에 따른 오버헤드가 줄어듭니다. 이러한 방식은 일종의 콜로케이션 컴퓨팅(collocated computing)이라고 할 수 있다.

이제 Service Grid의 장점을 알아보았으니, 이제 Service Grid의 개발 역사에 대해 이야기해 보겠습니다.

이전에 있었던 일

Service Grid의 이전 구현은 Ignite의 트랜잭션 복제 시스템 캐시를 기반으로 했습니다. Ignite에서 "캐시"라는 단어는 저장소를 의미합니다. 즉, 이것은 당신이 생각하는 것처럼 일시적인 것이 아닙니다. 캐시가 복제되고 각 노드에 전체 데이터 세트가 포함되어 있음에도 불구하고 캐시 내부에는 분할된 표현이 있습니다. 이는 스토리지 최적화 때문입니다.

사용자가 서비스를 배포하려고 했을 때 무슨 일이 일어났나요?

• 클러스터의 모든 노드는 내장된 연속 쿼리 메커니즘을 사용하여 스토리지의 데이터를 업데이트하도록 구독했습니다.
• 읽기 커밋된 트랜잭션에서 시작 노드는 직렬화된 인스턴스를 포함하여 서비스 구성이 포함된 데이터베이스에 레코드를 만들었습니다.
• 새 항목이 통보되면 코디네이터는 구성에 따라 분포를 계산했습니다. 결과 개체가 데이터베이스에 다시 기록되었습니다.
• 노드가 배포의 일부인 경우 코디네이터가 이를 배포해야 했습니다.

우리에게 적합하지 않은 것

어느 시점에서 우리는 이것이 서비스 작업 방식이 아니라는 결론에 도달했습니다. 몇 가지 이유가 있었습니다.

배포 중에 오류가 발생하면 모든 일이 발생한 노드의 로그에서만 찾을 수 있습니다. 비동기식 배포만 있었기 때문에 배포 방법에서 사용자에게 제어권을 반환한 후 서비스를 시작하는 데 약간의 추가 시간이 필요했고 이 시간 동안 사용자는 아무것도 제어할 수 없었습니다. Service Grid를 더욱 발전시키고, 새로운 기능을 만들고, 새로운 사용자를 유치하고, 모든 사람의 삶을 더 쉽게 만들기 위해서는 뭔가 변화가 필요합니다.

새로운 Service Grid를 설계할 때 우리는 무엇보다도 동기식 배포를 보장하고 싶었습니다. 즉, 사용자가 API에서 제어를 반환하자마자 즉시 서비스를 사용할 수 있었습니다. 또한 개시자에게 배포 오류를 처리할 수 있는 기능을 제공하고 싶었습니다.

또한 구현을 단순화하고 싶었습니다. 즉, 트랜잭션과 리밸런싱에서 벗어나고 싶었습니다. 캐시가 복제되고 밸런싱이 없음에도 불구하고 많은 노드가 있는 대규모 배포 중에 문제가 발생했습니다. 토폴로지가 변경되면 노드는 정보를 교환해야 하며 대규모 배포의 경우 이 데이터의 무게가 커질 수 있습니다.

토폴로지가 불안정하면 코디네이터는 서비스 배포를 다시 계산해야 했습니다. 그리고 일반적으로 불안정한 토폴로지에서 트랜잭션을 작업해야 하는 경우 예측하기 어려운 오류가 발생할 수 있습니다.

문제

문제가 수반되지 않는 글로벌 변화는 무엇입니까? 첫 번째는 토폴로지의 변경이었습니다. 서비스 배포 순간에도 언제든지 노드가 클러스터에 들어오거나 나갈 수 있다는 점을 이해해야 합니다. 또한 배포 시 노드가 클러스터에 참여하는 경우 서비스에 대한 모든 정보를 일관되게 새 노드로 전송해야 합니다. 그리고 우리는 이미 배포된 것뿐만 아니라 현재와 미래의 배포에 대해서도 이야기하고 있습니다.

이는 별도의 목록으로 수집할 수 있는 문제 중 하나일 뿐입니다.

• 노드 시작 시 정적으로 구성된 서비스를 배포하는 방법은 무엇입니까?
• 클러스터에서 노드 나가기 - 노드가 서비스를 호스팅하는 경우 어떻게 해야 합니까?
• 코디네이터가 바뀌면 어떻게 해야 하나요?
• 클라이언트가 클러스터에 다시 연결되면 어떻게 해야 합니까?
• 활성화/비활성화 요청을 처리해야 하며 어떻게 처리해야 합니까?
• 그들이 캐시 파괴를 요구했는데 우리가 이에 연관되어 있는 어피니티 서비스를 갖고 있다면 어떻게 될까요?

그리고 그것이 전부는 아닙니다.

결정

우리는 메시지를 사용한 프로세스 통신을 구현하는 이벤트 기반 접근 방식을 목표로 선택했습니다. Ignite는 노드가 서로 메시지를 전달할 수 있도록 하는 두 가지 구성 요소(communication-spi 및 discovery-spi)를 이미 구현하고 있습니다.

Communication-spi를 사용하면 노드가 직접 통신하고 메시지를 전달할 수 있습니다. 많은 양의 데이터를 전송하는 데 매우 적합합니다. Discovery-spi를 사용하면 클러스터의 모든 노드에 메시지를 보낼 수 있습니다. 표준 구현에서는 링 토폴로지를 사용하여 이 작업이 수행됩니다. Zookeeper와의 통합도 있으며 이 경우 스타 토폴로지가 사용됩니다. 주목할 만한 또 다른 중요한 점은 discovery-spi가 메시지가 모든 노드에 올바른 순서로 확실히 전달된다는 것을 보장한다는 것입니다.

배포 프로토콜을 살펴보겠습니다. 배포 및 배포 취소에 대한 모든 사용자 요청은 discovery-spi를 통해 전송됩니다. 이는 다음을 제공합니다 보증:

• 요청은 클러스터의 모든 노드에서 수신됩니다. 이렇게 하면 코디네이터가 변경될 때 요청이 계속 처리될 수 있습니다. 이는 또한 하나의 메시지에 각 노드가 서비스 구성 및 직렬화된 인스턴스와 같은 필요한 모든 메타데이터를 갖게 된다는 것을 의미합니다.
• 메시지 전달의 엄격한 순서는 구성 충돌과 경쟁 요청을 해결하는 데 도움이 됩니다.
• 노드의 토폴로지 진입도 discovery-spi를 통해 처리되므로 새 노드는 서비스 작업에 필요한 모든 데이터를 수신하게 됩니다.

요청이 수신되면 클러스터의 노드가 이를 검증하고 처리 작업을 생성합니다. 이러한 작업은 대기열에 추가된 다음 별도의 작업자에 의해 다른 스레드에서 처리됩니다. 배포에는 상당한 시간이 걸리고 비용이 많이 드는 검색 흐름이 견딜 수 없을 정도로 지연될 수 있기 때문에 이러한 방식으로 구현됩니다.

큐의 모든 요청은 배치 관리자에 의해 처리됩니다. 이 대기열에서 작업을 가져와 초기화하여 배포를 시작하는 특수 작업자가 있습니다. 그 후에는 다음 작업이 발생합니다.

1. 각 노드는 새로운 결정론적 할당 기능 덕분에 분포를 독립적으로 계산합니다.
2. 노드는 배포 결과로 메시지를 생성하여 코디네이터에게 보냅니다.
3. 코디네이터는 모든 메시지를 집계하고 전체 배포 프로세스의 결과를 생성하며, 이는 discovery-spi를 통해 클러스터의 모든 노드로 전송됩니다.
4. 결과가 수신되면 배포 프로세스가 종료되고 그 후 작업이 대기열에서 제거됩니다.

새로운 이벤트 중심 디자인: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java

배포 중에 오류가 발생하면 노드는 코디네이터에게 보내는 메시지에 이 오류를 즉시 포함합니다. 메시지 집계 후 코디네이터는 배포 중 모든 오류에 대한 정보를 갖게 되며 discovery-spi를 통해 이 메시지를 보냅니다. 오류 정보는 클러스터의 모든 노드에서 사용할 수 있습니다.

Service Grid의 모든 중요한 이벤트는 이 운영 알고리즘을 사용하여 처리됩니다. 예를 들어 토폴로지를 변경하는 것도 discovery-spi를 통한 메시지입니다. 그리고 일반적으로 이전 프로토콜과 비교했을 때 프로토콜은 매우 가볍고 안정적인 것으로 나타났습니다. 배포 중 모든 상황을 처리하기에 충분합니다.

다음에 어떤 일이 일어날 것입니까?

이제 계획에 대해. Ignite 프로젝트에 대한 주요 변경 사항은 IEP라고 하는 Ignite 개선 계획으로 완료됩니다. Service Grid 재설계에는 IEP도 있습니다. IEP #17 "서비스 그리드의 오일 교환"이라는 조롱 제목으로. 그런데 사실 우리는 엔진오일을 교체한 것이 아니라 엔진 전체를 교체했습니다.

우리는 IEP의 작업을 2단계로 나누었습니다. 첫 번째는 배포 프로토콜을 재작업하는 주요 단계입니다. 이는 이미 마스터에 포함되어 있으므로 버전 2.8에 나타날 새로운 Service Grid를 사용해 볼 수 있습니다. 두 번째 단계에는 기타 여러 작업이 포함됩니다.

• 핫 재배포
• 서비스 버전 관리
• 내결함성 향상
• 씬 클라이언트
• 다양한 지표를 모니터링하고 계산하는 도구

마지막으로, 내결함성, 고가용성 시스템 구축을 위한 Service Grid에 대해 조언해 드릴 수 있습니다. 우리는 또한 당신이 우리를 방문하도록 초대합니다 개발자 목록 и 사용자 목록 당신의 경험을 공유하십시오. 귀하의 경험은 커뮤니티에 정말 중요하며, 다음 단계로 나아갈 방향과 향후 구성 요소를 개발하는 방법을 이해하는 데 도움이 될 것입니다.

출처 : habr.com