"내 입장에서 걷기" - 잠깐, 표시가 되어 있나요?

2019년부터 러시아에는 의무 라벨링에 관한 법률이 제정되었습니다. 이 법은 모든 상품 그룹에 적용되지 않으며, 상품 그룹에 대한 의무 표시의 발효일이 다릅니다. 의무표시 대상 품목은 담배, 신발, 의약품이 우선이고, 향수, 섬유, 우유 등도 추후 추가될 예정이다. 이러한 입법 혁신으로 인해 최종 소비자의 생산부터 구매까지 제품의 전체 라이프 체인을 프로세스의 모든 참여자(국가 자체 및 제품을 판매하는 모든 조직 모두)까지 추적할 수 있는 새로운 IT 솔루션이 개발되었습니다. 필수 라벨링.

X5에서는 라벨이 붙은 상품을 추적하고 주 및 공급업체와 데이터를 교환하는 시스템을 "Marcus"라고 합니다. 어떻게, 누가 개발했는지, 기술스택은 무엇인지, 우리가 자랑스러워할 만한 이유가 있는지 순서대로 말씀드리겠습니다.

실제 고부하

"Marcus"는 많은 문제를 해결합니다. 그 중 가장 중요한 문제는 X5 정보 시스템과 라벨링된 제품에 대한 상태 정보 시스템(GIS MP) 간의 통합 상호작용으로 라벨링된 제품의 이동을 추적하는 것입니다. 또한 플랫폼은 당사가 수신한 모든 라벨링 코드와 개체 간 이러한 코드 이동의 전체 내역을 저장하고 라벨링된 제품의 등급 재지정을 방지하는 데 도움이 됩니다. 첫 번째 라벨 제품 그룹에 포함된 담배 제품의 예를 사용하면, 단 한 트럭 분량의 담배에는 약 600갑이 들어 있으며 각 담배에는 고유한 코드가 있습니다. 그리고 우리 시스템의 임무는 창고와 매장 간 각 팩의 이동에 대한 합법성을 추적하고 확인하며 궁극적으로 최종 구매자에게 판매가 허용되는지 확인하는 것입니다. 그리고 우리는 시간당 약 000건의 현금 거래를 기록하고, 각 팩이 어떻게 매장에 들어왔는지도 기록해야 합니다. 따라서 물체 간의 모든 움직임을 고려하면 연간 수백억 건의 기록이 예상됩니다.

M팀

Marcus는 X5 내의 프로젝트로 간주된다는 사실에도 불구하고 제품 접근 방식을 사용하여 구현되고 있습니다. 팀은 Scrum에 따라 작업합니다. 프로젝트는 지난 여름에 시작되었지만 첫 번째 결과는 16월에야 나왔습니다. 우리 팀은 완전히 구성되었고 시스템 아키텍처가 개발되었으며 장비를 구입했습니다. 이제 팀은 XNUMX명으로 구성되어 있으며 그 중 XNUMX명은 백엔드 및 프런트엔드 개발에 참여하고 있으며 그 중 XNUMX명은 시스템 분석에 참여하고 있습니다. 수동, 로드, 자동 테스트 및 제품 유지 관리에 XNUMX명의 인력이 더 참여하고 있습니다. 또한 SRE 전문가도 있습니다.

우리 팀에서는 개발자들만이 코드를 작성하는 것이 아니라 거의 모든 사람들이 자동 테스트, 로드 스크립트 및 자동화 스크립트를 프로그래밍하고 작성하는 방법을 알고 있습니다. 제품 지원에도 높은 수준의 자동화가 필요하기 때문에 우리는 이에 특별한 주의를 기울이고 있습니다. 우리는 항상 프로그래밍 경험이 없는 동료들에게 조언과 도움을 주고자 노력하며, 그들에게 작은 작업을 제공합니다.

