신뢰도

Salesforce는 자동 페일오버 및 인프라 수준 복원성으로 여러 지역에서 복원 가능한 인프라를 운영합니다. 이 플랫폼은 데이터 센터 이중화, 네트워크 가용성 및 인프라 패치를 처리하며, 실시간 플랫폼 가용성 상태는 Trust.salesforce.com에서 볼 수 있습니다.

이 인프라에서 실행되는 모든 항목의 신뢰성을 설계합니다. 총괄자 제한 내에서 확장되는 데이터 모델, 실패를 예상하고 복구하는 트랜잭션, 솔루션이 가용성 목표와 다른 경우를 감지하는 모니터링, 실패 발생 시 비즈니스 운영을 복원하는 재해 복구 절차.

Salesforce SLA는 플랫폼에 적용되지만 인프라 계층 위의 모든 사항에 대한 신뢰성을 보유합니다. 비즈니스에 필요한 신뢰도 목표인 자체 서비스 수준 목표(SLO)를 정의하고 달성할 책임이 있습니다. 애플리케이션 계층의 신뢰성은 플랫폼 SLA 계층에 관계없이 책임이 있습니다. 가용성을 보장하는 동일한 플랫폼도 이를 제한합니다. 총괄자는 각 테넌트의 리소스 소비량을 제한하므로 단일 테넌트가 다른 테넌트에 대해 플랫폼을 저하할 수 없습니다. 따라서 솔루션은 단순히 더 많은 용량을 요청하는 대신 해당 제한 내에 정밀하게 확장해야 합니다.

신뢰할 수 없는 솔루션은 계단식 비즈니스 영향을 미칠 수 있습니다. 상거래 플랫폼을 사용할 수 없는 경우 수익 플로가 느려집니다. 내부 도구가 워크플로 중에 실패하면 생산성이 하락합니다. 데이터가 손상되거나 레코드가 손실되면 Trust 손상됩니다. 이러한 문제는 해결 방법이 누적되고 기술 부채가 증가함에 따라 시간이 지남에 따라 복잡해집니다.

신뢰성은 모든 실패를 방지하는 것이 아닙니다. 분산 시스템에서 실패가 발생합니다. 신뢰성은 오류를 예상하고 폭발 반경을 줄이고 서비스가 자동으로 복원되는 시스템을 설계하는 것입니다. 신뢰성 요구 사항은 비즈니스 영향에 따라 다릅니다. 예를 들어 가용성이 99.9%가 필요한 고객 대면 Experience Cloud 포털은 지연을 허용하는 내부 배치 보고 프로세스와 근본적으로 다른 아키텍처 선택 항목이 수반됩니다.

신뢰성과 운영 우수성은 깊이 연결되어 있습니다. 주소 모니터링, 사고 응답, 시스템 가용성 모두 이 겹침은 의도적이며 우발적이지 않습니다. 차이점은 설계 시간과 실행 시간에 있습니다.

신뢰성은 시스템이 실행되기 전에 시스템을 구축하는 요소입니다.

• 총괄자 제한 내에서 확장되는 이전에 언급된 데이터 모델
• 실패를 예상하고 복구하는 트랜잭션
• 폭발 반경을 포함하는 중복 및 회로 차단기
• 복구 대상(복구 시간 목표(RTO) 및 복구 지점 목표(RPO)) - 오류가 발생할 경우 시스템이 동작하는 방식을 결정합니다.

안정성은 솔루션의 구조적 속성입니다.

운영 우수성은 시스템이 실행되면 시스템을 어떻게 운영하고, 개선하고, 유지하는지 말합니다.

• 변경 위험을 줄이는 배포 관행
• 사고 발생 시 팀을 안내하는 실행북 및 에스컬레이션 경로
• 신호를 표시하는 관찰 가능성 파이프라인
• 시간에 따라 시스템을 개선하는 사용자 의견 루프입니다.

운영 우수성은 솔루션과 관련된 인적 및 프로세스 분야로 구축됩니다.

두 기둥 간에 공유되는 영역은 모니터링 및 관찰 가능성 계층입니다. 모니터링은 신뢰성 문제로 설계되었습니다. 관찰 가능한 시스템을 구축해야 합니다. 그것은 운영 우수성의 관심사로 실행됩니다. 팀은 해당 시스템의 조치에 따라 작업을 수행합니다. 신뢰성은 경고 임계값 및 건강 대시보드 등 구축한 아키텍처 패턴에 적용됩니다. 운영 우수성은 팀이 런북 및 온콜 응답과 같은 신호에 응답하는 방식을 다룹니다.

다음과 같은 차이점을 고려하십시오. 신뢰성은 "이 시스템이 유지될 것입니까?"와 운영 우수성은 "팀에서 운영할 수 있습니까?"를 지정합니다. 실행 장부가 없거나, 배포가 일관되지 않거나, 사용자 의견 루프가 없는 팀에서 운영하는 완벽하게 신뢰할 수 있는 시스템은 여전히 실패할 수 있습니다. 취약하고 잘 설계되지 않은 시스템을 관리하는 운영상 우수한 팀은 예방할 수 없는 사고로 인해 압도될 것입니다. 두 기둥이 모두 필요하며 둘 다 다른 기둥을 대체할 수 없습니다.

신뢰성은 격리적으로 작동하지 않습니다. 이전 섹션에 설명된 것처럼 운영 우수성은 가장 가까운 파트너입니다. 두 가지 기둥은 관찰 가능성 계층을 공유하며, 신뢰도가 시스템에 구축하는 내용을 정의하고 운영 우수성이 팀의 작업 방식을 정의합니다. 또한 Trust에는 공격에 저항하고 데이터 무결성을 유지하는 인프라가 필요합니다. 시스템이 손상될 경우 신뢰할 수 없습니다. 리소스 최적화는 총괄자 제한 만료를 방지하므로 플랫폼이 대규모로 신뢰할 수 있도록 합니다. 비용 최적화는 신뢰도 투자와 비즈니스 가치의 균형을 맞춥니다. 가용성 목표는 이 목표를 달성하는 데 필요한 아키텍처 복잡성을 설명합니다. 단일 기둥은 고립적으로 잘 설계된 솔루션을 생성하지 않습니다. 안정성은 다른 기둥이 기존하고 강화하는 구조적 기반을 제공합니다.

다음 원칙을 사용하여 플랫폼의 신뢰성을 위한 아키텍처 결정을 안내합니다.

