Kafka에서 비동기 API를 활용한 Refund Tool 서비스 개발 경험

간소화된 프로세스와 수십 개의 상호 연결된 서비스를 갖춘 Lamoda와 같은 대기업이 접근 방식을 크게 바꾸도록 강요할 수 있는 이유는 무엇일까요? 동기 부여는 입법에서부터 모든 프로그래머에게 내재된 실험 욕구에 이르기까지 완전히 다를 수 있습니다.

그러나 이것이 추가 혜택을 기대할 수 없다는 의미는 아닙니다. Sergey Zaika는 Kafka에서 이벤트 중심 API를 구현하면 정확히 무엇을 얻을 수 있는지 알려줄 것입니다(소수의). 거물과 흥미로운 발견에 대한 이야기도 분명히 있을 것입니다. 실험은 그것 없이는 할 수 없습니다.

고지 사항: 이 기사는 Sergey가 2018년 XNUMX월 HighLoad++에서 개최한 모임의 자료를 기반으로 합니다. Kafka와 함께 작업한 Lamoda의 라이브 경험은 일정에 대한 다른 보고서만큼이나 청취자를 매료시켰습니다. 우리는 이것이 같은 생각을 가진 사람들을 항상 찾을 수 있고 찾아야 한다는 사실을 보여주는 훌륭한 예라고 생각하며 HighLoad++의 주최자는 이에 도움이 되는 분위기를 조성하기 위해 계속 노력할 것입니다.

과정에 대해

Lamoda는 자체 연락 센터, 배송 서비스(및 많은 계열사), 사진 스튜디오, 대규모 창고를 갖추고 있으며 이 모든 것이 자체 소프트웨어에서 실행되는 대규모 전자 상거래 플랫폼입니다. 이러한 서비스 중 일부 또는 전부를 사용할 수 있고 제품에 대한 최신 정보를 알고 싶어하는 수십 가지 결제 방법, b2b 파트너가 있습니다. 또한 Lamoda는 러시아 연방 외에 XNUMX개국에서 운영되고 있으며 모든 것이 약간 다릅니다. 전체적으로 새로운 주문을 구성하는 방법은 아마도 XNUMX가지가 넘을 것이며, 이를 자체 방식으로 처리해야 합니다. 이 모든 것은 때때로 명확하지 않은 방식으로 통신하는 수십 가지 서비스의 도움으로 작동합니다. 주문 상태를 주요 책임으로 하는 중앙 시스템도 있습니다. 우리는 그녀를 BOB라고 부릅니다. 저는 그녀와 함께 일합니다.

이벤트 기반 API를 갖춘 환불 도구

이벤트 중심이라는 단어는 상당히 험난한 표현입니다. 조금 더 나아가 이것이 의미하는 바를 더 자세히 정의하겠습니다. Kafka에서 이벤트 중심 API 접근 방식을 시도하기로 결정한 상황부터 시작하겠습니다.

어느 매장이든 고객이 결제한 주문 외에도 상품이 고객에게 맞지 않아 매장에서 환불을 요구하는 경우가 있습니다. 이는 상대적으로 짧은 과정입니다. 필요한 경우 정보를 명확히 하고 자금을 이체합니다.

하지만 법률 변경으로 인해 반환이 더욱 복잡해졌고 이를 위해 별도의 마이크로서비스를 구현해야 했습니다.

우리의 동기:

1. 법 FZ-54 - 간단히 말해서, 법에 따라 반품이든 영수증이든 모든 금전 거래에 대해 몇 분이라는 매우 짧은 SLA 내에 세무서에 보고해야 합니다. 우리는 전자상거래 회사로서 꽤 많은 업무를 수행하고 있습니다. 기술적으로 이는 새로운 책임(따라서 새로운 서비스)과 관련된 모든 시스템의 개선을 의미합니다.
2. 밥 분할 BOB의 비핵심 책임을 완화하고 전반적인 복잡성을 줄이기 위한 회사 내부 프로젝트입니다.

이 다이어그램은 주요 Lamoda 시스템을 보여줍니다. 이제는 대부분이 더 많아졌습니다. 축소되는 모놀리스 주변의 5~10개 마이크로서비스 집합. 천천히 성장하고 있지만 중앙에서 선택한 조각을 배포하는 것이 무섭기 때문에 더 작게 만들려고 노력하고 있습니다. 조각이 떨어지는 것을 허용할 수 없습니다. 우리는 모든 교환(화살표)을 예약해야 하며 그 중 하나라도 사용 불가능할 수 있다는 사실을 고려해야 합니다.

BOB에는 결제 시스템, 배송 시스템, 알림 시스템 등 많은 거래소가 있습니다.

기술적으로 BOB는 다음과 같습니다.

