서버에 들어오는 엄청난 양의 이벤트를 초당 약 1000 개의 이벤트로 평균 처리해야하는 상황이 있습니다 (피크는 ~ 2000 일 수 있음).

문제

우리의 시스템은 Heroku에서 호스팅되며 최대 500 개의 DB 연결을 허용하는 비교적 비싼 Heroku Postgres DB 를 사용합니다. 연결 풀링을 사용하여 서버에서 DB로 연결합니다.

DB 연결 풀이 처리 할 수있는 것보다 빠른 이벤트

우리가 가진 문제는 이벤트가 연결 풀이 처리 할 수있는 것보다 빠르다는 것입니다. 하나의 연결이 서버에서 DB 로의 네트워크 왕복을 완료 할 때까지 n추가 이벤트가 들어오는 것보다 풀로 다시 해제 될 수 있습니다 .

결국 이벤트가 누적되어 저장 대기 중이며 풀에 사용 가능한 연결이 없기 때문에 시간이 초과되고 전체 시스템이 작동하지 않습니다.

우리는 고객으로부터 더 느린 속도로 문제가되는 고주파 이벤트를 방출하여 긴급 상황을 해결했지만, 고주파 이벤트를 처리해야하는 경우이 시나리오를 처리하는 방법을 여전히 알고 싶습니다.

제약

다른 클라이언트가 동시에 이벤트를 읽고 싶을 수 있습니다

다른 클라이언트는 DB에 아직 저장되지 않은 경우에도 특정 키를 사용하여 모든 이벤트를 계속 읽도록 요청합니다.

클라이언트는 GET api/v1/events?clientId=1아직 이벤트를 DB에 저장하지 않은 경우에도 클라이언트 1이 보낸 모든 이벤트를 쿼리 하고 가져올 수 있습니다 .

이를 처리하는 방법에 대한 "교실"예가 있습니까?

가능한 해결책

서버에서 이벤트를 대기열에 넣습니다.

서버에서 이벤트를 큐에 넣을 수 있습니다 (큐의 동시성이 최대 400이므로 연결 풀이 부족하지 않음).

이것은 나쁜 생각 입니다.

• 사용 가능한 서버 메모리를 소모합니다. 누적 된 대기열 이벤트는 대량의 RAM을 소비합니다.
• 서버는 24 시간마다 한 번씩 다시 시작됩니다 . 이것은 Heroku가 부과 한 하드 한계 입니다. 이벤트가 대기열에있는 동안 서버가 다시 시작되어 대기열에있는 이벤트가 유실됩니다.
• 서버에 상태를 도입하여 확장 성을 손상시킵니다. 다중 서버 설정이 있고 클라이언트가 대기열에있는 + 저장된 이벤트를 모두 읽으려는 경우 대기열에있는 이벤트가 어떤 서버에 있는지 알 수 없습니다.

별도의 메시지 대기열을 사용하십시오.

메시지 를 펌핑 하는 메시지 대기열 (예 : RabbitMQ ?)을 사용할 수 있다고 가정 하고 다른쪽에는 DB에 이벤트 저장 만 처리하는 다른 서버가 있습니다.

메시지 큐가 대기열에 넣은 이벤트 (아직 저장되지 않은) 쿼리를 허용하는지 확실하지 않으므로 다른 클라이언트가 다른 클라이언트의 메시지를 읽으려면 DB에서 저장된 메시지와 큐에서 보류중인 메시지를 가져올 수 있습니다. 다시 연결하여 읽기 요청 클라이언트로 다시 보낼 수 있습니다.

중앙 DB 코디네이터 서버로 메시지의 일부를 저장하는 여러 데이터베이스를 사용하여 관리

우리가 해결 한 또 다른 솔루션은 중앙의 "DB 코디네이터 /로드 밸런서"와 함께 여러 데이터베이스를 사용하는 것입니다. 이벤트를 수신하면이 코디네이터는 메시지를 작성할 데이터베이스 중 하나를 선택합니다. 이를 통해 여러 개의 Heroku 데이터베이스를 사용할 수 있으므로 연결 제한을 500 x 수의 데이터베이스로 높일 수 있습니다.

읽기 쿼리에서이 코디네이터는 SELECT각 데이터베이스에 쿼리를 발행 하고 모든 결과를 병합 한 후 읽기를 요청한 클라이언트로 다시 보낼 수 있습니다.

