이 텍스트는 Salesforce의 자동 번역 시스템을 사용하여 번역되었습니다. 이 콘텐츠에 대한 피드백을 제공하고 다음에 원하는 내용을 알려주려면 저희의 설문 조사을 참조하십시오.

이 가이드는 Salesforce Platform에서 비동기 처리 요구 사항에 대한 올바른 접근 방식을 평가하는 데 도움이 됩니다. 각 접근 방식을 설명하여 각각의 강점과 제한 사항을 자세히 설명합니다. 대부분의 접근 방식은 제품 기능과 일치하지만 일부 접근 방식은 여러 기능을 조정합니다. 가이드에는 각 접근 방식을 사용할 시점을 강조하는 사용 사례가 포함되어 있습니다.

비동기 처리는 아키텍처에 두 가지 주요 혜택을 제공합니다. 먼저 비동기 프로세스에 더 높은 총괄자 제한이 있으므로 확장성이 향상됩니다. 두 번째로 비동기식 요청은 자체 스레드에서 실행되므로 사용자가 비동기식 과업이 백그라운드에서 실행되는 동안 다른 작업을 수행할 수 있습니다.

이 가이드는 Salesforce Platform 내에서 비동기 처리 기술 선택에만 중점을 두고 있습니다. 결정 프로세스를 돕는 다른 리소스는 리소스 섹션에 나와 있습니다.

Salesforce Platform Salesforce Lightning Platform은 직원, 자율 AI 에이전트, 회사 데이터 및 애플리케이션을 신뢰할 수 있는 단일 시스템으로 통합하여 생산성과 고객 경험을 향상시킬 수 있는 종합적인 AI 기반 플랫폼입니다. 이를 통해 Customer 360 앱, Data Cloud, Slack을 연결하여 엔드 투 엔드 자동화를 수행할 수 있게 되었습니다.

이 문서에서는 MuleSoft, Informatica, Commerce Cloud, Tableau, Marketing Cloud와 같은 다른 에코시스템의 기술을 다루지 않습니다.

  • 비동기식 처리를 사용하기 전에 사용 사례가 패턴에 맞는지 확인하십시오. 비동기 패턴에는 SLA가 없으며, 다중 총괄자 메커니즘이 적용되며, 라이센스를 기반으로 정의된 수용력 제한이 있을 수 있으며, Salesforce Platform 내 비동기 인프라에 할당된 리소스의 유한적인 특성으로 인해 처리 지연이 발생할 수 있습니다. 사용자가 작업을 계속하기 전에 시스템에서 응답해야 하는 시나리오에서 비동기 처리를 사용할 때 다음 제한 사항을 고려하십시오.
  • Salesforce를 통한 비동기식 처리는 경계 없는 확장 요구에 맞는 솔루션이 아닙니다. Salesforce Platform은 무제한으로 확장되지 않으며 비동기 패턴에는 제한이 적용됩니다. 비동기 처리는 스레드를 사용하며, 이는 CPU가 명령 스트림을 실행하기 위해 필요한 컨텍스트 정보를 포함합니다. 스레드는 병렬로 실행할 수 있습니다. CPU의 사용 가능한 스레드는 제한되므로 플랫폼에 사용 가능한 스레드를 최대한 효율적으로 사용할 수 있는 메커니즘이 마련되어 있습니다. 플랫폼의 흐름 제어 메커니즘은 조직이 너무 많은 스레드를 소비하고 다른 조직에 부정적인 영향을 미치지 않도록 방지합니다. 플랫폼의 공정 사용 알고리즘은 또한 조직이 각 메시지 유형에 사용할 수 있는 스레드 수를 제어합니다.
  • 극적인 부하를 유발할 수 있는 이벤트를 고려하십시오. 비동기 프로세스를 설계할 때 작업 부하 급증 및 Lull을 예측 가능한 방식으로 관리할 수 있는지 확인하십시오. 구현에서 전력 중단과 같은 예기치 않은 이벤트를 처리하는 방법을 고려하고 데이터 손실 또는 기능 손실을 완화하는 보안 조치를 설계합니다.

이 표는 Salesforce와 함께 비동기식 처리에 사용할 수 있는 도구를 간략하게 보여줍니다. 의사 결정 프로세스 동안 각 도구의 주요 특성을 검토하려면 이 표를 참조하십시오. 아키텍처에 적합한 도구를 선택하는 데 도움이 되는 사용 사례 및 결정 지점을 참조하십시오.