• 대량 처리를 통해 작업 부하 분배. 순차적인 레코드별 작업에 의존하지 않고 단일 트랜잭션으로 여러 레코드를 처리합니다. 대량 처리는 단일 트랜잭션에서 처리된 배치 전체에서 총괄자 제한을 공유하여 처리량을 극대화하면서 해당 제한을 준수합니다. 컬렉션 기반 Apex 처리, 구성 가능한 범위가 있는 배치 작업 및 대량으로 사용되는 플랫폼 이벤트 모두 이 원리를 구현합니다. 올바르게 대량 처리된 솔루션은 순차적인 처리 시 하나의 레코드와 동일한 수의 SOQL 및 DML 문이 있는 200개의 레코드를 처리합니다. 분산된 작업 부하 패턴은 단일 레코드 실패가 전체 배치 처리에 영향을 미치지 않으므로 복원 기능을 제공합니다.
• 모든 게 실패한다고 가정해요. 총괄자 제한, 플랫폼 서비스 점검 창, 통합 종속성은 Salesforce 다중 테넌트 아키텍처와 관련된 오류 모드를 만듭니다. 처음부터 이러한 플랫폼별 실패를 설계합니다. SOQL 쿼리는 데이터 왜곡 아래 행 제한을 초과합니다. 복잡한 계산 시 Apex CPU 시간이 만료될 수 있습니다. 외부 서비스가 느리면 콜아웃 시간 초과가 발생할 수 있습니다. 동시 트랜잭션이 충돌하면 DML 행 잠금이 실패합니다. 파일 업로드가 예기치 않게 급증하면 저장소 제한이 실패할 수 있습니다. 이러한 실패를 계획하는 설계자는 수동으로 개입하지 않고 신뢰할 수 있는 솔루션을 구축합니다. 해당 신뢰할 수 있는 시스템은 근접한 총괄자 제한을 감지하고, 오류 처리를 통해 폭발 반경을 포함하며, 프레임워크 재시도 및 플랫폼 이벤트를 통해 자동으로 복구합니다.
• 자기 복구 시스템 구축. 실패를 감지하고 사람의 개입 없이 자동으로 복구하는 솔루션을 설계합니다. 플랫폼 이벤트는 사용자 정의 재시도 패턴을 활성화합니다. 원래 트랜잭션을 재생하려면 사용자 정의 아키텍처가 필요하지만 EventBus.RetryableException을 사용하여 구독자에게 전달을 다시 시도할 수 있습니다. 플로 오류 처리에 따라 예외가 복구 플로로 이동됩니다. Apex 배치 작업은 청크 실패를 분리합니다(실패한 청크는 다른 청크의 처리를 방지하지 않으므로 부분적인 작업 완료 및 표적 재시도가 가능합니다). 임시 실패 복구를 위해 AsyncApexJob에서 오류 추적을 사용하여 명시적 재시도 논리를 구현합니다. 임시 실패를 처리할 때 이러한 재시도 패턴에 기하급수 백오프를 적용합니다. 셀프 복구 시스템은 시간 외 사고 중에도 가용성 대상을 유지하며, 인적 응답자가 부재할 수 있으므로 평균 복구 시간을 단축하면서 운영 부담을 줄일 수 있습니다.
• 비즈니스 요구 사항을 먼저 설계합니다. 기술 솔루션을 선택하기 전에 실제 비즈니스 영향을 기반으로 서비스 수준 목표를 정의합니다. 모든 구성 요소에 9개의 가용성이 필요하지는 않습니다. 신뢰성 투자와 비즈니스 크리티컬티티를 일치시키고 지원 기능에 대한 정상적인 저하를 설계합니다. 현실적인 목표는 적절한 아키텍처 선택을 활성화하고 과도한 엔지니어링 또는 과도한 전달을 방지합니다.
• 브릴을 통해 복구 확인. 백업 복원, 페일오버 절차, 사고 응답 플레이북을 테스트하는 재해 복구 드릴을 예약합니다. 프로덕션 백업에서 전체 사본 Sandbox를 복원하여 복구 프로세스를 확인합니다. Sandbox 환경에 의도한 실패를 도입하여 모니터링에서 문제를 감지하고 자동 복구가 올바르게 실행되는지 확인합니다. 실제 사고가 노출되기 전에 세부적으로 절차, 도구, 실행북의 격차가 표시됩니다. 드릴 결과를 문서화하고 발견된 격차의 해결 방법을 추적합니다. 정기적인 테스트를 통해 솔루션이 발전하고 팀 멤버십이 변경되면 복구 기능이 최신 상태로 유지됩니다.

Salesforce가 운영하는 항목을 이해하면 신뢰도 설계 노력을 자신이 제어하는 항목에 집중할 수 있습니다. 플랫폼은 다음과 같은 기존의 IT 환경에서 전담 팀이 필요한 인프라 문제를 처리합니다.

• 다중 지역 인프라 및 페일오버: Salesforce Hyperforce 지역 데이터 센터에 내부 서비스의 자동 페일오버를 제공합니다. 또한 지역 내에서 여러 가용성 영역과 인프라 계층에서 데이터 복제를 제공합니다. 플랫폼은 지역 내의 중복 및 가용성 영역 분포를 투명하게 처리합니다.
• 플랫폼 SLA 서약: 계약에 따라 보장되는 가용성 수준은 고객별로 협상됩니다. Trust.salesforce.com은 실시간 플랫폼 상태 및 가동 시간 내역을 게시하지만, 특정 가용성 보장 및 해당 보안은 협상된 계약에 적용됩니다. 조직에 적용되는 서약 및 Salesforce Trust 및 규정 준수 문서를 검토하십시오.
• 인프라 이중화: 플랫폼은 중복 서버, 네트워크 경로, 데이터베이스 인프라, 스토리지 시스템을 유지 관리합니다. 인프라 수준 페일오버는 고객 작업 없이 하드웨어 오류가 발생하는 동안 자동으로 발생합니다. 플랫폼 백업은 인프라 수준 데이터 손실을 방지합니다.
• 플랫폼 유지 관리 및 업데이트: 주요 플랫폼 릴리스는 Salesforce에서 이전 버전 호환성을 관리하는 기능 및 보안 패치를 제공합니다. 플랫폼 유지 관리 창은 Trust.salesforce.com에서 예약 및 통신됩니다. 인프라 패치는 고객의 참여 없이 투명하게 수행됩니다.
• 핵심 플랫폼 상태 모니터링: Salesforce는 데이터베이스 응답 시간, 네트워크 대기 시간, API 게이트웨이 상태, 스토리지 시스템 성능 등 인프라 성능을 모니터링합니다. 플랫폼 상태는 Trust.salesforce.com에 표시되며 실시간 사고 업데이트가 포함됩니다. 인스턴스별 상태는 상태 API를 통해 사용할 수 있습니다.

이러한 플랫폼 작업을 통해 구축할 기초가 생성됩니다. 데이터 센터, 프로비저닝 서버 또는 인프라 재해 복구 설계를 관리하지 않습니다. 대신 이 파운데이션 위에 설계하고 구성하는 작업에 대한 책임이 있습니다.

공유 책임 모델은 Salesforce로 만든 모든 것에 대한 신뢰성을 소유하도록 지정합니다. 플랫폼 신뢰도는 작업을 지원하지만 대체할 수는 없습니다. 신뢰성 책임은 6가지 상호 연결된 영역에 적용됩니다.

서비스 수준 목표(SLO)는 측정 가능한 조건으로 신뢰도 요구 사항을 수량화합니다. SLO는 비즈니스 요구 사항 및 기술 아키텍처를 연결합니다. 기술을 선택하거나 데이터 모델을 설계하기 전에 각 중요 사용자 플로에 대한 성공을 정의하는 SLO를 설정합니다.

SLO는 일반적으로 다음을 측정합니다.

• 가용성 - 시스템이 운영되고 액세스할 수 있는 시간 비율
• 대기 시간 - 작업을 완료하는 데 필요한 시간이며, 백분율로 측정됨(p50, p95, p99)
• 진입량 - 단위 시간당 성공적으로 완료된 작업의 양
• 오류율 - 실패하거나 오류를 반환하는 요청 비율
• 복구 시간 - 사고 후 서비스 복구에 필요한 기간

기술 구성 요소별이 아닌 비즈니스 기능별로 SLO를 정의합니다. 사용자 대면 기능에는 관리 또는 배치 프로세스보다 더 엄격한 SLO가 필요합니다. 각 SLO는 사용 가능한 계측기를 사용하여 객관적으로 측정할 수 있어야 합니다.

서비스 수준 계약(SLA)은 실패로 인한 결과가 있는 계약상 서약입니다. 보장 가용성 수준 및 계약상의 조치는 고객별로 협상됩니다. 조직에 적용되는 서약 및 현재 Salesforce Trust 및 규정 준수 문서를 검토하십시오.

오류 예산을 유지하기 위해 솔루션 SLO는 플랫폼 SLA보다 엄격하지 않아야 합니다. 플랫폼 SLA 및 솔루션 SLO가 모두 99.9%를 목표로 하는 경우 중요한 플랫폼 가동 중지 시간은 오류 예산을 직접 사용하므로 같은 측정 기간 내에 응용 프로그램 계층 실패, 통합 문제 또는 계획된 서비스 점검에 대한 버퍼를 남길 수 없습니다. 누적 가동 중지 시간이 측정 기간의 전체 오류 예산을 소모하는 경우에만 SLO가 공식적으로 위반됩니다. SLA 및 SLO가 동일한 대상으로 설정된 경우 단일 플랫폼 사고로 인해 해당 예산이 완전히 소진될 수 있습니다. 예를 들어 플랫폼에서 99.9%를 제공하는 경우 99.5%의 솔루션 SLO를 대상으로 애플리케이션 버그, 통합 실패, 배포 기간 등 해결해야 하는 문제에 대해 의미 있는 버퍼를 유지합니다.

서비스 수준 지표(SLI)는 SLO 성과를 평가하는 데 사용되는 측정값입니다. SLI는 객관적으로 측정 가능하며 일관되게 수집되고 사용자 환경과 직접 연결되어야 합니다.

Salesforce 솔루션의 경우 SLI에는 다음이 포함됩니다.

• Trust.salesforce.com을 통해 플랫폼 가동 시간
• Experience Cloud 분석을 통한 페이지 로드 시간
• 이벤트 모니터링을 통한 API 응답 시간(이벤트 모니터링 추가 기능 또는 Salesforce Shield 필요)
• 사용자 정의 응용 프로그램 로깅을 통한 트랜잭션 성공률
• AsyncApexJob 모니터링을 통한 배치 작업 완료