이것은 나쁜 생각 입니다.

• 이 아이디어는 ... ahem .. over-engineering? 관리해야 할 악몽이 될 것입니다 (백업 등). 구축 및 유지 관리가 복잡하며 꼭 필요한 경우가 아니면 KISS 위반 처럼 들립니다 .
• 일관성을 희생 합니다. 이 아이디어를 사용하면 여러 DB에서 트랜잭션을 수행 할 수 있습니다.

입력 스트림

초당 1000 개의 이벤트가 최고점을 나타내는 지 또는 지속적인로드인지는 확실하지 않습니다.

• 최대 인 경우 메시지 큐를 버퍼로 사용하여 더 오래 DB 서버에로드를 분산시킬 수 있습니다.
• 일정하게로드되는 경우 DB 서버가이를 따라 잡을 수 없으므로 메시지 큐만으로는 충분하지 않습니다. 그런 다음 분산 데이터베이스에 대해 생각해야합니다.

제안 된 해법

직관적으로 두 경우 모두 Kafka 기반 이벤트 스트림을 사용합니다.

• 모든 이벤트는 체계적으로 kafka 주제 에 게시됩니다
• 소비자는 이벤트에 가입하여 데이터베이스에 저장합니다.
• 쿼리 프로세서는 클라이언트의 요청을 처리하고 DB를 쿼리합니다.

이것은 모든 수준에서 확장 성이 뛰어납니다.

• DB 서버에 병목 현상이 발생하면 여러 소비자를 추가하십시오. 각각 주제를 구독하고 다른 DB 서버에 쓸 수 있습니다. 그러나 DB 서버에서 분산이 무작위로 발생하는 경우 쿼리 프로세서는 DB 서버가 여러 DB 서버를 가져 와서 쿼리해야한다고 예측할 수 없습니다. 이로 인해 쿼리 측에 새로운 병목 현상이 발생할 수 있습니다.
• 따라서 이벤트 분배를 여러 주제 (예 : 키 또는 특성 그룹을 사용하여 예측 가능한 논리에 따라 DB를 분할)로 구성하여 DB 분배 체계를 예상 할 수 있습니다.
• 하나의 메시지 서버로 점점 더 많은 입력 이벤트를 처리하기에 충분하지 않은 경우 kafka 파티션 을 추가 하여 여러 실제 서버에 kafka 주제를 분배 할 수 있습니다 .

아직 DB에 기록되지 않은 이벤트를 클라이언트에게 제공

클라이언트가 아직 파이프에 있지만 아직 DB에 기록되지 않은 정보에 액세스 할 수 있기를 원합니다. 좀 더 섬세합니다.

옵션 1 : 캐시를 사용하여 DB 쿼리 보완

심도있게 분석하지는 않았지만 쿼리 프로세서를 kafka 주제의 소비자 로, 다른 kafka 소비자 그룹 으로 만드는 것이 가장 먼저 생각됩니다 . 그런 다음 요청 프로세서는 DB Writer가받을 모든 메시지를 독립적으로받습니다. 그런 다음 로컬 캐시에 보관할 수 있습니다. 그런 다음 쿼리는 DB + 캐시에서 실행됩니다 (+ 중복 제거).

디자인은 다음과 같습니다.

이 쿼리 계층의 확장 성은 쿼리 프로세서를 추가하여 (각각 자체 소비자 그룹에) 추가 할 수 있습니다.

옵션 2 : 이중 API 디자인

IMHO의 더 나은 접근 방식은 이중 API를 제공하는 것입니다 (별도의 소비자 그룹의 메커니즘 사용).

• DB의 이벤트에 액세스하거나 분석하기위한 쿼리 API
• 주제에서 직접 메시지를 전달하는 스트리밍 API

장점은 클라이언트가 흥미로운 것을 결정할 수 있다는 것입니다. 따라서 클라이언트가 새로운 수신 이벤트에만 관심이있는 경우 DB 데이터를 새로 현금화 된 데이터와 체계적으로 병합하지 않아도됩니다. 새로운 이벤트와 보관 된 이벤트 사이의 섬세한 병합이 실제로 필요한 경우 클라이언트가이를 구성해야합니다.

변형