• ~150개의 코드 라인 + ~100개의 테스트 라인;
• php7.2 + Zend 1 및 Symfony 구성 요소 3;
• 100개 이상의 API 및 ~50개의 아웃바운드 통합
• 4개국은 각자의 비즈니스 로직을 가지고 있습니다.

BOB를 배포하는 것은 비용이 많이 들고 고통스럽습니다. BOB를 통해 해결되는 코드와 문제의 양은 누구도 머리 속에 집어넣을 수 없을 정도입니다. 일반적으로 이를 단순화하는 데에는 여러 가지 이유가 있습니다.

반품 절차

처음에는 BOB와 결제라는 두 가지 시스템이 프로세스에 참여합니다. 이제 두 가지가 더 나타납니다.

• 재정화 서비스(Fiscalization Service)는 재정화 및 외부 서비스와의 의사소통 문제를 해결합니다.
• BOB를 부풀리지 않도록 새로운 교환을 포함하는 환불 도구입니다.

이제 프로세스는 다음과 같습니다.

1. BOB가 환불 요청을 받았습니다.
2. BOB가 이 환불 도구에 대해 이야기합니다.
3. 환불 도구는 결제 수단에 "금액을 반환하세요"라고 알려줍니다.
4. 지불은 돈을 반환합니다.
5. 환불 도구와 BOB는 현재 둘 다 필요하기 때문에 상태를 서로 동기화합니다. BOB에는 UI, 회계 보고서 및 일반적으로 쉽게 전송할 수 없는 많은 데이터가 있으므로 환불 도구로 완전히 전환할 준비가 되지 않았습니다. 의자 XNUMX개에 앉아야 합니다.
6. 재정화 요청이 사라집니다.

결과적으로 우리는 모든 것이 시작된 이벤트 버스인 Kafka에서 일종의 이벤트 버스를 만들었습니다. 만세, 이제 단일 실패 지점(풍자)이 생겼습니다.

장점과 단점은 꽤 분명합니다. 우리는 버스를 만들었고 이는 이제 모든 서비스가 버스에 의존한다는 것을 의미합니다. 이는 설계를 단순화하지만 시스템에 단일 실패 지점을 도입합니다. Kafka가 충돌하고 프로세스가 중지됩니다.

이벤트 중심 API란?

이 질문에 대한 좋은 대답은 Martin Fowler의 보고서(GOTO 2017)에 있습니다. "이벤트 중심 아키텍처의 다양한 의미".

간략하게 우리가 한 일:

1. 다음을 통해 모든 비동기 교환을 마무리합니다. 이벤트 저장. 관심 있는 모든 소비자에게 네트워크를 통해 상태 변경에 대해 알리는 대신 중앙 저장소에 상태 변경에 대한 이벤트를 작성하고 해당 주제에 관심이 있는 소비자는 거기에 나타나는 모든 내용을 읽습니다.
2. 이 경우 이벤트는 알림(알림) 어딘가에 뭔가가 바뀌었다는 것입니다. 예를 들어 주문 상태가 변경되었습니다. 알림에 포함되지 않은 상태 변경에 수반되는 일부 데이터에 관심이 있는 소비자는 상태를 직접 확인할 수 있습니다.
3. 최대 옵션은 본격적인 이벤트 소싱이며, 국가 이전, 여기에는 처리에 필요한 모든 정보가 포함되어 있습니다. 즉, 어디서 왔는지, 어떤 상태로 이동했는지, 데이터가 정확히 어떻게 변경되었는지 등이 있습니다. 유일한 질문은 실행 가능성과 저장할 수 있는 정보의 양입니다.

환불 도구 출시의 일환으로 우리는 세 번째 옵션을 사용했습니다. 자세한 정보를 추출할 필요가 없기 때문에 이벤트 처리가 단순화되었으며, 각각의 새로운 이벤트가 소비자로부터 명확한 가져오기 요청을 대량으로 생성하는 시나리오도 제거되었습니다.

환불 도구 서비스 로드되지 않음, 그래서 Kafka에는 필요성보다 펜의 맛이 더 많습니다. 환불 서비스가 고부하 프로젝트가 된다면 사업이 기뻐할 것 같지는 않습니다.

있는 그대로 비동기 교환

비동기 교환의 경우 PHP 부서에서는 일반적으로 RabbitMQ를 사용합니다. 우리는 요청에 대한 데이터를 수집하여 대기열에 넣었고, 동일한 서비스의 소비자는 이를 읽고 보냈습니다(또는 보내지 않았습니다). API 자체의 경우 Lamoda는 Swagger를 적극적으로 사용합니다. 우리는 API를 설계하고 이를 Swagger로 설명하며 클라이언트 및 서버 코드를 생성합니다. 또한 약간 향상된 JSON RPC 2.0을 사용합니다.

