새로운 조건에서 온라인 거래에 빠르게 적응하는 데 도움이 된 것은 무엇입니까?

Привет!

제 이름은 Mikhail이고 Sportmaster 회사의 IT 담당 부국장입니다. 저는 팬데믹 기간 동안 발생한 어려움에 우리가 어떻게 대처했는지에 대한 이야기를 나누고 싶습니다.

새로운 현실의 첫날에는 Sportmaster의 일반적인 오프라인 거래 형식이 정지되었고 주로 고객 주소로의 배송 측면에서 온라인 채널의 부하가 10배 증가했습니다. 단 몇 주 만에 우리는 대규모 오프라인 비즈니스를 온라인 비즈니스로 전환하고 고객의 요구에 맞게 서비스를 조정했습니다.

기본적으로 우리의 부업이었던 것이 우리의 핵심 사업이 되었습니다. 모든 온라인 주문의 중요성이 극도로 증가했습니다. 고객이 회사에 가져온 모든 루블을 저장해야했습니다. 

고객의 요청에 신속하게 대응하기 위해 회사 본사에 컨택센터를 추가로 개설하여 현재 주당 약 285통의 전화를 받을 수 있게 되었습니다. 동시에 우리는 270개 매장을 새로운 비접촉식 안전한 운영 형식으로 전환하여 고객이 주문을 받고 직원이 직업을 유지할 수 있도록 했습니다.

변환 과정에서 우리는 두 가지 주요 문제에 직면했습니다. 첫째, 온라인 리소스의 부하가 크게 증가했습니다(Sergey가 이 문제를 어떻게 처리했는지 알려드릴 것입니다). 둘째, 희귀한(COVID 이전) 작업의 흐름이 여러 번 증가하여 대규모의 신속한 자동화가 필요했습니다. 이 문제를 해결하기 위해 우리는 이전에 주요 지역이었던 지역에서 자원을 신속하게 이전해야 했습니다. Elena가 우리가 이 문제를 어떻게 처리했는지 알려줄 것입니다.

온라인 서비스 운영

온라인 상점 및 마이크로서비스 운영을 담당하는 Kolesnikov Sergey

소매점이 방문자에게 문을 닫기 시작한 순간부터 사용자 수, 애플리케이션에 대한 주문 수, 애플리케이션에 대한 요청 수와 같은 측정 항목의 증가가 기록되기 시작했습니다. 

18월 31일부터 XNUMX월 XNUMX일까지의 주문수온라인 결제 마이크로서비스에 대한 요청 수웹사이트에서 접수된 주문 수

첫 번째 그래프에서는 증가폭이 약 14배, 두 번째 그래프에서는 4배로 증가한 것을 볼 수 있습니다. 우리는 애플리케이션의 응답 시간 측정항목을 가장 잘 나타내는 것으로 간주합니다. 

이 그래프에서 우리는 프론트와 애플리케이션의 반응을 볼 수 있으며, 우리 스스로는 그러한 성장을 눈치채지 못했다고 판단했습니다.

이는 주로 2019년 말에 준비 작업을 시작했기 때문입니다. 이제 우리 서비스는 예약되어 있으며 물리적 서버, 가상화 시스템, 도커 및 서비스 수준에서 내결함성이 보장됩니다. 동시에 우리 서버 리소스의 용량 덕분에 여러 부하를 견딜 수 있습니다.

이 전체 이야기에서 우리에게 도움이 된 주요 도구는 모니터링 시스템이었습니다. 사실, 아주 최근까지 물리적 장비 및 하드웨어 수준에서 비즈니스 지표 수준에 이르기까지 모든 계층에서 지표를 수집할 수 있는 단일 시스템이 없었습니다. 

형식적으로는 사내 모니터링이 있었지만, 원칙적으로는 분산되어 특정 부서의 책임 영역에 있었다. 실제로 사건이 발생했을 때 정확히 무슨 일이 일어났는지에 대한 공통된 이해가 거의 없었고, 의사소통도 없었으며, 이로 인해 문제를 해결하기 위해 이리저리 맴돌며 문제를 찾아 격리하는 경우가 많았습니다.

어느 시점에서 우리는 이것을 견딜 만큼 충분하다고 생각하고 결정했습니다. 전체 그림을 전체적으로 보려면 통일된 시스템이 필요했습니다. 스택에 포함된 주요 기술로는 알림 및 메트릭 스토리지 센터인 Zabbix, 애플리케이션 메트릭을 수집 및 저장하는 Prometheus, 전체 모니터링 시스템의 데이터를 로깅 및 저장하는 Stack ELK, 시각화를 위한 Grafana, Swagger, Docker가 있습니다. 기타 유용하고 친숙한 것들.

