확장성 패턴 | 패턴 |

확장성 패턴

잘 설계된 신뢰성 → 확장성 및 용량 계획에 대해 자세히 알아보기

패턴

찾을 위치	유사성
SOQL 쿼리 효율	관련 개체별로 별도의 쿼리 대신 관계 쿼리(Contacts, Cases__r)를 사용하여 쿼리를 통합합니다. 모든 필요한 데이터를 트랜잭션당 한 번 쿼리합니다. 동기 트랜잭션의 경우 <50개의 쿼리 대상, 비동기 트랜잭션의 경우 <100개(제한: 동기화 100개, 비동기화 200개). 30-50% 버퍼를 제한 미만으로 유지합니다.
DML 작업 대량 처리	목록에 레코드를 수집하고 트랜잭션당 개체 유형당 단일 DML 문을 실행합니다. 부분 성공 동작을 제어하는 allOrNone 매개 변수와 함께 Database.insert/update/delete를 사용합니다. 트랜잭션당 <75개의 DML 문 목표(제한: 150). 배치는 DML 사용량을 N 문에서 1으로 줄입니다.
힙 크기 관리	필수 필드만 쿼리합니다(SELECT * 패턴을 피하십시오). 대규모 결과 집합을 청크로 처리합니다. 자유 메모리로 처리한 후 컬렉션을 지웁니다. 동기 컨텍스트의 대상 <4MB 힙(제한: 6MB), <8MB 비동기식(제한: 12MB). 힙 초과 오류는 청크 또는 스트리밍 패턴이 필요하다는 의미입니다.
CPU 시간 최적화	루프의 계산 복잡성을 최소화합니다. 중첩된 목록 반복(O(n2) 대신 검색에 지도를 사용합니다(O(1)). 대량 계산을 비동기 컨텍스트에 오프로드합니다. 동기 트랜잭션의 대상 <7,000ms CPU(제한: 10,000ms), <40,000ms 비동기식(제한: 60,000ms).
SOQL 쿼리 행	합리적인 결과 집합 크기를 반환하는 쿼리를 설계합니다. LIMIT 절을 사용하여 결과를 극대화합니다. 동기 컨텍스트에서 쿼리당 <25,000개의 행 목표(제한: 50,000). 제한에 가까운 쿼리는 페이지 매김을 사용하거나 배치 Apex 또는 대기 가능을 사용하여 비동기식 처리로 이동해야 합니다.
API 호출 할당	시스템 개요를 통해 24시간 API 제한 소비를 모니터링합니다. 레코드별 호출 대신 배치 API 작업 플랫폼 캐시를 사용하여 자주 액세스한 참조 데이터를 캐시합니다. 급증을 수용하기 위해 일일 API 제한의 <70%를 목표로 지정합니다. API 제한은 Edition 및 라이센스 수에 따라 다릅니다.
콜아웃 제한	외부 콜아웃 통합: 외부 시스템에서 지원하는 경우 여러 레코드를 단일 API 요청에 배치합니다. 요청 대기열을 구현하여 콜아웃을 직렬화합니다. 트랜잭션당 총 120초의 콜아웃 시간을 준수합니다. 제한: 트랜잭션당 100개의 콜아웃 콜아웃이 많은 통합을 위해 비동기 처리를 설계합니다.
코드(Apex, Aura, LWC)	대량 처리 패턴을 구현합니다. 개별 레코드가 아닌 컬렉션을 처리하고, 한 번 쿼리하고 지도에서 캐시하며, 개체 유형당 단일 DML을 실행합니다. 관계 쿼리를 사용하여 SOQL 소비를 최소화합니다. 대규모 데이터 집합에 중첩된 루프를 피하는 효율적인 알고리즘을 적용합니다.

안티 패턴

찾을 위치	불만 사항
루프의 SOQL	문제: 레코드 컬렉션을 처리하는 루프에 대해 내부에서 SOQL 쿼리를 실행합니다. 영향: 100개 이상의 레코드에서 쿼리 제한 초과 오류 발생(제한: 트랜잭션당 100개의 쿼리). 해결: 루프 전에 쿼리를 한 번 수행하고 관계 필드에 따라 매핑에 결과를 저장합니다. 맵 내 루프(불량 처리 패턴)에서 조회합니다.
루프의 DML	문제: 루프에 대해 내부에서 삽입/업데이트/삭제 문 실행 영향: DML 제한 초과 오류는 150개 이상의 레코드에서 발생했습니다(제한: 트랜잭션당 DML 문 150개). 해결: 루프 내에서 목록에 레코드를 수집하고 루프가 완료된 후 단일 DML 문을 실행합니다.
총괄자 제한 버퍼 없음	문제: 정상적인 조건에서 총괄자 제한의 95% 이상을 사용하는 트랜잭션을 설계합니다. 영향: 약간의 부하가 증가하는 동안 프로덕션 실패가 발생하며, 가장자리 사례에 대한 용량이 없습니다. 해결: 제한의 70%를 운영 제한으로 지정합니다. 급증 및 극단 사례에 30% 버퍼를 예약합니다.
중첩 루프 카르테시아 제품	문제: O(n2) 작업을 생성하는 두 개의 대규모 컬렉션을 반복하는 중첩된 루프입니다. 영향: CPU 제한이 오류를 초과하고 임시 개체에서 힙 제한을 초과했습니다. 해결: O(n2)를 O(n)로 변환하는 지도 기반 조회를 사용합니다. 외부 루프 키를 수집하고 관련 레코드를 한 번 쿼리한 후 내부 루프에서 조회를 수행합니다.
힙 누적	문제: 대규모 쿼리를 로드하면 청크로 처리하지 않고 메모리에 전달됩니다. 영향: 힙 제한을 초과한 오류(6MB 동기화, 12MB 비동기화). 해결: 필요한 필드만 쿼리합니다. 각 배치 후 컬렉션을 지우는 배치로 처리합니다. 수백만 개의 레코드 처리에 배치 Apex 함께 QueryLocator를 사용합니다.
필드 수준 필터링 없음	문제: 필요한 경우 모든 필드(명시 또는 암시적)를 선택합니다. 영향: 과도한 힙 소비, 쿼리 실행 속도가 느려지고 SOQL 행 제한에 불필요하게 접근했습니다. 해결: 처리에 필요한 필드만 선택합니다. 관계 표기를 사용하여 별도의 쿼리 대신 단일 쿼리에서 관련 데이터를 가져옵니다.
동기식 처리 과도한 사용	문제: 사용자 트랜잭션 내에서 대용량 데이터를 동기식으로 처리합니다. 영향: 사용자가 여러 초 동안 작업을 대기하고 CPU/힙 제한을 초과하여 사용자를 차단했습니다. 해결: 대량 처리를 비동기 컨텍스트로 이동합니다(배치, 대기 가능, 플랫폼 이벤트). 상태 폴링을 통해 사용자에게 즉각적인 응답을 제공합니다.

패턴

찾을 위치	유사성
비동기식 처리	대량 레코드 볼륨(백만 개)을 처리하려면 배치 Apex 사용합니다. 체이닝을 사용하는 복잡한 다단계 오케스트레이션에 대기 가능한 Apex 사용합니다. 이벤트 중심 분리에 플랫폼 이벤트를 사용합니다. 정기적인 서비스 점검에 예약된 Apex 사용합니다. 사용 사례에 비동기 패턴 일치: 볼륨용 배치, 복잡성용 대기 가능, 분리용 이벤트
배치 Apex 구현	선택적 QueryLocator를 반환하는 시작 방법을 설계하여 처리된 레코드를 최소화합니다. 레코드 복잡성(실행당 레코드 200~2,000개)을 기반으로 배치 크기를 구성합니다. 처리량을 줄이므로 필요한 경우에만 상태 지정 인터페이스를 구현합니다. AsyncApexJob의 성공/실패를 모니터링합니다. 배치는 청크당 전용 총괄자 제한을 제공합니다.
플랫폼 이벤트 아키텍처	다운스트림 처리가 필요한 상태 변경 사항에 대한 이벤트를 게시합니다. CometD를 통해 플랫폼 이벤트 개체 또는 외부 구독자의 Apex 트리거를 사용하여 구독합니다. 동일한 구독자 설계(재생 시 이벤트를 여러 번 전달할 수 있음) 임시 구독자 실패 복구 시 72시간 보존을 사용합니다.
날짜 기반 파티션	시간 구간의 데이터 처리: 현재 달, 지난 분기, 올해. 내역 데이터를 주요 개체 또는 외부 저장소에 보관합니다. 시간 기반 파티션을 사용하면 병렬 배치 작업이 동시에 다른 날짜 범위를 처리할 수 있습니다. 대부분의 쿼리는 날짜별로 자연스럽게 필터링하여 효율적으로 작업을 수행합니다.
레코드 유형 파티션	다양한 레코드 유형을 독립적으로 처리합니다. 레코드 유형별로 별도의 배치 작업을 예약하여 병렬화를 활성화합니다. 레코드 유형은 독립적인 처리를 정당화하는 고유한 비즈니스 프로세스와 관련이 있는 경우가 많습니다. 조직당 최대 5개의 동시 배치 작업은 전략적 분할이 필요합니다.
지역 기반 파티션	소유자, 디비전 또는 영역별로 분할하여 배포를 처리합니다. 병렬 배치 작업에서 각 지역, 사업부 또는 세일즈 영역을 처리합니다. 지역 기반 분할은 공유 모델을 활용합니다. 각 배치 작업은 데이터를 자연스럽게 필터링하는 특정 사용자 그룹의 컨텍스트에서 실행됩니다.
캐싱 전략	자주 액세스하는 참조 데이터에 플랫폼 캐시(조직/세션 파티션)를 사용합니다. 캐시는 쿼리 및 API 소비를 줄입니다. 조직 및 세션 파티션을 전체MB 증분으로 할당합니다. 기본 용량은 버전에 따라 다르며 추가 용량은 블록으로 구매할 수 있습니다. 캐시 누락은 쿼리로 재배치되어야 합니다. 캐시 TTL은 데이터 변경 주기와 일치해야 합니다(정적 참조 데이터의 경우 시간, 세미동적 데이터의 경우 분).
플로 대량 처리	루프 및 컬렉션 변수를 사용하여 레코드 컬렉션을 처리하는 플로를 설계합니다. 레코드 컬렉션을 만들고 단일 레코드 가져오기를 수행하거나 단일 레코드 업데이트 요소로 컬렉션을 업데이트합니다. 루프 내에서 개별 레코드 작업을 피하십시오. 플로 대량 처리 패턴은 Apex Best Practice를 반영합니다.

안티 패턴

찾을 위치	불만 사항
순차적 처리만 해당	문제: 모든 5천만 개의 레코드를 24시간 이상 순차적으로 처리하는 단일 배치 작업 영향: 기타 처리, 서비스 점검 기간 소모, 사용자 대면 지연을 차단합니다. 해결: 날짜, 레코드 유형 또는 지역별로 데이터를 분할합니다. 동시에 독립 파티션을 처리하는 병렬 배치 작업을 실행합니다.
동기식 통합 종속성	문제: 동기식 콜아웃을 통해 외부 시스템 응답을 기다리는 동안 차단된 사용자 트랜잭션 영향: 외부 시스템 성능과 관련된 사용자 환경, 외부 중단 시 시간 초과 실패 해결: 비동기 통합에 플랫폼 이벤트를 사용합니다. 외부 시스템 가용성에서 사용자 트랜잭션을 분리합니다.
캐싱 레이어 없음	문제: 트랜잭션 전반에서 동일한 참조 데이터를 반복적으로 쿼리합니다. 영향: SOQL 소비 과도, API 제한 폐기물, 트랜잭션 실행 속도 저하 해결: 자주 액세스하는 참조 데이터에 대해 플랫폼 캐시를 구현합니다. 캐시는 총괄자 제한 소비를 줄이고 성능을 향상합니다.
배치 작업 스택	문제: 동시에 시작되는 20개가 넘는 배치 작업을 예약합니다. 영향: 대기열 깊이 구축, 동시 작업 5개 제한으로 인해 직렬화되고 완료 시간이 예측할 수 없습니다. 해결: 스태거 일정은 시간에 걸쳐 부하를 배포합니다. 동적 발송 논리를 사용하여 유사한 작업을 단일 배치로 통합합니다.
시/도 배치 과도한 사용	문제: 필요하지 않은 경우 Database.Stateful로 배치 Apex 구현 영향: execute() 호출 전반에서 인스턴스 구성원 변수가 불필요하게 직렬화되고 보존된 상태에서 잠재적인 힙이 누적됩니다. 해결: 실행 호출에서 상태를 유지해야 하는 경우에만 stateful을 사용합니다. 불필요한 시/도 직렬화 오버헤드가 발생하지 않도록 시/도 없는 배치를 선호합니다.
단일 스레드 플로 설계	문제: 반복당 개별 레코드 가져오기/업데이트 요소를 사용하여 루프 내에서 일대일로 레코드를 처리합니다. 영향: 총괄자는 레코드 수, 규모에 따른 트랜잭션 실패에 비례하여 소비를 제한합니다. 해결: 레코드를 컬렉션 변수로 수집하고, 단일 레코드 가져오기를 수행하고, 루프 외부의 단일 레코드 업데이트 요소로 컬렉션을 업데이트합니다.
비동기 재시도 전략 없음	문제: 실패한 비동기 작업이 자동으로 재시도되지 않으므로 수동으로 중재해야 합니다. 영향: 데이터 불일치, 수동 운영 부담, SLA 누락 해결: 기하성 백오프를 사용하여 자동 재시도를 구현합니다. 지속적인 대기열에 플랫폼 이벤트를 사용하여 재생할 수 있습니다. AsyncApexJob을 모니터링하고 지속적인 실패를 경고합니다.

패턴

찾을 위치	유사성
배치 및 대기 가능 선택 항목 비교	배치 Apex 사용하여 청크, 예약된 대량 작업, 데이터 마이그레이션으로 수백만 개의 레코드를 처리합니다. 다단계 통합 워크플로 및 체인화, 복잡한 개체 매개 변수가 필요한 작업, @future보다 더 나은 모니터링이 필요한 작업에 대기 가능한 Apex 사용합니다. Async Apex는 대기열별 할당이 아닌 배치, 대기 가능, 미래, 예약된 Apex 간에 24시간당 250,000번의 실행(DailyAsyncApexExecutions)을 공유합니다.
대기 가능 체인	현재 작업의 execute 메서드에서 다음 작업을 대기열에 지정하여 다단계 워크플로를 구현합니다. 체인은 콜아웃 → 구문 분석 응답 → 대기열 팔로우업 작업의 순차적인 처리를 활성화합니다. 대기 가능 실행당 최대 1개의 대기열이 런어웨이 체인을 방지합니다. 완료 감지를 사용하여 체인을 설계하여 무한 루프를 방지합니다.
@future 메서드 사용	복잡한 매개 변수(기본값만 해당) 및 체이닝이 필요하지 않은 간단한 비동기 작업에 @future를 사용합니다. 제한: Apex 트랜잭션당 50 @future 호출. @future는 가장 간단한 비동기 패턴을 제공하지만 가시성이 부족합니다. 작업 모니터링, 체인화, 복잡한 매개 변수가 없습니다. 새 개발 시 대기 가능을 선호합니다.
예약된 Apex 최적화	예약된 작업을 단일 예약 가능한 클래스에 통합하여 특정 처리기에 발송합니다. 조직당 최대 100개의 예약된 작업을 전략적으로 통합해야 합니다. 사용자 작업에 대한 충돌을 줄이기 위해 시간 외 시간에 일정을 예약합니다. 오케스트레이션에 예약된 Apex 사용하고 대량 처리를 배치 Apex 위임합니다.
플랫폼 이벤트 재생	구독자가 실패한 후 중복 이벤트, 연장된 중단 후 누락 이벤트 등 재생 시나리오를 처리하는 구독자를 설계합니다. 구독자당 마지막으로 처리된 ReplayId를 유지합니다. EventBus.getReplayId()를 사용하여 재생 및 새 이벤트를 감지합니다. 동일한 이벤트를 두 번 처리하면 동일한 결과가 생성됩니다.
연속 패턴	5초 이상의 응답 시간이 필요한 Lightning 구성 요소의 장기 실행 콜아웃에 Continuation을 사용합니다. 연속을 사용하면 병렬 작업에 대해 인식되는 성능을 향상하는 동시 120초 콜아웃이 여러 개 활성화됩니다. 제한: 요청당 연속 3개 시간 초과 처리를 구현하고 사용자 피드백을 구현합니다.

인라인 예제 및 자세한 지침은 신뢰도 기둥을 참조하거나 Patterns 및 Anti-Patterns 탐색기를 탐색하십시오.