일부 장소에서는 ESB 버스가 사용되고 일부는 activeMQ에서 실행되지만 일반적으로 RabbitMQ - 표준.

비동기 교환 예정

이벤트 버스를 통한 교환을 설계할 때 비유를 추적할 수 있습니다. 마찬가지로 이벤트 구조 설명을 통해 향후 데이터 교환을 설명합니다. yaml 형식에서는 코드 생성을 직접 수행해야 했으며 생성기는 사양에 따라 DTO를 생성하고 클라이언트와 서버에 이를 사용하도록 가르칩니다. 세대는 두 가지 언어로 진행됩니다 - 골랑과 PHP. 이는 라이브러리의 일관성을 유지하는 데 도움이 됩니다. 생성기는 golang으로 작성되었으므로 gogi라는 이름이 붙었습니다.

Kafka의 이벤트 소싱은 일반적인 것입니다. Kafka Confluent의 주요 엔터프라이즈 버전에는 솔루션이 있습니다. 나카디, 도메인 형제 Zalando의 솔루션입니다. 우리의 바닐라 카프카로 시작하게 된 동기 - 이는 우리가 솔루션을 모든 곳에서 사용할지 여부를 최종적으로 결정할 때까지 솔루션을 무료로 남겨두고 조작 및 개선을 위한 여지를 남겨두는 것을 의미합니다. JSON RPC 2.0, 두 가지 언어에 대한 생성기 및 그 밖의 내용을 살펴 보겠습니다.

이렇게 행복한 경우에도 대략 비슷한 사업이 있는데, 대략 비슷한 솔루션을 만든 Zalando를 효과적으로 활용하지 못한다는 것이 아이러니합니다.

출시 시 아키텍처 패턴은 다음과 같습니다. Kafka에서 직접 읽지만 이벤트 버스를 통해서만 씁니다. Kafka에는 브로커, 밸런서 등 읽을 준비가 많이 되어 있으며 수평 확장을 위한 준비가 어느 정도 준비되어 있으므로 이를 유지하고 싶었습니다. 우리는 하나의 게이트웨이(이벤트 버스)를 통해 녹음을 완료하고 싶었고 그 이유는 다음과 같습니다.

이벤트 버스

아니면 이벤트 버스. 이것은 몇 가지 중요한 역할을 수행하는 상태 비저장 http 게이트웨이입니다.

• 검증 생성 — 이벤트가 우리의 사양을 충족하는지 확인합니다.
• 이벤트 마스터 시스템즉, 이것은 어떤 구조가 유효한 것으로 간주되는지에 대한 질문에 답하는 회사의 주요이자 유일한 시스템입니다. 유효성 검사에는 단순히 콘텐츠를 엄격하게 지정하기 위한 데이터 유형과 열거형이 포함됩니다.
• 해시 함수 샤딩의 경우 - Kafka 메시지 구조는 키-값이며 키 해시를 사용하여 어디에 넣을지 계산됩니다.

우리는 간소화된 프로세스를 갖춘 대기업에서 일하고 있습니다. 왜 뭔가를 바꾸나요? 이것은 실험이다, 우리는 여러 가지 이점을 얻을 것으로 기대합니다.

1:n+1 교환(일대다)

Kafka를 사용하면 새로운 소비자를 API에 매우 쉽게 연결할 수 있습니다.

여러 시스템(및 일부 새로운 시스템)에서 동시에 최신 상태를 유지해야 하는 디렉토리가 있다고 가정해 보겠습니다. 이전에는 set-API를 구현하는 번들을 개발했으며 마스터 시스템에 소비자 주소가 통보되었습니다. 이제 마스터 시스템은 주제에 대한 업데이트를 보내고 관심 있는 모든 사람이 이를 읽습니다. 새로운 시스템이 나타났습니다. 주제에 등록했습니다. 예, 번들도 있지만 더 간단합니다.

BOB의 일부인 환불 도구의 경우 Kafka를 통해 동기화를 유지하는 것이 편리합니다. 지불에는 돈이 반환되었다고 표시됩니다. BOB, RT가 이를 발견하고 상태를 변경했으며 Fiscalization Service가 이를 발견하고 수표를 발행했습니다.

우리는 고객에게 주문/반품에 관한 소식을 알리는 통합 알림 서비스를 만들 계획이 있습니다. 이제 이 책임은 시스템 간에 분산됩니다. Kafka에서 관련 정보를 포착하고 이에 응답하도록 알림 서비스를 교육하는 것만으로도 충분합니다(그리고 다른 시스템에서는 이러한 알림을 비활성화합니다). 새로운 직접 교환은 필요하지 않습니다.

데이터 중심

