원격으로 증가하는 x10 워크로드에서 어떻게 살아남았으며 어떤 결론을 내렸습니까?

헤이 하브르! 지난 몇 달 동안 우리는 매우 흥미로운 상황에서 살았으며 인프라 확장에 대한 이야기를 나누고 싶습니다. 이 기간 동안 SberMarket은 주문이 4배 증가했으며 17개의 새로운 도시에서 서비스를 시작했습니다. 식료품 배달 수요가 폭발적으로 증가함에 따라 인프라를 확장해야 했습니다. 컷에서 가장 흥미롭고 유용한 결론에 대해 읽어보십시오.

제 이름은 Dima Bobylev이고 SberMarket의 기술 이사입니다. 이것은 우리 블로그의 첫 번째 게시물이므로 저와 회사에 대해 몇 마디 말씀드리겠습니다. 지난 가을, 저는 Runet의 젊은 지도자 대회에 참가했습니다. 대회를 위해 나는 작은 이야기를 썼다 SberMarket에서 내부 문화와 서비스 개발 접근 방식을 보는 방법에 대해. 그리고 경쟁에서 이기지는 못했지만 IT 생태계 발전을 위한 기본 원칙을 스스로 공식화했습니다.

팀을 관리할 때 비즈니스 요구 사항과 개별 개발자의 요구 사항을 이해하고 균형을 찾는 것이 중요합니다. 이제 SberMarket은 13년에 18번 성장하고 있으며 이는 제품에 영향을 미치므로 개발의 양과 속도를 지속적으로 늘려야 합니다. 그럼에도 불구하고 사전 분석 및 고품질 코딩을 위해 개발자에게 충분한 시간을 할당합니다. 형성된 접근 방식은 작동하는 제품을 만드는 데 도움이 될 뿐만 아니라 추가 확장 및 개발에도 도움이 됩니다. 이러한 성장의 결과로 SberMarket은 이미 식료품 배달 서비스의 선두주자가 되었습니다. 3500월 초에는 약 XNUMX건의 주문이 있었지만 하루에 약 XNUMX건의 주문을 배송합니다.

어느 날 한 고객이 SberMarket 택배에게 비접촉식으로 발코니에서 직접 식료품을 배달해 달라고 요청했습니다.

그러나 세부 사항에 대해 알아 보겠습니다. 지난 몇 달 동안 우리는 회사의 인프라를 적극적으로 확장해 왔습니다. 이러한 필요성은 외부 및 내부 요인에 의해 설명되었습니다. 고객 기반 확대와 동시에 연결된 매장 수는 연초 90개에서 200월 중순에는 XNUMX개 이상으로 증가했습니다. 물론 우리는 스스로 준비하고 기본 인프라를 예약했으며 Yandex 클라우드에서 호스팅되는 모든 가상 머신의 수직 및 수평 확장 가능성에 의존했습니다. 그러나 연습은 "잘못될 수있는 모든 것이 잘못 될 것"이라는 것을 보여주었습니다. 그리고 오늘 저는 이번 주에 일어난 가장 흥미로운 상황을 공유하고 싶습니다. 우리의 경험이 당신에게 도움이 되기를 바랍니다.

완전한 전투 준비 상태의 노예

팬데믹이 시작되기 전부터 백엔드 서버에 대한 요청 수가 증가했습니다. 식료품을 택배로 주문하는 추세가 탄력을 받기 시작했고, 코로나19와 관련해 첫 자가격리 조치가 시행되면서 하루 종일 우리 눈앞에 짐이 극적으로 커졌다. 메인 데이터베이스의 마스터 서버를 빠르게 언로드하고 일부 읽기 요청을 레플리카 서버(슬레이브)로 전달해야 했습니다.

우리는 이 단계를 미리 준비하고 있었고, 그러한 기동을 위해 이미 2개의 슬레이브 서버가 실행되고 있었습니다. 파트너와 데이터를 교환하기 위한 정보 피드를 생성하는 배치 작업을 주로 했습니다. 이러한 프로세스는 추가 부하를 생성했으며 몇 달 전에 괄호에서 완전히 제거되었습니다. 

