비동기식 처리는 컨텍스트별로 더 높은 제한을 허용하여 확장성을 향상합니다. 비동기식 요청은 자체 스레드에서 실행되므로 사용자가 비동기식 과업이 백그라운드에서 실행될 때 계속해서 클라이언트 측에서 작업을 수행할 수 있습니다.

Salesforce Lightning Platform은 특정 사용 사례를 해결하는 데 사용할 수 있는 다양한 비동기식 기술을 제공합니다. 각 기술에는 각 사용 사례에 대한 접근 방식을 선택할 때 고려해야 하는 이점과 제한이 있습니다.

구현할 기술을 선택할 때 다음과 같은 세 가지 중요한 고려 사항에 유의하십시오.

1. 비동기 처리는 모든 문제에 가장 적합한 접근 방식이 아닙니다. 비동기식 처리를 위해 직접 사용자 상호 작용이 필요하지 않은 프로세스를 좋은 후보로 생각하는 것은 유혹스러운 일일 수 있지만 몇 가지 단점이 있습니다. 먼저 비동기 프로세스에는 SLA가 없으므로 비동기 프로세스가 설정된 시간 내에 완료되도록 보장할 수 없습니다. 두 번째로, 일관된 응답 대기 시간이 보장되지 않습니다. 비동기 프로세스가 특정 시간 내에 완료되는 경우 후속 프로세스가 완료되기까지 다른 시간이 소요될 수 있습니다. 따라서 사용자가 응답을 직접 대기하지 않는 경우에도 응답에 의존하는 후속 프로세스가 있는 경우 또는 과도한 응답 시간이 있으면 데이터가 외부 시스템의 데이터와 동기화되지 않을 수 있습니다.
2. Salesforce Platform에서 비동기 요청을 처리하는 방법은 여러 가지이므로 최상의 접근 방식을 선택해야 합니다. Salesforce Platform에서 비동기 처리를 지원하는 기술은 "일반적으로" 다르게 작동하며 일부는 매우 특정한 사용 사례에 맞게 설계되었습니다.
3. 클라이언트 측에서 기술이 비동기식인 경우 모든 종단간 처리가 병렬로 수행되는 것은 아닙니다. 선택 항목에 따라 클라이언트의 메시지는 서버 측에서 계속해서 직렬화될 수 있습니다.

작업에 잘못된 기술 또는 잘못된 기술 조합을 사용할 경우 비동기식 처리의 혜택을 취소하는 의도하지 않은 결과가 발생할 수 있습니다. 이 가이드에서는 다양한 비동기식 사용 사례에 대한 잠재적인 단점 및 안티 패턴뿐 아니라 설명 및 권장 사항과 같은 이유를 제공합니다. 또한 다양한 비동기 구현 기법이 Salesforce Platform에서 작동하고 규제되는 방식에 대한 인사이트를 제공합니다.

어떤 기술을 사용할 것인지 결정할 경우 가장 적합한 기술에 대한 일반적인 사용 사례의 빠른 매핑을 제공하는 집중된 비동기 처리 결정 가이드가 있습니다.

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

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

이 가이드는 Salesforce Lightning Platform 내의 비동기 처리에만 중점을 두고 있습니다. 비동기 통합 패턴에 대한 정보를 원하는 경우 이벤트 기반 아키텍처를 참조하십시오.

• 비동기식 처리를 사용하기 전에 사용 사례가 패턴에 맞는지 확인하십시오. 비동기 패턴에는 SLA가 없으며, 다중 총괄자 메커니즘이 적용되며, 라이센스를 기반으로 정의된 수용력 제한이 있을 수 있으며, Salesforce Platform 내 비동기 인프라에 할당된 리소스의 유한적인 특성으로 인해 처리 지연이 발생할 수 있습니다. 사용자가 작업을 계속하기 전에 시스템에서 응답해야 하는 시나리오에서 비동기 처리를 사용할 때 이러한 제한 사항을 심각하게 고려하십시오.
• Salesforce를 통한 비동기식 처리는 경계 없는 확장 요구에 맞는 솔루션이 아닙니다. Salesforce Platform은 무제한으로 확장되지 않으며 비동기 패턴은 여전히 제한이 적용됩니다. 비동기 처리는 스레드를 사용하며, 이는 CPU가 명령 스트림을 실행하기 위해 필요한 컨텍스트 정보를 포함합니다. 스레드는 병렬로 실행할 수 있습니다. CPU의 사용 가능한 스레드는 제한되므로 플랫폼에 사용 가능한 스레드를 최대한 효율적으로 사용하도록 하는 메커니즘이 마련되어 있습니다. 플랫폼의 흐름 제어 메커니즘은 조직이 너무 많은 스레드를 소비하고 다른 조직에 부정적인 영향을 미치지 않도록 방지합니다. 플랫폼의 공정 사용 알고리즘은 조직이 각 메시지 유형에 사용할 수 있는 스레드 수를 제어합니다.
• 트랜잭션이 실제로 비동기식인 경우 파악하기. 일부 아키텍처 패턴은 종단간 비동기식으로 동작합니다. 그러나 다른 프로세스는 클라이언트 또는 브라우저 측에서 비동기식으로 동작하지만 서버 측 요청을 직렬화하면 동기식 총괄자 제한이 적용됩니다.
• Salesforce Platform에서 대규모 아웃바운드 통합을 구축하려면 비동기 Apex를 통한 콜아웃 대신 플랫폼 이벤트 및 강력한 미들웨어를 사용합니다. 플랫폼에서 사용할 수 있는 비동기 스레드 수는 제한되므로 비동기 Apex 통한 아웃바운드 통합의 확장성이 제한됩니다. 조직에 메시지 용량이 많은 아웃바운드 통합이 있고 사용 가능한 스레드를 초과하고 처리 시간이 긴 경우 비동기 Apex 사용하면 불가피하게 지연이 발생합니다.
• 비동기식 처리를 사용할 때 모니터링을 포함해야 합니다. 모니터링을 통해 주요 성능 사고가 발생하기 전에 가능한 한 빨리 문제를 감지하고 문제를 수정할 수 있습니다.
• 극적인 부하를 유발할 수 있는 이벤트를 고려하십시오. 비동기 프로세스를 설계할 때 작업 부하 급증 및 Lull을 예측 가능한 방식으로 관리할 수 있는지 확인하십시오. 구현에서 전력 중단과 같은 예기치 않은 이벤트를 처리하는 방법을 고려하고 데이터 손실 또는 기능 손실을 완화하는 보안 조치를 설계합니다.