시스템 간 정보는 투명해집니다. 어떤 "피묻은 기업"을 갖고 있든, 백로그가 얼마나 많든 상관없습니다. Lamoda에는 시스템에서 데이터를 수집하여 비즈니스 및 지능형 시스템 모두에 재사용 가능한 형식으로 변환하는 데이터 분석 부서가 있습니다. Kafka를 사용하면 많은 데이터를 신속하게 제공하고 해당 정보 흐름을 최신 상태로 유지할 수 있습니다.

복제 로그

RabbitMQ처럼 메시지를 읽은 후에도 메시지가 사라지지 않습니다. 이벤트에 처리하기에 충분한 정보가 포함되어 있으면 객체에 대한 최근 변경 내역이 있으며, 원하는 경우 이러한 변경 사항을 적용할 수 있습니다.

복제 로그의 저장 기간은 이 주제에 대한 쓰기 강도에 따라 달라지며 Kafka를 사용하면 저장 시간 및 데이터 볼륨에 대한 제한을 유연하게 설정할 수 있습니다. 집중적인 주제의 경우, 단기적으로 작동하지 않는 경우에도 정보가 사라지기 전에 모든 소비자가 해당 정보를 읽을 시간을 갖는 것이 중요합니다. 일반적으로 다음에 대한 데이터를 저장할 수 있습니다. 일 단위, 지원하기에 충분합니다.

다음으로, Kafka에 익숙하지 않은 사람들을 위해 문서에 대해 조금 다시 설명합니다. (그림도 문서에서 가져온 것입니다.)

AMQP에는 대기열이 있습니다. 소비자를 위해 대기열에 메시지를 씁니다. 일반적으로 하나의 대기열은 동일한 비즈니스 논리를 사용하는 하나의 시스템에서 처리됩니다. 여러 시스템에 알려야 하는 경우 애플리케이션에 여러 대기열에 쓰도록 지시하거나 대기열 자체를 복제하는 팬아웃 메커니즘을 사용하여 교환을 구성할 수 있습니다.

Kafka도 비슷한 추상화를 가지고 있습니다. 화제, 메시지를 작성하지만 읽은 후에도 사라지지 않습니다. 기본적으로 Kafka에 연결하면 모든 메시지를 수신하고 중단한 부분을 저장할 수 있는 옵션이 제공됩니다. 즉, 순차적으로 읽으면 메시지를 읽은 것으로 표시하지 않고 계속 읽을 수 있는 ID를 저장합니다. 설정한 ID를 오프셋이라고 하며 메커니즘은 커밋 오프셋입니다.

따라서, 다른 로직이 구현될 수 있다. 예를 들어, 다양한 국가에 대해 4개의 인스턴스에 BOB가 있습니다. Lamoda는 러시아, 카자흐스탄, 우크라이나, 벨로루시에 있습니다. 별도로 배포되므로 구성과 자체 비즈니스 로직이 약간 다릅니다. 우리는 그것이 어느 국가를 가리키는지 메시지에 표시합니다. 각 국가의 각 BOB 소비자는 서로 다른 groupId로 읽고 메시지가 적용되지 않으면 건너뜁니다. 즉시 오프셋 +1을 커밋합니다. 동일한 주제를 결제 서비스에서 읽는 경우 별도의 그룹으로 읽으므로 오프셋이 교차하지 않습니다.

이벤트 요구사항:

• 데이터 완전성. 이벤트가 처리될 수 있을 만큼 충분한 데이터를 갖고 싶습니다.

• 무결성 우리는 이벤트가 일관성이 있고 처리할 수 있는지 확인하는 작업을 Events-bus에 위임합니다.
• 순서가 중요합니다. 반품의 경우 역사를 가지고 작업을 해야 합니다. 알림의 경우 순서는 중요하지 않습니다. 동종 알림인 경우 어떤 순서가 먼저 도착했는지에 관계없이 이메일은 동일합니다. 환불의 경우 명확한 절차가 있습니다. 주문을 변경하면 예외가 발생하고 환불이 생성되거나 처리되지 않으며 결국 다른 상태가 됩니다.
• 일관성. 상점이 있고 이제 API 대신 이벤트를 만듭니다. 새로운 이벤트와 기존 이벤트의 변경 사항에 대한 정보를 빠르고 저렴하게 서비스에 전달할 수 있는 방법이 필요합니다. 이는 별도의 Git 저장소 및 코드 생성기의 공통 사양을 통해 달성됩니다. 따라서 서로 다른 서비스의 클라이언트와 서버가 조정됩니다.

라모다의 카프카

세 가지 Kafka 설치가 있습니다.

1. 로그;
2. 연구개발
3. 이벤트 버스.