슬레이브에서 복제가 발생했기 때문에 우리는 애플리케이션이 읽기 전용 모드에서만 작동할 수 있다는 개념을 고수했습니다. 재해 복구 계획에서는 재해 발생 시 마스터 대신 슬레이브를 마운트하고 모든 쓰기 및 읽기 요청을 슬레이브로 전환할 수 있다고 가정했습니다. 그러나 우리는 또한 분석 부서의 요구에 따라 복제본을 사용하기를 원했기 때문에 서버가 완전히 읽기 전용 상태로 설정되지 않았고 각 호스트에는 자체 사용자 집합이 있으며 일부는 중간 계산 결과를 저장할 쓰기 권한이 있습니다.

일정 수준의 부하까지는 http 요청을 처리할 때 쓰기와 읽기 모두에 충분한 마스터가 있었습니다. XNUMX월 중순 Sbermarket이 원격 작업으로 완전히 전환하기로 결정했을 때 우리는 RPS 성장을 배가하기 시작했습니다. 점점 더 많은 고객이 자가 격리 또는 재택근무를 했으며 이는 부하 지표에 반영되었습니다.

"마스터"의 성능이 더 이상 충분하지 않아 가장 많은 읽기 요청 중 일부를 복제본으로 전송하기 시작했습니다. 쓰기 요청을 마스터에게 투명하게 전달하고 읽기 요청을 슬레이브에게 투명하게 전달하기 위해 ruby ​​gem을 사용했습니다."문어". 쓰기 권한이 없는 _readonly 접미사가 있는 특수 사용자를 만들었습니다. 그러나 호스트 중 하나의 구성 오류로 인해 쓰기 요청의 일부가 적절한 권한을 가진 사용자를 대신하여 슬레이브 서버로 이동했습니다.

문제는 즉시 나타나지 않았습니다. 증가된 부하로 인해 슬레이브의 백로그가 증가했습니다. 아침에 데이터 불일치가 발견되었는데, 야간 가져오기 후 슬레이브가 마스터를 "따라잡지" 못했습니다. 우리는 이것이 서비스 자체에 대한 높은 부하와 신규 매장 출시와 관련된 수입 때문이라고 생각했습니다. 그러나 많은 시간 지연된 데이터를 제공하는 것은 용납할 수 없었고, 프로세스를 두 번째 분석 슬레이브로 전환했습니다.о더 큰 리소스와 읽기 요청으로 로드되지 않았습니다(이는 우리가 복제 지연 부족을 설명하는 방법입니다).

메인 슬레이브의 "확산"에 대한 이유를 알아냈을 때 분석적인 슬레이브는 이미 같은 이유로 실패했습니다. 불행한 오류로 인해 마스터 충돌시 부하를 전송할 계획이었던 두 개의 추가 서버가 있음에도 불구하고 중요한 순간에 서버가 하나도 없다는 것이 밝혀졌습니다.

하지만 데이터베이스 덤프(당시 복원 시간은 약 5시간)뿐만 아니라 마스터 서버의 스냅샷도 수행했기 때문에 2시간 이내에 복제본을 시작할 수 있었습니다. 사실, 그 후 복제 로그를 오랫동안 롤링해야 했습니다(프로세스가 단일 스레드 모드에 있기 때문에 완전히 다른 이야기입니다).

결론 : 이러한 사건 이후 사용자에 대한 쓰기 제한 관행을 포기하고 전체 서버를 읽기 전용으로 선언해야 한다는 것이 분명해졌습니다. 이 접근 방식을 사용하면 중요한 순간에 복제본을 사용할 수 있습니다.

하나의 무거운 쿼리를 최적화하면 데이터베이스를 다시 사용할 수 있습니다.

우리는 사이트에서 카탈로그를 지속적으로 업데이트하지만 슬레이브 서버에 대한 요청으로 인해 마스터보다 약간의 지연이 발생했습니다. 우리가 "갑자기 궤도를 이탈한" 노예의 문제를 발견하고 제거한 시간은 "심리적 장벽" 이상이었습니다(이 시간 동안 가격이 업데이트될 수 있었고 고객은 오래된 데이터를 볼 수 있었습니다). 기본 데이터베이스 서버에 대한 모든 쿼리. 결과적으로 사이트는 느렸지만... 적어도 작동은 했습니다. 그리고 슬레이브가 회복되는 동안 최적화 외에는 우리에게 남은 것이 없었습니다. 