서버측 비동기 처리를 위한 접근 방식을 선택할 때 먼저 조직의 요구 사항 및 사용 가능한 자원을 평가합니다. 목표는 구현 및 유지 관리 비용을 최소화하는 동시에 확장성을 유지하고 제한 위반 가능성을 최소화하는 접근 방식을 선택하는 것입니다. 이 목표는 다음 섹션에 설명된 기술적 고려 사항 및 팀 구성에 따라 다릅니다. 예를 들어, 프로 코드 솔루션을 유지 관리할 수 있는 팀에 Apex 개발자가 있는지 고려하십시오. 그렇지 않으면 선언적 접근 방식이 더 적합할 수 있습니다. 또한 다른 도구에 다른 집합의 제한이 적용될 수 있다는 점에 유의하십시오.

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

아키텍처에 대한 고려 사항:

• 몇 개의 동시 프로세스가 필요합니까?
• 동시 프로세스가 서로 상호 작용하는 방식
• 각 프로세스 내에서 실행되는 SOQL 쿼리는 몇 개입니까?
• 각 프로세스 내에서 실행되는 DML 작업은 몇 개입니까?
• 각 프로세스가 실행되기까지 얼마나 걸립니까?
• 프로세스가 특정 타이밍에 얼마나 민감합니까?

Salesforce Platform의 다중 테넌트 아키텍처는 많은 테넌트(조직)의 다양한 요구 사항을 격리하고 동시에 지원합니다. 이 가이드에 포함된 모든 비동기식 Apex 메서드는 Salesforce Platform의 동일한 비동기식 인프라 내에서 실행됩니다. 두 가지 기본 적용 메커니즘인 플로 제어 및 공정 사용에 따라 관리되는 메시지 대기열 프레임워크를 사용합니다.

플로 제어 및 공정 사용 메커니즘을 통해 단일 테넌트가 너무 많은 서버 자원을 사용하고 나머지 테넌트에 충분한 자원을 남길 수 없습니다. 이러한 메커니즘의 작동 방식을 이해하는 것이 유용하지만 다음 섹션에 간략하게 설명된 모범 사례와 같은 비동기식 처리 모범 사례를 수행하면 문제가 발생할 가능성이 크게 줄어듭니다.

플랫폼의 플로 제어 메커니즘은 단일 조직이 주어진 메시지 유형을 홍보하지 않도록 방지하므로 스레드를 너무 많이 사용하고 다른 조직에 부정적인 영향을 미칩니다. 프레임워크가 메시지 유형과 연결된 대기열에 새 항목을 추가하기 전에 대기열에 있는 처음 몇 천개의 기존 항목을 확인합니다. 대부분의 기존 항목이 동일한 조직과 연결되어 있고 해당 조직에 이미 작업자 스레드에 항목이 있는 경우 새로 추가된 항목이 대기열의 뒤쪽으로 이동됩니다. 이 프로세스를 다시 대기열 지정이라고 합니다. 배치 Apex 및 대량 API 프로세스에서는 대기열에 대량 항목을 동시에 삽입하므로 재대기열 지정이 일반적으로 발생합니다.

플랫폼의 공정 사용 메커니즘은 계층 기반 시스템을 구현합니다. 시스템을 사용하면 Salesforce Platform의 각 조직이 향후, 대기 가능, 배치 메시지 유형을 포함하여 지정된 메시지 유형에 대한 처리 시간을 공정하게 할당할 수 있습니다. 한 조직이 동일한 메시지 유형에 대한 작업을 수행하기 위해 다른 조직이 대기하는 동일한 시간 동안 지정된 메시지 유형을 지배하는 경우 공정 사용 알고리즘은 조직에서 해당 메시지 유형에 사용할 수 있는 스레드 수를 줄입니다.