kafka 는 영구 메시지가있는 매우 큰 볼륨 을 위해 설계되어 필요한 경우 서버를 다시 시작할 수 있기 때문에 제안했습니다 .

RabbitMQ로 유사한 아키텍처를 구축 할 수 있습니다. 그러나 지속적 대기열이 필요한 경우 성능이 저하 될 수 있습니다 . 또한 내가 아는 한 RabbitMQ를 사용하여 여러 독자 (예 : writer + cache)가 동일한 메시지를 병렬로 소비하는 유일한 방법 은 대기열 을 복제하는 것 입니다. 따라서 더 높은 확장 성은 더 높은 가격에 올 수 있습니다.

내 추측은 당신이 거부 한 접근법을 더 신중하게 탐색해야한다는 것이다.

• 서버에서 이벤트를 대기열에 넣습니다.

저의 제안은 LMAX 아키텍처 에 관해 출판 된 다양한 기사를 읽는 것 입니다. 그들은 그들의 사용 사례를 위해 대량의 일괄 처리 작업을 수행했으며, 트레이드 오프를 자신의 것처럼 보이게 만들 수 있습니다.

또한 읽기를 방해하지 않는지 확인하고 싶을 수도 있습니다. 쓰기와 독립적으로 확장 할 수있는 것이 이상적입니다. 이는 CQRS (명령 쿼리 책임 분리)를 조사하는 것을 의미 할 수 있습니다.

이벤트가 대기열에있는 동안 서버가 다시 시작되어 대기열에있는 이벤트가 유실됩니다.

분산 시스템에서는 메시지가 손실 될 것이라고 확신 할 수 있습니다. 시퀀스 장벽에 대해 신중하게 판단함으로써 영향의 일부를 완화 할 수 있습니다 (예 : 이벤트가 시스템 외부에서 공유되기 전에 내구성있는 스토리지에 쓰기가 수행되도록 보장).

• 중앙 DB 코디네이터 서버로 메시지의 일부를 저장하는 여러 데이터베이스를 사용하여 관리

아마도-데이터를 샤딩 할 자연적인 장소가 있는지 알아보기 위해 비즈니스 경계를 ​​살펴볼 가능성이 큽니다.

데이터 손실이 허용 가능한 트레이드 오프 인 경우가 있습니까?

글쎄, 나는있을 수 있다고 생각하지만, 내가 가고있는 곳이 아닙니다. 요점은 디자인이 메시지 손실에도 불구하고 발전하는 데 필요한 견고성을 갖추어야한다는 것입니다.

이것이 자주 보이는 것은 알림이있는 풀 기반 모델입니다. 공급자는 주문 된 내구성 저장소에 메시지를 씁니다. 소비자는 상점에서 메시지를 가져와 고유 한 상위 워터 마크를 추적합니다. 푸시 알림은 대기 시간을 줄이는 장치로 사용됩니다. 그러나 알림이 손실 된 경우 소비자가 정기적으로 일정을 잡아 당기기 때문에 메시지가 계속 페치됩니다 (알림이 수신되면 더 빨리 풀림이 발생 함) ).

Udi Dahan ( Andy에서 이미 참조 )의 분산 트랜잭션없는 안정적인 메시징 및 Greg Young의 Polyglot Data 를 참조하십시오 .

내가 올바르게 이해하면 현재 흐름은 다음과 같습니다.

1. 수신 및 이벤트 (HTTP를 통해 가정합니까?)
2. 풀에서 연결을 요청하십시오.
3. 이벤트를 DB에 삽입
4. 풀에 대한 연결을 해제하십시오.

그렇다면 디자인의 첫 번째 변경 사항은 모든 이벤트에서 짝수 처리 코드가 풀에 연결을 반환하지 않는 것입니다. 대신 DB 연결 수와 일대일 인 삽입 스레드 / 프로세스 풀을 작성하십시오. 이들은 각각 전용 DB 연결을 유지합니다.

그런 다음 일종의 동시 큐를 사용하여 이러한 스레드가 동시 큐에서 메시지를 가져 와서 삽입합니다. 이론적으로 풀에 대한 연결을 다시 반환하거나 새로 요청할 필요는 없지만 연결이 잘못 될 경우 처리를 위해 빌드해야 할 수도 있습니다. 스레드 / 프로세스를 종료하고 새로 시작하는 것이 가장 쉬울 수 있습니다.

