Sidekiq 최적화 또는 모니터링에 대한 질문을 종종 받습니다. 모니터링은 일종의 우리 게임이지만 Sidekiq의 성능을 최적화하는 것은 완전히 다른 게임입니다. 실제로 최적화는 복잡하지만 겉보기에는 간단해 보이는 답변부터 살펴보겠습니다...
속도를 높이는 두 가지 방법
우선 속도를 두 가지 방법으로 높일 수 있습니다. 더 큰 작업을 수행하거나(더 많은 메모리 또는 IO를 차지하거나 더 복잡할 수 있음) 동시성 설정 또는 작업자를 조정하여(더 많은 CPU와 가능한 IO를 사용함) 속도를 높일 수 있습니다. 아야, 현실이 이미 시작되고 있습니다. 속도에는 대가가 따릅니다. 추가 메모리, IO 또는 CPU를 절약할 수 있는 경우 이는 무료이지만 우리는 절충해야 할 수 있는 절충안을 깨닫는 것이 중요하다고 생각합니다.
동시 설정을 통한 속도 향상
Sidekiq는 프로세스에서 여러 스레드를 사용하여 동시성을 처리합니다. 이런 식으로 한 번에 여러 작업을 처리할 수 있으며 각 스레드는 한 번에 하나의 작업을 처리합니다. 기본적으로 Sidekiq은 프로세스당 10개의 스레드를 사용합니다. 더 많은 스레드를 사용하도록 구성하여 동시성을 높일 수 있습니다.
<블록 인용>새로운 동시성 모델은 앱에서 지원해야 합니다. 예를 들어, 데이터베이스에 대한 연결 풀이 충분히 커야 하고 호스트가 증가하는 I/O 작업을 처리할 수 있어야 합니다. 자세한 내용은 동시성에 대한 Sidekiq 문서를 확인하세요.
여러 작업자를 실행하여 속도 향상
여러 프로세스를 생성하는 것 외에도 여러 작업자를 실행할 수도 있습니다. 이러한 방식으로 CPU를 많이 사용하는 부품을 확장하여 한 프로세스에서 실행되는 경우 CPU에서 서로 방해가 될 때 병렬로 실행할 수 있습니다. 우리는 이전에 Ruby의 동시성과 Global Interpreter Lock에 대해 작성한 적이 있습니다.
작동합니까 아니면 파손됩니까? 모니터링 대상 및 Magic Dashboard
기본 매개변수를 변경하면 애플리케이션 성능에 영향을 미칠 수 있습니다. 설정을 변경하기 전에 모니터링을 설정하여 변경 사항이 긍정적인 영향을 미치는지 또는 성능이 저하되는지 확인하는 것이 좋습니다.
호스트 수준에서 문제가 발생하는지 확인하는 것으로 시작하겠습니다. 실행 중인 하드웨어에서 앱이 얼마나 리소스를 많이 사용하는지 확인하고 싶을 것입니다. 메모리와 CPU에 용량이 남아 있는 경우 동시성 설정을 높여 작업을 조금 더 빠르게 할 수 있습니다.
사용하는 APM(응용 프로그램 성능 모니터링)에 관계없이 호스트 메트릭을 추적하는 방법이 있을 수 있습니다. AppSignal을 사용하면 호스트용 대시보드가 자동으로 생성됩니다. 문제가 실제로 실행되기 전에 알림을 받을 수 있도록 Anomaly detection을 사용하여 특정 호스트의 CPU 사용량에 대한 알림을 쉽게 설정할 수 있습니다.
이제 Sidekiq 수준에서 문제가 발생하지 않는지 봅시다. 선택한 APM을 사용하면 수동 방식으로 백그라운드 작업에 대한 모니터링 및 경고를 설정할 수 있습니다. AppSignal에서는 매우 쉽습니다. Sidekiq 매직 대시보드에서 이를 추적합니다(최신 버전의 gem을 실행할 때 사용자 측에서 설정이 필요 없이 생성됨).
이 설정에서 작업 상태를 모니터링해야 합니다. 대기열당 실패율에 대한 트리거를 설정하여 Slack, PagerDuty, 이메일 또는 사용하는 모든 항목에 대해 경고합니다.
더 적은 작업, 더 큰 작업?
CPU를 교환하면서 속도를 높이는 방법을 간략하게 살펴보았습니다. 이제 메모리나 IO 또는 더 많은 복잡성을 상쇄하면서 속도를 높이는 방법을 살펴보겠습니다. 당신은 더 큰 일자리를 창출함으로써 그렇게 할 수 있다고 생각할 것입니다. 큰 작업은 작업당 Sidekiq 오버헤드가 없기 때문에 더 빠를 수 있다는 아이디어입니다. 그러나 우리의 경험에 따르면 Sidekiq 오버 헤드는 성능을 거의 죽이지 않습니다. 종종 성능을 저하시킬 수 있는 작업이 수행하는 데이터베이스 쿼리입니다. 더 적은 수의 쿼리를 수행하기 위해 더 많은 작업을 결합하는 것이 입니다 더 나은 성능을 위한 중요한 방법입니다. 단순화:1개 레코드의 1000개 업데이트 대신 1000개 레코드의 1개 업데이트를 수행합니다.
작동 여부를 확인하기 위해 무엇을 모니터링해야 합니까?
먼저 작업 상태를 모니터링해야 합니다. 여기에서 대기열당 실패율에 대한 트리거를 설정합니다. . 작업은 더 오래 걸리고 더 많은 작업을 수행하므로 Sidekiq의 메모리 사용량도 모니터링해야 합니다. . Sidekiq 메모리 사용에 대한 알림도 설정해야 합니다. , 그러나 특히 메모리가 부족한 호스트의 경우 AppSignal의 Anomaly 감지를 사용합니다.
대기열 길이도 모니터링해야 합니다. 대기열당. 이렇게 하면 작업자가 처리할 수 있는 것보다 대기열에 더 많은 백로그가 생성될 때 알려줍니다. '중요' 작업 대기열에 대해 이상 감지 트리거를 설정하는 것이 좋습니다.
APM에서는 볼 수 없는 절충안
더 큰 작업의 가장 큰 문제는 코딩하기가 더 어렵다는 것입니다. 개별 작업을 명시적으로 멱등적으로 만들고 상태를 추적해야 합니다. 간단한 예에서:한 사람에게 메일을 보내는 작업이 있고 실패하면 큰 피해 없이 다시 시도할 수 있습니다. 1000명에게 메일을 보낼 때 작업이 실패하면 작업이 실패하기 전에 메일을 보낸 240명에게 다시 보내고 싶지 않습니다. 이러한 일이 발생하지 않도록 하면 코드가 더 복잡해집니다.
현실의 진정한 복잡성
또 다른 현실 확인을 위한 시간입니다. 종종 Sidekiq에서 실행 중인 항목으로 인해 백그라운드 프로세스가 느려지지 않을 수 있습니다. 쿼리하는 데이터베이스가 실행되는 호스트의 메모리가 부족하기 때문에 속도가 느릴 수 있습니다. 이 게시물에서 사용할 멋진 예제를 찾다가 이러한 시나리오 중 하나에 부딪쳤습니다. 외부 API의 응답 시간이 길어 지속 시간이 정점에 달했습니다. Sidekiq의 어떤 것도 이 문제를 해결할 수 없습니다.
문제는 한 곳에서 볼 수 있지만 완전히 다른 곳에서 발생할 수 있기 때문에 AppSignal에서는 오류, 성능 및 호스트 메트릭을 올인원으로 갖도록 제품을 구축했습니다. 이 보기의 결합된 측정항목을 사용하면 문제의 근본 원인을 더 쉽게 찾을 수 있습니다.
쉬운 답은 없습니까?
Sidekiq 모니터링 및 최적화의 기본 사항으로 이 기사를 시작했지만 속도가 CPU와 IO를 소모하게 된다는 현실에 즉시 부딪쳤습니다. 또는 기억. 또는 더 많은 복잡성을 도입하십시오. 아키텍처에서 성능의 복잡성에 대해 몇 가지 설명했지만 이 게시물에서 어려운 부분의 약 99%를 건너뛰었습니다.
따라서 간단한 답변에 대한 귀하의 희망을 앗아갔을지 모르지만 이 기사가 귀하의 Sidekiq 설정 최적화 및 모니터링에 대한 흥미로운 생각을 일으키기를 바랍니다!