비동기식 Apex 메서드를 사용하는 장점은 SOQL 쿼리 제한 및 힙 크기 제한과 같은 일부 총괄자 제한이 더 높다는 것입니다. 그러나 이러한 방법에 지나치게 의존하지 마십시오. 비동기 인프라에 할당되는 유한한 자원으로 인해 Future, Queueable, Batch Apex 사용하는 것이 많으면 공정한 사용 및 플로 제어를 기반으로 한 제한으로 인한 처리 지연이 발생할 수 있습니다.

비동기 Apex 사용하는 아웃바운드 콜아웃은 비동기 Apex 제한에 포함됩니다. 일일 제한은 현재 적용 가능한 사용자 라이센스의 250,000개 또는 200배입니다. 더 큰 값입니다. 이 제한은 대량 사용 사례에 문제가 될 수 있습니다. 제한을 초과하면 비동기식 Apex 작업과 연결된 아웃바운드 콜아웃이 실패합니다.

또한 플랫폼에 사용 가능한 비동기 스레드 수가 제한되므로 비동기 Apex 통한 아웃바운드 통합의 확장성이 제한됩니다. 사용 가능한 스레드를 초과하는 대용량 아웃바운드 통합은 처리 시간이 길어지며 지연이 발생할 수 있습니다.

대량 사용 사례의 경우 다음과 같은 대체 접근 방식을 고려하십시오. 이러한 접근 방식의 API 호출은 일일 API 요청 제한에 포함됩니다. 이는 일일 비동기식 Apex 제한보다 상당히 높습니다. 따라서 이러한 접근 방식은 더욱 확장 가능합니다. 그러나 CPU에서 처리할 수 있는 동시 요청 수에 여전히 물리적 제한이 있습니다.

• 중간웨어 예약 가져오기. 비동기식 Apex 통해 데이터를 푸시하는 대신 미들웨어를 사용하여 예약에 따라 데이터를 가져오는 방식으로 대용량 아웃바운드 통합 작업과 관련된 지연을 방지합니다. MuleSoft Anypoint Platform과 같은 중간웨어는 기본 SOAP API 또는 REST API를 동기식으로 사용할 수 있으므로 지연이 거의 발생하지 않습니다(있는 경우). 중간웨어는 대용량 데이터에 기본 대량 API를 사용할 수도 있습니다.

• 플랫폼 이벤트 알림을 통해 중간 장치 가져오기. 아웃바운드 통합을 수행하기 위해 Future, Queueable 또는 Batch 비동기 Apex 대기열에 지정하는 대신 플랫폼 이벤트를 사용할 수 있습니다. 플랫폼 이벤트는 아웃바운드 정보를 직접 전달하거나 미들웨어 도구에 네이티브 API를 통해 필수 정보를 가져와 최종 대상으로 전달하도록 지시할 수 있습니다. 이러한 접근 방식에는 비동기 Apex 적용되는 지연이 적용되지 않습니다. 그러나 플랫폼 이벤트 제한은 여전히 적용됩니다.

대기 가능한 Apex 사용하면 광범위한 데이터베이스 작업 또는 외부 웹 서비스 콜아웃과 관련된 Apex 프로세스를 비동기식으로 실행할 수 있습니다. Queueable Apex를 사용하려면 Queueable 인터페이스를 구현하고 Apex 작업 대기열에 작업을 추가합니다. 이 접근 방식은 비동기식 Apex 작업이 자체 분리 스레드에서 백그라운드에서 실행되도록 하며 기본 Apex 논리의 실행을 지연하지 않습니다. 시스템 자원을 사용할 수 있게 되면 대기열에 지정된 각 작업이 실행됩니다.

대기 가능 Apex 비동기 Apex 진화를 나타냅니다. 다음을 포함하여 Apex 미래 방법에 사용할 수 없는 기능을 제공합니다.

• 작업 ID: System.enqueueJob 메서드를 호출하여 작업을 제출하면 메서드가 새 작업의 ID를 반환합니다. 이 ID를 사용하여 작업을 식별할 수 있습니다. 진행 상태를 모니터링하려면 Salesforce 설정의 Apex 작업 페이지를 보거나 AsyncApexJob 개체를 쿼리합니다.
• 비기본 유형 지원: 대기 가능한 클래스에는 sObjects 또는 사용자 정의 Apex 유형과 같은 비기본 데이터 유형의 구성원 변수가 포함될 수 있습니다.
• 작업 체인화 지원: 실행 중인 작업에서 두 번째 작업을 시작하여 대기 가능 작업을 함께 연결할 수 있습니다. 이 기술은 프로세스 종속성과 관련된 시나리오를 해결하는 데 도움이 됩니다.
• 최대 깊이 제어: 최대 스택 깊이로 대기 가능 작업을 구성하여 작업 체인이 예기치 않은 반복으로 끝나지 않도록 할 수 있습니다.
• 중복 제거 서명: 대기 가능한 작업은 중복 작업을 감지하고 제거하는 옵션 서명을 제공합니다.
• 구성 가능한 지연: 대기 가능 작업이 실행되기까지 최대 10분의 지연 시간을 정의할 수 있습니다.
• 트랜잭션 마무리자: 대기 가능 작업에 작업 후 순서를 첨부하고 결과를 기반으로 관련 작업을 수행할 수 있습니다. 예를 들어, 트랜잭션 파이널라이저는 처리되지 않은 예외로 인해 실패한 대기 가능 작업을 최대 5회까지 다시 대기열에 지정할 수 있습니다.

