여기에 업데이트 일정에 대해 알아보십시오.

신뢰할 수 있는 솔루션은 효율적이고 신뢰할 수 있도록 작동합니다. 사용 가능하며 일관적으로 수행할 수 있으며 성장하는 비즈니스를 지원하기 위해 확장할 수 있습니다.

신뢰할 수 있는 시스템은 오류가 발생하지 않으며 예상대로 동작하며 적시에 결과를 제공합니다. 반대로 신뢰할 수 없는 시스템은 느리거나 예상대로 동작하지 않거나 중요한 시기에 실패합니다. 신뢰할 수 없는 시스템은 부정확한 정보를 제공하므로 이해당사자가 비즈니스 결정을 위해 시스템을 Trust 수 없습니다.

시스템 신뢰도는 상수하지 않습니다. 성장에 맞게 설계되지 않은 경우 현재 신뢰할 수 있는 시스템이 신뢰할 수 없게 될 수 있습니다. 신뢰할 수 없는 시스템은 비용이 많이 드는 서비스 점검, 리팩터링 또는 재구현이 필요할 수 있으므로 전략적 프로젝트에서 자금을 방출할 수 있습니다.

가용성, 성능 및 확장성과 같은 세 가지 원칙에 초점을 맞추어 Salesforce 솔루션의 신뢰성을 향상합니다. Salesforce의 확장성 제품군은 설계자가 안정적인 구현을 실행할 수 있도록 지원하는 기본 기능을 제공합니다.

가용성은 시스템이 작동하는 시간의 비율을 측정합니다. Salesforce Platform은 대부분의 인프라급 가용성 문제를 처리합니다. 그러나 플랫폼에서 구축하고 고객이 경험한 솔루션의 가용성은 공유 책임입니다. Salesforce의 고가용성에도 불구하고 서비스 중단의 위험은 결코 0이 아닙니다.

설계자는 계획된 서비스 점검 또는 예상치 못한 상황과 같은 Salesforce 서비스 중단에 대비해야 합니다. 서비스 중단 외에도 고성능을 유지하고 비즈니스를 성장시키는 방법을 고려하십시오. 아키텍처 선택 항목의 범위를 좁히면 장기 가용성 문제가 발생할 수 있습니다.

솔루션이 구축되기 전에 설계 단계에서 가용성에 대해 생각해 보십시오. 가용성에 대한 아키텍처를 지연하는 시간이 길수록 장기적으로 가용성 문제의 실제 비용이 더 높습니다. 잠재적인 위험을 완화하려면 테스트 환경에서 Salesforce 확장형 테스트 사용하십시오. 해당 환경에서는 프로덕션에서 코드를 배포하기 전에 프로덕션 규모에서 테스트할 수 있습니다.

설계자는 비즈니스 언어를 사용하여 비즈니스 이해당사자의 기술적 우려 사항을 구축하고 가용성 작업의 우선 순위를 지정합니다. 잠재적인 위험을 완화하려면 테스트 환경에서 Salesforce 확장형 테스트 사용하십시오. 해당 환경에서는 프로덕션에서 코드를 배포하기 전에 프로덕션 규모에서 테스트할 수 있습니다.

위험 관리 및 실패 완화를 통해 Salesforce 솔루션의 가용성을 높일 수 있도록 설계할 수 있습니다.

Salesforce 아키텍처의 컨텍스트에서 위험을 관리하려면 시스템 운영, 직원, 파트너, 고객을 비롯한 사용자, 비즈니스 프로세스에 대한 잠재적인 위험을 식별해야 합니다. 종종 공식적인 위험 분석 프로세스는 프로젝트 관리자의 책임에 속합니다. 설계자는 위험 분석이 기술 및 비즈니스 이해당사자의 우려 사항을 적절하게 나타내는지 확인합니다. 또한 프로덕션 피크 핫스팟을 기반으로 확장 테스트해야 하는 비즈니스에 중요한 사용 사례를 식별할 책임이 있습니다.

위험 관리에서 가장 큰 장애물 중 일부는 충분한 시간을 할애하고 고려하지 않는 것 때문입니다. 팀은 종종 위험 평가를 건너뛰거나 데이터 무결성 위험을 완화하는 데 중요한 부분인 백업 및 복원 솔루션을 포괄적인 위험 평가 및 완화와 결합합니다.

Salesforce 솔루션에 대한 위험을 평가하려면 다음 방법을 사용합니다.