코로나바이러스 팬데믹으로 인해 우리는 팀 전체를 원격 작업으로 전환했으며, 개발 관리를 위한 모든 도구의 가용성, Jira 및 GitLab의 구축된 워크플로 덕분에 이 단계를 쉽게 통과할 수 있었습니다. 원격으로 보낸 몇 달 동안 결과적으로 팀의 생산성은 저하되지 않았으며, 많은 사람들에게 직장에서의 편안함은 증가했지만 누락된 유일한 것은 실시간 커뮤니케이션이었습니다.

원격 팀 회의

원격 근무 중 회의

솔루션의 기술 스택

X5의 표준 저장소 및 CI/CD 도구는 GitLab입니다. 우리는 이를 코드 저장, 지속적인 테스트, 테스트 및 프로덕션 서버 배포에 사용합니다. 또한 개발자가 코드에 적용한 변경 사항을 최소 2명의 동료가 승인해야 하는 경우 코드 검토 방법을 사용합니다. 정적 코드 분석기인 SonarQube와 JaCoCo는 코드를 깨끗하게 유지하고 필요한 수준의 단위 테스트 적용 범위를 보장하는 데 도움이 됩니다. 코드에 대한 모든 변경 사항은 이러한 검사를 거쳐야 합니다. 수동으로 실행되는 모든 테스트 스크립트는 이후에 자동화됩니다.

"Marcus"의 성공적인 비즈니스 프로세스 구현을 위해 우리는 여러 가지 기술적 문제를 각각 순서대로 해결해야 했습니다.

과제 1. 시스템의 수평적 확장성의 필요성

이 문제를 해결하기 위해 우리는 아키텍처에 대한 마이크로서비스 접근 방식을 선택했습니다. 동시에 서비스의 책임 영역을 이해하는 것이 매우 중요했습니다. 우리는 프로세스의 특성을 고려하여 이를 비즈니스 운영으로 나누려고 노력했습니다. 예를 들어, 창고에서의 인수는 빈번하지 않지만 매우 대규모 작업이므로 한 번의 배송으로 600000에 도달하는 승인되는 상품 단위에 대한 정보를 주 규제 기관으로부터 신속하게 얻어야 합니다. , 이 제품을 창고에 수용할 수 있는지 확인하고 창고 자동화 시스템에 필요한 모든 정보를 반환하십시오. 그러나 창고에서의 배송은 훨씬 더 강도가 높지만 동시에 적은 양의 데이터로 운영됩니다.

우리는 모든 서비스를 무상태 기반으로 구현하고 심지어 Kafka 자체 주제라고 부르는 것을 사용하여 내부 작업을 여러 단계로 나누려고 노력합니다. 이는 마이크로서비스가 자신에게 메시지를 보내는 경우입니다. 이를 통해 리소스 집약적인 작업에 대한 로드 균형을 맞추고 제품 유지 관리를 단순화할 수 있습니다. 이에 대한 자세한 내용은 나중에 설명합니다.

우리는 외부 시스템과의 상호 작용을 위한 모듈을 별도의 서비스로 분리하기로 결정했습니다. 이를 통해 비즈니스 기능을 갖춘 서비스에 거의 영향을 주지 않으면서 외부 시스템의 API가 자주 변경되는 문제를 해결할 수 있게 되었습니다.

모든 마이크로서비스는 OpenShift 클러스터에 배포되어 각 마이크로서비스 확장 문제를 해결하고 타사 서비스 검색 도구를 사용하지 않아도 됩니다.

작업 2. 플랫폼 서비스 간 높은 로드와 매우 집중적인 데이터 교환을 유지해야 하는 필요성: 프로젝트 시작 단계에서만 초당 약 600개의 작업이 수행됩니다. 소매점이 우리 플랫폼에 연결되면 이 값이 5000ops/sec로 증가할 것으로 예상됩니다.