동시에 우리는 시장에 나와 있는 기술을 사용할 뿐만 아니라 자체 기술도 개발합니다. 예를 들어, 우리는 시스템을 서로 통합하는 서비스, 즉 지표를 수집하기 위한 일종의 API를 만듭니다. 또한 우리는 UI 테스트를 사용하는 비즈니스 지표 수준에서 자체 모니터링 시스템을 개발하고 있습니다. 또한 팀에 알리는 Telegram의 봇도 있습니다.

또한 우리는 널리 사용되지 않는 일부 좁은 지표에 대한 경고 설정을 포함하여 팀이 독립적으로 지표를 저장하고 작업할 수 있도록 모니터링 시스템에 액세스할 수 있도록 노력하고 있습니다. 

시스템 전반에 걸쳐 우리는 가능한 한 빨리 사고의 사전 대응과 현지화를 위해 노력합니다. 또한 최근 마이크로서비스와 시스템의 수가 크게 증가했고 그에 따라 통합 수도 늘어났습니다. 그리고 통합 수준에서 사고 진단 프로세스를 최적화하는 일환으로 시스템 간 검사를 수행하고 결과를 표시할 수 있는 시스템을 개발하고 있습니다. 이를 통해 시스템 가져오기 및 상호 작용과 관련된 주요 문제를 찾을 수 있습니다. 서로. 

물론, 운영체제 측면에서는 아직 성장하고 발전할 여지가 있고, 이를 위해 적극적으로 노력하고 있습니다. 모니터링 시스템에 대해 자세히 알아볼 수 있습니다. 여기에. 

기술 테스트 

Orlov Sergey, 웹 및 모바일 개발 역량 센터 책임자

오프라인 매장 폐쇄가 시작된 이후 우리는 개발 관점에서 다양한 어려움에 직면했습니다. 우선 부하가 급증합니다. 적절한 조치를 취하지 않으면 시스템에 높은 부하가 가해지면 시스템이 호박처럼 변하거나 성능이 완전히 저하되거나 심지어 기능을 잃을 수도 있다는 것은 분명합니다.

조금 덜 분명한 두 번째 측면은 부하가 높은 시스템을 비즈니스 프로세스의 변화에 ​​맞춰 매우 빠르게 변경해야 한다는 것입니다. 때로는 하루에 여러 번. 많은 회사에는 마케팅 활동이 많으면 시스템을 변경할 필요가 없다는 규칙이 있습니다. 전혀 없습니다. 작동하는 한 그대로 두십시오.

그리고 우리는 본질적으로 끝없는 블랙 프라이데이를 보냈고 그 동안 시스템을 변경해야 했습니다. 그리고 시스템의 모든 오류, 문제 또는 실패는 비즈니스에 막대한 비용을 초래하게 됩니다.

앞으로 우리는 이러한 테스트에 대처할 수 있었고 모든 시스템이 부하를 견디고 쉽게 확장되었으며 글로벌 기술 오류가 발생하지 않았다고 말할 것입니다.

높은 서지 부하를 견딜 수 있는 시스템 능력을 뒷받침하는 네 가지 기둥이 있습니다. 그 중 첫 번째는 바로 위에서 읽은 모니터링입니다. 내장된 모니터링 시스템이 없으면 시스템 병목 현상을 찾는 것이 거의 불가능합니다. 좋은 모니터링 시스템은 집에서 입는 옷과 같아서 편안하고 나에게 꼭 맞아야 합니다.

두 번째 측면은 테스트입니다. 우리는 이 점을 매우 진지하게 생각합니다. 우리는 각 시스템에 대해 클래식 유닛, 통합 테스트, 로드 테스트 및 기타 여러 가지를 작성합니다. 우리는 또한 테스트 전략을 작성하는 동시에 더 이상 수동 점검이 필요하지 않을 정도로 테스트 수준을 높이려고 노력하고 있습니다.

세 번째 기둥은 CI/CD 파이프라인입니다. 애플리케이션 구축, 테스트, 배포 프로세스는 최대한 자동화되어야 하며 수동 개입이 있어서는 안 됩니다. CI/CD 파이프라인에 대한 주제는 꽤 깊어서 간략하게만 다루겠습니다. 각 제품 팀이 역량 센터의 도움을 받아 통과하는 CI/CD 파이프라인 체크리스트가 있다는 점만 언급할 가치가 있습니다.

