작업 처리를 사용하여 많은 파일을 효율적으로 처리하세요

IBM Cloud Object Storage 버킷에 저장된 파일이 많고 Code Engine에서 일괄처리를 사용하려 한다고 가정합니다. 목표는 한 버킷에서 파일을 읽고 파일을 조작하며 가장 효율적인 방법으로 다른 Object Storage 버킷에 파일을 저장하는 것입니다. 매일 입력 버킷에 2000개의 파일이 있다고 가정합니다. 모든 파일의 파일 이름은 서로 다르며 파일 이름은 영문자 (A-Z, a-z) 로 시작합니다.

이 시나리오에 대한 솔루션을 계획할 때 먼저 이벤트 기반 솔루션에 대해 생각합니다. 이 경우, 입력 Object Storage 버킷에 기록되는 모든 파일에 대해 이벤트가 작성되고 Code Engine 애플리케이션이 호출됩니다. 이벤트를 사용하면 단일 파일이 개별 처리를 트리거할 수 있으며, 이는 많은 파일에 대해 비효율적일 수 있습니다.

일괄처리 작업을 실행하는 것이 더 나은 방법일 수 있습니까? 네, 가능합니다! 일괄처리 작업이 여러 파일을 함께 처리하는 데 더 적합한 이유를 알아보겠습니다.

1. 파일 세트를 병렬 스트림으로 나누는 접근 방식을 판별하십시오. 파일 이름의 첫 번째 문자를 기반으로 파일을 나누도록 합니다. 이 접근 방식을 사용하면 26개의 스트림을 가질 수 있으며 각 스트림은 하나의 특정 문자로 시작하는 파일을 담당합니다. 실행 중인 작업 인스턴스의 자동으로 삽입된 JOB_INDEX 환경 변수를 읽어 특정 스트림을 식별할 수 있습니다. 작업에 대해 자동으로 삽입된 환경 변수 를 참조하십시오. 이 예제의 경우 인스턴스 수를 26 로 지정하거나 배열 인덱스를 0-25 로 지정하여 작업 인스턴스를 구성할 수 있습니다.

   실행 중인 각 작업 인스턴스에는 0-25의 색인이 지정됩니다. 사용자 코드에서 다음 패턴을 사용하여 입력 데이터를 작업 인스턴스에 분배하십시오.

   • JOB_INDEX=0 을 갖는 작업 인스턴스는 A 또는 a 로 시작하는 파일에서 작동합니다.
   • JOB_INDEX=1 이 있는 작업 인스턴스는 B 또는 b 로 시작하는 파일에서 작동합니다.
   • JOB_INDEX=2 를 사용하는 작업 인스턴스는 C 또는 c 로 시작하는 파일에서 작동합니다.
   • [D ... y]
   • JOB_INDEX=25 를 사용하는 작업 인스턴스는 Z 또는 z 로 시작하는 파일에서 작동합니다.

   각 스트림이 여러 파일을 처리하므로 스트림의 큐 길이를 단일 스트림에서 처리하는 파일 수로 정의하십시오.

2. Code Engine에서 작업 및 해당 구성을 작성하십시오.

   • 작업 배열 인덱스를 0-25 로 지정하십시오. 이는 26개의 병렬 스트림을 나타냅니다.
   • 작업에 대한 CPU및 메모리 자원을 지정하거나 기본값을 사용하십시오. 각 작업 색인은 작업에 지정한 것과 동일한 CPU및 메모리 자원을 가져옵니다. 예를 들어, 1 vCPU 및 4GB메모리입니다.

3. 작업 실행. Code Engine 콘솔에서 보류 중, 실행 중 및 완료된 작업 인덱스의 수를 볼 수 있습니다. 마지막 작업 색인이 실행을 완료하면 작업이 종료됩니다.

데이터의 하위 집합을 처리하고 병렬 작업 실행 인스턴스에 작업을 동적으로 할당합니다

특정 수의 병렬 인스턴스로 제한하지 않는다고 가정하십시오.

이전 시나리오에서는 26개의 병렬 스트림이 정의되었으며 제출된 작업 실행이 정의된 26개의 병렬 스트림에서 실행되었습니다.

그러나 특정 수의 병렬 인스턴스로 제한하지 않고 특정 작업 실행 인스턴스에 작업 스트림을 동적으로 지정하는 작업을 실행하려 한다고 가정하십시오. 이 경우 JOB_INDEX 및 JOB_ARRAY_SIZE 환경 변수를 모두 사용하여 처리되는 작업 스트림을 판별하는 값을 파생시킬 수 있습니다. 이러한 환경 변수는 작업에 대해 자동으로 삽입됩니다.

• JOB_INDEX 환경 변수는 특정 작업 실행 인스턴스의 색인 값입니다.
• JOB_ARRAY_SIZE 환경 변수는 병렬로 실행할 작업 인스턴스의 수를 지정합니다. 이 값은 작업 실행 배열 크기로 직접 지정되거나 지정된 배열 색인을 계수하여 계산됩니다.

예를 들어, 각 작업 실행 인스턴스가 전체 데이터의 10%에서 작동하도록 배열 크기를 10으로 구성했다고 가정합니다 (10개의 작업 실행 인스턴스가 병렬로 실행됨). 이 구성 설정을 사용하여 JOB_INDEX 환경 변수는 작업할 데이터의 10% 청크를 판별하고 JOB_ARRAY_SIZE 의 계산된 값은 10입니다.