Salesforce는 대기열 기반 프레임워크를 사용하여 비동기 프로세스를 처리합니다. 이 대기열은 조직 전반의 요청 작업 부하 균형을 맞추는 데 사용됩니다. 조직이 이 대기열을 최대한 효율적으로 사용하도록 하려면 다음을 수행합니다.

• 대량의 최종 사용자 활동 또는 통합 API 호출으로 생성된 작업에서 직접 Future 또는 Queueable 메서드를 대기열에 지정하지 마십시오. 이 접근 방식은 일일 비동기식 Apex 한도를 빠르게 소진할 수 있으므로 심각한 비즈니스 영향을 미칠 수 있습니다.
• 동기 작업당 두 개 이상의 비동기 작업을 대기열에 지정하지 마십시오. 단일 동기 작업에서 여러 비동기 메서드가 대기열에 지정되면 비동기 활동이 동시에 실행되며 행 잠금 충돌 및/또는 행 잠금 시간 초과 오류에 기여합니다.
• 비동기 대기열에 많은 수의 Future 또는 Queueable 메서드를 추가하지 마십시오.
• Future 및 Queueable 메서드가 가능한 한 빨리 실행되는지 확인합니다. 향후 메서드를 실행하는 데 시간이 더 오래 걸릴수록 대기열에서 이후의 요청이 지연될 가능성이 높습니다. 배치 작업의 빠른 실행을 보장하려면 웹 서비스 콜아웃 시간을 최소화하고, 향후 방법에 사용되는 쿼리를 조정하고, 프로세스 빌더 프로세스, 워크플로 규칙, 플로 및 Apex 트리거를 비롯한 기타 개체 자동화를 최적화합니다.
• 비동기 메서드를 대규모로 테스트합니다. 처리할 최대 메서드 수를 생성하는 환경을 사용합니다. 이 테스트를 통해 프로덕션 환경에서 성능 문제 또는 제한이 발생하는지 여부를 판단할 수 있습니다. 누적 일일 제한에 미치는 영향도 고려하십시오.
• Future 또는 Queueable 메서드 대신 배치 Apex 사용하여 대량의 레코드를 처리합니다. 배치 Apex 수천 개의 레코드에 대해 실행되는 복잡하고 장기 실행되는 프로세스를 처리할 수 있으며, 더 많은 자원을 사용할 수 있는 시간 동안 실행되도록 예약할 수 있습니다.

예약된 Apex 사용하여 cron 식으로 정의된 대로 지정된 시간 및 반복 빈도로 실행합니다. Cron 식을 통해 Apex 예약하는 작업은 비동기식 프로세스이지만, 작업이 시작되면 기본 코드가 동기식으로 실행됩니다. 예약된 Apex 일별 또는 주별 서비스 점검 과업에 적합합니다.

• 예약된 Apex 작업은 한 번에 100개만 가능합니다. 이 제한을 피하려면 예약된 Apex 대신 Apex 코드를 호출하는 일정 트리거 플로를 사용하는 것이 좋습니다.
• 트리거에서 강의 일정을 예약하려는 경우에는 주의를 기울여야 합니다. 트리거가 제한보다 더 많은 예약 클래스를 추가하지 않도록 보장할 수 있어야 합니다. 특히 API 대량 업데이트, 가져오기 마법사, 사용자 인터페이스를 통한 대량 레코드 변경, 한 번에 두 개 이상의 레코드를 업데이트할 수 있는 모든 사례를 고려하십시오.
• 향후 최대 10분까지 예약해야 하는 일회성 과업의 경우 지연된 대기 가능 작업을 사용합니다. 이 접근 방식은 예약된 작업 100개 제한에 포함되지 않습니다.
• 예약된 Apex 동기 제한이 있는 동기 컨텍스트에서 실행됩니다.
• 예약된 작업이 실행되는 기간을 고려합니다. 장기 실행 작업은 다음에 예약된 작업의 시작과 겹칠 수 있습니다.
• Salesforce가 지정된 시간에 클래스를 실행하도록 예약합니다. 서비스 가용성에 따라 실제 실행이 지연될 수 있습니다. 서비스 점검 가동 중지 시간 동안 실행되도록 예약된 작업은 서비스가 다시 시작되면 실행되도록 예약됩니다.
• 배치 작업을 대기열에 지정하는 유일한 목적으로 예약된 작업이 아닌 배치 작업을 예약하는 데 System.scheduleBatch를 사용합니다.

이전에는 Visualforce 컨트롤러 또는 Lightning 구성 요소 컨트롤러와 같은 동기식 Apex 트랜잭션 컨텍스트에서 실행되는 Apex 메서드에서 생성된 동기식 콜아웃이 장기 실행 요청에 대해 Apex 동시 제한이 적용되었습니다. Winter '19부터 동기식 콜아웃은 더 이상 장기 실행으로 간주되지 않습니다. Apex 연속은 원래 동기식 콜아웃에 대한 솔루션으로 생성되었지만, 오랫동안 실행되는 요청으로 인한 몇 가지 추가적인 이점을 제공합니다.