오늘 우리는 마지막 요점에 대해서만 이야기하고 있습니다. 이벤트 버스에는 3개의 브로커(서버)와 27개의 토픽만 설치되어 있어 대규모 설치가 없습니다. 원칙적으로 하나의 주제는 하나의 프로세스입니다. 그러나 이것은 미묘한 점이므로 지금부터 다루겠습니다.

위는 rps 그래프입니다. 환불 프로세스는 청록색 선(예, X축)으로 표시되어 있으며, 분홍색 선은 콘텐츠 업데이트 프로세스입니다.

Lamoda 카탈로그에는 수백만 개의 제품이 포함되어 있으며 데이터는 항상 업데이트됩니다. 일부 컬렉션은 유행에 뒤떨어지고, 이를 대체하기 위해 새로운 컬렉션이 출시되며, 새로운 모델이 카탈로그에 지속적으로 등장합니다. 우리는 내일 고객에게 무엇이 흥미로울지 예측하려고 노력하므로 끊임없이 새로운 것을 구입하고 사진을 찍고 진열장을 업데이트합니다.

분홍색 피크는 제품 업데이트, 즉 제품의 변경 사항입니다. 남자들이 사진을 찍고, 사진을 찍고, 또 찍는 모습이 보이네요! — 이벤트 팩을 로드했습니다.

Lamoda 이벤트 사용 사례

우리는 다음 작업을 위해 구성된 아키텍처를 사용합니다.

• 반품 상태 추적: 모든 관련 시스템의 클릭 유도 문구 및 상태 추적. 결제, 상태, 재정화, 알림. 여기에서 우리는 접근 방식을 테스트하고, 도구를 만들고, 모든 버그를 수집하고, 문서를 작성하고, 동료들에게 사용 방법을 알려주었습니다.
• 제품 카드 업데이트 중: 구성, 메타데이터, 특성. 한 시스템은 읽고(표시됨) 여러 시스템은 씁니다.
• 이메일, 푸시 및 SMS: 주문이 접수되었습니다, 주문이 도착했습니다, 반품이 접수되었습니다 등, 그 수가 많습니다.
• 재고, 창고 리뉴얼 — 품목의 정량적 업데이트, 숫자만 포함: 창고 도착, 반품. 상품 예약과 관련된 모든 시스템은 최신 데이터로 작동해야 합니다. 현재 재고 업데이트 시스템은 매우 복잡하므로 Kafka에서는 이를 단순화할 예정입니다.
• 데이터 분석 (R&D 부서), ML 도구, 분석, 통계. 우리는 정보가 투명하기를 원합니다. Kafka는 이에 매우 적합합니다.

이제 지난 XNUMX개월 동안 발생한 큰 변화와 흥미로운 발견에 대한 더 흥미로운 부분입니다.

디자인 문제

예를 들어 전체 전달 프로세스를 Kafka로 전송하는 등 새로운 작업을 수행하고 싶다고 가정해 보겠습니다. 이제 프로세스의 일부가 BOB의 주문 처리에서 구현됩니다. 주문을 배송 서비스로 이전하고 중간 창고로 이동하는 등의 이면에는 상태 모델이 있습니다. 전체 단일체(심지어 XNUMX개 포함)와 전달 전용 API가 많이 있습니다. 그들은 배달에 대해 훨씬 더 많이 알고 있습니다.

비슷한 영역인 것 같지만 BOB의 주문 처리와 배송 시스템의 상태는 다릅니다. 예를 들어, 일부 택배 서비스는 중간 상태를 보내지 않고 최종 상태인 "배달됨" 또는 "분실"만 보냅니다. 반대로 다른 사람들은 상품 이동에 대해 매우 자세히 보고합니다. 모든 사람은 자신만의 확인 규칙을 가지고 있습니다. 어떤 경우에는 이메일이 유효하므로 처리된다는 의미입니다. 다른 사람들에게는 유효하지 않지만 연락 가능한 전화 번호가 있기 때문에 주문은 계속 처리되며 누군가는 그러한 주문이 전혀 처리되지 않을 것이라고 말할 것입니다.

데이터 스트림

Kafka의 경우 데이터 흐름을 구성하는 문제가 발생합니다. 이 작업에는 여러 가지 사항을 기반으로 전략을 선택하는 작업이 포함되며, 이를 모두 살펴보겠습니다.

한 주제에서요, 아니면 다른 주제에서요?

이벤트 사양이 있습니다. BOB에서는 이러한 주문이 배송되어야 함을 기록하고 주문 번호, 구성, 일부 SKU 및 바코드 등을 표시합니다. 상품이 창고에 도착하면 배송 상태, 타임스탬프 및 필요한 모든 정보를 받을 수 있습니다. 하지만 우리는 BOB에서 이 데이터에 대한 업데이트를 받고 싶습니다. 배송에서 데이터를 받는 역과정이 있습니다. 이것도 같은 이벤트인가요? 아니면 자체 주제에 맞는 별도의 교환입니까?