접근 방식 설명 필요한 기술 라이센스 및 제한
Queueable Apex 장기 실행 데이터베이스 작업 또는 외부 웹 서비스 콜아웃과 관련된 프로세스에 사용합니다. 대기 가능한 Apex 작업 ID, 비기본 유형 지원, 작업 체인화와 같은 기능을 제공합니다. 프로 코드 라이센스 수는 제한을 늘릴 수 있습니다.
배치 Apex 레코드 집합을 분할하고 관리 가능한 청크로 처리하여 수백만 개의 레코드를 포함하는 복잡한 장기 실행 프로세스를 구축합니다. 프로 코드 라이센스 수는 제한을 늘릴 수 있습니다.
예약된 Apex Cron 식으로 정의된 예약된 시간에 Apex 실행합니다. Cron 식을 통해 Apex 예약하는 작업은 비동기식 프로세스이지만, 작업이 시작되면 기본 코드가 동기식으로 실행됩니다. 프로 코드 라이센스 수는 제한을 늘릴 수 있습니다.
Apex 계속 콜아웃 동기 트랜잭션 컨텍스트에서 실행되는 Apex 메서드의 콜아웃을 실행합니다. 프로 코드 아니요
비동기 경로(레코드 트리거 플로) 자체 시간에 실행할 작업을 실행합니다. 플로를 트리거한 레코드의 일부가 아닌 관련 레코드의 값을 업데이트할 때 발생하는 혼합 DML 오류를 방지합니다. 낮은 코드 라이센스 수와 유형에 따라 제한이 증가할 수 있습니다.
예약 경로(커밋 플로 후) 트리거 이벤트 후 동적으로 예약된 시간(예: 레코드가 생성, 업데이트 또는 삭제된 경우)에 실행합니다. 낮은 코드 라이센스 수와 유형에 따라 제한이 증가할 수 있습니다.
예약된 흐름 지정된 시간 및 반복 빈도(매일, 매주 또는 한 번)에 백그라운드에서 플로를 실행하여 레코드 배치에 대한 작업을 수행합니다. 낮은 코드 라이센스 수와 유형에 따라 제한이 증가할 수 있습니다.
플랫폼 이벤트 트리거 Salesforce를 외부 시스템과 쉽게 연결하고 Salesforce Platform 내 비동기 구성 요소 간에 통신합니다. 하위 코드 + Pro 코드 대용량 플랫폼 이벤트 사용 사례에 추가 기능 라이센스가 필요합니다.
변경 데이터 수집 데이터베이스 트랜잭션이 커밋된 후 비동기식으로 변경 이벤트를 수집하고 처리합니다. 프로 코드 기본 할당을 넘어 확장하려면 추가 기능 라이센스가 필요합니다.
Bulk API 많은 레코드를 비동기식으로 삽입, 업데이트, 업서트, 쿼리 또는 삭제하고 나중에 결과를 처리합니다. 프로 코드 제한이 있습니다.
Lightning 작업 사용자가 페이지를 완전히 새로 고칠 필요 없이 Lightning 페이지가 서버와 상호 작용하도록 허용합니다. 낮은 코드 아니요

이 표에는 사용할 비동기식 도구를 결정할 때 고려해야 할 사항의 개요가 포함되어 있습니다.

필수 기술 이 가이드에 설명된 일부 도구에는 코드가 필요하며, 다른 도구는 선언적으로 구성할 수 있습니다. 옵션을 고려할 때 팀 구성원이 보유한 기술 집합을 생각해 보십시오. 초기 구현을 위해 개발자를 사용할 수 있는 경우(예: 구현 파트너를 통해) 나중에 솔루션을 수정해야 할 수도 있다는 점에 유의하십시오. 서비스 점검 팀에 개발자가 부족할 경우 하위 코드 옵션이 더 적합할 수 있습니다.
적용되는 플랫폼 제한 유형 실행에 적용되는 제한의 유형을 결정합니다. 솔루션을 설계할 때 매일 선택한 접근 방식의 총괄자 제한에 트랜잭션의 양과 빈도가 어떻게 계산되는지 주의 깊게 생각합니다. 매일 발생할 실행 횟수를 계산합니다. 계산된 값이 선택한 도구와 연결된 제한에 속하는지 확인합니다.
대기 시간 플랫폼에서 처리 결과를 얼마나 빠르게 사용할 수 있는지 결정합니다. 일부 접근 방식에서는 변경 사항이 거의 즉시 적용되지만, 다른 접근 방식에서는 분 또는 시간으로 변경될 수 있습니다.

비동기식 처리를 위한 도구를 선택할 때 먼저 조직의 요구 사항 및 사용 가능한 자원을 평가합니다. 목표는 구현 및 유지 보수 비용을 최소화하지만 확장성을 유지하고 제한 위반 가능성을 최소화하는 도구를 선택하는 것입니다. 이 목표는 앞서 요약된 기술적 고려 사항 및 팀 구성에 따라 다릅니다.

Salesforce에서 비동기 주문 프로세스를 고려하십시오. 주문이 저장되면 항목을 패킹하고 배송하는 방법에 대한 특별 지침이 포함된 외부 창고 관리 시스템에 메시지를 트리거합니다. 주문하는 사용자는 창고 관리 시스템의 즉각적인 응답이 필요하지 않으므로 비동기식으로 요청을 보낼 수 있습니다. 비동기 처리를 사용하면 사용자가 응답을 기다리지 않고 작업을 계속할 수 있습니다.