가용성 목표가 높으면 복잡성과 비용이 기하급수적으로 증가합니다. 목표를 커밋하기 전에 아키텍처에 미치는 영향을 이해합니다.

"모든 항목에 대해 9개 5개"와 같은 임의의 목표를 피하십시오. 대신 성능당 가동 중지 시간의 비즈니스 영향을 평가하고 그에 따라 대상을 설정합니다. 7시간의 월간 가동 중지 시간을 허용하는 내부 배치 보고에는 시간 초과 복구가 필요한 매출 크리티컬 주문 처리에 비해 근본적으로 다른 아키텍처가 필요합니다.

기술 메트릭이 아닌 사용자 관점에서 신뢰도를 정의합니다. 시스템에서 가동 시간을 99.9% 보고하지만 시간 초과가 자주 발생하면 사용자 환경 기반 신뢰도가 저하됩니다. 사용자는 개별 API 가동 시간보다 워크플로를 성공적으로 완료하는 것이 더 중요합니다.

개별 API 호출이 아닌 사용자 여정을 반영하는 SLO를 설계합니다. 여러 단계 Checkout 플로는 모든 단계를 허용 가능한 시간 내에 성공적으로 완료해야 합니다. 기본 신뢰도 지표로 최종 사용자 간 플로 완료율을 측정합니다. 구성 요소 가용성은 필수이지만 사용자 환경의 신뢰성에는 충분하지 않습니다.

Salesforce Hyperforce 지리적 배포를 지원하는 지역 데이터 센터를 제공합니다. 플랫폼은 여러 가용성 영역, 내부 서비스의 자동 페일오버, 인프라 계층의 데이터 복제를 포함하여 지역 내의 인프라 중복을 처리합니다. 플랫폼 SLA는 이 인프라 중복성을 반영합니다.

대부분의 솔루션에서 플랫폼이 관리하는 중복성을 사용하는 단일 지역 배포는 가용성을 충분히 제공합니다. 기본 가용성에 대한 Salesforce 인프라를 Trust 오류를 방지하는 통합 패턴, 정상적인 성능 저하, 자동 복구 등 응용 프로그램 계층의 신뢰성에 중점을 둡니다.

가용성 영역 전반의 지역 내 페일오버는 자동이며 표준 플랫폼 SLA 서약에 포함됩니다. Salesforce는 인프라 계층에서 이를 투명하게 관리합니다. 지역 간(영역 외) 재해 복구는 별도의 유료 혜택이며, 기본적으로 표준 Edition에 포함되지 않습니다. 비즈니스 연속성 요구 사항이 지역 간 페일오버를 요구하는 경우 이해당사자가 포함된 플랫폼 복원 능력과 구매한 지역 간 DR 기능 간의 차이점을 이해할 수 있도록 재해 복구 계획에 이 종속성을 명시적으로 문서화합니다.

다중 조직 아키텍처는 가장 강력한 격리 및 지리적 중복성을 제공하지만 데이터 동기화, 사용자 프로비저닝, 배포 조정, 라이센스 비용을 비롯한 운영 복잡성이 증가합니다. 비즈니스 요구 사항이 복잡성을 명확하게 정당화하는 시나리오에 다중 조직 패턴을 예약합니다. 예를 들어 다음 시나리오에 대한 다중 조직 패턴을 고려합니다.

• 플랫폼 기능 외에도 보증 RPO/RTO가 필요합니다.
• 규제 요구 사항은 지리적 데이터 분리를 요구하며, 무중단 업무 운영 계획은 단일 지역과 완벽하게 독립해야 합니다.
• 사업부 자율성 요구 사항으로 인해 조직 통합을 실행할 수 없습니다.

액티브 패턴: - 기본 조직은 정상적인 조건에서 모든 트래픽을 제공합니다. 다른 지역의 보조 조직은 동기화 상태를 유지하지만 유휴 상태가 됩니다. 기본 영역이 중단되는 동안 페일오버가 발생합니다. 이 솔루션은 가장 간단한 다중 조직 패턴을 제공하지만 보조 용량은 사용되지 않습니다. DNS 라우팅 또는 사용자 인증 계층은 사용자를 활성 조직으로 안내합니다.

액티브-액티브 패턴: - 두 조직 모두 프로덕션 트래픽을 지속적으로 제공합니다. 사용자는 지역, 사업부 또는 작업 부하 유형별로 할당됩니다. 활성 - 활성 - 수용력 활용도를 극대화하지만 정교한 데이터 동기화 및 사용자 라우팅이 필요합니다. 두 조직에서 동일한 레코드가 수정되는 경우 충돌 해결이 중요합니다.

RPO 요구 사항에 적합한 데이터 동기화를 설계합니다. 플랫폼 이벤트는 중요한 데이터 변경에 대한 실시간 이벤트 스트리밍을 제공합니다. 변경 데이터 수집 최소한의 개발을 통해 선택한 개체에 대한 자동 변경 추적을 제공합니다. 고정 간격으로 대량 API 2.0을 통한 예약된 API 복제는 시간이 덜 중요한 참조 데이터에 적합합니다.

데이터, 응용 프로그램, 통합 계층에 중복을 적용하여 단일 지점의 실패를 방지합니다. 계층화된 중복성을 통해 단일 레이어의 실패로 인해 전체 시스템 가용성이 저하되지 않습니다.

• 데이터 이중화: 플랫폼은 인프라 백업을 통해 데이터 중복을 제공합니다. 비즈니스에서 플랫폼 복원 절차에서 제공하는 것보다 더 빠른 복구가 필요한 경우 응용 프로그램 수준 복제를 사용하여 이 중복을 보완합니다. 변경 데이터 수집 또는 플랫폼 이벤트를 사용하여 중요한 데이터를 보조 저장소 또는 외부 시스템에 지속적으로 복제합니다. 이를 통해 인프라 백업에서 해결할 수 없는 논리적 손상 또는 구성 오류를 복구할 수 있습니다.
• 응용 프로그램 이중화: 응용 프로그램 서버가 모든 요청을 처리할 수 있도록 상태가 없는 응용 프로그램 논리를 설계합니다. 서버측 상태는 가로 확장을 방지합니다. 모든 응용 프로그램 서버에서 즉시 사용할 수 있어야 하는 구성에 사용자 정의 메타데이터 유형 및 사용자 정의 설정을 사용합니다. 시/도 없는 설계를 사용하면 응용 프로그램 서버가 특정 서버 상태에 따라 요청을 처리할 수 있습니다.
• 통합 이중화: 일시적인 외부 시스템을 사용할 수 없는 통합을 설계합니다. 통합 실패를 감지하는 회로 차단기 패턴을 구현합니다. 사용자 작업을 차단하는 대신 외부 시스템이 다운되었을 때 플랫폼 이벤트를 통해 요청을 대기열에 지정합니다. 이렇게 하면 외부 시스템 오류가 사용자 대면 기능과 분리됩니다.

Trust.salesforce.com 및 인스턴스별 상태 API를 사용하여 Salesforce 플랫폼 상태를 모니터링합니다. 인스턴스에 대한 상태 알림을 구독하여 사고, 서비스 점검 기간, 성능 영향에 대한 알림을 수신합니다. 플랫폼 상태 신호는 반응형 문제 해결 대신 사전 예방적 응답을 지원합니다.

플랫폼 상태에 반응하는 솔루션을 설계합니다. 플랫폼 성능이 저하되면 중요하지 않은 배치 처리 부하를 줄입니다. 예약된 작업 모니터링을 사용하여 서비스 점검 기간 동안 백그라운드 작업을 지연합니다. 비필수 통합을 비활성화하여 사고 중 중요한 사용자 대면 작업을 보호합니다. 이 동적 로드 분산은 스트레스를 받는 경우 중요 성능의 신뢰성을 유지합니다.

스케일 센터를 사용하여 비율적인 플랫폼 자원을 소비하는 장기 실행 트랜잭션 및 작업을 식별합니다. 스케일 센터는 트랜잭션 수준의 가시성을 제공하므로 설계자가 신뢰성 위험을 감지한 후에 사용자에게 발생하는 사고가 됩니다. 주간 Scale Center 검토는 아키텍처 수정이 필요한 패턴을 보여줍니다.

여러 수준에서 실패 감지를 구현하여 문제를 포착한 후에 전체 중단이 발생합니다. 계층형 감지는 감지되지 않은 실패를 심층적으로 방어합니다.

조기 감지와 위양성과의 균형을 맞추는 경고 임계값을 설계합니다. 오류 비율이 임계값을 초과하거나 단독 실패가 아닌 지속적인 저하가 발생하면 경고합니다. 단일 오류는 분산 시스템에서 일반적입니다. 오류 패턴은 주의를 기울여야 하는 신뢰성 문제를 나타냅니다.