• 단일 동기 작업은 최대 3개의 연속 작업을 수행할 수 있습니다. 새 연속 작업을 수행하기 전에 이전 연속을 완료해야 합니다.
• 각 연속 작업은 최대 3개의 콜아웃을 동시에 실행할 수 있습니다.
• 연속 작업에서 수행한 모든 콜아웃이 완료되면 플랫폼에서 연속 콜백 메서드를 호출하여 결과를 처리합니다.

연속은 원래 동기식 작업에 비동기식으로 실행되지만, Apex 연속과 기타 비동기식 Apex 기술(예: future methods, Queueable 또는 Batch)에는 주요 차이가 있습니다. 주요 차이점은 다음과 같습니다.

• 연속은 어떠한 방식으로도 대기열에 지정되지 않습니다.
• 연속은 일일 비동기 Apex 실행 제한에 영향을 미치지 않습니다.
• Continuations는 응용 프로그램 서버의 스레드 컨텍스트를 중량 Apex 플랫폼 스레드에서 콜아웃만 수행하는 경량 스레드로 전환합니다. 최대 120초까지 실행될 수 있는 콜아웃을 실행하기 위해 연속을 사용하면 응용 프로그램 서버 메모리를 크게 절약할 수 있습니다.
• 원래 계속은 Visualforce JavaScript 원격 호출에서만 실행할 수 있었습니다. 그러나 Summer '19부터 Lightning 구성 요소 프레임워크에 연속 기능이 공식적으로 추가되었으므로 Visualforce 필요하지 않습니다.

플랫폼 이벤트는 Salesforce Platform의 순전히 이벤트 중심 아키텍처 구현입니다. 이 유형의 아키텍처와 관련된 구성 요소에 대한 자세한 내용은 Event-Driven Architecture의 아키텍처 가이드에서 확인할 수 있습니다.

플랫폼 이벤트 및 플랫폼 이벤트 트리거/플로는 비동기식 Apex 실행하는 대안이 될 수 있습니다. 또한 플랫폼 외부 처리를 호출하는 훌륭한 방법입니다. 예를 들어, Amazon Web Services(AWS) 이벤트 릴레이 및 플랫폼 이벤트의 조합을 사용하여 AWS 람다에서 서버리스 컴퓨팅 기능을 호출할 수 있습니다. 플랫폼 이벤트 트리거 또는 플로에서 불가능한 콜아웃 없이 상대적으로 빠르게 수행되는 작업은 플랫폼 이벤트/트리거 또는 이벤트/플로 조합에 적합한 후보입니다.

공개 후 커밋을 통해 버스에 게시된 이벤트는 순서대로 전달되며 트리거 또는 플로에서 별도의 동기식 컨텍스트에서 대량 처리할 수 있습니다. 컨텍스트는 동기식이며 모든 동기식 총괄자 제한이 적용됩니다. 플랫폼 이벤트 트리거/플로 배치 크기를 신중하게 선택하여 제한에 도달하지 않도록 합니다.

• 이벤트가 이벤트 버스에 게시되므로 소비자가 사용할 수 있습니다. 이벤트 트리거(Apex 또는 flow)의 경우 이러한 이벤트는 앱 계층에서 사용 가능한 동기 스레드(이벤트 트리거/플로당 스레드 1개)로 발송됩니다. 이 프로세스에는 SLA가 없습니다.
• 게시 작업이 대기열에 추가되면 대기열 지정 프로세스의 결과가 Database.SaveResult 개체에 저장됩니다. 이러한 항목은 대기열 작업이 성공했는지 여부만 나타냅니다. 이벤트 버스를 통해 게시된 이벤트의 최종 결과를 가져오려면 Apex 게시 콜백을 구현합니다. 이 추가 정보를 사용하면 실패한 이벤트 다시 게시를 시도하는 등 추가 작업에 대한 결정을 내릴 수 있습니다.
• 플랫폼 이벤트는 비동기식 Apex와 동일한 제한이 적용되지 않지만 자체 규제 제한이 적용됩니다. 제한이 있는 문제가 발생할 경우 특정 이벤트가 의도한 것보다 더 많은 할당을 사용하고 있는지 확인하기 위해 고급 이벤트 사용 메트릭을 활성화할 수 있습니다. 이벤트 트리거에 더 많은 처리량이 필요한 경우 단일 스트림이 아닌 동시에 이벤트를 처리하는 데 병렬 구독을 사용하는 것이 좋습니다. 병렬 구독을 사용하면 Apex 플랫폼 이벤트 트리거를 확장하여 대용량 이벤트를 처리할 수 있습니다. 병렬 구독은 사용자 정의 대용량 플랫폼 이벤트에 사용할 수 있지만 표준 이벤트 또는 변경 이벤트에는 사용할 수 없습니다.
• 플랫폼 이벤트에는 다음과 같은 두 가지 게시 동작 옵션이 있습니다.
  • 즉시 게시: 최종 데이터베이스 커밋 전에 트랜잭션 중에 즉시 이벤트가 게시됩니다. 이 방식으로 게시된 이벤트는 순서에 따라 게시되지 않습니다.
  • 커밋 후 게시: 데이터베이스 트랜잭션이 성공적으로 커밋된 시점에 이벤트가 게시됩니다. 이 방식으로 게시된 이벤트는 순서에 따라 게시됩니다.