• 위험 평가 프레임워크 사용 일부 대기업에는 이미 관련 위험 행렬이 있을 수 있습니다. 위험을 분류하는 방법, 수집할 정보의 종류, 해결을 위해 필요한 사항 등을 결정하는 데 사용합니다. 위험 평가 프레임워크가 없는 경우 신뢰할 수 있는 소스에서 찾고 사용하십시오.
• 고객의 관점에서 영향 심각도 및 위험 범주 평가 Proactive Monitoring 및 Scale Center는 구성 가능한 경고 및 대시보드를 제공합니다. 성능 및 확장성 위험을 지속적으로 평가하고 수동 체크리스트에 대한 의존도를 줄입니다. 고객 Trust 인식은 모든 비즈니스의 핵심입니다. 비즈니스 영향 측면에서 고객에게 도달하는 문제에 대한 위험은 일반적으로 그렇지 않은 문제에 대한 위험보다 높습니다. 고객은 내부 팀과 같은 방식으로 위험을 생각하거나 인식하지 못할 수 있습니다. 고객이 계정에 로그인할 수 없는 경우 문제의 근본 원인을 신경쓰지 않을 수 있습니다. 즉각적인 자신의 경험을 가장 신경쓰고 있습니다.
• 위험 우선 순위 지정 이상적으로 모든 위험은 견고한 경감 및 대응 계획과 연결됩니다. 실제로는 시간이 지나면서 해결해야 하는 격차가 있습니다. "이전에 가치 제공 및 반복" 접근 방식을 채택하는 것이 중요합니다. 귀하 및 배달 및 서비스 점검 팀은 지정된 시간에 충분한 작업량만 할 수 있습니다. Salesforce에서 일반적인 표현식은 "모든 것이 중요하다면 아무것도 중요하지 않습니다."입니다. V2MOM을 사용하여 회사 전체, 팀 전반, 개인별로 작업의 우선 순위를 지정하고 조율합니다. (Trailhead에서 V2MOM에 대해 자세히 알아볼 수 있음.) 위험 평가를 사용하면 이해당사자와 협력하여 가장 중요한 위험 관리 작업의 우선 순위를 지정하고 참여할 수 있습니다. 확장형 테스트 - 테스트 계획 생성을 사용하여 확장형 테스트를 사용하여 위험을 파악하여 우선 순위를 지정하고 위험을 완화합니다.

사전 Proactive Monitoring 사용하여 조기 가용성 위험을 감지합니다. API 요청 제한 증가, 행 잠금 오류 또는 동시 Apex 실패와 같은 변칙을 표시하여 문제가 서비스 중단으로 에스컬레이션되기 전에 실행 가능한 인사이트를 제공합니다.

가용성 패턴 및 안티 패턴은 Salesforce 솔루션 내에서 적절한 리스크 관리와 부적절한 리스크 관리를 보여줍니다. 패턴을 사용하여 구축하기 전에 디자인을 확인하거나 시스템의 리팩터링 영역을 식별합니다.

위험 관리와 관련된 Salesforce 도구에 대해 자세히 알아보려면 Salesforce 신뢰도 도구를 참조하십시오.

장애 지점은 시스템을 신뢰할 수 없게 만드는 취약점입니다. 성공적인 실패 완화는 잠재적인 모든 실패 지점을 찾는 것이 아닙니다. 대신 서비스 점검 및 지원 팀이 효율적으로 대응할 수 있도록 오류 지점을 빠르게 분류하고 우선 순위를 지정해야 합니다. 사고 대응을 참조하십시오.

더 나은 실패 완화 전략 개발:

• 사람, 프로세스 및 기술 측면에서 장애 지점에 대한 트리거를 분류합니다. 사람, 프로세스 및 기술 측면에서 위험을 분류하는 것과 마찬가지로 우선 순위가 높은 실패 지점이 트리거되는 방법에 같은 생각을 적용합니다. 이 접근 방식을 사용하면 잠재적인 실패 트리거를 식별하고 해당 트리거에 대한 응답을 개발하고 구성할 수 있습니다. 트리거가 분류되는 방식을 기반으로 유사한 경감 접근 방식을 사용하여 가시적으로 서로 다른 실패 트리거를 완화할 수도 있습니다.

• 기본, 중간 및 성숙한 완화가 어떻게 보이는지 확인하십시오. 완화 전략을 구축하는 데 시간이 걸릴 것입니다. 완화 수준을 정의하여 사용자 및 팀이 즉시 제어할 수 있는 위치와 시간에 따른 노력을 집중하는 방법을 파악할 수 있습니다. 가능한 한 빨리 경감 접근 방식에서 자동화를 사용할 기회를 찾으십시오. 이 접근 방식을 실제로 보여주기 위해 이 예는 사람 중심 트리거와 기본, 중간, 성숙 수준의 정책 기반 경감 방식을 보여줍니다.

