외부 라이브러리 및 종속 항목이 필요 없는 Ruby 백그라운드 작업 처리

최초 출시: 2020년 6월 5일 https://darnahsan.medium.com/background-job-processing-in-ruby-without-external-libraries-and-dependencies-ccdfe1dc5855
루비는 녹색 라인과 진정한 합병성이 없어 비난을 받고 있지만 루비 라이브러리(예를 들어 Resque, Delayed Job, Sidekiq)는 업계에서 백엔드 작업이 가장 유행하는 선택 중 하나이다.수백만 개의 요청과 수십만 개의 조작이 필요한 거대한 프로젝트가 있을 때, 그 중 하나의 기능이 완전한 해결 방안을 사용하십시오. 바퀴를 복잡한 소프트웨어로 재발명하지 않고 수천 시간의 인력이 필요합니다.확장에 도움을 줄 수 있지만, 이것은 당신이 원하거나 필요로 하는 것이 아닙니다. 이것은 초당 10000개의 작업을 처리할 수 있다는 것을 의미하고, 일부 작업은 메모리에서 처리할 수 있으며, 레디스와 같은 작업은 메모리에서 처리할 수 있기 때문입니다.Sidekiq의 기준 데이터를 보면 10만 개의 업무를 대상으로 합니다. 이것은 그 규모이기 때문입니다. 비록 대기열 관리와 감독이 필요한 곳에서 수백 개의 복잡한 작업을 실행할 수 있지만.

나는 네가 이 점을 이해했다고 믿는다. 더 이상 말할 필요가 없다. 이러한 외부 의존항 중 하나를 사용하지 않으면 어떻게 해야 할지 깊이 있게 연구해 보자.그래서 나는 약 4년 전에 이 백엔드 작업 처리 코드(Naiver and basic)를 작성했는데 그때부터 생산 과정에서 아무런 고장도 없이 그것을 만족시켰다.이것은 작업 서버에 있기 때문에 작업이 실패할 때 다시 시작해야 합니다. 이렇게 하면 복잡한 대기열 관리가 필요하지 않고, 라크 작업으로서 백엔드 작업 지원이 필요한 작업의 일부분을 실행하기 위해 Redis를 의존항으로 추가하는 것은 지나친 방법입니다.본고에서 작성한 임무는 Trustyou Metareviews that you can read about here의 테라바이트 데이터를 처리하는 것이다.
그래서 이 용례와 내가 그것을 어떻게 해결했는지 이야기해 봅시다.우리는 16개의 데이터를 다운로드해야 한다. 데이터 집합마다 16개의 파일이 있다. (이것은 16진수 데이터 집합이다.)이러한 데이터 세트는 AWS S3에 저장되므로 각 데이터 세트별로 작업을 할당한 다음 각 임무마다 자신의 16개 파일을 순서대로 실행할 수 있는 데이터 세트를 지정해야 합니다.각 파일을 순서대로 다운로드하는 것은 아무런 의미가 없습니다. AWS S3는 여러 파일을 다운로드할 수 있기 때문에 파일이 충분할 때 병렬 다운로드를 하면 전체 시간이 가장 느린 다운로드 시간과 같고 순서대로 다운로드하는 것은 전체 시간의 총계입니다.현재, 많은 도구에서 귀속 표지를 사용하면 이 점을 실현할 수 있다.그러나 이 백엔드 작업의 실현은 s3 다운로드와 무관하기 때문에 걱정하지 마세요. 장시간 실행되는 모든 작업에 대해 자신의 대기열을 실현하는 지식을 배울 수 있습니다.백그라운드에서 명령으로 다운로드하더라도 작업 관리와 마운트 해제 과정이 필요하기 때문이다.)
파일을 다운로드하기 위해서 s3cmd를 사용했습니다.AWS Ruby gem을 사용하고 다운로드한 내용을 메모리에서 파일로 쓰는 것보다 쓰기 작업을 직접 처리할 수 있는 툴입니다.토론이 끝났으니 코드를 보고 다시 한 번 봅시다.
다음은 실행 중인 작업을 실행하고 감시하는 데 필요한 모든 코드입니다.우선 Fury to run shell commands for jobs을 사용하고 있다는 것을 눈치채지 못하면 셀프 마케팅을 하세요.필요한 것은 Ruby Process 모듈뿐입니다.Process module에는 fork이라는 방법이 있습니다. 이 방법은 하위 프로세스를 만들고 실행 가능한 블록을 받아들일 수 있으며, 이 프로세스는 상태로 종료됩니다.비법은 detach 방법입니다. 포크 방법으로 되돌아오는 PID를 받아들이고, 스크립트가 실행 과정에서 실패하면 이 프로세스가 좀비 프로세스로 멈추지 않도록 합니다.그것은 약간의 자원 안전을 가져왔다.일단 모든 백엔드 작업을 시작하고, 완성이든 실패든 진행 상황을 감시하려고 한다.여기서 모든 PID는 케이스 마법을 사용할 수 있다

Fury.run_now(“ps ho pid,state -p #{job}”

우리는 모든 작업이 끝난 후에 프로세스를 분리했기 때문에, 프로세스는 살아 있는 것처럼 걸리지 않고, PID를 우아하게 종료하고 방출한다.
이것이 바로 네가 필요로 하는 것이다. 메모리의 대기열을 실현하고 너의 작업을 감시하는 것은 정말 쉽다.이것은 백그라운드 작업 대기열을 만드는 기본 구성 블록입니다.운영체제에서 수백 개의 작업을 실행한 다음 로컬 그림의 크기를 조정하고 업로드하는 등 단계별로 작업을 진행하면 편리합니다. 그림 목록을 불러와서 백엔드에서 실행한 다음, 완성된 그림 목록을 병렬 업로드하면 백엔드 작업 대기열이 생기고 작업이 완료됩니다.여러 개의 라크 작업을 실행하고 감시하며 실행을 바탕으로 구축할 수도 있습니다.일단 당신이 어떻게 백그라운드에서 업무를 처리하고 어떻게 이런 업무를 감시하는지의 기본 원리를 이해하게 된다면 이런 가능성은 부지기수다.
나는 이것이 내가 그것을 실현해야 했을 때와 같이 너를 도와 몇 가지 건의를 찾을 수 있기를 바란다.