트랜잭션 성공 및 커밋 여부 또는 실패 및 롤백 여부와 상관없이 로깅과 같은 사용 사례에 즉시 게시를 사용하는 것이 좋습니다. 플랫폼 이벤트 트리거에서 사용되는 플랫폼 이벤트를 즉시 게시할 수 있습니다. 그러면 플랫폼 이벤트 트리거가 데이터베이스 행 잠금을 게시한 트랜잭션과 경쟁합니다. 플랫폼 이벤트를 즉시 게시하기 전에 모든 디자인을 철저하게 검토하여 이 시나리오를 피하십시오.

비동기 플로는 비동기 Apex 대한 하위 코드 대안을 제공합니다. 다른 비동기식 처리의 경우와 마찬가지로 자원을 사용할 수 있는 경우 백그라운드에서 실행됩니다. 또한 비동기 플로에는 SLA가 없으며, 예측할 수 없는 대기 시간이 있을 수 있습니다.

예약 경로는 특정 시간에 실행되도록 cron 트리거를 기반으로 합니다. 레코드가 생성, 업데이트 또는 삭제될 때 실행되며 레코드 변경 사항과 관련하여 자동화를 실행할 시기를 세부적으로 제어할 수 있습니다. (예: 과업 기한 1시간 전에 사용자에게 이메일을 보냅니다.) 동기 트랜잭션에 대기열에 지정된 최대 50개의 메서드에 제한되는 Apex future 메서드와 달리 예약된 플로 작업에는 현재 트랜잭션당 최대 대기열 제한이 없습니다. 그러나 예약 경로의 정의 내에 배치 크기 구성이 있어 예약 경로 플로 실행에서 처리되는 레코드 수를 약간 제어할 수 있습니다.

레코드 트리거 플로에 비동기 경로를 추가할 수 있습니다. 백그라운드에서 실행되며 플로를 처음 트리거한 트랜잭션의 실행을 지연하지 않습니다. 비동기 경로를 사용하여 장기 실행 작업 또는 자체 시간에 실행하려는 작업을 실행할 수 있습니다. 비동기 경로는 플로를 트리거한 레코드의 일부가 아닌 관련 레코드의 값을 업데이트해야 할 때 발생하는 혼합 DML 오류를 방지하는 데 도움이 됩니다.

참고: 아웃바운드 메시지는 기존 기능이며 플랫폼 이벤트(이전 섹션에 설명됨)는 보다 현대적인 접근 방식을 제공하며 유연성을 높입니다. 플랫폼 이벤트는 이벤트 중심 통합을 위한 Salesforce의 권장 패턴입니다.

아웃바운드 메시지는 SOAP API를 통해 비동기식 아웃바운드 통신을 수행하는 수단을 제공합니다. Salesforce에 구성되면 아웃바운드 메시지 정의가 외부 웹 서비스 공급자가 사용할 수 있는 SOAP WSDL을 생성합니다. 워크플로 규칙, 프로세스 빌더 프로세스 또는 Lightning 저장 후 플로 트리거에서 아웃바운드 메시지를 트리거할 수 있습니다. 아웃바운드 SOAP 메시지에 알림을 최대 100개까지 포함할 수 있습니다. 각 알림에는 개체 ID와 관련 sObject 데이터에 대한 참조가 포함됩니다. 알림이 대기 중이지만 전송되기 전에 기본 개체의 정보가 변경되는 경우 중간 변경 사항이 아닌 최신 데이터만 전달됩니다.

생성된 WSDL을 사용하여 구성한 웹 서비스인 아웃바운드 메시지 수신기가 메시지를 수신하면 포함된 세션 ID 정보를 사용하여 Lightning Platform API를 호출하여 아웃바운드 메시지를 트리거한 Salesforce의 레코드를 업데이트합니다.

• 아웃바운드 메시지는 Future Methods, Queueable Apex, Batch Apex, Bulk API 등과 같은 활동을 실행하는 Salesforce의 대기열 기반 비동기 인프라를 통해 처리되지 않습니다. 대신 레코드가 OutboundMessage 개체에 로컬로 저장됩니다. 메시지가 발송되고 로컬 예약 백그라운드 프로세스를 통해 다시 시도됩니다.
• 아웃바운드 메시지 작업이 시작 자동화(예: 저장 후 플로 트리거)를 통해 실행될 때 동기식으로 메시지가 전송되지 않습니다. 대신 성공적으로 전송되거나 24시간 후에 삭제될 때까지 OutboundMessage 개체에 남아 있습니다.
• 아웃바운드 메시지의 무한 루프를 방지하려면 개체를 업데이트하는 사용자에게 아웃바운드 메시지 보내기 권한이 없는지 확인하십시오.

Email-to-Case는 일반적으로 동기식으로 작동합니다. 인바운드 Email-to-Case 요청을 처리하는 동기 스레드는 4개로 제한됩니다. 처리기의 동기식 형식은 이메일을 수신하는 인바운드 Salesforce 메일 서버(MTA)에 대한 연결을 유지합니다. 그러나 Email-to-Case를 비동기식으로 처리할 수 있는 이유는 다음과 같습니다.