아키텍처 플레이북 및 연속성 계획을 사용하는 것 외에도 Proactive Monitoring 사용하십시오. 사전 Proactive Monitoring 사용하면 로그인 실패, CPU 시간 초과 예외 또는 동시 API 요청 오류와 같은 실패 트리거에 대한 실시간 경고를 설정할 수 있습니다. 이 경고 접근 방식은 기술적 이해당사자와 비즈니스 이해당사자가 실패의 영향을 줄이기 위해 적시에 정보를 받을 수 있도록 하여 장애 완화 효과를 높입니다.

가용성 패턴 및 안티 패턴은 Salesforce 솔루션에서 올바른 장애 완화 및 저하를 보여줍니다. 이를 사용하여 구축하기 전에 설계의 유효성을 검사하거나 시스템에서 리팩터할 위치를 식별합니다.

오류 완화용 Salesforce 도구에 대해 자세히 알아보려면 신뢰할 수 있는 도구를 참조하십시오.

이 표는 조직에서 찾거나 구축할 패턴을 선택한 다음, 방지하거나 수정할 항 패턴을 보여줍니다.

✨ Pattern & Anti-Pattern Explorer에서 추가 패턴의 가용성을 확인하십시오.

시스템 아키텍처 성능은 시스템의 처리량(처리량) 및 응답 속도(대기 시간)를 측정합니다. 일반적으로 프로덕션 테스트 및 모니터링을 통해 시스템의 성능을 이해할 수 있습니다.

성능이 뛰어난 시스템은 예상되는 모든 수요 수준에서 프로세스를 적시에 완료합니다.

성능이 낮으면 대기 시간이 높고 처리량이 낮아 생산성이 저하되고 사용자 불만이 증가합니다. 고객의 Trust 잃고 재정적 손실을 야기할 수 있으므로 성능 문제를 해결해야 합니다.

처리량 및 대기 시간을 최적화하여 솔루션의 성능을 향상할 수 있습니다.

참고: 처리량 및 대기 시간 최적화는 시스템 처리 및 응답성을 개선하는 데 필수적인 측면입니다. 그러나 전체 시스템 성능은 규모에 맞게 얼마나 잘 설계하는지에 따라 달라집니다. 설계에서 두 치수를 모두 고려해야 합니다.

Salesforce 아키텍처의 컨텍스트에서 처리량은 시스템에서 지정된 시간 간격 내에 완료할 수 있는 동시 요청의 수입니다. 처리량에 맞게 설계 및 최적화된 고객의 Salesforce 솔루션은 Salesforce Platform의 내장된 관리자 제한 내에서 더 잘 작동합니다.

Salesforce에서 처리량을 최적화하는 것은 시스템의 작업 부하를 정확하게 계산하고 증가를 계획하는 것부터 시작합니다. 시스템에 대한 요구 사항에 대한 정확한 예측이 없으면 시스템의 처리량 기능으로 잠재적인 문제를 파악할 수 없습니다.

작업 부하에 대해 생각할 때 다음 세 가지 차원을 고려하십시오.

• 주어진 기간 동안 시스템에서 처리해야 하는 트랜잭션 수
• 동시에 시스템에 액세스해야 하는 사용자 수
• 시스템에서 트랜잭션 논리의 전체적인 복잡성

성능에 대해 생각할 때 팀이 플랫폼의 총괄자 제한 중 하나인 최대 CPU 시간에 대한 제약 및 계산에 너무 좁게 집중하는 경우가 있습니다. CPU 시간에 집중도가 좁은 팀은 처리량을 최적화하는 다른 방법을 무시합니다. 포커스를 확장하고 해당 메서드를 적용하면 Salesforce 아키텍처의 전반적인 처리량과 효율성이 향상됩니다. 이러한 개선 사항은 대기 시간을 줄이고 전체 시스템 성능을 향상하는 데 도움이 됩니다. ApexGuru는 루프의 SOQL, 루프의 DML, 비효율적인 GGD 호출, 비비용이 많은 메서드와 같은 처리량 제한 안티 패턴을 사전에 감지합니다. 이러한 인사이트를 통해 팀이 처리량을 제한하는 총괄자 제한 위험을 제거할 수 있습니다.

시스템의 처리량 최적화:

• 비동기식 처리를 촉진합니다. Salesforce Platform은 트랜잭션 컨텍스트를 사용하여 데이터 무결성을 제어하고 런어웨이 코드를 제한합니다. 아키텍처 기본 사항의 아키텍처 기본 사항에서 트랜잭션을 참조하십시오. 따라서 가능한 경우 비동기(비동기) 처리를 사용하면 동기 실행 컨텍스트에서 잠재적인 지체 지점을 최소화할 수 있습니다. 데이터 처리을 참조하십시오. 비동기 계산을 사용하면 모든 종류의 성능 문제를 해결할 수 없으며 비동기 프로세스를 통합할 때 대기 시간을 고려해야 합니다. 대기 가능한 Apex 같은 특정 플랫폼 기능은 메시지가 대기열에서 더 오래 대기하므로 트래픽이 급증하는 동안 대기 시간이 증가할 수 있습니다. 사용 사례에 따라 처리량을 유지하거나 향상하기 위해 응답성의 잠재적 저하를 허용할 수 있습니다. 그 외의 경우에는 대기 시간이 증가하면 허용되지 않을 수 있습니다. 확장형 테스트 사용하면 전체 Sandbox 트래픽 급증을 시뮬레이션하여 이러한 제약을 확인할 수 있습니다. 작업이 처리량 및 대기 시간에 미치는 영향을 측정할 수 있습니다.
• 항상 대량 처리을 사용하십시오. 높은 수준에서 대량 처리은 컬렉션에 대한 작업 수행을 의미합니다. Salesforce 솔루션에 대한 대량 처리를 논의하는 팀이 컬렉션에 대한 데이터 작업 간소화를 집중하는 경우가 많습니다. 작동 논리를 참조하십시오. 그러나 시스템 수준에서 대량 처리하려면 데이터 작업 이상이 필요합니다. 또한 콜아웃 또는 복잡한 계산과 같은 특정 과업을 대량 처리 후보로 고려하십시오. 적절한 대량 처리로 오버헤드가 줄어듭니다. 작업당 하나의 요청 대신 하나의 요청으로 여러 작업을 실행합니다. ApexGuru는 프로덕션으로 확장하기 전에 수정할 수 있는 DML 또는 SOQL 내부 루프와 같은 안티 볼키핑 패턴을 표시합니다. Bulk Operations를 참조하십시오.
• 검색에 SOSL을 사용하고 SOQL을 데이터 작업처럼 취급합니다. 과도하게 복잡한 SOQL 문을 사용하면 시스템에서 레코드를 검색하는 데 걸리는 시간이 증가할 수 있습니다. SOQL은 기본 관계형 데이터베이스에 오버헤드를 추가하여 처리 속도를 느립니다. 텍스트 또는 와일드카드 기준을 사용할 경우 SOSL이 더 성능이 뛰어납니다. SOSL은 전체 텍스트 색인화 및 범용 검색에 최적화된 플랫폼의 검색 엔진을 사용합니다. 레코드 검색 패턴을 최적화하려면 설계 표준에서 SOSL을 사용하여 시스템에서 데이터를 찾는 시기를 지정해야 합니다. 또한 SOQL을 사용하여 효율적인 데이터 작업을 수행하는 방법을 지정해야 합니다. 운영 논리 참조).
• 플랫폼 캐시 및 ApexGuru를 사용합니다. Lightning Platform Cache 레이어는 Salesforce 세션 및 조직 데이터 캐싱 시 더 빠른 성능과 더 나은 신뢰성을 제공합니다. 플랫폼 캐시는 캐시 공간을 배포하여 성능을 향상하므로 일부 응용 프로그램 또는 작업이 다른 응용 프로그램에서 용량을 훔치지 않습니다. ApexGuru는 반복 쿼리(예: SOQL 결과의 Platform Cache)를 캐싱하기 위해 누락된 기회를 감지하여 대규모 환경에서 처리량을 개선합니다.

성능에 대한 패턴 및 안티패턴은 Salesforce 조직에서 적절한 처리량과 적절한 처리량을 보여줍니다. 구축하기 전에 설계를 확인하거나 추가 최적화를 위한 기회를 식별하는 데 사용합니다.

처리량 최적화를 위한 Salesforce 도구에 대해 자세히 알아보려면 Salesforce 신뢰도 도구를 참조하십시오.

대기 시간은 시스템이 실행 경로를 얼마나 빠르게 완료하는지 측정합니다. 시스템 처리량을 최적화하면 대기 시간이 향상됩니다. 대기 시간의 또 다른 측면은 인식 성능 또는 시스템이 사용자에게 얼마나 반응하는지입니다.