그러나 이전에 실패했기 때문에 초기 10개의 작업 실행 인스턴스 중 3개를 재실행하려 한다고 가정합니다. 데이터의 다른 70%가 성공적으로 처리되었습니다. 작업 실행을 다시 제출할 때 특정 3개의 실패 인덱스를 지정하려고 합니다. 3, 7 및 9 인덱스를 재실행하려 한다고 가정하십시오.

이 새 작업 실행의 경우 배열 색인 (예: "3, 7, 9") 만 업데이트한다고 가정합니다. 배열 크기 대신 배열 색인이 지정되면 JOB_ARRAY_SIZE 환경 변수의 값이 자동으로 계산되므로 3개의 배열 색인이 지정되었으므로 JOB_ARRAY_SIZE 의 값은 이제 10이 아니라 3입니다.

대신, 작업 실행 제출 (또는 다시 제출) 조치가 지정된 색인 3, 7 및 9 에 대해 올바른 데이터 청크를 처리하는지 확인하기 위해 CLI에서 --array-size-var-override 옵션을 사용하거나 콘솔의 JOB_ARRAY_SIZE 입력 필드에서 사용자 정의 값을 지정하여 JOB_ARRAY_SIZE 환경 변수의 자동으로 계산된 값을 대체할 수 있습니다.

사용자 정의 배열 크기 재정의 값을 10으로 설정하면 작업 실행 인스턴스가 청크 크기를 10%로 올바르게 계산하고 다시 제출된 작업 실행 인스턴스가 원하는 데이터를 처리합니다(인덱스 3, 7, 및 9). 이 옵션을 사용하여 일부 작업 인스턴스만 제출되거나 다시 제출되는 작업 재실행 시나리오에 대해 상수 배열 크기 값을 적용할 수 있습니다.

이 작업 실행 접근 방식을 구현한 후에는 병렬 작업 실행 수를 동적으로 늘리거나 줄일 수 있습니다.

작업 실행 작업 스트림 관계를 정의하기 위해 JOB_INDEX 환경 변수를 사용하여 지정하는 접근 방식과 달리, 작업 스트림을 동적으로 지정하기 위해 JOB_ARRAY_SIZE 환경 변수를 대체하는 이 방법은 보다 유연하며 사용자의 요구에 맞게 특정 작업 실행을 조정할 수 있습니다.

병렬 일괄처리 작업 실행의 이점

병렬 일괄처리 작업을 구현하는 이 방법은 이점을 제공합니다.

• 초기화 감소-하나의 작업 인덱스가 유사한 시작 문자를 사용하여 파일을 처리하므로 작업 인덱스당 하나의 초기화 또는 연결 설정만 필요합니다. 이 접근 방식은 파일별로 개별적으로 초기화하는 것과 비교할 때 자원 및 비용을 절약합니다. 병렬 작업 솔루션을 사용하면 2000개의 초기화 대신 26개의 초기화가 있습니다.

• 효율적인 자원 사용-태스크를 병렬 장기 실행 스트림으로 나누면 이 솔루션은 사용 가능한 자원을 보다 효율적으로 사용하는 반면 처리 속도는 최대화됩니다.

병렬 배치 작업 계획 시 고려사항

병렬 배치 작업 솔루션을 계획할 때 다음 사항을 고려하십시오.

• 병렬 작업 색인 및 큐 길이의 균형 조절-스트림 수 (병렬 작업 색인) 와 큐 길이 사이의 균형을 잘 유지하는 것이 중요합니다. 너무 적은 작업 색인은 사용 가능한 자원을 완전히 사용할 수 없는 반면, 너무 많은 색인은 초기화 처리를 늘리고 Object Storage와 같은 클라우드 서비스의 로드를 늘릴 수 있습니다. 이로 인해 다른 클라우드 서비스를 호출할 때 비율 한계가 발생할 수 있습니다.

• 유사한 작업 처리 시간-솔루션을 계획할 때 각 작업 색인이 해당 태스크를 완료하는 데 거의 동일한 시간이 소요되는 것을 고려하십시오. 처리 시간으로 인해 자원 사용이 비효율적이고 작업 처리 시간이 길어질 수 있으므로 한 작업 색인이 다른 작업 색인보다 훨씬 더 오래 걸리는 시나리오를 피하십시오.

• 다중 작업 사용-이전 시나리오의 경우 다른 방법은 다중 작업을 사용하는 것입니다. 이러한 다중 작업은 구성된 배열 인덱스에 의존하지 않습니다. 대신, A - Z 로 시작하는 파일에 대해 하나, a - z 로 시작하는 파일에 대해 다른 하나의 배치 작업을 작성하는 것을 고려하십시오. 코드를 변경하지 않고 처리 요구사항 및 자원 가용성에 따라 병렬 또는 순차적으로 이 두 작업을 트리거할 수 있습니다.

• 작업 트리거 메커니즘-특정 간격으로 cron 등록 을 사용하거나 Object Storage 버킷에서 새 파일을 모니터하고 필요에 따라 일괄처리를 시작하는 트리거 애플리케이션을 사용하여 작업을 트리거하도록 선택할 수 있습니다. 시나리오에 따라, 파일이 버킷에 기록된 후 처리되는 속도에 대한 응답 시간 대비 비용 효율성을 위해 Code Engine 사용을 최적화할 수 있습니다.