그리고 체크리스트는 이렇습니다

이런 식으로 많은 목표가 달성됩니다. 이는 릴리스 트레인을 피하고 테스트가 완전히 자동화되고 배포가 원활해지는 수준에서 다양한 테스트의 적용 범위를 달성하기 위한 API 버전 관리 및 기능 토글입니다.

네 번째 기둥은 아키텍처 원칙과 기술 솔루션입니다. 우리는 오랫동안 건축에 관해 많은 이야기를 할 수 있지만, 제가 집중하고 싶은 몇 가지 원칙을 강조하고 싶습니다.

먼저 특정 작업에 특화된 도구를 선택해야 합니다. 예, 당연하게 들리며, 못은 망치로 박아야 하고, 손목시계는 특수 드라이버로 분해해야 한다는 것도 분명합니다. 그러나 우리 시대에는 데이터베이스, 캐시, 프레임워크 등 최대 사용자 세그먼트를 포괄하기 위해 많은 도구가 보편화를 위해 노력하고 있습니다. 예를 들어 MongoDB 데이터베이스를 사용하면 다중 문서 트랜잭션에서 작동하고 Oracle 데이터베이스는 json에서 작동합니다. 그리고 모든 것이 모든 것에 사용될 수 있는 것 같습니다. 그러나 우리가 생산성을 옹호한다면 각 도구의 강점과 약점을 명확하게 이해하고 작업 클래스에 필요한 도구를 사용해야 합니다. 

둘째, 시스템을 설계할 때 각각의 복잡성 증가가 정당화되어야 합니다. 우리는 이것을 항상 염두에 두어야 하며, 낮은 결합의 원리는 모든 사람에게 알려져 있습니다. 특정 서비스 수준, 전체 시스템 수준, 아키텍처 랜드스케이프 수준에서 적용되어야 한다고 생각합니다. 로드 경로를 따라 각 시스템 구성 요소를 수평으로 확장하는 기능도 중요합니다. 이 능력이 있다면 스케일링은 어렵지 않을 것입니다.

기술 솔루션에 관해 우리는 제품 팀에 차세대 워크로드에 대비하여 구현한 새로운 권장 사항, 아이디어 및 솔루션 세트를 준비하도록 요청했습니다.

케시

로컬 및 분산 캐시 선택에 의식적으로 접근할 필요가 있습니다. 때로는 동일한 시스템 내에서 두 가지를 모두 사용하는 것이 합리적입니다. 예를 들어 일부 데이터가 본질적으로 쇼케이스 캐시인 시스템이 있습니다. 즉, 업데이트 소스가 시스템 자체 뒤에 있고 시스템이 변경되지 않습니다. 이 데이터. 이 접근 방식에서는 로컬 카페인 캐시를 사용합니다. 

그리고 시스템이 작동 중에 적극적으로 변경되는 데이터가 있는데 여기서 우리는 이미 Hazelcast와 함께 분산 캐시를 사용하고 있습니다. 이 접근 방식을 통해 우리는 실제로 필요한 곳에 분산 캐시의 이점을 사용할 수 있고, 헤이즐캐스트 클러스터 데이터 없이도 Hazelcast 클러스터 데이터를 순환하는 데 드는 서비스 비용을 최소화할 수 있습니다. 우리는 캐시에 관해 많은 글을 썼습니다. 여기에 и 여기에.

게다가 Hazelcast에서 시리얼라이저를 Kryo로 변경한 것은 우리에게 큰 도움이 되었습니다. 그리고 Hazelcast의 ReplicatedMap에서 IMap + Near Cache로의 전환을 통해 클러스터 전체의 데이터 이동을 최소화할 수 있었습니다. 

약간의 조언: 대량 캐시 무효화의 경우 때로는 두 번째 캐시를 워밍업한 다음 해당 캐시로 전환하는 전술이 적용 가능합니다. 이 접근 방식을 사용하면 메모리 소비가 두 배로 늘어나는 것처럼 보이지만 실제로는 이것이 실행된 시스템에서 메모리 소비가 감소했습니다.

반응성 스택

우리는 꽤 많은 수의 시스템에서 반응성 스택을 사용합니다. 우리의 경우에는 코루틴이 포함된 Webflux 또는 Kotlin입니다. 반응성 스택은 느린 입출력 작업이 예상되는 경우에 특히 좋습니다. 예를 들어 느린 서비스 호출, 파일 시스템 또는 스토리지 시스템 작업 등이 있습니다.