사람들이 페이지가 로드되거나 프로세스가 완료될 때까지 기다리지 않기를 원합니다. 목록 보기, 레코드 페이지, 보고서 등을 탐색하려는 경우 시스템 사용자가 자주 로드 시간이 오래 걸리면 실망할 수 있습니다. 이러한 경우 고객 또는 파트너가 성능이 좋지 않은 시스템을 다루는 대신 비즈니스를 다른 곳으로 옮길 수 있습니다. 내부적으로 직원은 시스템을 설계된 대로 사용하지 않도록 해결 방법을 만들 수 있으므로 다운스트림에서 보안 및 데이터 무결성에 문제가 발생할 수 있습니다.

감지된 성능은 진단하기 어려울 수 있습니다. 사용자가 성능 저하를 보고하면 지원 팀에서 문제를 재현할 수 없습니다. 대기 시간이 증가하는 것은 서로 구축되는 작은 문제의 조합으로 인해 발생하는 경우가 많으므로 인식되는 성능 문제의 정확한 원인을 진단하기가 어렵습니다.

Salesforce 시스템에서 대기 시간 줄이기 및 응답성 향상:

• 보고서를 최적화합니다. 각 보고서가 하나의 특정 목적을 제공하는지 확인합니다. 시스템의 모든 보고서의 대상 그룹 및 목적을 명확하게 식별합니다. 보고서에 대상 그룹 구성원이 결정하는 데 필요한 최소 데이터 양만 포함합니다. 보고서의 목적과 일치하지 않는 열을 제거하면 검색하고 표시해야 하는 데이터의 양을 줄여 보고서 성능이 향상됩니다.
• 필터 최적화 효과적인 필터는 데이터베이스에서 검색되는 행 수의 범위를 정확하게 지정하여 보고서 및 목록 보기 성능 속도를 높입니다. 일반적으로 필터 논리를 구체화할수록 데이터에 대한 기본 쿼리가 더욱 효율적입니다. 필터를 최적화하는 방법은 다음과 같습니다.
  • “포함” 및 “포함 안 함” 대신 “같음” 및 “같지 않음” 사용
  • 수식 필드별 필터링 방지
• 공유 모델 단순화 공유 모델이 지나치게 복잡하면 시스템에서 공유 및 가시성 모델을 확인하여 사용자에게 표시 또는 처리할 데이터에 대한 액세스 권한이 있는지 확인해야 하므로 다양한 프로세스가 느려질 수 있습니다. 복잡한 공유 계산은 사용자 컨텍스트에서 실행되는 보고, 목록 보기 및 자동화의 대기 시간을 늘릴 수 있습니다. 공유 및 가시성을 참조하십시오.
• 사용자 정의 UI 구성 요소 최적화 사용자 정의 사용자 인터페이스(UI) 구성 요소는 대기 시간을 늘릴 수 있습니다. 사용자 정의 UI 구성 요소의 성능을 최적화하려면 다음 작업을 고려하십시오.
  • Lightning 웹 구성 요소(LWC) 사용 LWC 프레임워크는 최신 웹 표준에 밀접하게 부합합니다. LWC에 작성된 사용자 정의 구성 요소는 웹 브라우저에서 더욱 효율적으로 렌더링되며 개발자가 더 성능이 뛰어난 JavaScript 메서드를 사용할 수 있습니다. 항상 Aura 또는 Visualforce 같은 이전 UI 기술 대신 LWC를 사용하십시오.
  • Lightning 데이터 서비스 사용 Lightning 데이터 서비스는 구성 요소 간에 안전하고 성능이 뛰어난 공유 캐싱을 생성하고 유지 관리합니다. 이를 사용하여 데이터를 위해 불필요하게 서버로 이동하는 것을 방지하고 전체 응용 프로그램 응답을 향상합니다.
  • 목록 데이터에 클라이언트측 정렬 및 필터링을 사용합니다. LWC(권장) 및 Aura(기본) 구성 요소 모두에서 개발자는 표준 JavaScript 배열 기능을 사용하여 클라이언트 측에서 값을 정렬, 필터링, 선택하여 서버에 필요한 이동 횟수를 줄일 수 있습니다.

패턴 및 안티패턴은 Salesforce 조직에서 올바른 대기 시간과 낮은 대기 시간을 보여줍니다. 구축하기 전에 설계를 확인하거나 추가 최적화를 위한 기회를 식별하는 데 사용합니다.

대기 시간 최적화를 위한 Salesforce 도구에 대해 자세히 알아보려면 Salesforce 신뢰도 도구를 참조하십시오.