이 문제는 Kafka 클러스터를 배포하고 플랫폼의 마이크로서비스 간의 동기식 상호 작용을 거의 완전히 포기함으로써 해결되었습니다. 모든 작업이 비동기식일 수는 없으므로 이를 위해서는 시스템 요구 사항을 매우 신중하게 분석해야 합니다. 동시에 브로커를 통해 이벤트를 전송할 뿐만 아니라 필요한 모든 비즈니스 정보를 메시지로 전송합니다. 따라서 메시지 크기는 수백 킬로바이트에 이를 수 있습니다. Kafka의 메시지 크기 제한은 메시지 크기를 정확하게 예측해야 하며, 필요한 경우 이를 분할하지만 비즈니스 운영과 관련하여 분할은 논리적입니다.
예를 들어, 자동차에 도착한 물품을 상자로 나눕니다. 동기식 작업의 경우 별도의 마이크로서비스가 할당되고 철저한 로드 테스트가 수행됩니다. Kafka를 사용하면 또 다른 과제가 발생합니다. Kafka 통합을 고려하여 서비스 운영을 테스트하면 모든 단위 테스트가 비동기화됩니다. 우리는 Embedded Kafka Broker를 사용하여 자체 유틸리티 메서드를 작성하여 이 문제를 해결했습니다. 이로 인해 개별 메서드에 대한 단위 테스트를 작성할 필요가 없어지지는 않지만 Kafka를 사용하여 복잡한 사례를 테스트하는 것을 선호합니다.

서비스 운영 중 예외가 발생하거나 Kafka 배치 작업 시 TraceId가 손실되지 않도록 추적 로그에 많은 주의를 기울였습니다. 첫 번째 항목에 특별한 문제가 없다면 두 번째 경우에는 일괄 처리와 함께 제공되는 모든 TraceId를 기록하고 하나를 선택하여 추적을 계속해야 합니다. 그러면 원래 TraceId로 검색하면 사용자는 어떤 추적이 계속되었는지 쉽게 알 수 있습니다.

작업 3. 대량의 데이터를 저장해야 하는 필요성: 담배에만 연간 1억 개 이상의 라벨이 X5에 제공됩니다. 지속적이고 빠른 액세스가 필요합니다. 전체적으로 시스템은 이러한 라벨이 부착된 상품의 이동 기록에 대한 약 10억 개의 기록을 처리해야 합니다.

세 번째 문제를 해결하기 위해 NoSQL 데이터베이스 MongoDB가 선택되었습니다. 우리는 5개의 노드로 구성된 샤드를 구축했으며 각 노드에는 3개의 서버로 구성된 복제본 세트가 있습니다. 이를 통해 시스템을 수평으로 확장하고 클러스터에 새 서버를 추가하고 내결함성을 보장할 수 있습니다. 여기서 우리는 수평으로 확장 가능한 마이크로서비스의 사용을 고려하여 mongo 클러스터의 트랜잭션성을 보장하는 또 다른 문제에 직면했습니다. 예를 들어, 당사 시스템의 작업 중 하나는 동일한 라벨 코드를 사용하여 제품을 재판매하려는 시도를 식별하는 것입니다. 여기에서는 계산원의 잘못된 스캔이나 잘못된 조작으로 오버레이가 나타납니다. 우리는 이러한 중복이 처리 중인 하나의 Kafka 배치 내에서와 병렬로 처리되는 두 개의 배치 내에서 모두 발생할 수 있음을 발견했습니다. 따라서 데이터베이스를 쿼리하여 중복을 확인해도 아무 것도 제공되지 않았습니다. 각 마이크로서비스에 대해 이 서비스의 비즈니스 로직을 기반으로 문제를 개별적으로 해결했습니다. 예를 들어 수표의 경우 배치 내부에 수표를 추가하고 삽입 시 중복이 나타나는 것에 대한 별도 처리를 추가했습니다.

사용자의 운영 내역 작업이 가장 중요한 것, 즉 비즈니스 프로세스의 기능에 어떤 식으로든 영향을 미치지 않도록 하기 위해 모든 내역 데이터를 별도의 데이터베이스가 있는 별도의 서비스로 분리했으며, 이는 Kafka를 통해 정보도 수신합니다. . 이러한 방식으로 사용자는 지속적인 작업을 위해 데이터를 처리하는 서비스에 영향을 주지 않고 격리된 서비스로 작업할 수 있습니다.

작업 4: 대기열 재처리 및 모니터링:

분산 시스템에서는 데이터베이스, 대기열, 외부 데이터 소스의 가용성 문제와 오류가 필연적으로 발생합니다. Marcus의 경우 이러한 오류의 원인은 외부 시스템과의 통합입니다. 지정된 시간 초과로 잘못된 응답에 대한 반복 요청을 허용하는 동시에 기본 대기열에서 성공적인 요청 처리를 중단하지 않는 솔루션을 찾아야 했습니다. 이를 위해 소위 "주제 기반 재시도" 개념이 선택되었습니다. 각 기본 주제에 대해 잘못된 메시지가 전송되는 하나 이상의 재시도 주제가 생성되고 동시에 기본 주제의 메시지 처리 지연이 제거됩니다. 상호 작용 방식 -

이러한 체계를 구현하려면 이 솔루션을 Spring과 통합하고 코드 중복을 피하기 위해 다음이 필요했습니다. 웹서핑을 하던 중 Spring BeanPostProccessor를 기반으로 한 유사한 솔루션을 발견했지만 불필요하게 번거로워 보였습니다. 우리 팀은 소비자 생성을 위해 Spring 주기에 통합하고 추가로 Retry Consumer를 추가할 수 있는 더 간단한 솔루션을 만들었습니다. 우리는 Spring 팀에 우리 솔루션의 프로토타입을 제공했습니다. 보시다시피 여기에. 재시도 소비자 수와 각 소비자에 대한 시도 횟수는 비즈니스 프로세스의 요구 사항에 따라 매개 변수를 통해 구성되며 모든 것이 작동하려면 org.springframework.kafka.annotation.KafkaListener 주석을 추가하는 것뿐입니다. 이는 모든 Spring 개발자에게 친숙합니다.

모든 재시도 후에도 메시지를 처리할 수 없으면 Spring DeadLetterPublishingRecoverer를 사용하여 DLT(데드 레터 주제)로 이동합니다. 지원 요청에 따라 우리는 이 기능을 확장하고 DLT, stackTrace, TraceId에 포함된 메시지 및 이에 대한 기타 유용한 정보를 볼 수 있는 별도의 서비스를 만들었습니다. 또한 모든 DLT 주제에 모니터링 및 알림이 추가되었으며, 이제 실제로 DLT 주제에 메시지가 나타나는 것은 결함을 분석하고 수정하는 이유입니다. 이는 매우 편리합니다. 주제 이름을 통해 문제가 발생한 프로세스의 어느 단계에서 즉시 이해하므로 근본 원인 검색 속도가 크게 빨라집니다.

가장 최근에는 원인을 제거(예: 외부 시스템의 기능 복원)하고 분석을 위해 해당 결함을 설정한 후 지원을 사용하여 메시지를 다시 보낼 수 있는 인터페이스를 구현했습니다. 이것이 바로 자체 주제가 유용한 곳입니다. 긴 처리 체인을 다시 시작하지 않으려면 원하는 단계에서 다시 시작할 수 있습니다.

플랫폼 운영

플랫폼은 이미 생산적으로 운영되고 있으며 매일 배송 및 배송을 수행하고 새로운 유통 센터와 매장을 연결합니다. 파일럿의 일환으로 시스템은 "담배" 및 "신발" 제품 그룹과 함께 작동합니다.

우리 팀 전체가 파일럿 수행에 참여하고, 새로운 문제를 분석하고, 로그 개선부터 프로세스 변경에 이르기까지 제품 개선을 위한 제안을 제시합니다.

실수를 반복하지 않기 위해 파일럿 과정에서 발견된 모든 사례는 자동화 테스트에 반영됩니다. 다수의 자동 테스트 및 단위 테스트가 있으면 문자 그대로 몇 시간 내에 회귀 테스트를 수행하고 핫픽스를 설치할 수 있습니다.

이제 우리는 계속해서 플랫폼을 개발하고 개선하며 끊임없이 새로운 도전에 직면하고 있습니다. 관심이 있으시면 다음 기사에서 솔루션에 대해 이야기하겠습니다.

출처 : habr.com