가장 중요한 원칙은 통화 차단을 피하는 것입니다. 반응형 프레임워크에는 내부적으로 실행되는 소수의 라이브 서비스 스레드가 있습니다. JDBC 드라이버 호출과 같은 직접 차단 호출을 부주의하게 허용하면 시스템이 정지될 것입니다. 

오류를 자신만의 런타임 예외로 전환해 보세요. 프로그램 실행의 실제 흐름은 반응형 프레임워크로 전환되고 코드 실행은 비선형이 됩니다. 결과적으로 스택 추적을 사용하여 문제를 진단하는 것은 매우 어렵습니다. 여기서 해결책은 모든 오류에 대해 명확하고 객관적인 런타임 예외를 만드는 것입니다.

탄성 검색

Elasticsearch를 사용할 때 사용하지 않는 데이터를 선택하지 마십시오. 이것은 원칙적으로 매우 간단한 조언이지만 대부분 잊혀지는 것입니다. 한 번에 10개 이상의 레코드를 선택해야 하는 경우 스크롤을 사용해야 합니다. 비유하자면 관계형 데이터베이스의 커서와 비슷합니다. 

꼭 필요한 경우가 아니면 사후 필터를 사용하지 마세요. 기본 샘플에 대용량 데이터가 있는 경우 이 작업을 수행하면 데이터베이스에 큰 부하가 걸립니다. 

해당되는 경우 대량 작업을 사용합니다.

API

API를 설계할 때 전송되는 데이터를 최소화하기 위한 요구 사항을 포함하세요. 이는 특히 전면과 관련하여 사실입니다. 우리가 데이터 센터의 채널을 넘어 우리와 고객을 연결하는 채널을 이미 작업하고 있는 곳이 바로 이 교차점입니다. 사소한 문제가 있어도 트래픽이 너무 많으면 부정적인 사용자 경험이 발생합니다.

그리고 마지막으로, 많은 데이터를 버리지 말고 소비자와 공급자 간의 계약을 명확히 하세요.

조직 변화

Eroshkina Elena, IT 부국장

방역이 일어나고, 온라인 개발 속도를 대폭 높이고 옴니채널 서비스를 도입해야 할 필요성이 대두된 순간, 우리는 이미 조직 변혁을 진행하고 있었습니다. 

우리 구조의 일부는 제품 접근 방식의 원칙과 관행에 따라 업무로 이전되었습니다. 이제 각 제품의 운영과 개발을 담당하는 팀이 구성되었습니다. 이러한 팀의 직원은 100% 참여하고 자신에게 선호하는 것이 무엇인지에 따라 Scrum 또는 Kanban을 사용하여 작업을 구성하고 배포 파이프라인 설정, 기술 관행 구현, 품질 보증 관행 등을 수행합니다.

운 좋게도 우리 제품 팀의 대부분은 온라인 및 옴니채널 서비스 분야에 있었습니다. 이를 통해 효율성 저하 없이 최대한 짧은 시간(말 그대로 이틀 만에)에 원격 작업 모드로 전환할 수 있었습니다. 맞춤형 프로세스를 통해 우리는 새로운 작업 조건에 신속하게 적응하고 새로운 기능을 상당히 빠른 속도로 제공할 수 있었습니다.

또한, 우리는 온라인 비즈니스의 최전선에 있는 팀을 강화할 필요가 있습니다. 그 순간 우리는 내부 자원을 통해서만 이 일을 할 수 있다는 것이 분명해졌습니다. 그리고 50주 만에 약 XNUMX명이 이전에 일하던 지역을 바꾸고 새로운 제품 작업에 참여하게 되었습니다. 

이를 위해서는 특별한 관리 노력이 필요하지 않았습니다. 자체 프로세스 구성, 제품의 기술 개선 및 품질 보증 관행과 함께 팀에게 자체 구성, 즉 관리 자원을 사용하지 않고 자체 생산 프로세스를 관리하도록 가르치기 때문입니다.

우리는 그 순간 필요한 곳에 정확히 관리 자원을 집중할 수 있었습니다. 즉, 비즈니스와의 협력에 집중할 수 있었습니다. 지금 클라이언트에게 중요한 것은 무엇인지, 먼저 구현해야 할 기능은 무엇인지, 처리 능력을 높이기 위해 수행해야 할 작업은 무엇입니까? 주문을 전달하고 처리합니다. 이 모든 것과 명확한 역할 모델 덕분에 이 기간 동안 우리의 생산 가치 흐름에 정말 중요하고 필요한 것을 로드할 수 있었습니다. 