이 표는 조직에서 찾거나 구축할 패턴을 선택한 다음, 방지하거나 수정할 항 패턴을 보여줍니다.

✨ Pattern & Anti-Pattern Explorer에서 성능을 위한 더 많은 패턴을 알아보십시오.

확장성은 시스템이 발전하고 성장하면서 일관적으로 수행할 수 있는 기능입니다. 확장 가능한 시스템은 기본적인 변경 사항 없이 트랜잭션 볼륨이 대규모로 증가하거나 동시 액세스를 처리합니다. Salesforce의 플랫폼 서비스는 응용 프로그램 확장성을 지원하도록 설계되었습니다. 내부 플랫폼 처리을 참조하십시오. 따라서 조직이 성장하고 제품 및 서비스에 대한 수요가 증가함에 따라 효율적으로 예상대로 작동할 수 있는 시스템을 만드는 책임이 있습니다. 처음부터 확장성을 위해 아키텍션을 수립하면 사용자 트래픽이 증가함에 따라 신속하게 새로운 기능을 제공하고 서비스 중단이 줄어듭니다. 설계 단계 초반에서 새로운 기능을 생산에 배포하기 전에 확장형 테스트를 사용하여 예상 작업 부하를 시뮬레이션하고 아키텍처가 이를 지원하기 위해 확장할 수 있는지 검증합니다.

확장성에 맞게 설계되지 않은 시스템에는 지속적이고 비용이 많이 드는 문제 해결, 재설계, 재구성이 필요합니다. 확장성 문제는 시간이 지나면서 복잡해지고 시스템 전체의 성능이 저하됩니다. 경우에 따라 비즈니스는 가치를 창출하는 새로운 기능 대신 확장성 문제를 해결하기 위해 대부분의 개발 및 유지 관리 자원을 사용합니다.

때로는 비즈니스가 중요한 지점에 도달하는 경우가 있습니다. 시스템의 원래 설계는 비즈니스 성장을 지원하지 않으며 예기치 않은 이벤트로 인해 시스템이 불안정해집니다. 스케일 센터의 인사이트를 사용하여 조기에 확장성 고급 지점을 파악할 수 있습니다. 스케일 센터는 시간에 따라 악화되는 예외 핫스팟, 장기 실행 트랜잭션, 대기열 지체 지점을 표시합니다.

데이터 모델 최적화 및 데이터 용량 관리를 집중하여 규모에 맞게 더 나은 설계를 수행할 수 있습니다.

참고: 여기에 설명되어 있지 않지만 확장성 테스트는 응용 프로그램 아키텍처의 유효성을 검사하는 데 중요한 부분입니다. 지침은 테스트 전략을 참조하십시오.

데이터 모델링은 조직의 개체를 구조화하고 사용자 및 자동 프로세스가 필요한 데이터를 가능한 한 빨리 검색할 수 있는 방식으로 서로 연결합니다. 처리량을 개선시키기 위한 조치를 취하면 많은 성능 문제를 해결할 수 있지만 최적화된 데이터 모델이 없으면 효과적으로 작업할 수 없습니다.

잘못 설계된 데이터 모델의 부정적인 영향은 즉시 눈에 띄지 않습니다. 데이터 용량, 프로세스, 사용자, 통합 측면에서 시스템이 성장함에 따라 약점이 노출됩니다. 잘 설계된 데이터 모델을 사용하면 요구 사항이 추가되고 확장될 때 응용 프로그램을 지속적으로 리팩터링할 수 있습니다. ApexGuru는 비선택적 SOQL, 사용되지 않는 필드 및 스키마 비효율성과 같은 데이터 액세스 방지 패턴을 표시하며, 이는 데이터 모델의 확장성에 직접적인 영향을 미칩니다.

데이터 모델 최적화:

• Salesforce에서 미리 작성된 데이터 모델을 사용합니다. Salesforce는 세일즈, 서비스, 다양한 산업 분야에 사전 구축된 데이터 모델을 제공합니다. Salesforce에서 제공하는 데이터 모델을 사용하면 시스템의 기능이 한 번만 정의되므로 중복성과 사일로가 없어지고 전체 시스템에서 신뢰할 수 있는 단일 소스를 설정할 수 있습니다. 단일 소스에 대해 Salesforce 사전 빌드 데이터 모델을 사용했으므로 분석을 사용하여 응용 프로그램 데이터를 더 쉽게 이해하고 Salesforce의 사전 빌드 인공 지능 서비스를 사용할 수 있습니다. 또한 지원해야 하는 사용자 정의를 줄여 서비스 점검 비용을 절감하고 기술 부채를 줄입니다.
• 적절한 데이터 유형 선택 Salesforce에서 지원하는 다양한 유형의 필드 및 제한 사항을 이해합니다. 향후 유형 간 데이터를 변환할 필요가 없도록 보고 및 암호화 요구 사항을 고려하십시오.
• 적절한 관계를 선택하십시오. Salesforce는 개체 간의 두 가지 관계, 즉 마스터-세부 사항 및 조회를 지원합니다. 마스터-세부 사항 관계는 두 가지 기본 혜택을 제공합니다. 하나는 하위 레코드의 세부 사항을 계산하고 집계하는 기본 롤업 요약 기능입니다. 다른 기능은 상위 레코드를 삭제하면 해당 하위 레코드도 삭제되는 내장 계단식 삭제 기능입니다. 그러나 사용하기 전에 마스터-세부 사항 관계의 공유 및 데이터 왜곡 영향을 이해해야 합니다.
• 규모를 위한 비정규화. 정규화는 데이터 중복을 줄이고 데이터 무결성을 향상하기 위해 데이터 모델을 구조화하는 프로세스입니다. 불행하게도 정규화로 인해 확장 문제가 발생하는 경우가 있습니다. 비정규화된 테이블은 대규모에서 더 나은 성능을 제공할 수 있지만 데이터 무결성 및 중복성을 고려하십시오.

패턴 및 안티패턴은 Salesforce 조직에서 올바른 데이터 모델 최적화와 나쁜 데이터 모델 최적화를 보여줍니다. 구축하기 전에 설계를 확인하거나 추가 최적화를 위한 기회를 식별하는 데 사용합니다.

데이터 모델 최적화를 위한 Salesforce 도구에 대해 자세히 알아보려면 Salesforce 신뢰도 도구를 참조하십시오.

데이터 용량은 레코드 개수 및 크기를 기반으로 시스템에 저장된 데이터의 양을 측정합니다. 조직에 수만 명의 사용자, 수천만 개의 레코드 또는 수백 개의 기가바이트의 총 레코드 저장소가 있는 경우 데이터 용량이 많습니다. 조직의 데이터 용량 및 개체 간 관계는 확장성에 영향을 미치며 단순히 레코드 수보다 확장성에 더 큰 영향을 미칠 수 있습니다.

데이터 용량이 큰 조직의 확장성 향상:

• 하위 레코드를 배포합니다. 상위 항목에 많은 하위 레코드가 없는지 확인하여 상위-하위 데이터 왜곡을 방지합니다. 일반 권장 사항은 상위 레코드가 10,000개를 초과하지 않아야 합니다. 예를 들어 연락처가 많지만 계정을 사용하지 않는 배포에서 여러 계정 레코드를 설정하고 관련 연락처 레코드를 해당 레코드 간에 배포하는 것이 좋습니다.
• 레코드의 공유 소유권 단일 사용자 또는 대기열이 소유하지 않거나 단일 역할 또는 공개 그룹의 모든 구성원이 같은 개체의 레코드를 10,000개 이상 소유하지 않도록 하여 소유권 왜곡을 방지합니다. "더미 사용자"와 함께 "주차" 데이터는 자주 소유권 왜곡으로 이어집니다. 이 문제가 발생하면 계산 공유에 미치는 영향에 유의하십시오. 소유권 왜곡을 완화하기 위해 레코드를 재배포할 수 없는 경우 데이터 소유자 사용자를 역할에 할당하지 마십시오. 조직의 공유 모델에 역할 할당이 필요한 경우 데이터 소유자 사용자를 공유 계층 상단의 고유한 역할에 배치합니다. 공유 재계산으로 인해 모든 변경 사항이 상당한 성능에 영향을 미치므로 해당 사용자의 역할에 자주 또는 계획되지 않은 변경을 허용하지 마십시오. 공유 규칙에서 참조할 수 있는 공개 그룹에서 해당 사용자를 제외합니다.
• Salesforce에서 레코드 데이터의 양을 축소합니다. Salesforce는 비즈니스에서 고객을 한눈에 파악할 수 있도록 설계되었습니다. Salesforce에서 데이터를 제한하는 것이 가장 좋은 방법인 것처럼 보일 수 있습니다. 그러나 단일 보기의 장점은 비즈니스 사용자가 고객 데이터를 이해하고 조치를 취할 수 있게 하는 정도입니다. 데이터 용량이 증가함에 따라 일상적인 프로세스 또는 분석과 관련이 없거나 최신 상태가 아닌 데이터로 인해 몇 가지 문제가 발생합니다. 이러한 문제에는 앱 성능 저하, 증가된 데이터 보안 위험, 검색, 보고, 분석에 미치는 부정적인 영향이 포함됩니다. 이러한 문제를 방지하려면 데이터 모델의 모든 개체에 대한 데이터 수명 주기를 정의하고 데이터가 오래되고 즉각적인 비즈니스 가치가 손실될 때 데이터에 대한 타임라인 및 분류를 정의합니다. 데이터 수명 주기에 따라 다음 절차를 구현하여 시간에 따른 데이터를 관리합니다.
  • 데이터 아카이빙 및 제거 - 데이터 볼륨을 가능한 한 낮게 유지하려면 비즈니스에서 필요하지 않은 레코드를 제거하여 데이터 볼륨을 가능한 한 낮게 유지합니다. 대량 데이터 볼륨을 삭제하려면 대량 API 2.0의 영구 삭제 기능을 사용합니다.
  • 데이터 집계- 주요 과거 추세 또는 요약 데이터를 보고와 호환되는 형식으로 요약하는 집계 사용자 정의 개체를 만듭니다. 배치 Apex를 사용하여 사용자 정의 개체를 채웁니다. 그러면 사용자가 집계된 개체 레코드를 기반으로 보고서를 실행할 수 있습니다.
  • 데이터 계층화 Salesforce 보고서 또는 일상적인 작업에 필요하지 않은 경우 다른 응용 프로그램에서 대규모 데이터 집합을 유지합니다. 매시업, 콜아웃 또는 외부 개체를 통해 필요에 따라 Salesforce에서 데이터를 사용할 수 있도록 합니다.