슬레이브 서버가 복구되는 동안 몇 분은 천천히 지연되고 마스터는 여전히 과부하 상태였으며 파레토 규칙에 따라 활성 작업을 최적화하는 데 모든 노력을 기울였습니다. 대부분의 부하를 주는 TOP 쿼리를 선택하고 튜닝을 시작했습니다. 이것은 즉시 수행되었습니다.

흥미로운 효과는 안구에 로드된 MySQL이 프로세스의 약간의 개선에도 반응한다는 것입니다. 총 로드의 5%만 제공하는 몇 가지 쿼리의 최적화는 이미 눈에 띄는 CPU 오프로드를 보여주었습니다. 결과적으로 우리는 마스터가 데이터베이스와 작업하고 복제본을 복구하는 데 필요한 시간을 확보할 수 있도록 허용 가능한 예약 리소스를 제공할 수 있었습니다. 

결론 : 약간의 최적화만으로도 몇 시간 동안 과부하를 "생존"할 수 있습니다. 이것은 복제본으로 서버를 복원하기에 충분했습니다. 그건 그렇고, 다음 게시물 중 하나에서 쿼리 최적화의 기술적 측면에 대해 논의할 것입니다. 유용한 정보가 있다면 저희 블로그를 구독하십시오.

파트너 서비스 상태 모니터링 구성

당사는 고객의 주문을 처리하므로 당사 서비스는 SMS, 결제 플랫폼, 라우팅 시스템, 지오코더, Federal Tax Service 및 기타 여러 시스템을 전송하기 위한 게이트웨이인 제XNUMX자 API와 지속적으로 상호 작용합니다. 그리고 부하가 급격히 증가하기 시작하면서 이전에는 생각조차 하지 못했던 파트너 서비스의 API 한계에 부딪히기 시작했습니다.

예상치 못한 파트너 서비스 할당량 초과로 인해 다운타임이 발생할 수 있습니다. 많은 API가 한도를 초과하는 클라이언트를 차단하고 경우에 따라 과도한 요청으로 인해 파트너의 프로덕션에 과부하가 걸릴 수 있습니다. 

예를 들어 배송 횟수가 증가했을 때 동반 서비스는 배포 및 경로 결정 작업에 대처할 수 없었습니다. 그 결과 주문은 됐지만 경로를 생성한 서비스가 작동하지 않는 것으로 드러났다. 물류 담당자는 이러한 조건에서 거의 불가능한 일을 해냈고 팀의 명확한 상호 작용은 일시적인 서비스 장애를 보상하는 데 도움이 되었다고 말해야 합니다. 그러나 그러한 양의 응용 프로그램을 항상 수동으로 처리하는 것은 비현실적이며 잠시 후 주문과 실행 사이에 허용할 수 없는 격차가 발생합니다. 

많은 조직적 조치가 취해졌고 팀의 잘 조율된 작업은 우리가 새로운 조건에 동의하고 일부 파트너의 서비스 현대화를 기다리는 동안 시간을 ​​벌 수 있도록 도왔습니다. 트래픽이 많은 경우 높은 내구성과 경건하지 않은 속도를 제공하는 다른 API가 있습니다. 예를 들어 처음에는 배달 지점의 주소를 결정하기 위해 잘 알려진 매핑 API를 사용했습니다. 그러나 월말에 그들은 거의 2 백만 루블에 대한 원형 청구서를 받았습니다. 그 후 신속하게 교체하기로 결정했습니다. 나는 광고에 관여하지 않겠지 만 비용이 크게 줄었다 고 말할 것입니다.

결론 : 모든 파트너 서비스의 작업 조건을 모니터링하고 이를 염두에 두는 것이 중요합니다. 오늘은 그들이 당신에게 "큰 마진을 가진"것처럼 보이지만 이것이 내일 그들이 성장의 장애물이 되지 않을 것이라는 의미는 아닙니다. 물론 서비스 요청 증가에 대한 재정 조건에 미리 동의하는 것이 좋습니다. 

때로는더 많은 금이 필요합니다"(c) 도움이 되지 않는다