• Email-to-Case에는 스레드 제한이 적용되며, 특히 앱 서버당 총 10개의 처리 스레드(동기식 처리를 위한 스레드 4개 및 비동기식 처리를 위한 스레드 6개)가 적용됩니다.
• 동기 이메일 처리기가 실행 시간 15초를 초과하는 경우 해당 특정 이메일 서비스 주소가 30분 동안 비동기식으로 표시됩니다. 해당 서비스 주소에 대한 후속 처리기 요청으로 인해 이메일 콘텐츠에 대한 참조와 함께 MessageTypeName = MAILCATCHER_EMAIL_TO_CASE에 대해 대기열에 지정되는 메시지가 나타납니다.
• 특정 조직 및 서비스 주소에 동기 스레드가 이미 사용 중인 경우 해당 서비스 주소에 대한 추가 요청이 비동기식으로 대기열에 지정됩니다.
• 동기식으로 처리되는 이메일에 행 잠금 시간 제한과 같은 오류가 발생하면 요청이 저장되고 비동기식으로 대기열에 지정됩니다.
• 동기식 처리 스레드를 사용할 수 없는 경우 요청이 비동기식으로 대기열에 지정됩니다.

• Email-to-Case를 구성할 때 중복 제거 옵션이 있지만 이메일이 처리될 때까지 첨부 파일의 중복 제거를 수행하지 않습니다. 이 중복 제거는 데이터베이스의 공간을 절약하지만 이메일 처리 시간은 줄이지 않습니다. 그러나 메시지 처리에 사용자 지정된 Apex Email-to-Case 처리기를 구현하여 성능을 향상할 수 있습니다. 이 구현은 총괄자 제한에 영향을 미치지 않지만 처리기에 데이터베이스에 적용되기 전에 이메일 메시지 및 모든 첨부 파일에 대한 액세스 권한을 부여합니다. 이 액세스를 사용하면 모든 포함된 첨부 파일에 대한 점검 합계를 계산하고 중복 파일, 잘 알려진 서명 사진 또는 원하지 않는 파일 유형 등 불필요한 항목을 삭제할 수 있습니다.
• Salesforce Files에 이메일 첨부 파일을 커밋하면 이메일 처리 시간이 대부분 소요됩니다. 연락처 또는 연락처의 회신 응답이 증가하고 이메일 체인이 커지면 각 이메일의 처리 시간이 증가합니다. "새 콘텐츠로만 회신" 이메일 옵션을 선택하지 않으면 이메일 체인이 각 회신에 따라 증가합니다. 따라서 처리 시 첨부 파일 중복 제거를 구현하는 논리와 함께 Apex Email-to-Case 처리기를 사용하는 것이 좋습니다.
• 처리의 일환으로 Apex 트리거를 호출하더라도 Email-to-Case 처리기는 동시 Apex 제한에서 면제됩니다.

대량의 레코드를 비동기식으로 처리하려면 다음 접근 방식을 고려하십시오.

배치 Apex 사용하여 수천 개의 레코드를 포함하는 복잡한 장기 실행 프로세스를 구축할 수 있습니다. 배치 Apex 레코드 집합을 분할하고 관리 가능한 청크로 처리하여 작동합니다. 예를 들어, 매일 밤 실행되고 특정 날짜보다 오래된 레코드를 보관소에 추가하는 보관 솔루션을 구축할 수 있습니다. 또는 모든 계정 및 기회를 매일 밤 확인하고 사전 정의된 기준 집합을 기반으로 필요한 업데이트를 수행하는 데이터 정리 작업을 구축할 수 있습니다.