원격 근무와 빠른 변화 속도로 인해 비즈니스 지표가 모든 사람의 참여에 좌우되는 경우 시리즈 "우리가 잘 지내고 있나요? "시리즈의 내부 감정에만 의존할 수는 없다는 것이 분명합니다. 응, 좋은 것 같아.” 생산 과정에 대한 객관적인 지표가 필요합니다. 우리는 이를 보유하고 있으며 제품 팀의 지표에 관심이 있는 모든 사람이 사용할 수 있습니다. 우선 팀 자체, 비즈니스, 하청업체 및 경영진입니다.

10주에 한 번씩 각 팀의 현황을 파악하여 XNUMX분 동안 지표를 분석하고, 생산 프로세스의 병목 현상을 식별하고, 이러한 병목 현상을 제거하기 위해 무엇을 할 수 있는지에 대한 공동 솔루션을 개발합니다. 식별된 문제가 팀의 영향권을 벗어나거나 이미 유사한 문제를 겪었을 수 있는 동료의 전문 지식을 벗어나는 경우 여기에서 즉시 경영진에게 도움을 요청할 수 있습니다.

그러나 우리는 여러 번 가속화하려면(이것이 바로 우리가 설정한 목표임) 여전히 많은 것을 배우고 이를 일상 업무에 구현해야 한다는 것을 알고 있습니다. 현재 우리는 다른 팀과 신제품에 대한 제품 접근 방식을 계속 확장하고 있습니다. 이를 위해 우리는 온라인 방법론 학교라는 새로운 형식을 마스터해야 했습니다.

팀이 프로세스를 구축하고, 커뮤니케이션을 구축하고, 업무 효율성을 향상시키는 데 도움을 주는 방법론자는 본질적으로 변화의 주체입니다. 현재 우리 첫 번째 집단의 졸업생들은 팀과 협력하여 그들이 성공할 수 있도록 돕고 있습니다. 

나는 현재 상황이 아마도 우리 자신이 아직 완전히 인식하지 못한 기회와 전망을 열어주고 있다고 생각합니다. 그러나 지금 우리가 얻고 있는 경험과 실천은 우리가 올바른 개발 경로를 선택했음을 확인시켜 줍니다. 우리는 미래에 이러한 새로운 기회를 놓치지 않을 것이며 Sportmaster가 직면하게 될 도전에 효과적으로 대응할 수 있을 것입니다.

조사 결과

이 어려운 시기에 우리는 소프트웨어 개발의 기반이 되는 주요 원칙을 공식화했는데, 제 생각에는 이 원칙이 이를 다루는 모든 회사에 적용될 것입니다.

사람들. 이것이 모든 것이 달려 있는 것입니다. 직원은 자신의 업무를 즐겨야 하며, 회사의 목표와 자신이 작업하는 제품의 목표를 이해해야 합니다. 물론 전문적으로 발전할 수도 있습니다. 

Технология. 회사는 기술 스택을 활용하고 실제로 필요한 역량을 구축하는 데 성숙한 접근 방식을 취해야 합니다. 그것은 매우 간단하고 분명하게 들립니다. 그리고 매우 자주 무시됩니다.

프로세스. 파트너로서 비즈니스와 협력하려면 제품 팀과 역량 센터의 작업을 적절하게 구성하고 비즈니스와의 상호 작용을 구축하는 것이 중요합니다.

일반적으로 이것이 우리가 살아남은 방법과 거의 같습니다. 이마에 찰칵 소리가 나면서 우리 시대의 주요 논제가 다시 한 번 확인되었습니다.

많은 매장과 운영하는 도시가 있는 대규모 오프라인 비즈니스이더라도 온라인 비즈니스를 발전시키세요. 이는 단순히 추가 판매 채널이나 무언가를 구매할 수 있는 아름다운 애플리케이션이 아닙니다(경쟁업체에도 아름다운 제품이 있기 때문입니다). 이것은 폭풍우를 헤쳐나가는 데 도움이 되는 임시 스페어 타이어가 아닙니다.

이것은 절대적으로 필요한 것입니다. 이를 위해서는 기술 역량과 인프라뿐만 아니라 인력과 프로세스도 준비해야 합니다. 결국 몇 시간 안에 추가 메모리, 공간을 구입하고 새 인스턴스를 배포하는 등의 작업을 신속하게 수행할 수 있습니다. 하지만 이에 대비하려면 사람과 프로세스를 미리 준비해야 합니다.

출처 : habr.com