우리는 메인 데이터베이스나 애플리케이션 서버에서 "개그"하는 데 익숙하지만 확장할 때 예상하지 못한 곳에 문제가 나타날 수 있습니다. 사이트에서 전체 텍스트 검색을 위해 Apache Solr 엔진을 사용합니다. 부하가 증가함에 따라 응답 시간이 감소하고 서버 CPU 부하가 100%에 도달했습니다. 더 간단할 수 있는 것은 Solr 컨테이너에 더 많은 리소스를 제공하는 것입니다.

예상되는 성능 향상 대신 서버가 단순히 "죽었습니다". 즉시 100% 로드되었고 훨씬 더 느리게 반응했습니다. 처음에는 2개의 코어와 2GB의 RAM이 있었습니다. 우리는 일반적으로 도움이 되는 일을 하기로 결정했습니다. 서버에 8개의 코어와 32GB를 제공했습니다. 모든 것이 훨씬 더 나빠졌습니다 (별도의 게시물에서 그 방법과 이유를 정확히 알려 드리겠습니다). 

며칠 만에 우리는 이 문제의 복잡성을 파악하고 8코어와 32GB로 최적의 성능을 달성했습니다. 이 구성을 사용하면 오늘날 매우 중요한 부하를 계속 늘릴 수 있습니다. 성장은 고객 측면뿐만 아니라 연결된 매장 수에서도 2개월 만에 두 배가 되었기 때문입니다. 

결론 : "철분 추가"와 같은 표준 방법이 항상 작동하는 것은 아닙니다. 따라서 서비스를 확장할 때 리소스를 사용하는 방법을 잘 이해하고 미리 테스트하여 새로운 조건에서 작업해야 합니다. 

상태 비저장은 단순한 수평 확장의 핵심입니다.

일반적으로 우리 팀은 잘 알려진 접근 방식을 고수합니다. 서비스는 내부 상태(상태 비저장)가 없어야 하며 런타임 환경과 독립적이어야 합니다. 이를 통해 우리는 간단한 수평 확장으로 부하 증가를 견딜 수 있었습니다. 그러나 하나의 서비스 예외가 있었습니다. 바로 긴 백그라운드 작업을 위한 처리기였습니다. 그는 이메일 및 SMS 전송, 이벤트 처리, 피드 생성, 가격 및 주식 가져오기, 이미지 처리에 관여했습니다. 그것은 로컬 파일 저장소에 의존하고 단일 사본에 있었습니다. 

프로세서 대기열의 작업 수가 증가하면(주문 수가 증가함에 따라 자연스럽게 발생) 프로세서와 파일 스토리지를 호스팅하는 호스트의 성능이 제한 요소가 되었습니다. 결과적으로 범위 및 가격 업데이트, 사용자에게 알림 보내기 및 대기열에 갇힌 기타 많은 중요한 기능이 중지되었습니다. Ops 팀은 파일 스토리지를 S3와 유사한 네트워크 스토리지로 신속하게 마이그레이션했으며 이를 통해 몇 대의 강력한 머신을 일으켜 백그라운드 작업 핸들러를 확장할 수 있었습니다.

결론 : 상태 비저장 규칙은 "우리가 여기서 쉬지 않을 것"으로 보이더라도 예외 없이 모든 구성 요소에 대해 준수되어야 합니다. 서둘러 코드를 다시 작성하고 과부하된 서비스를 수정하는 것보다 모든 시스템 작업의 올바른 구성에 약간의 시간을 보내는 것이 좋습니다.

집약적 성장 7원칙

추가 용량의 가용성에도 불구하고 성장 과정에서 몇 가지 갈퀴를 밟았습니다. 이 기간 동안 주문 건수는 4배 이상 증가했습니다. 이제 우리는 이미 17개 도시에서 하루 000개 이상의 주문을 배송하고 있으며 지역을 더욱 확장할 계획입니다. 62년 상반기에 이 서비스는 러시아 전역에서 출시될 예정입니다. 증가하는 작업량에 대처하기 위해 이미 가득 찬 범프를 고려하여 지속적인 성장 환경에서 작업하기 위한 2020가지 기본 원칙을 도출했습니다.