Salesforce 총괄자는 다중 테넌트 플랫폼에서 각 테넌트의 자원 소비를 제한하므로 단일 테넌트가 다른 테넌트의 성능을 저하할 수 없습니다. 임의 제한이 아니라 솔루션 설계를 형성하는 아키텍처 경계입니다. 신뢰할 수 있는 아키텍처를 설계하기 전에 총괄자 제한을 이해하십시오. 정상 부하에서 정기적으로 총괄자 제한에 도달하는 솔루션은 스트레스를 받으면 실패할 가능성이 높습니다.

아키텍처 결정에 영향을 미치는 중요 총괄자 제한:

최대 부하에서도 제한 내에 완벽하게 완료되는 트랜잭션을 설계합니다. 일반적인 조건에서 총괄자 제한의 70%를 운영 제한으로 지정하고 예기치 않은 급증 시 30%를 예약하여 마진을 구축합니다. 이 버퍼는 일반적으로 하드 제한에 도달하지 않고 임시 로드 증가를 수용합니다.

대량 처리는 Salesforce의 기본 확장성 패턴입니다. 개별 레코드 작업이 아닌 단일 트랜잭션에서 여러 레코드를 처리합니다. 대량 처리는 처리량을 늘리면서 총괄자 제한 소비를 줄입니다. 모든 Salesforce 아키텍처는 모든 확장 가능한 솔루션을 기반으로 하는 대량 처리 패턴을 관리해야 합니다.

모든 Apex 트리거, 배치 클래스 및 통합을 설계하여 레코드 컬렉션을 효율적으로 처리합니다. 레코드 식별자를 먼저 수집한 다음, 단일 쿼리 및 DML 문을 사용하여 모든 레코드를 처리합니다. 개별 쿼리와 함께 중첩된 루프가 아닌 효율적인 조회를 위해 맵 및 집합을 사용합니다. 컬렉션 기반 처리는 레코드별 접근 방식 대비 대규모 효율성 향상을 제공합니다.

플랫폼 프로세스가 최대 200개의 레코드 배치로 실행을 트리거하므로 레코드 트리거 자동화는 트리거 호출당 200개의 레코드를 처리해야 합니다. Lightning 데이터 서비스 작업은 자동으로 배치되지만 사용자 정의 구성 요소는 DML 작업을 수행할 때 명시적으로 대량 패턴을 구현해야 합니다.

비동기 처리는 단일 트랜잭션의 총괄자 제한 내에서 즉시 완료를 시도하지 않고 시간에 따른 작업을 배포합니다. 작업에서 동기화 총괄자 제한을 초과하는 대용량 데이터를 처리하거나, 변수 응답 시간이 있는 외부 시스템에 의존하거나, 완료 지연을 허용하거나, 동기화된 CPU 제한을 넘어 실행 시간이 연장되어야 하는 경우 비동기 패턴을 사용합니다.

Salesforce 비동기 기능 및 아키텍처 맞춤:

• 배치 Apex: execute 메서드당 최대 2,000개의 레코드를 청크로 대용량 레코드를 처리합니다. 배치는 청크당 전용 총괄자 제한 및 실패 격리를 제공합니다. 청크가 실패해도 다른 청크가 완료되지 않습니다. 이를 통해 부분적으로 성공하고 표적 재시도할 수 있습니다. AsyncApexJob 개체에서 실패한 청크 범위를 추적하고 대상 배치 작업을 다시 대기열에 지정하여 임시 실패에 대한 사용자 정의 재시도 논리를 구현합니다. 데이터 마이그레이션, 예약된 대량 업데이트, 대규모 데이터 처리에 배치를 사용합니다. 조직당 실행 중이거나 보류 중인 배치 작업은 최대 5개입니다. Apex Flex 대기열에 추가 작업이 대기열에 지정됩니다(최대 100개의 작업이 보류 상태) 슬롯이 열리면 자동으로 실행됩니다.
• 대기 가능 Apex: 체인화 기능을 사용하여 비동기 작업을 실행하여 다단계 워크플로 및 복잡한 개체 매개 변수를 활성화합니다. Queueable Apex는 24시간마다 250,000건의 조직 전체 DailyAsyncApexExecutions 제한을 다른 모든 비동기식 Apex(배치, 미래, 예약된 Apex)와 공유하며, 전용 Queueable별 할당을 보유하지 않습니다. @future 메서드보다 더 나은 모니터링과 함께 순차적인 처리가 필요한 다단계 오케스트레이션 및 통합 워크플로에 대기 가능한 Apex 사용합니다.
• 플랫폼 이벤트: 플랫폼 이벤트는 게시자를 구독자와 분리하는 게시 구독 이벤트 아키텍처에서 사용됩니다. 이벤트는 유지 기간인 72시간(3일)에서 재생됩니다. 72시간 이상의 연장된 보존은 유료 추가 기능으로 사용할 수 있습니다. 연장된 재생에 의존하는 SLA 의무를 맺기 전에 최신 Salesforce Platform 이벤트 문서에서 현재의 최대 한도 및 GA 상태를 확인합니다. 이벤트 중심 자동화, 시스템 간 통합, 실시간 데이터 스트리밍에 플랫폼 이벤트를 사용합니다. 플랫폼 이벤트는 트랜잭션 단계 간의 자연스러운 비동기 경계를 제공합니다.
• 예약된 Apex: System.schedule()을 통해 CRON 식을 사용하여 고정된 일정에 따라 작업을 실행합니다. 작업을 한 시간에 한 번 이상 실행하도록 예약할 수 있습니다. CRON 초 및 분 필드는 범위가 아닌 고정 값을 사용해야 합니다. 유사한 작업을 단일 Schedulable 클래스로 통합하여 조직당 최대 100개의 예약된 Apex 작업 범위를 유지합니다.

대량 처리 및 비동기 패턴에서도 데이터 용량이 실제 처리 제한을 초과할 경우 논리적 경계 전반에 걸쳐 데이터를 분할하여 병렬 처리를 활성화합니다. 데이터 분할은 대규모 순차 작업을 더 빠르게 완료하고 총괄자 제한 내에 머무른 작은 병렬 작업으로 변환합니다.

• 날짜 기반 분할: 이번 달의 트랜잭션 또는 지난 분기의 사례를 포함하여 시간 구간에서 데이터를 처리합니다. 내역 데이터를 주요 개체 또는 외부 저장소에 보관하여 작업 집합을 관리 가능한 상태로 유지합니다. 대부분의 트랜잭션 쿼리는 시간 기반 파티션을 자연스럽게 효율적으로 만드는 최근 데이터에 초점을 맞춥니다.
• 레코드 유형 분할: 파트너 사례와 고객 사례 또는 엔터프라이즈 계정과 SMB 계정을 비교하여 다양한 레코드 유형을 독립적으로 처리합니다. 유형당 별도의 배치 작업을 사용하면 병렬이 활성화됩니다. 레코드 유형은 독립적인 처리를 정당화하는 고유한 비즈니스 프로세스와 관련이 있는 경우가 많습니다.
• 소유자 기반 파티션: 각 세일즈 지역의 기회를 독립적으로 처리하는 등 레코드 소유자별로 처리를 배포합니다. 소유자 기반 파티션은 기존 메커니즘을 통해 보안이 적용되므로 공유 모델과 결합하면 특히 효과적입니다. 소유자 기반 분할은 처리 로드의 지리적 분포를 지원합니다.

사용량 제한에 대응하는 대신 비즈니스 성장에 기반하여 향후 수용력 요구 사항을 예측합니다. 사전 예방적 수용력 계획은 플랫폼 자원 부족으로 인해 발생하는 신뢰 사고를 방지합니다.

• 사용자 라이센스 - 사용자당 사용자 수 증가를 촉진하는 API 호출 할당 및 스토리지 권한
• 데이터 저장소 - 트랜잭션 볼륨 및 보존 정책이 스토리지 소비량을 촉진합니다(최소 10%~20%의 연간 증가 계획).
• API 호출 - 통합 수와 주파수로 24시간 API 할당(새 통합 패턴마다 반복적인 소비량을 추가)
• 처리 용량 - 배치 작업 수와 복잡성이 비동기 처리 대기열 및 동시 실행 제한을 촉진합니다.