아마도 그들은 매우 유사할 것이며 하나의 주제를 만들려는 유혹은 근거가 없습니다. 왜냐하면 별도의 주제는 별도의 소비자, 별도의 구성, 이 모든 것에 대한 별도의 생성을 의미하기 때문입니다. 그러나 사실은 아닙니다.

새로운 분야 또는 새로운 이벤트?

하지만 동일한 이벤트를 사용하면 또 다른 문제가 발생합니다. 예를 들어 모든 전달 시스템이 BOB가 생성할 수 있는 종류의 DTO를 생성할 수 있는 것은 아닙니다. 우리는 그들에게 ID를 보냈지만 그들은 필요하지 않기 때문에 저장하지 않았고, 이벤트 버스 프로세스를 시작한다는 관점에서 이 필드는 필수입니다.

이 필드가 필수라는 이벤트 버스 규칙을 도입하면 BOB 또는 시작 이벤트 핸들러에서 추가 유효성 검사 규칙을 설정해야 합니다. 유효성 검사가 서비스 전반에 걸쳐 확산되기 시작합니다. 이는 그리 편리하지 않습니다.

또 다른 문제는 점진적인 개발에 대한 유혹입니다. 이벤트에 뭔가를 추가해야 한다고 하는데, 생각해보면 별도의 이벤트였어야 했을지도 모르겠습니다. 그러나 우리 계획에서는 별도의 이벤트가 별도의 주제입니다. 별도의 주제는 위에서 설명한 전체 프로세스입니다. 개발자는 JSON 스키마에 다른 필드를 추가하고 다시 생성하고 싶은 유혹을 받습니다.

환불의 경우 반년 만에 이벤트 행사에 도착했습니다. 환불 업데이트라는 메타 이벤트가 하나 있었는데, 여기에는 이 업데이트가 실제로 무엇인지 설명하는 유형 필드가 있었습니다. 이로 인해 우리는 이 유형으로 이 이벤트를 검증하는 방법을 알려주는 검증자가 있는 "훌륭한" 스위치를 갖게 되었습니다.

이벤트 버전 관리

Kafka에서 메시지의 유효성을 검사하려면 다음을 사용할 수 있습니다. 아 브로, 그러나 즉시 누워서 Confluent를 사용해야했습니다. 우리의 경우 버전 관리에 주의해야 합니다. 모델이 "남았기" 때문에 복제 로그에서 메시지를 다시 읽는 것이 항상 가능하지는 않습니다. 기본적으로 모델이 이전 버전과 호환되도록 버전을 빌드하는 것으로 나타났습니다. 예를 들어 필드를 일시적으로 선택 사항으로 만듭니다. 차이가 너무 심하면 새 주제를 쓰기 시작하고 고객이 이전 주제를 다 읽은 후에 고객을 이전합니다.

파티션 읽기 순서 보장

Kafka 내부의 주제는 파티션으로 나뉩니다. 이는 엔터티와 거래소를 설계하는 동안에는 그다지 중요하지 않지만 이를 소비하고 확장하는 방법을 결정할 때는 중요합니다.

일반적인 경우에는 Kafka에서 하나의 주제를 작성합니다. 기본적으로 하나의 파티션이 사용되며 이 주제의 모든 메시지가 해당 파티션으로 이동됩니다. 결과적으로 소비자는 이러한 메시지를 순차적으로 읽습니다. 이제 서로 다른 두 소비자가 메시지를 읽을 수 있도록 시스템을 확장해야 한다고 가정해 보겠습니다. 예를 들어 SMS를 보내는 경우 Kafka에 추가 파티션을 만들도록 지시하면 Kafka는 메시지를 두 부분(여기서 절반, 여기에서 절반)으로 분할하기 시작합니다.

카프카는 그것들을 어떻게 나누나요? 각 메시지에는 본문(JSON이 저장됨)과 키가 있습니다. 이 키에 해시 함수를 첨부하면 메시지가 어느 파티션에 들어갈지 결정됩니다.

환불의 경우 이것이 중요합니다. 두 개의 파티션을 사용하는 경우 병렬 소비자가 첫 번째 이벤트보다 두 번째 이벤트를 처리할 가능성이 있어 문제가 발생할 수 있습니다. 해시 함수는 동일한 키를 가진 메시지가 동일한 파티션에 있도록 보장합니다.

이벤트와 명령