1. 사고 관리. Jira에서 각 사건이 티켓 형태로 반영되는 게시판을 만들었습니다. 이렇게 하면 사고 관련 작업의 우선 순위를 실제로 지정하고 완료하는 데 도움이 됩니다. 사실, 본질적으로 실수를 저지르는 것은 끔찍하지 않습니다. 같은 경우에 실수를 두 번 저지르는 것은 끔찍합니다. 원인을 바로잡기 전에 사고가 재발하는 경우에는 조치 지침을 준비해야 합니다. 왜냐하면 과부하 중에는 번개처럼 빠른 속도로 대응하는 것이 중요하기 때문입니다.
2. 모니터링 예외 없이 모든 인프라 요소에 필요합니다. 부하 증가를 예측하고 제거 우선 순위를 지정하기 위해 "병목 현상"을 올바르게 선택할 수 있었던 것은 그 덕분입니다. 아마도 부하가 높으면 생각조차하지 않은 모든 것이 깨지거나 느려지기 시작할 것입니다. 따라서 이를 모니터링하고 예측하기 위해 첫 번째 사건이 발생한 직후에 새로운 경보를 생성하는 것이 가장 좋습니다.
3. 올바른 알림 부하가 급격히 증가하면 필요합니다. 첫째, 무엇이 고장났는지 정확히 보고해야 합니다. 둘째, 중요하지 않은 경고가 많으면 일반적으로 모든 경고를 무시하기 때문에 경고가 많지 않아야 합니다.
4. 애플리케이션은 상태 비저장이어야 합니다. 우리는 이 규칙에 예외가 없도록 했습니다. 런타임 환경으로부터 완전한 독립이 필요합니다. 이를 위해 공유 데이터를 데이터베이스에 저장하거나 예를 들어 S3에 직접 저장할 수 있습니다. 더 좋은 방법은 규칙을 따르는 것입니다. https://12factor.net. 시간이 급격히 증가하는 동안 코드를 최적화할 방법이 없으며 컴퓨팅 리소스를 직접 늘리고 수평적 확장을 통해 부하에 대처해야 합니다.
5. 외부 서비스의 할당량 및 성능. 급속한 성장으로 인해 인프라뿐만 아니라 외부 서비스에서도 문제가 발생할 수 있습니다. 가장 성가신 일은 실패 때문이 아니라 할당량이나 한도에 도달했기 때문에 이런 일이 발생하는 경우입니다. 따라서 외부 서비스는 귀하와 마찬가지로 확장되어야 합니다. 
6. 프로세스와 대기열을 분리하십시오. 이는 게이트웨이 중 하나에서 플러그가 발생할 때 많은 도움이 됩니다. SMS 전송을 위한 전체 대기열이 정보 시스템 간의 알림 교환을 방해하지 않았다면 데이터 전송 지연이 발생하지 않았을 것입니다. 그리고 따로따로 일하면 일꾼을 늘리는 것이 더 쉬울 것이다.
7. 금융 현실. 데이터 흐름이 폭발적으로 증가하면 관세와 구독에 대해 생각할 시간이 없습니다. 그러나 특히 소규모 회사인 경우 기억해야 합니다. 모든 API 소유자와 호스팅 제공업체가 큰 금액을 청구할 수 있습니다. 따라서 계약서를 주의 깊게 읽으십시오.

결론

손실이 없는 것은 아니지만 우리는 이 단계에서 살아남았고 오늘날 우리는 발견된 모든 원칙을 고수하려고 노력하고 있으며 각 기계는 몇 가지 놀라움에 대처하기 위해 쉽게 x4 성능을 향상시킬 수 있습니다. 

다음 게시물에서는 Apache Solr에서 성능 저하를 조사한 경험을 공유하고 쿼리 최적화에 대해 설명하고 Federal Tax Service와의 상호 작용이 회사의 비용 절감에 어떻게 도움이 되는지 설명합니다. 아무것도 놓치지 않도록 블로그를 구독하고 트래픽이 증가하는 동안 비슷한 문제가 발생한 경우 의견에 알려주십시오.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

다음으로 인해 부하가 급격히 증가하여 서비스 속도가 느려지거나 중단된 적이 있습니까?

• 55,6%컴퓨팅 리소스를 빠르게 추가할 수 없음10

• 16,7%호스팅 공급자 인프라 제한3

• 33,3%타사 API6 제한

• 27,8%무국적 애플리케이션의 원칙 위반5

• 88,9%최적이 아닌 자체 서비스 코드16

18명의 사용자가 투표했습니다. 6명의 사용자가 기권했습니다.

출처 : habr.com