사전 Proactive Monitoring 사용하여 조직의 수용력 사용을 지속적으로 평가합니다. Proactive Monitoring 모니터링은 API 사용이 요청 제한 상승에 도달하고 저장소 제한에 도달하고 지속 가능한 수준을 넘어 증가하는 배치 작업 대기열 깊이 등 수용력 위험을 표시합니다. 주간 수용력 검토를 통해 비즈니스에 영향을 미치기 전에 추가 라이센스 또는 제한에 대한 조달 리드 시간을 확보할 수 있습니다.

프로덕션 배포 전에 로드 테스트를 통해 확장성 가정을 확인합니다. 로드 테스트는 소량 개발 테스트에서 볼 수 없는 총괄자 제한 문제, 통합 지체점, 수용력 제약을 보여줍니다. 프로덕션 규모의 데이터 볼륨 및 동시성을 사용하여 실질적인 조건에서 신뢰성을 검증합니다.

• 데이터 볼륨 테스트: 전체 복사 Sandbox에 프로덕션 규모의 데이터 볼륨을 채워 실제 데이터 왜곡, 관계 깊이, 레코드 수를 사용하여 쿼리 성능을 확인합니다. 프로덕션이 해당 규모에 도달하면 1,000만 개 이상의 레코드를 테스트합니다. 데이터 용량이 증가함에 따라 쿼리-optimizer의 동작이 급격하게 변경되며, 이는 소규모 확장형 테스트 결과를 잘못 만들 수 있습니다.
• 동시 사용자 테스트: 최대 동시 사용자 로드를 시뮬레이션하여 트랜잭션 처리량 및 충돌을 확인합니다. 적격 조직에 사용할 수 있는 규모 테스트를 사용하여 배포하기 전에 Sandbox 환경에서 프로덕션 워크로드를 시뮬레이션합니다. 동시 실행은 단일 사용자 테스트에서 보이지 않는 잠금 문제를 표시합니다.
• API 로드 테스트: 최대 API 볼륨을 생성하여 통합 확장성, 속도 제한 처리, 지속적인 부하 시 회로 차단기 동작을 확인합니다. API 로드 테스트는 재시도 논리 및 오류 처리가 스트레스 조건에서 올바르게 작동하는지 여부를 보여줍니다.
• 확장형 테스트: 확장형 테스트 프로덕션 수용력과 일치하도록 확장된 전체 사본 Sandbox 환경에 대한 프로덕션 워크로드를 시뮬레이션하는 데 사용되는 Salesforce 제품입니다. 확장형 테스트 Hyperforce 전체 사본 Sandbox에서 실행됩니다. 프로덕션 인스턴스를 사용하려면 Hyperforce 있지 않아도 됩니다. 테스트가 Sandbox에 대해 실행되는 동안 프로덕션 조직에서 테스트 계획을 만듭니다. 확장형 테스트 사용하여 주요 배포 전에 최대 로드 조건에서 총괄자 제한 헤드룸, 비동기 처리 처리 처리량, 통합 응답 동작을 확인합니다.

중요하지 않은 구성 요소가 실패할 경우 유연한 저하가 핵심 기능을 유지합니다. 장애 발생 시 지원 기능보다 중요 사용자 플로의 우선 순위를 지정하는 시스템을 설계합니다. 일부 기능은 비즈니스 중요도가 동일하지 않으며, 아키텍처는 이러한 우선 순위를 반영해야 합니다.

기능 중요성 계층 정의:

이 계층을 사용하면 아키텍처가 부분적인 시스템 장애 발생 시에도 비즈니스 연속성을 유지하는 저하 정책을 설계할 수 있습니다. 사용자는 완전한 가용성 대신 기능 감소를 선호합니다.

회로 차단기 패턴은 통합을 사용할 수 없는 경우 계단식 실패를 방지합니다. 트랜잭션 시간 및 총괄자 제한을 소비하는 시간 초과를 누적하는 대신 실패 패턴을 감지하고 실패 시스템 호출을 중지합니다. 회로 차단기는 느린 실패가 아닌 빠른 실패를 제공합니다.

회로 차단기 상태:

• 종료 - 정상 작동, 요청이 설계된 대로 외부 시스템으로 흐름
• 열림 - 실패 임계값을 초과하고, 외부 호출을 시도하지 않고 요청이 즉시 실패하고, 자원을 절약합니다.
• 반 개방형 - 회로를 완전히 닫기 전에 외부 시스템을 탐지하기 위한 제한된 요청 복구 테스트 기간

플랫폼 캐시를 사용하여 회로 차단기를 구현하여 모든 트랜잭션에서 액세스할 수 있는 회로 상태를 저장합니다. 플랫폼 이벤트를 사용하여 조직 전체에서 상태 변경 사항을 브로드캐스트합니다. 차단기 논리는 외부 호출을 시도하기 전에 상태를 확인하여 실패로 확인된 시스템에서 콜아웃 제한이 낭비되지 않도록 합니다.

일시적 오류는 분산 시스템에서 일반적입니다. 네트워크 중단, 일시적인 서비스 가동 불가능, 속도 제한 응답은 주로 몇 초 이내에 해결됩니다. 즉시 실패하지 않고 점진적인 지연 후 실패한 작업을 반복하는 재시도 논리를 구현합니다.

기하급수 백오프는 복구 시스템을 압도하는 재시도 폭풍을 방지합니다. 첫 번째 재시도는 1초 후에, 두 번째는 2초 후, 세 번째는 4초 후, 네 번째는 8초 후에 수행될 수 있습니다. 기하성 증가에 관계없이 최대 지연 30~60초로 제한됩니다. 이 백오프 패턴을 사용하면 실패한 시스템이 총 재시도 기간을 제한하면서 복구할 수 있습니다.

재시도 전략을 실패 유형에 일치시킵니다.

• 네트워크 시간 초과: 짧은 백오프로 다시 시도합니다(작업이 서버에 도달하지 못했을 수 있음)
• 율 제한 오류 (429): 재시도 후 머리글 값 또는 속도 제한 재설정 시간 이후 다시 시도
• 서버 오류 (5xx): 서버가 일시적으로 과부하될 수 있으므로 기하급수 백오프로 다시 시도하십시오.
• 클라이언트 오류(429를 제외한 4xx): 다시 시도하지 말고 잘못된 입력을 나타내는 오류로 요청을 수정합니다.
• 구버너 제한 오류: 동일한 트랜잭션에서 다시 시도하지 마십시오. 예를 들어 비동기적 구독자가 새 트랜잭션 제한 아래 백오프로 다시 처리하는 실패 이벤트를 게시하여 전용 제한이 있는 비동기 작업으로 다시 대기열 지정

대체 전략은 기본 메서드가 실패할 경우 대체 접근 방식을 정의하여 저하된 조건에서 계속 작업할 수 있습니다.

• 다른 데이터 소스: 실시간 API를 사용할 수 없는 경우 플랫폼 캐시 세션 또는 조직 파티션에서 데이터를 검색합니다. 성공적으로 작업하는 동안 캐시를 미리 채웁니다. 캐시는 오래되었지만 사용 가능한 데이터를 제공하며, 이는 많은 사용 사례에서 완전한 실패보다 낫습니다.
• 기본 동작: 개인 설정 또는 보강 서비스를 사용할 수 없는 경우 표준 비즈니스 규칙을 적용합니다. 기본값으로 처리하고 서비스 복구 시 보강에 플래그를 지정합니다. 기본 동작은 정밀도가 낮은 비용으로 처리량을 유지합니다.
• 수동 프로세스: 자동화가 실패하면 수동 작업 완료를 활성화합니다. 중단된 트랜잭션을 완료할 수 있는 관리자 인터페이스를 제공합니다. 수동 대체는 데이터 손실을 방지하고 자동화가 저하될 경우 비즈니스 연속성을 유지합니다.
• 다시 시도할 대기열: 외부 시스템이 복구될 때 처리할 수 있도록 플랫폼 이벤트 또는 사용자 정의 대기열 개체에 작업을 저장합니다. 72시간 표준 보존이 포함된 플랫폼 이벤트 재생을 통해 일시적인 실패 후 데이터 손실 없이 구독자 복구를 수행할 수 있습니다.

모든 통합 콜아웃에 적절한 시간 제한을 구성합니다. Salesforce는 트랜잭션당 총 콜아웃 시간을 최대 120초까지 적용합니다. 이번에는 단일 트랜잭션 내의 모든 콜아웃 전반에 대한 예산을 할당하여 대기 중인 연결에서 트랜잭션 시간이 소모되지 않도록 합니다.

시간 제한 설계 고려 사항:

• 사용자 방향 동기식 콜아웃: 사용자가 더 이상 대기하지 않는 경향이 있으므로 최대 5~10초를 사용하여 반응형 UI 유지
• 백그라운드 비동기식 콜아웃: 30~60초를 사용하여 사용자가 기다리지 않고 변수 외부 성능을 수용
• 배치 처리 콜아웃: 사용자가 응답을 기다리지 않을 때 허용되는 전한 120초 사용
• 트랜잭션당 여러 콜아웃: 각각 120초 예산의 30초를 소비하는 10초로 3개의 콜아웃 등 모든 콜아웃 전반의 예산 총 시간입니다.

시간 초과가 짧을수록 실패가 더 빠르므로 대체 전략이 더 빨리 참여할 수 있습니다. 시간 초과가 길면 느리지만 기능이 적은 외부 시스템의 성공률이 증가합니다. 잔액 고려 사항은 사용자가 응답을 기다리고 있는지 여부 및 대체 전략의 가용성을 기반으로 합니다.

종합적인 오류 처리를 설계하여 실패를 충돌에서 관리되는 성능 저하로 전환합니다.

• 빠르게 실패: 입력 지점에서 입력 및 전제 조건을 확인합니다. 비용이 많이 드는 작업 전에 총괄자 제한 소비를 확인합니다. 여러 처리 계층을 통해 잘못된 상태를 전파하는 대신 즉시 실패를 감지합니다. 조기에 감지를 수행하면 폭발 반경이 줄어들고 디버깅이 간소화됩니다.
• 순수하게 실패: 작업이 부분적으로 실패하는 경우에도 사용자 기능을 유지합니다. 배치의 레코드 200개 중 3개가 유효성 검사에 실패할 경우 전체 배치가 실패하는 대신 성공한 레코드를 197개 처리하고 실패를 보고합니다. 일부 성공은 배치 작업의 전체 실패보다 낫습니다.
• 정보적으로 실패: 트랜잭션 ID, 사용자 컨텍스트, 입력 매개 변수, 스택 추적과 함께 오류를 기록합니다. 오류 컨텍스트가 부족하면 사고를 신속하게 해결하기 위한 주요 장애물이 됩니다. 모든 오류 로그를 사용하면 응답자가 실패한 내용, 실패 이유, 재현 방법을 파악할 수 있습니다.
• 안전한 실패: 실패로 인해 데이터 무결성 또는 보안이 저하되지 않도록 합니다. 데이터를 일관되지 않은 상태로 두지 않고 부분 트랜잭션을 롤백합니다. 스택 추적은 공격자에게 유용한 구현 세부 사항을 표시하므로 최종 사용자에게 내부 오류 세부 사항을 노출하지 마십시오.

복구 시간 목표는 재해 후 허용되는 최대 가동 중지 시간을 정의합니다. RTO는 페일오버 자동화, 백업 주기, 복구 테스트 투자에 대한 아키텍처적 결정을 촉진합니다. 비즈니스 기능이 다르면 다양한 RTO 투자를 할 수 있습니다. RTO는 사용자가 직접 경험하는 가동 중지 시간이므로 실패한 대상은 장기간 중단되고 고객 Trust 손상됩니다.

RTO는 비즈니스 성능에 따라 다릅니다.

재해 복구 아키텍처를 설계하기 전에 수용력당 RTO를 정의합니다. RTO는 기술 선택, 자동화 투자, 테스트 케이던스를 구성합니다. 더욱 적극적인 RTO 대상을 위해 자동화 및 중복에 더 많은 투자를 해야 합니다.

복구 지점 목표는 시간에 측정된 허용되는 최대 데이터 손실 기간을 정의합니다. RPO는 백업 빈도, 복제 전략, 동기화 패턴을 결정합니다. 더욱 엄격한 RPO를 사용하려면 더 자주 데이터를 복제해야 하므로 복잡성과 비용이 증가합니다. RPO는 비즈니스에서 흡수하는 데이터 손실이므로 대상 누락은 트랜잭션 손실 및 레코드에서 복구할 수 없는 공백을 의미할 수 있습니다.

비용 및 복잡성에 대한 RPO 요구 사항의 균형을 맞춥니다. 거의 0 RPO는 상당한 인프라 투자로 지속적인 데이터 복제가 필요합니다. 일일 백업은 복잡성이 최소화된 24시간 RPO를 제공합니다. 대부분의 조직은 비 금융 데이터에 대한 일부 데이터 손실을 허용할 수 있습니다.

플랫폼 인프라 중복은 인프라 장애를 방지하지만 대부분의 데이터 손실을 유발하는 사용자 오류, 결함이 있는 배포, 통합 결함의 결과를 복제합니다. 백업은 플랫폼의 신뢰성을 보상하지 않고 이러한 응용 프로그램 계층 실패를 복구하기 위해 존재합니다. 각각 다른 백업 접근 방식이 필요하므로 데이터, 메타데이터, 파일을 포함하는 백업 전략을 구현합니다.

• 데이터 백업: 데이터와 메타데이터를 모두 해결하는 포괄적인 백업 전략을 구현합니다. 기본 데이터 내보내기 서비스를 사용하여 중요한 개체 데이터를 내보냅니다. Enterprise, Performance, Unlimited Edition의 경우 7일마다, Professional 및 이후 버전의 경우 29일마다. 자동 삭제 전에 주말을 제외하고 알림 이메일이 전송된 후 48시간 동안 내보내기 파일을 사용할 수 있습니다. 파일이 영구적으로 손실되지 않도록 자동 다운로드 프로세스를 설정합니다. 메타데이터 API 및 Salesforce CLI(sf 프로젝트 검색)를 사용하여 Git와 같은 소스 제어 시스템에서 버전 제어 조직 구성, 사용자 정의 코드 및 선언적 자동화를 수행합니다. 표준 CI/CD 파이프라인의 일부로 메타데이터 백업을 처리합니다. 포인트 인 타임 복원, 세분화된 레코드 수준 복구, 네이티브 내보내기 케이던스 외 유지와 같은 전용 백업 및 복구 서비스를 사용하여 데이터 백업을 보완합니다.**** 기본 데이터 내보내기는 시점 복원을 지원하지 않으며 RTO/RPO에 세분화된 복구 기간이 필요한 경우 타사 도구가 필요합니다. 정기적으로 복원 절차를 테스트합니다. 복원되지 않은 백업은 테스트되지 않은 가정입니다.
• 메타데이터 백업: Git 저장소의 Salesforce DX 소스 형식을 사용하여 모든 메타데이터를 버전으로 제어합니다. 메타데이터 버전 관리를 사용하면 손상 또는 의도하지 않은 변경 후 빠르게 구성을 복원할 수 있습니다. 모든 배포는 소스 제어에서 재현할 수 있어야 합니다. Git의 메타데이터는 구성을 위한 시점 복구를 제공합니다.
• 파일 백업: ContentVersion 레코드, 첨부 파일 및 문서를 외부 저장소로 내보냅니다. Salesforce는 장기 파일 보관이 아닌 활성 데이터에 가장 적합합니다. 규정 보존을 위해 파일을 외부 저장소로 내보냅니다. 플랫폼 기능을 초과하는 규제 보존 요구 사항에 대해 자동 파일 내보내기를 구현합니다.
• 확인: 스크래치 조직 또는 개발자 Sandbox에 대한 백업을 정기적으로 복원하여 절차 및 백업 무결성을 모두 확인합니다. 백업 범위가 불완전하거나 아카이브가 손상되어 필요한 경우 테스트되지 않은 백업이 실패하는 경우가 많습니다. 분기별 복원 유효성 검사를 예약하여 재해가 발생하기 전에 문제를 파악합니다. 복원 확인 외에도 백업 새로 고침을 모니터링합니다. 가장 최근에 성공한 백업이 예상 케이던스보다 오래된 경우(예: 주간 내보내기가 8일 이상 완료되지 않은 경우) 경고를 표시합니다. 이 확인을 통해 자동으로 실패한 백업 작업이 다음 세부적으로 표시되지 않고 즉시 나타납니다.

RPO 및 다중 조직 요구 사항에 적합한 복제 설계:

• 변경 데이터 수집(CDC): 추적된 개체에 대한 변경 이벤트를 구독합니다. CDC는 필드 값이 변경된 만들기, 업데이트, 삭제, 삭제 취소 이벤트를 제공합니다. 표준 및 사용자 정의 등 지원되는 개체에 대한 개발 노력을 최소화하면서 거의 실시간으로 복제를 제공합니다. Edition에 따른 일일 배달 할당이 적용됩니다.
• 플랫폼 이벤트: 비즈니스 이벤트 및 상태 변경을 복제하기 위한 사용자 정의 이벤트 아키텍처입니다. 사용자 정의 페이로드 및 복잡한 이벤트 구조를 지원하는 CDC보다 유연하지만 트리거 또는 프로세스에서 명시적 게시 논리가 필요합니다. 72시간 재생 기간 표준은 임시 구독자 실패 복구를 지원합니다.
• 예약된 API 복제: 예약 API 복제는 고정된 일정에 대량 API 2.0을 통한 배치 추출입니다. 추출 주기와 동일한 RPO가 있는 가장 간단한 구현입니다. 예약된 API 복제는 참조 데이터 또는 내역 분석과 같이 거의 실시간 실행이 필요하지 않은 비중요 데이터에 적합합니다.
• MuleSoft 오케스트레이션 복제: 복잡한 다중 시스템 복제 토폴로지의 경우 MuleSoft Anypoint Platform은 오케스트레이션, 변환, 모니터링을 제공합니다. 이를 사용하면 Salesforce 및 다중 외부 시스템 전반에서 복제할 수 있으므로 정교한 라우팅 및 변환 논리가 필요합니다.

사람, 프로세스, 기술을 함께 확인하는 예약된 드릴을 사용하여 재해 복구를 테스트합니다.

• Tabletop 연습: 팀은 실제 페일오버 없이 역할 및 결정 지점을 논의하는 재해 시나리오를 살펴봅니다. 이 활동은 비용이 낮으며 절차적 차이와 커뮤니케이션 장애가 표시됩니다. 직원 변화에 맞춰 팀의 준비 상태를 유지하기 위해 정기적으로 테이블 모음 연습을 수행합니다.
• 일부 페일오버: - 소스 제어에서 메타데이터 복원, 백업 서비스에서 데이터 복원 또는 Sandbox 새로 고침과 같은 특정 복구 절차를 테스트합니다. 이는 비즈니스에 제한된 영향을 미치는 기술 절차의 유효성을 검사합니다. 연간 모든 복구 기능을 적용하도록 테스트되는 절차를 순차적으로 순환하여 정기적으로 수행합니다.
• 전체 페일오버 드릴: 전체 페일오버는 프로덕션 트래픽 컷오버를 사용하는 재해 복구 환경에 대한 완전한 페일오버입니다. 가장 높은 신뢰도를 제공하지만 비즈니스 조정과 사용자 커뮤니케이션이 필요합니다. 중요 시스템에 대해 매년 이 드릴을 수행합니다. 전체 페일오버 드릴은 컷오버 절차 및 사용자 커뮤니케이션 등 전체 복구 기능을 확인합니다.

모든 드릴 후에 학습된 내용을 문서화합니다. 결과를 기반으로 실행북을 업데이트합니다. 팀이 변화하고 솔루션이 발전함에 따라 복구 기능이 저하될 수 있습니다. DR 문서를 일회성 배달이 아닌 정기적인 서비스 점검이 필요한 실물로 취급하십시오.

비즈니스 연속성은 기술 복구 이상으로 사람, 프로세스, 공급업체 종속성을 포괄합니다.

• 팀 가용성: 중요 역할에 대한 에스컬레이션 절차 및 백업 직원을 문서화합니다. 운영 Knowledge 단일 지점이 없는지 확인합니다. 재해 발생 시 기본 대응 담당자를 사용할 수 없을 수 있으므로 백업 직원 배치가 매우 중요합니다.
• 통신 절차: 사용자, 고객, 경영진에게 사고가 전달되는 방법을 정의합니다. Salesforce 자체 등 기본 도구(예: 외부 상태 페이지 또는 SMS 알림 시스템)를 사용할 수 없는 경우 작동하는 커뮤니케이션 채널을 설정합니다.
• 공급업체 부속: 솔루션 운영에 중요한 외부 공급업체 종속성을 매핑합니다. Salesforce, 통합 파트너, ISV 패키지 공급자를 비롯한 각 중요 공급업체에 대한 에스컬레이션 경로 및 계약 SLA를 문서화합니다. 예를 들어 연중무휴 지원을 제공하는 공급업체와 복구 타이밍에 영향을 미치는 업무 시간 전용 지원을 제공하는 공급업체를 이해합니다.
• 규제 의무: 연장 중단으로 인해 트리거되는 알림 요구 사항을 식별합니다. 금융 서비스, 헬스케어, 정부 계약은 특정 시간 범위 내에서 사고 알림을 요구하는 경우가 많습니다. 규정을 준수하지 않으면 규정 및 법적 위험이 발생할 수 있으며, 이는 모두 복합 재해에 영향을 미칩니다.

여러 신호를 전체 시스템 상태로 집계하는 상태 모델을 정의합니다. 건강 모델은 상세한 메트릭 분석이 필요하지 않고도 한눈에 운영 상태를 보여줍니다. 예:

즉시 운영 상태를 표시하는 상태 대시보드를 설계합니다. 상태는 녹색 상태의 정상 작업, 노란 상태의 강화된 모니터링, 빨간색 상태의 활성 사고 응답 등 운영 응답을 안내합니다.

플랫폼 상태 신호(이전에 플랫폼 상태 모니터링)는 Salesforce 인프라가 저하되었지만 자체 솔루션의 성능은 표시되지 않습니다.

솔루션별 관찰 가능성을 사용하여 다음 신호를 늘립니다.

• 이벤트 모니터링: 이벤트 모니터링에는 API 호출, 페이지 보기, 보고서 내보내기, 로그인 활동 및 Apex 실행을 캡처하는 자세한 로그가 포함되어 있습니다. EventLogFile 개체는 24시간(매일) 또는 1시간 빈도로 로그를 전달합니다. 시간당 전달 시 이벤트 모니터링 추가 기능 또는 Salesforce Shield 필요합니다. 보존은 설정을 통해 최대 365일까지 구성할 수 있지만, 연장 보존에는 Salesforce Shield 또는 이벤트 모니터링 추가 기능이 필요합니다. 추가 기능이 없으면 로그 파일이 1일 동안 보존됩니다. 외부 보안 정보 및 이벤트 관리(SIEM) 시스템 또는 로그 집계 플랫폼에 이벤트를 라우팅하여 네이티브 제한을 넘어 상관 관계, 경고, 유지합니다. 이벤트 모니터링을 사용하여 비정상적인 API 사용 패턴을 감지하고, 실행 중인 Apex 프로세스를 식별하고, 규제된 환경에서 데이터 액세스를 감사합니다.
• 스케일 센터: 확장 센터는 장기 실행 작업, 행 잠금 충돌, 자원 집약 트랜잭션에 대한 트랜잭션 수준 가시성을 제공합니다. 스케일 센터를 사용하면 아키텍처가 특정 트랜잭션 패턴의 신뢰성 위험을 식별한 후에 사용자 대면 사고가 발생할 수 있습니다. 매주 검토하면 최적화 기회가 표시될 수 있습니다.
• 사전 예방적 모니터링: Proactive Monitoring 사용하면 조직 상태를 지속적으로 평가하여 성능 및 확장성 위험을 파악할 수 있습니다. Proactive Monitoring API 요청 제한 증가, 동시 Apex 실행 실패, SOQL 행 제한 문제, 스토리지 소비 추세에 대한 경고를 제공합니다. Signature Success(이전 서명 지원) 권한이 있는 고객에게 제공되며, 표준 버전에 포함된 셀프 서비스 기능이 아닙니다.

인프라스트럭처 관점이 아닌 사용자 관점에서 응용 프로그램 성능을 모니터링합니다.

• 실제 사용자 모니터링(RUM): Experience Cloud 분석 또는 사용자 정의 계측을 통해 실제 사용자 환경을 측정합니다. RUM은 실제 네트워크 조건, 장치 성능, 지리적 분포를 반영하는 실제 대기 시간을 수집합니다. 합성 모니터링은 이 변수를 복제할 수 없습니다.
• 합성 모니터링: 여러 위치에서 주기적으로 자동화된 트랜잭션을 실행하여 가용성 및 성능을 확인합니다. 합성 모니터링은 사용자가 보고하기 전에 문제를 감지합니다. 예약된 Apex 사용하여 합성 모니터링을 구현하고, 중요 작업을 실행하고, 플랫폼 이벤트로 결과를 보고합니다.
• 트랜잭션 추적: 단계당 타이밍을 수집하는 복잡한 다단계 작업을 계측합니다. 그런 다음, 5단계 워크플로에서 대기 시간이 발생하는 단계를 식별합니다. 전체 플로를 블랙박스로 취급하지 마십시오. 단계 수준 타이밍은 집계 메트릭에 표시되지 않는 최적화 기회를 표시합니다.