이는 연결 풀 오버 헤드를 효과적으로 제거해야합니다. 물론 각 연결에서 초당 최소 1000 / 연결 이벤트를 푸시 할 수 있어야합니다. 같은 테이블에서 500 개의 연결이 작동하면 DB에서 경합이 발생할 수 있기 때문에 다른 수의 연결을 시도 할 수도 있지만 완전히 다른 질문입니다. 고려해야 할 또 다른 사항은 일괄 삽입을 사용하는 것입니다. 즉, 각 스레드가 여러 메시지를 가져 와서 한 번에 푸시합니다. 또한 여러 연결이 동일한 행을 업데이트하지 않도록하십시오.

가정

설명하기 어려운 부하가 해결하기 어려운 시나리오이기 때문에 설명하는 부하가 일정하다고 가정합니다.

또한 웹 응용 프로그램 프로세스 외부에서 트리거 된 장기 실행 워크로드를 실행할 수있는 방법이 있다고 가정하겠습니다.

해결책

프로세스와 Postgres 데이터베이스 간의 대기 시간-병목 현상을 올바르게 식별했다고 가정하면 해결해야 할 주요 문제입니다. 솔루션은 이벤트를 수신 한 후 가능한 빨리 이벤트를 읽으려는 다른 클라이언트와의 일관성 제약 조건을 고려해야합니다.

지연 시간 문제를 해결하려면 이벤트 당 발생하는 지연 시간을 최소화하는 방식으로 작업해야합니다. 하드웨어를 기꺼이 바꾸거나 변경할 수없는 경우 달성해야 할 핵심 사항 입니다. PaaS 서비스를 사용 중이고 하드웨어 또는 네트워크를 제어 할 수없는 경우 이벤트 당 대기 시간을 줄이는 유일한 방법은 일종의 일괄 처리 된 이벤트 쓰기입니다.

주어진 크기에 도달하거나 경과 시간이 지나면 데이터베이스에 주기적으로 플러시 및 기록되는 이벤트 큐를 로컬로 저장해야합니다. 상점에 대한 비우기를 트리거하려면 프로세스가이 큐를 모니터해야합니다. 선택한 언어로 주기적으로 플러시되는 동시 큐를 관리하는 방법에 대한 많은 예제가 있어야합니다. 다음은 널리 사용되는 Serilog 로깅 라이브러리의 주기적 배치 싱크 에서 C # 예제입니다 .

이 SO 답변 은 Postgres에서 데이터를 플러시하는 가장 빠른 방법을 설명합니다-비록 배치를 대기열에 디스크에 저장해야하지만 Heroku에서 재부팅 할 때 디스크가 사라지면 문제가 해결 될 수 있습니다.

강제

또 다른 대답은 이미 CQRS를 언급 했으며 제약 조건을 해결하는 올바른 접근 방법입니다. 각 이벤트가 처리 될 때 읽기 모델을 수화하고자합니다. 중개자 패턴 은 이벤트를 캡슐화하여 처리중인 여러 핸들러에 분배하는 데 도움이 될 수 있습니다. 따라서 하나의 핸들러는 클라이언트가 쿼리 할 수있는 메모리에있는 읽기 모델에 이벤트를 추가 할 수 있으며 다른 핸들러는 이벤트의 일괄 처리 된 쓰기를 위해 이벤트를 큐잉 할 책임이 있습니다.

CQRS의 주요 이점은 개념적 읽기 및 쓰기 모델을 분리하는 것입니다. 이는 하나의 모델에 쓰고 다른 완전히 다른 모델에서 읽는다는 멋진 방법입니다. CQRS의 확장 성 이점을 얻으려면 일반적으로 사용 모델에 가장 적합한 방식으로 각 모델을 별도로 저장해야합니다. 이 경우, 데이터를 기록하기 위해 트랜잭션 데이터베이스를 사용하면서도 읽기 속도가 빠르고 일관성을 유지하기 위해 집계 읽기 모델 (예 : Redis 캐시 또는 단순히 메모리 내)을 사용할 수 있습니다.

DB 연결 풀이 처리 할 수있는 것보다 빠른 이벤트