이것은 우리가 직면한 또 다른 문제입니다. 이벤트는 특정 이벤트입니다. 예를 들어 항목이 취소되었거나 환불이 발생한 등 어딘가에서 어떤 일이 발생했다고 말합니다(something_happened). 누군가 이러한 이벤트를 듣는 경우 "item cancelled"에 따라 환불 엔터티가 생성되고 "refund failed"가 설정 어딘가에 기록됩니다.

그러나 일반적으로 이벤트를 디자인할 때 이벤트를 헛되이 작성하고 싶지는 않습니다. 누군가가 이벤트를 읽을 것이라는 사실에 의존합니다. Something_happened(item_canceled, Refund_refunded)가 아닌, Something_should_be_done을 쓰고 싶은 유혹이 큽니다. 예를 들어, 상품을 반품할 준비가 되었습니다.

한편으로는 이벤트가 어떻게 사용될 것인지 제안합니다. 반면에 일반적인 이벤트 이름처럼 들리지는 않습니다. 게다가 여기에서 do_something 명령까지 멀지 않습니다. 하지만 누군가가 이 이벤트를 읽었다는 보장은 없습니다. 그리고 만약 당신이 그것을 읽으면, 당신은 그것을 성공적으로 읽은 것입니다. 그리고 만약 당신이 그것을 성공적으로 읽었다면 당신은 뭔가를 했다는 것이고, 그 뭔가는 성공한 것입니다. 이벤트가 do_something이 되는 순간 피드백이 필요하게 되는데 그게 문제가 됩니다.

RabbitMQ의 비동기 교환에서 메시지를 읽을 때 http로 이동하면 최소한 메시지가 수신되었다는 응답을 받게 됩니다. 카프카에 글을 쓰다 보면 카프카에 쓴 메시지가 있는데 어떻게 처리됐는지 전혀 알 수 없습니다.

따라서 우리의 경우에는 응답 이벤트를 도입하고 모니터링을 설정하여 너무 많은 이벤트가 전송되면 이 시간이 지나면 동일한 수의 응답 이벤트가 도착해야 했습니다. 이것이 일어나지 않으면 뭔가 잘못된 것 같습니다. 예를 들어, "item_ready_to_refund" 이벤트를 전송하면 환불이 생성되고 금액이 클라이언트에 반환되며 "money_refunded" 이벤트가 우리에게 전송될 것으로 예상됩니다. 하지만 이는 확실하지 않아 모니터링이 필요하다.

뉘앙스

상당히 명백한 문제가 있습니다. 주제를 순차적으로 읽었는데 잘못된 메시지가 있으면 소비자가 추락하고 더 이상 진행되지 않습니다. 당신은 필요 모든 소비자를 중지, 읽기를 계속하려면 오프셋을 더 커밋하세요.

우리는 그것에 대해 알고 있었고, 그것을 믿었지만, 그런 일이 일어났습니다. 그리고 이는 이벤트 버스의 관점에서는 이벤트가 유효하고 애플리케이션 유효성 검사기의 관점에서는 이벤트가 유효했지만 PostgreSQL의 관점에서는 유효하지 않았기 때문에 발생했습니다. UNSIGNED INT가 있는 MySQL, 새로 작성된 시스템에는 INT만 있는 PostgreSQL이 있었습니다. 그의 사이즈는 조금 작아서 이드도 맞지 않았다. Symfony는 예외적으로 사망했습니다. 물론 우리는 예외에 의존하고 이 오프셋을 커밋하려고 했기 때문에 예외를 포착했지만 그 전에는 메시지가 성공적으로 처리되지 않았기 때문에 문제 카운터를 늘리고 싶었습니다. 이 프로젝트의 카운터도 데이터베이스에 있으며 Symfony는 이미 데이터베이스와의 통신을 종료했으며 두 번째 예외로 인해 오프셋을 커밋할 기회도 없이 전체 프로세스가 종료되었습니다.

서비스는 한동안 중단되었습니다. 다행스럽게도 Kafka를 사용하면 메시지가 남아 있기 때문에 그렇게 나쁘지 않습니다. 작업이 복원되면 읽기를 완료할 수 있습니다. 편안해요.

Kafka에는 도구를 통해 임의의 오프셋을 설정할 수 있는 기능이 있습니다. 그러나 이렇게 하려면 모든 소비자를 중지해야 합니다. 우리의 경우 소비자, 재배포가 없는 별도의 릴리스를 준비합니다. 그런 다음 Kafka에서 도구를 통해 오프셋을 이동할 수 있으며 메시지가 전달됩니다.

또 다른 뉘앙스 - 복제 로그 대 rdkafka.so - 우리 프로젝트의 세부 사항과 관련이 있습니다. 우리는 PHP를 사용하며 PHP에서는 원칙적으로 모든 라이브러리가 rdkafka.so 저장소를 통해 Kafka와 통신하며 일종의 래퍼가 있습니다. 어쩌면 이것은 우리 개인적인 어려움일지도 모르지만, 우리가 이미 읽은 부분을 단순히 다시 읽는 것은 그리 쉬운 일이 아니라는 것이 밝혀졌습니다. 일반적으로 소프트웨어 문제가있었습니다.