오류 비율, 대기율 백분율, 처리량을 사용하여 모든 외부 통합을 모니터링합니다. 통합 실패는 신뢰성 사고의 주요 원인입니다.

• 오류율 - 오류를 반환하는 통화 비율(목표: 정상적인 통합의 경우 <1%)
• 지연 시간 - p50, p95, p99로 측정된 응답 시간(시간 초과 예산을 기반으로 통합당 SLO 설정)
• 시간 초과율 - 구성된 시간 초과를 초과하는 비율(목표: <0.1%)
• 교환기 상태 - 열림 상태는 즉각적인 주의가 필요한 지속적인 오류를 나타냅니다.
• 대기열 깊이 - 비동기 통합의 경우 증가하는 대기열은 처리 속도가 생산 속도 뒤로 떨어지는 것을 나타냅니다.

모든 통합 호출을 요청 ID, 끝점, 응답 코드, 기간으로 기록합니다. 이 데이터를 사용하면 통합 실패로 인해 신뢰성에 영향을 미칠 경우 근본 원인을 빠르게 분석할 수 있습니다. 통합 로그는 집계 및 추세 분석을 활성화해야 합니다.

사용자에게 영향을 미치기 전에 문제에 대한 경고를 설계하여 사전 예방적 응답을 활성화합니다.

• 실행 가능한 경고: 모든 경고에는 정의된 응답 작업과 할당된 응답자가 있습니다. 명확한 응답이 없는 경고는 피로와 모호한 중요 신호를 생성합니다. 경고 설계에는 응답하는 사람, 확인하는 항목 및 수정 방법이 포함되어야 합니다.
• 적절한 긴급: 사용자에게 영향을 미치는 실패에 대한 방문 담당자에게 페이지를 보냅니다. 성능이 저하된 경우 이메일을 보냅니다. 일일 요약에 문제를 포함하여 추세와 관련하여 수집합니다. 긴급성이 일치하지 않으면 과도한 에스컬레이션으로 인해 경고 피로 또는 에스컬레이션 부족으로 인해 누락된 사고가 발생합니다.
• 컨텍스트가 풍부한 알림: 지정된 임계값, 현재 값, 최근 추세, 관련 대시보드 또는 실행북에 대한 링크를 포함합니다. 응답자가 컨텍스트를 수집하지 않고 즉시 진단을 시작할 수 있습니다. 모든 경고에 추가 쿼리 없이 정렬할 수 있는 충분한 정보가 포함되어야 합니다.
• 폭풍 억제: 여러 시스템이 동시에 실패할 경우 중복 경고를 억제합니다. 통합 플랫폼 실패를 나타내는 하나의 경고는 근본 원인을 숨기는 50개의 개별 통합 실패 경고보다 실행할 수 있습니다.

변칙 감지는 일반적이지 않은 패턴을 식별하고 정적 임계값 경고에 표시되지 않는 신규 문제를 나타낼 수 있습니다.

• 볼륨 변칙: 트랜잭션 볼륨이 예상되는 일일 패턴보다 상당히 높거나 낮을 경우 런어웨이 프로세스 또는 사용자 액세스 문제를 나타낼 수 있습니다.
• 오류율 변칙: 같은 시간 - 지난 주 기준선과 비교하여 증가한 오류 비율은 임계값 위반이 발생하기 전에 점진적으로 저하됩니다.
• 대기 시간 변칙: 여러 날 동안 상향으로 드리프트되는 응답 시간은 수용력 채워짐 또는 성능 회귀를 나타냅니다.
• 행동 변칙: 일반적이지 않은 로그인 패턴, 예기치 않은 API 사용 증가, 예약 기간 외에 실행되는 배치 작업은 의심스러운 사용을 나타낼 수 있습니다.

서명 성공 권한이 있는 고객의 경우 Proactive Monitoring 추가 구성 없이 플랫폼 수준의 변칙 감지를 제공합니다. 외부 분석 플랫폼으로 내보낸 사용자 정의 SLI에 대한 응용 프로그램별 변칙 감지로 보완합니다. 변칙 감지에 임계값 경고보다 더 높은 위양성 비율이 있기 때문에 변칙 신호를 사용하여 즉시 에스컬레이션을 트리거하는 대신 조사를 안내합니다.

아키텍처를 검토하는 동안, 프로덕션 배포 전에, 지속적인 신뢰도 평가를 위해 주기적으로 이 체크리스트를 사용합니다.

신뢰도 목표 및 SLO

• 설계를 시작하기 전에 모든 중요 사용자 플로에 대한 SLO 정의
• 인프라 메트릭뿐만 아니라 사용자 환경과 연결된 측정 가능한 SLI 설정
• 임의의 목표가 아닌 비즈니스 영향 분석을 기반으로 실질적인 가용성 목표 설정
• 오류 예산을 제공하기 위해 솔루션 SLO가 플랫폼 SLA보다 엄격하지 않은지 확인
• 아키텍처 결정 레코드의 문서 가용성 목표 및 근거

고가용성 아키텍처

• 데이터, 응용 프로그램, 통합 계층의 중복 설계
• Trust.salesforce.com 및 인스턴스 상태 API를 통해 플랫폼 상태 모니터링
• 플랫폼 상태와 무관한 응용 프로그램 상태 확인 구현
• 비즈니스 요구 사항이 복잡성을 명확하게 정당화하는 경우에만 다중 조직 아키텍처를 고려하십시오.
• 테스트된 다중 조직 패턴의 실행북을 사용하여 자동 페일오버 설계

확장성 및 수용력 계획

• 일반 부하에서 총괄자 제한의 70% 이내에 완료되는 트랜잭션 설계
• 모든 Apex 트리거, 배치 클래스 및 통합에 대량 처리 패턴 구현
• 동기 제한을 초과하는 작업에 비동기 처리 사용
• 개별 레코드 호출 대신 모든 API 통합 배치
• 배포 전에 프로덕션 규모 데이터 볼륨으로 로드 테스트 수행
• OrgLimits API 또는 사용자 정의 Apex 통해 수용력 사용량 모니터링 및 사용량이 70% 운영 제한에 도달할 때 경고
• 12개월 성장 예상에 따른 프로젝트 수용력 요구 사항
• 날짜, 레코드 유형 또는 소유자별로 대용량 데이터를 분할하여 볼륨이 순차 제한을 초과할 경우 병렬 처리를 활성화합니다.

장애 허용 및 복원성

• 정의된 기능 중요성 계층으로 유연한 저하 설계
• 모든 외부 시스템 통합에 대한 회로 차단기 구현
• 임시 실패에 대한 기하수적 백오프를 사용하여 재시도 논리 적용
• 작업 유형에 적합한 시간 초과 구성(사용자 대면 510초, 비동기 3060초)
• 플랫폼 캐시 및 대기열 기반 패턴을 사용하여 대체 전략 설계
• 충분한 진단 컨텍스트를 사용하여 구조화된 오류 처리를 구현

재해 복구 및 무중단 업무 운영

• 설계 전에 비즈니스 성능당 RTO 및 RPO 정의
• 데이터, 메타데이터(소스 제어), 파일에 대한 자동 백업 구현
• 비프로덕션 환경에서 분기별 백업 복원 절차 확인
• 예약된 백업 지연 시 백업 새로 고침 모니터링 및 경고
• RPO 요구 사항과 일치하는 데이터 복제 전략 설계
• 연간 재해 복구 테스트 수행(태블릿탑 분기별)
• 공급업체 에스컬레이션 경로를 포함한 비즈니스 연속성 절차 문서화

모니터링 및 관찰 가능성

• 서비스, 통합, 데이터, 수용력 신호를 집계하는 건강 모델 정의
• Salesforce 인스턴스에 대한 플랫폼 상태 알림 구독
• 중요한 Experience Cloud 플로에 대한 실제 사용자 모니터링 구현
• 오류 속도, 대기 시간, 회로 차단기 상태로 통합 상태 모니터링
• 정의된 응답 절차 및 소유권으로 실천 가능한 경고 설계
• 장기 보존 및 분석을 위해 이벤트 모니터링 데이터를 외부 플랫폼으로 라우팅
• Proactive Monitoring 및 Scale Center를 사용하여 지속적인 신뢰성 위험 평가
• 볼륨, 오류 비율, 대기 시간 패턴에 대한 변칙 감지를 적용하여 정적 임계값에서 놓친 저하를 포착합니다.

좋게 설계된 프레임워크에 대한 사용자 의견을 공유하십시오.