실제로 문제가 발생하면 확장성 문제의 근본 원인을 즉시 해결할 수 없습니다. 따라서 Salesforce는 즉각적인 불만 사항을 완화하는 옵션을 제공합니다. 조직에서 이러한 기능을 활성화해도 대용량 데이터를 처리하기 위한 실현 가능한 장기 아키텍처 전략이 아닙니다. 이러한 단기 중단 간격 해결 방법은 데이터 아키텍처가 좋지 않은 시스템에서 대기 시간을 줄이는 데 도움이 될 수 있지만 조직에 기술적 부채를 추가할 수도 있습니다.

규모 문제에 대한 단기 해결 방법은 다음과 같습니다.

• 사용자 지정 색인 색인은 플랫폼의 쿼리 최적화 프로그램이 데이터 액세스 작업을 가속화하기 위해 사용하는 특별한 내부 테이블에 저장됩니다. Multitenant Indexes 참조). 플랫폼은 기본적으로 특정 유형의 필드를 자동으로 색인화합니다. 성과가 좋지 않은 쿼리 속도를 높이려면 Salesforce 고객 지원에 문의하여 추가 사용자 정의 색인을 요청할 수 있습니다. 쿼리 계획 도구를 사용하여 사용자 정의 색인이 쿼리 성능을 향상할지 여부를 결정합니다.
• 스키니 테이블 100만 개가 넘는 레코드가 있는 개체의 공통 필드 집합에 대한 쿼리를 추가로 최적화해야 하는 경우 스키니 테이블을 사용하면 도움이 됩니다. 스키니 테이블은 보고서 또는 자동화에서 동일한 개체의 사용자 정의 및 표준 필드를 사용할 때 발생하는 백그라운드 조인을 제거합니다. 스키니 테이블을 사용하려면 Salesforce 고객 지원에서 조직에 대해 활성화해야 합니다.

확장성에 대한 패턴과 안티패턴은 Salesforce 조직에서 올바른 데이터 볼륨 관리와 나쁜 데이터 볼륨 관리를 보여줍니다. 구축하기 전에 설계를 확인하거나 추가 최적화를 위한 기회를 식별하는 데 사용합니다.

데이터 볼륨을 관리하는 Salesforce 도구에 대해 자세히 알아보려면 Salesforce 신뢰도 도구를 참조하십시오.

이는 조직에서 찾거나 구축할 패턴을 선택하고, 방지하거나 수정할 항 패턴을 표시합니다.

✨ Pattern & Anti-Pattern Explorer에서 확장성을 위한 더 많은 패턴을 알아보십시오.

Salesforce Well-Architected의 관련성을 유지할 수 있도록 도와주십시오. 이 콘텐츠에 대한 사용자 의견을 제공하려면 설문 조사을 작성하고 다음에 표시할 내용을 알려주십시오.