이 사용 사례의 경우 Apex 사용하여 구현할 수 있습니다. 이 접근 방식은 팀에 프로 코드 솔루션을 유지 관리할 수 있는 Apex 개발자가 있는 경우에만 작동합니다. 그렇지 않으면 선언적 접근 방식이 더 적합합니다. 또한 다른 도구에 다른 집합의 제한이 적용된다는 점에 유의하십시오.

다음 표에서 왼쪽 끝의 열에 일반적인 사용 사례를 나열하고 설명을 확인할 수 있습니다. 첫 번째 선택 열은 이러한 사용 사례를 충족하기 위해 사용되는 가장 일반적인 접근 방식을 제공하고 첫 번째 선택 접근 방식을 설명합니다. 이를 분석의 시작점으로 사용하십시오. 첫 번째 선택 접근 방식에는 사용 사례에서 작동하지 않는 제한 사항이 있을 수 있습니다.

사용 사례 설명 첫 번째 선택 접근 방식 근거
고성능 배치 가공 수천 또는 수백만 개의 레코드를 효율적으로 처리해야 하는 자동화 배치 Apex 배치 Apex 플랫폼과 인터페이스하고 원시 속도를 위해 서식 있는 API를 제공합니다.
데이터 정리 작업 정리하는 데이터를 정기적으로 실행하거나 요청 시 실행하는 작업입니다. 중복 제거, 주소 확인 또는 데이터 통합을 예로 들 수 있습니다. 배치 Apex 배치 Apex 플랫폼과 인터페이스하고 원시 속도를 위해 서식 있는 API를 제공합니다.
야간 롤업 작업 영업일이 끝날 때 롤업 데이터를 계산하는 작업입니다. 배치 Apex 배치 Apex 플랫폼과 인터페이스하고 원시 속도를 위해 서식 있는 API를 제공합니다.
레코드 트리거형 논리 레코드 업데이트에 대한 응답으로 논리를 실행합니다. 다른 동료 결정 가이드, 레코드 트리거 이벤트 자동화를 참조하십시오. 대기 가능한 Apex, 배치 Apex, 예약된 Apex, 예약된 플로, 비동기 경로 플로, 변경 데이터 수집 등 비동기 사용 사례에 대한 결정 트리가 포함되어 있습니다.
개체 그래프를 통해 업데이트 캐스팅 사용자의 저장 작업을 빠르게 완료할 수 있으므로 다른 개체에 대한 계단식 업데이트가 비동기식으로 실행되도록 지연됩니다. 대기 가능한 Apex 대기 가능한 Apex 논리를 사용하여 업데이트 체인을 일련의 비동기 트랜잭션으로 나눌 수 있는 강력한 체인화 기능이 있습니다.
레코드별 예약된 처리 레코드에 고유한 향후 동적 날짜(예: 마감 날짜 3일 전)의 자동화 예약 경로가 있는 플로 예약 경로는 플로에 고유한 강점이므로 플랫폼이 레코드의 데이터가 변경될 경우 해당 경로의 예약, 취소, 재예약을 자동으로 처리합니다.
다중 느린 외부 서비스 병렬 호출 동기 실행 중에는 전체 실행 시간을 최적화하기 위해 여러 외부 서비스를 병렬로 호출합니다. Apex 계속 콜아웃 느리게 실행되는 여러 콜아웃을 병렬로 실행하도록 허용하면 작업을 완료하는 전체 시간이 최소화됩니다.
외부 시스템에서 레코드의 데이터 마이그레이션 대량의 레코드를 외부 시스템에서 Salesforce Platform으로 이동합니다. 일회성 또는 정기적으로 예약된 프로세스입니다. 대량 API 이는 데이터 마이그레이션을 위한 가장 효율적이고 제한적인 접근 방식입니다.
외부 시스템에서 추가 논리 실행 플랫폼에서 외부 시스템에 이벤트를 알린 후 해당 시스템이 비동기식으로 이벤트를 처리할 수 있도록 합니다. 플랫폼 이벤트 또는 변경 데이터 수집 pub-sub 모델은 여기에서 가장 적합하며, 준비가 되면 외부 시스템에서 이벤트를 처리할 수 있습니다. 이 패턴에 대한 자세한 내용은 이벤트 구동 아키텍처를 참조하십시오.

사용 사례 테이블은 각 사용 사례에 가장 적합한 접근 방식을 안내합니다. 그러나 First Choice 기술이 사용 사례의 특정 요구 사항에 얼마나 적합한지 확인해야 합니다. 특히 선택한 접근 방식을 조직의 총괄자 제한을 준수할 수 있는지 확인합니다.

사용 사례에 대한 후보 접근 방식을 식별하면 비동기 처리 기본 사항 가이드가 솔루션을 완벽하게 검사하는 데 도움이 됩니다.

결정 프로세스에 도움이 되는 추가 자원은 다음과 같습니다.