파티션 작업의 세부 사항으로 돌아가서 문서에 바로 기록되어 있습니다. 소비자 >= 주제 파티션. 그러나 나는 내가 원했던 것보다 훨씬 늦게 이것에 대해 알게되었습니다. 확장하고 소비자가 두 명인 경우 최소한 두 개의 파티션이 필요합니다. 즉, 20만 개의 메시지가 누적된 하나의 파티션이 있고 새로 만든 경우 메시지 수가 곧 균등해지지 않습니다. 따라서 두 개의 병렬 소비자를 가지려면 파티션을 처리해야 합니다.

모니터링

우리가 모니터링하는 방식을 보면 기존 접근 방식에 어떤 문제가 있는지 더욱 명확해질 것이라고 생각합니다.

예를 들어, 데이터베이스에서 최근 상태가 변경된 제품 수를 계산하고 이에 따라 이러한 변경 사항을 기반으로 이벤트가 발생해야 하며 이 숫자를 모니터링 시스템에 보냅니다. 그런 다음 Kafka에서 실제로 기록된 이벤트 수인 두 번째 숫자를 얻습니다. 분명히, 이 두 숫자의 차이는 항상 XNUMX이어야 합니다.

또한 생산자의 상태, 이벤트 버스가 메시지를 수신했는지 여부, 소비자의 상태를 모니터링해야 합니다. 예를 들어, 아래 차트에서 환불 도구는 잘 작동하지만 BOB에는 분명히 몇 가지 문제(파란색 정점)가 있습니다.

나는 이미 소비자 그룹 지연에 대해 언급했습니다. 대략적으로 말하면 읽지 않은 메시지 수입니다. 일반적으로 우리 소비자는 빠르게 일하므로 지연은 대개 0이지만 때로는 단기적인 피크가 있을 수 있습니다. Kafka는 이 작업을 즉시 수행할 수 있지만 특정 간격을 설정해야 합니다.

프로젝트가 있습니다 굴Kafka에 대한 자세한 정보를 제공합니다. 단순히 소비자 그룹 API를 사용하여 이 그룹이 어떻게 수행되고 있는지에 대한 상태를 제공합니다. OK 및 Failed 외에도 경고가 표시되며 소비자가 생산 속도에 대처할 수 없다는 사실을 알 수 있습니다. 작성된 내용을 교정할 시간이 없습니다. 이 시스템은 매우 스마트하고 사용하기 쉽습니다.

API 응답은 다음과 같습니다. 다음은 bob-live-fifa 그룹, return.update.v1 파티션, 상태 OK, 지연 0 - 마지막 최종 오프셋 등입니다.

모니터링 업데이트_at SLA(중단) 나는 이미 언급했다. 예를 들어, 상품이 반품 준비 상태로 변경되었습니다. 우리는 Cron을 설치합니다. 이는 5분 내에 이 개체가 환불되지 않으면(우리는 결제 시스템을 통해 매우 빠르게 돈을 반환함) 확실히 문제가 발생한 것이며 이는 확실히 지원이 필요한 경우입니다. 따라서 우리는 그러한 내용을 읽는 Cron을 사용하고 0보다 크면 경고를 보냅니다.

요약하자면, 이벤트를 사용하는 것은 다음과 같은 경우에 편리합니다.:

• 여러 시스템에서 정보가 필요합니다.
• 처리 결과는 중요하지 않습니다.
• 행사나 작은 행사가 거의 없습니다.

기사에는 Kafka의 비동기 API라는 매우 구체적인 주제가 있는 것 같지만 이와 관련하여 한 번에 많은 것을 추천하고 싶습니다.
첫째, 다음 HighLoad ++ XNUMX월까지 기다려야 합니다. XNUMX월에는 상트페테르부르크 버전이 나올 예정이며, XNUMX월에는 노보시비르스크의 높은 부하에 대해 이야기하겠습니다.
둘째, 보고서 작성자인 Sergei Zaika는 지식 관리에 관한 새로운 컨퍼런스의 프로그램 위원회 회원입니다. 지식컨퍼런스. 이 컨퍼런스는 26월 XNUMX일 하루 동안 진행되지만 프로그램은 매우 강렬합니다.
그리고 XNUMX월이겠지 PHP 러시아 и RIT++ (DevOpsConf 포함) - 거기에서 주제를 제안하고, 경험에 대해 이야기하고, 채워진 원뿔에 대해 불평할 수도 있습니다.

출처 : habr.com