각 프로세스마다 하나의 데이터베이스 연결이 필요한 경우에 문제가됩니다. 각 작업자가 하나의 데이터베이스 연결 만 필요하고 각 작업자가 여러 이벤트를 처리 할 수있는 작업자 풀을 갖도록 시스템을 설계해야합니다.

메시지 큐를 해당 디자인과 함께 사용할 수 있으므로 이벤트를 메시지 큐로 푸시하고 작업자 (소비자)가 큐에서 메시지를 처리하는 메시지 생성자가 필요합니다.

다른 클라이언트가 동시에 이벤트를 읽고 싶을 수 있습니다

이 제한 조건은 이벤트 (처리되지 않은 이벤트)없이 데이터베이스에 이벤트가 저장된 경우에만 가능합니다. 이벤트가 데이터베이스에 저장되기 전에 처리되는 경우 이벤트를 얻는 유일한 방법은 데이터베이스입니다.

클라이언트가 원시 이벤트를 쿼리하려면 Elastic Search와 같은 검색 엔진을 사용하는 것이 좋습니다. 쿼리 / 검색 API를 무료로받을 수도 있습니다.

데이터베이스에 저장되기 전에 이벤트를 쿼리하는 것이 중요하다고 생각되면 Elastic Search와 같은 간단한 솔루션이 작동해야합니다. 기본적으로 모든 이벤트를 저장하고 데이터베이스에 복사하여 동일한 데이터를 복제하지 않습니다.

Elastic Search의 확장은 쉽지만 기본 구성으로도 성능이 뛰어납니다.

처리가 필요할 때 프로세스는 ES에서 이벤트를 가져 와서 처리하여 데이터베이스에 저장할 수 있습니다. 이 처리에서 필요한 성능 수준을 모르지만 ES에서 이벤트를 쿼리하는 것과는 완전히 별개입니다. 고정 된 수의 작업자와 각각 하나의 데이터베이스 연결을 가질 수 있으므로 연결 문제가 발생하지 않아야합니다.

데이터베이스에 적절한 스키마 및 스토리지 엔진이있는 경우 초당 1k 또는 2k 이벤트 (5KB)는 그다지 많지 않습니다. @eddyce가 제안한 것처럼 하나 이상의 슬레이브가있는 마스터는 읽기 쿼리와 쓰기 커밋을 분리 할 수 ​​있습니다. 더 적은 DB 연결을 사용하면 전반적인 처리량이 향상됩니다.

다른 클라이언트가 동시에 이벤트를 읽고 싶을 수 있습니다

이러한 요청의 경우 읽기 슬레이브에 복제 지연이 발생하기 때문에 마스터 DB에서도 읽어야합니다.

대용량 쓰기를 위해 (Percona) MySQL을 TokuDB 엔진과 함께 사용했습니다. 쓰기로드에 적합한 LSMtree를 기반으로하는 MyRocks 엔진도 있습니다. 이러한 엔진과 PostgreSQL 모두에 대해 트랜잭션 격리 및 커밋 동기화 동작에 대한 설정이있어 쓰기 용량을 크게 늘릴 수 있습니다. 과거에는 커밋 된 것으로 db 클라이언트에보고 된 최대 1 초의 손실 된 데이터를 허용했습니다. 다른 경우에는 손실을 피하기 위해 배터리 지원 SSD가있었습니다.

MySQL의 Amazon RDS Aurora는 제로 비용 복제 (마스터와 파일 시스템을 공유하는 슬레이브와 유사)로 쓰기 처리량이 6 배 더 높다고 주장합니다. Aurora PostgreSQL 플레이버에는 다른 고급 복제 메커니즘도 있습니다.

나는 heroku를 한꺼번에 떨어 뜨릴 것입니다. 즉, 중앙 집중식 접근 방식을 포기합니다. 최대 풀 연결을 최대로하는 여러 쓰기는 DB 클러스터가 발명 된 주요 원인 중 하나입니다. 주로 쓰기를로드하지 못하게합니다 클러스터의 다른 db에 의해 수행 될 수있는 읽기 요청이있는 db는 마스터 슬레이브 슬레이브로 시도해 보았습니다. 다른 사람이 이미 언급했듯이 자신의 db 설치가 있으면 전체를 조정할 수 있습니다. 시스템은 쿼리 전파 시간이 올바르게 처리되도록합니다.

행운을 빕니다