• 일괄 처리 Apex는 비동기식 Apex가 동기식 Apex보다 더 높은 한도를 가지고 있으므로 대용량 데이터를 처리하는 데 가장 적합합니다. 배치 Apex 대기열 관리의 오버헤드가 적은 대량 작업을 사용하므로 배치당 더 많은 항목을 처리할 때 더 효율적으로 수행할 수도 있습니다. 따라서 대기열 홍수를 통해 흐름 제어 메커니즘을 트리거하지 않고 일일 비동기식 Apex 한도를 소모하지 않으려면 범위 크기가 작거나 처리 시간이 빠른 배치를 만들지 마십시오.
• 대량의 최종 사용자 활동 또는 통합 API 호출으로 생성된 작업에서 배치 작업을 직접 대기열에 지정하지 마십시오. 이 접근 방식은 Flex 대기열을 빠르게 소모할 수 있습니다. 트리거에서 배치 작업을 호출하려는 경우 트리거가 제한보다 더 많은 배치 작업을 추가하지 않도록 해야 합니다.
• 배치 Apex 최대 5개의 동시 스레드로 제한되므로 향후 메서드 또는 대기 가능한 Apex 처리량이 훨씬 더 제한됩니다.
• 실시간 또는 실시간에 가까운 응답이 필요한 프로세스에 자원을 확보하기 위해 대용량 데이터와 관련된 배치 작업을 피크 외 시간에 실행하도록 예약하는 것이 좋습니다.
• System.scheduleBatch를 호출하면 플랫폼에서 지정한 시간에 작업을 실행하도록 예약합니다. 서비스 가용성에 따라 실제 실행이 해당 시간에 또는 그 이후에 발생합니다.
• 스케줄러는 시스템 컨텍스트에서 실행됩니다. 실행을 예약한 사용자에게 클래스를 실행할 수 있는 권한이 있는지 여부와 상관없이 모든 클래스가 실행됩니다.
• System.scheduleBatch를 사용하여 예약된 배치 작업에는 모든 예약된 Apex 제한이 적용됩니다. 배치 작업이 대기열에 지정된 후(대기 중 또는 대기 중 상태) 모든 배치 작업 제한이 적용되며, 작업은 더 이상 예약된 Apex 제한에 포함되지 않습니다.
• 반복 일정이 있는 배치 작업의 경우 새 작업이 실행되기 시작할 때 이전 작업이 계속 실행 중인 경우 올바른 동작을 고려하십시오.
• 동기식 Apex 트랜잭션에서 대기열에 지정된 배치 작업은 플렉스 대기열을 사용합니다. 유연한 대기열은 언제든지 최대 100개의 항목으로 제한됩니다. 트랜잭션에서 더 많은 항목을 추가하려고 시도하는 경우 플랫폼에서 오류를 생성하고 배치 작업을 제출하지 않습니다.
• 배치 작업의 콜아웃 및 기타 비트랜잭션 작업은 동일한 설계 고려 사항을 따라야 합니다. Salesforce 서비스 점검 가동 중지 시간 전에 대기 중인 배치 작업은 대기열에 남아 있습니다. 서비스 가동 중지 시간이 종료되고 시스템 자원을 사용할 수 있게 되면 대기열에 지정된 배치 작업이 실행됩니다. 가동 중지 시간이 발생할 때 배치 작업이 실행 중인 경우 서비스가 복원된 후 배치 실행이 롤백 및 다시 시작됩니다. 따라서 익스큐션 메서드를 여러 번 실행할 수 있으므로 콜아웃과 같은 비트랜잭션 작업을 다시 시도할 수 있습니다.
• 배치 작업을 구성하여 BatchApexErrorEvent 이벤트를 올려 오류 및 예외 시나리오를 처리합니다.

일정 트리거 플로는 지정된 시간 및 반복 빈도(매일, 매주 또는 한 번)에 따라 실행되도록 예약된 플로로 레코드 배치에서 작업을 수행합니다. (예: 모든 사례에서 매일 오전 2시에 "열림" 상태의 필드를 업데이트합니다.) 예약된 플로는 Cron 트리거 메커니즘을 통해 실행되며 대량 처리됩니다.

• 일정 트리거 플로는 호출당 200개의 레코드를 실행하지만 200개가 넘는 레코드가 있는 경우 여러 개의 동시 스레드를 사용하여 실행됩니다.
• 일정 트리거 플로는 동기 제한이 있는 동기 컨텍스트에서 실행됩니다.
• 현재 예약된 플로 호출당 처리되는 레코드 수를 제어할 수 있는 방법은 없습니다. 200개 이상의 레코드를 실행하는 경우 동시 Apex 오류가 발생할 수 있습니다.

대량 API는 REST 원칙을 기반으로 하며 대규모 데이터 집합에 대해 작업할 수 있도록 최적화되어 있습니다. 이를 사용하여 많은 레코드를 비동기식으로 삽입, 업데이트, 업서트, 쿼리 또는 삭제하고 나중에 결과를 처리할 수 있습니다. Salesforce Platform은 백그라운드에서 요청을 처리합니다. 이와 달리 SOAP API 및 REST API는 동기식 요청을 사용하며 한 번에 몇 개의 레코드를 업데이트하는 실시간 클라이언트 응용 프로그램에 최적화되어 있습니다. 두 가지 API를 모두 사용하여 많은 레코드를 처리할 수 있지만, 데이터 집합에 수천 개의 레코드가 포함되어 있으면 실용적이지 않습니다. 대량 API의 비동기 프레임워크는 수천 개에서 수백만 개의 레코드의 데이터를 간단하고 효율적으로 처리하도록 설계되었습니다.

대량 API를 사용하는 가장 쉬운 방법은 CSV 파일을 사용하여 Data Loader에서 레코드를 처리하는 데 사용하는 것입니다. Data Loader를 사용하면 자체 클라이언트 앱을 작성할 필요가 없습니다. 그러나 때로는 고유한 요구 사항에 따라 사용자 정의 앱을 작성해야 합니다.

Salesforce Platform 내에서 사용할 수 있는 대량 API는 두 개입니다.

• Bulk API 2.0은 최신 API입니다. 간소화되고 쉽게 사용할 수 있는 워크플로를 제공하며 개선 사항에 초점을 맞춥니다.
• 원래의 Bulk API는 여전히 완전히 지원되지만 더 이상 향상되지 않습니다. 가능한 경우 대량 API 2.0을 사용하는 것이 좋습니다.

API 제한에 대한 자세한 내용은 Bulk API 제한 및 Bulk API 2.0 제한을 참조하십시오.

Salesforce Platform에서 비동기 처리를 구축하거나 고려할 경우 이 가이드를 참조하십시오. 사용 가능한 옵션의 전체 범위와 특정 사용 사례에 맞는 방법을 이해하는 것이 좋습니다. 특히 현재 솔루션이 제대로 작동하는 경우 기존 아키텍처를 변경하기 전에 현재 환경을 철저하게 평가해야 합니다.