저장소 및 API 비용 최적화 - 패턴
잘 설계된 자원 및 비용 최적화에 대해 자세히 알아보기 → 데이터 최적화
패턴
| 찾을 위치 | 유사성 |
|---|---|
| 데이터 모델 활성 데이터 | ✅ 활성 데이터는 프리미엄 스토리지 처리를 받습니다 - 비즈니스 운영을 위해 정기적으로 액세스한 데이터는 전체 쿼리 기능, 워크플로 자동화, 사용자 액세스를 갖춘 표준 Salesforce 개체로 유지됩니다. 자주 액세스하려면 즉시 가용성이 필요하므로 활성 데이터가 저장소에 투자해야 합니다. ✅ 예: 현재 연도 기회 및 활성 사례는 전체 기능을 갖춘 표준 개체에 유지됩니다. |
| 데이터 모델 뜨거운 데이터 | ✅ 온드 데이터는 중간 수준의 스토리지 전략을 사용합니다 - 보고 또는 참조를 위해 가끔 액세스한 데이터는 필터링된 보기를 지원하는 아카이빙 플래그가 있는 Salesforce에 남아 있거나 워크플로 기능이 없는 인덱스 기반 검색을 지원하는 주요 개체로 마이그레이션할 수 있습니다. ✅ 예: 보관된 상태로 플래그가 지정된 이전 연도 기회는 내역 분석을 위해 계속 쿼리할 수 있습니다. |
| 데이터 모델 콜드 데이터 | ✅ Big Objects 또는 외부 시스템에 아카이빙되는 콜드 데이터 - 규정 준수를 위해 보존되는 데이터는 거의 액세스하지 않는 경우 Big Objects(표준 데이터 저장량 제한에 포함되지 않음) 또는 외부 아카이빙 시스템으로 이동합니다. 예측 가능한 액세스 패턴이 있는 대용량 아카이빙에 적합한 주요 개체입니다. 데이터 웨어하우스 또는 개체 저장소에 외부 보관 - 규정 준수 데이터 보존 비용 최소화 ✅ 예: 규정 준수 액세스를 위해 색인 기반 검색을 사용하여 주요 개체에 보관된 36개월 이상 경과한 사례 |
| 만료된 데이터 데이터 모델 | ✅ 자동화된 수명 주기 프로세스를 통해 삭제된 데이터 - 비즈니스 가치가 없는 데이터 과거 보존 요구 사항은 무기한 누적이 아닌 자동화된 프로세스를 통해 삭제해야 합니다. 많은 조직은 “다음에 필요할 경우 어떻게 해야 할지” 걱정으로 인해 데이터를 삭제하지 않으므로 비즈니스 근거 없이 스토리지 증가 예산이 소모됩니다. ✅ 예: 데이터 보존 정책은 규제 보존 요구 사항에 따라 7년 후에 레코드를 자동으로 삭제합니다. |
| 설정 → 시스템 개요 → 데이터 저장소 설정 → 스토리지 사용량 | ✅ 패턴: 수용력 대시보드에 증가 추세가 있는 개체별 스토리지 소비량, 상위 패턴과 통합된 API 사용량, 예상 처리 수용력 활용도가 표시됩니다. ✅ 제한으로 인해 중단 또는 예기치 않은 초과 요금이 발생하기 전에 사전 예방적 최적화 활성화 |
| 스토리지 추적 없음 → Annual Surprises | ⚡️ 안티 패턴: 보관 전략을 평가할 시간 없이 프리미엄 가격으로 즉시 구매해야 하는 갱신 협상 동안 발견된 스토리지 초과 사용 ⚡️ 조직에서 수용력 소비 데이터 또는 보관 성장을 저하할지 여부를 분석하지 않고 매년 추가 저장소를 구매합니다. |
패턴
| 찾을 위치 | 유사성 |
|---|---|
| 대용량 파일 Salesforce Files | ✅ 외부 파일 저장소 통합 - 대규모 비용 절감 - Salesforce에서 외부 콘텐츠에 연결되는 참조 레코드를 유지하면서 Amazon S3 또는 Azure Blob Storage와 같은 서비스에 파일을 저장합니다. Salesforce 파일 저장소가 Edition에 따라 월별 GB당 1 ✅ 예: 계약 관리 솔루션은 기본 미리 보기 및 공동 작업을 위해 활성 계약(지난 24개월)을 Salesforce Files에 저장하고 Salesforce 링크를 사용하여 이전 계약을 S3로 자동 마이그레이션하여 액세스를 유지하면서 파일 저장소를 70% 줄입니다. ✅ 상환: 외부 저장소 통합은 개발 노력을 필요로 하며 외부 서비스에 대한 종속성을 도입하지만 파일이 많은 사용 사례에서 비용을 10 |
| 콘텐츠 관리 파일 수명 주기 | ✅ 파일 수명 주기 관리에서 오래된 파일을 보관하거나 삭제 - 외부 저장소 또는 삭제에 보존 임계값을 넘어 파일을 자동으로 보관합니다. 최초 생성 후 거의 액세스하지 않는 파일(마감된 사례에 대한 사례 첨부 파일 및 대체된 문서 버전 포함)은 기본 보관 후보입니다. ✅ 참고: 파일 저장소에는 Salesforce Files, 첨부 파일, 문서 및 콘텐츠가 포함됩니다. 계약 관리, 자산 라이브러리, 사례 첨부 파일 등 문서가 많은 사용 사례가 있는 조직은 데이터 저장소보다 빠르게 파일 저장소 제한에 도달하는 경우가 많습니다. |
패턴
| 찾을 위치 | 유사성 |
|---|---|
| Sandbox 관리 부분 복제 템플릿 | ✅ 선택적 데이터 템플릿은 샌드박스 저장 용량을 최적화합니다 - 전체 데이터 용량이 테스트 시나리오에 필요하지 않은 경우 부분 복제 템플릿에서 대용량 개체를 제외합니다. Sandbox별 데이터 보존을 구현하여 테스트 요구보다 오래된 레코드를 제거하고 추가 테스트 데이터 용량을 확보합니다. ✅ 예: 부분 복사 Sandbox 템플릿에는 지난 12개월간의 기회 및 사례가 포함되지만 보관된 데이터는 제외되어 전체 복사 필요 없이 5GB 용량 내의 대표적인 테스트 데이터를 제공합니다. ✅ 상환: 선택적 데이터 템플릿을 정의하려면 분석 작업이 필요하지만 테스트 시나리오에 불필요한 데이터를 제거하여 비용이 적은 Sandbox 유형을 사용할 수 있습니다. |
| Sandbox 관리 새로 고침 케이던스 | ✅ 실제 데이터 새로 고침 요구 사항에 맞춰 케이던스 새로 고침 - 임의의 일정이 아닌 실제 데이터 새로 고침 요구 사항에 맞춰 샌드박스 새로 고침을 조정합니다. 많은 조직이 테스트 패턴에 분기별 새로 고침이 충분할 경우 매월 전체 사본 Sandbox를 새로 고치므로 추가 Sandbox를 지원할 수 있는 새로 고침 용량이 낭비됩니다. ✅ 예: 전체 사본 Sandbox는 매달이 아닌 분기별로 새로 고쳐 추가 부분 사본 Sandbox에 대한 새로 고침 용량을 확보합니다. |
| Sandbox 관리 임시 Sandbox | ✅ 만료 정책이 있는 임시 샌드박스 관리 - 문서화된 삭제 날짜를 사용하여 특정 프로젝트 또는 스파이크 테스트에 대해 생성된 환경을 추적합니다. 임시 Sandbox 확산은 프로젝트 Sandbox가 근거 없이 영구 상태로 전환되므로 일반적인 폐기물 소스입니다. 갱신 사유가 필요한 만료 정책을 구현하여 초기 범위를 벗어난 임시 환경 유지 ✅ 예: 프로젝트 완료 이후로 연장하는 비즈니스 근거가 필요한 90일 만료 시 생성된 프로젝트 sandbox |
패턴
| 찾을 위치 | 유사성 |
|---|---|
| 통합 모니터링 피크 사용량 분석 | ✅ 최대 사용량 분석 - 일정 최적화 기회를 파악 - 일일 및 주간 소비 패턴을 파악합니다. 업무 시간에 집중된 통합 일정은 사용자 시작 API 호출과 경쟁합니다. 일괄 통합을 피크 외 기간 전체에 분산하여 제한을 늘리지 않고 수용력 활용도를 최적화 ✅ 예: 오전 9시~오전 2시로 배치 통합이 다시 예약되어 최대 시간의 API 충돌을 줄이고 기존 수용력 내에서 추가 통합이 활성화됨 |
| 사용자 정의 코드 대량 API 2.0 | ✅ 수백 개의 레코드를 처리하는 작업에 대한 Bulk API 2.0 - 수백 개 이상의 레코드를 처리하는 작업에 대량 API 2.0을 사용합니다. 대량 API는 작업당 최대 150만 개의 레코드를 처리하며, 개별적으로 레코드를 처리하는 것과 비교하여 최소한의 API 호출을 사용합니다. ✅ 예: 야간 데이터 동기화는 레코드당 개별 API 호출 대신 최소한의 API 소비를 통해 100,000개의 레코드를 처리하는 대량 API 2.0을 사용합니다. |
| 사용자 정의 코드 플랫폼 캐시 | ✅ 플랫폼 캐시는 참조 데이터에 대한 반복 쿼리를 제거합니다 - 자주 액세스한 참조 데이터를 캐시하여 반복 쿼리를 제거합니다. 국가 코드, 제품 카탈로그 또는 구성 데이터 캐싱은 변경되지 않는 참조 데이터를 반복적으로 쿼리하는 통합의 API 소비를 줄입니다. ✅ 예: 플랫폼 캐시에 캐시된 제품 카탈로그로 일일 쿼리 1,000개에서 단일 캐시 새로 고침으로 API 호출 감소 |
| 통합 아키텍처 변경 데이터 수집 | ✅ 변경 데이터 수집은 낭비적인 폴링 패턴을 제거합니다 - 폴링 패턴이 아닌 데이터 동기화에 변경 데이터 수집을 사용합니다. CDC는 데이터가 변경될 때만 이벤트를 게시하므로 발생하지 않은 변경 사항을 확인하는 API 호출이 낭비되지 않습니다. ✅ 예: 고객 데이터 동기화는 고객이 업데이트할 때 변경 데이터 수집 게시 이벤트를 사용하며, 실제 변경 사항에 대해서만 API 호출을 사용합니다(매일 200개) 모든 고객 레코드를 매시간 폴링하는 대신(매일 1.2백만 개의 쿼리) ✅ 상환: 이벤트 중심 아키텍처는 플랫폼 이벤트 또는 CDC 구현 노력을 필요로 하지만 변경 감지 패턴에 대한 API 소비량을 95% 이상 줄여주며 몇 주 이내에 중단 |
| 모니터링 없음 → 반응형 검색 | ⚡️ 안티 패턴: 제한 예외가 발생하는 경우에만 API 소비가 모니터링되므로 압박을 받는 상태에서 반응형 소방 및 비상 아키텍처 변경이 발생합니다. ⚡️ 제한이 비즈니스 운영을 제한하기 전에 최적화를 활성화하는 사전 예방적 추세 분석 누락 |
패턴
| 찾을 위치 | 유사성 |
|---|---|
| 통합 패턴 동기식 실시간 | ✅ 동기 통합은 가장 높은 API 용량을 소비합니다 - 실시간 통합은 트랜잭션당 하나 이상의 API 호출을 사용합니다. 대용량 트랜잭션 플로는 상당한 API 용량을 소비할 수 있습니다. 즉각적인 데이터 일관성이 필수 비즈니스 요구 사항이지만 API 소비 비용이 가장 높은 경우 적절한 동기 패턴 ✅ 예: 주문을 제출하려면 즉시 재고 점검 및 ERP 시스템 예약이 필요하므로 API 비용이 더 높더라도 동기식 패턴이 적용됩니다. |
| 통합 패턴 배치 처리 | ✅ 배치 통합은 동기식 레코드 대량 처리 대비 API 소비량을 90% 이상 줄여 레코드당 API 호출을 대폭 줄여줍니다. 대량 API 2.0은 최소한의 API 소비 내에서 수백만 개의 레코드를 처리합니다. 비즈니스 요구를 충족하고 동기식 패턴과 비교하여 API 소비량이 90% 이상 제거되는 경우 거의 실시간 동기화가 적합합니다. ✅ 예: 고객 데이터 동기화는 실시간 업데이트 대신 시간별 배치로 실행되어 허용되는 1시간 데이터 대기 시간으로 API 소비를 95% 줄입니다. |
| 이벤트 중심의 통합 패턴 | ✅ 이벤트 중심 패턴은 실제 변경 사항에만 효율적으로 자원을 소비 - 플랫폼 이벤트 또는 변경 데이터 수집을 사용하여 폴링 오버헤드 없이 효율적인 이벤트 배포를 수행합니다. 이벤트 중심 패턴은 발생하지 않은 변경 사항을 반복적으로 확인하는 대신 실제 변경 사항이 발생하는 경우에만 자원을 소비하므로 효율적으로 확장할 수 있습니다. ✅ 예: 기회 단계 변경 사항은 다운스트림 시스템에서 사용한 플랫폼 이벤트를 게시하여 폴링을 제거하고 API 소비를 98% 줄입니다. |
| 통합 플랫폼 MuleSoft TCO | ✅ MuleSoft는 플랫폼 비용을 추가하지만 총 통합 TCO를 줄일 수 있습니다. - MuleSoft Anypoint Platform은 플랫폼 라이센스 비용을 추가합니다(연간 20,000 ✅ 상환: 통합 수가 5 |
| 타사 통합 API 가격 책정 | ✅ 예상 트랜잭션 볼륨을 기반으로 하는 타사 API 비용 모델링 - 낮은 볼륨을 가정하는 최소 계층이 아닌 실제 사용량을 반영하는 예상 트랜잭션 볼륨을 기반으로 하는 타사 비용 모델링 타사 API 가격 책정은 무료 계층에서 통화당 계량 청구부터 고정 요금 엔터프라이즈 라이센스까지 다양합니다. ✅ 예: 결제 게이트웨이의 통합 TCO 모델에는 연간 15,000달러의 플랫폼 비용 + 연간 50,000건의 트랜잭션으로 추정되는 트랜잭션당 0.10달러(5,000달러) + 연간 25,000달러의 통합 개발 + 1년 총 50,000달러, 진행 중인 10,000달러의 연간 5,000달러의 서비스 점검이 포함됩니다. |
| 지점 간 통합 유지 관리 vs Hub | ✅ 지점 간 통합은 유지 보수 작업을 기하급수적으로 곱합니다 - 각 통합 지점에는 초기 구축, 지속적인 유지 보수, 오류 처리 진화, 엔드포인트 변경 시 적응이 포함됩니다. 지점 간 통합은 시스템 수가 증가함에 따라 서비스 점검 노력을 기하급수적으로 곱합니다. 지점 간 연결이 있는 시스템 5개에는 10개의 통합 서비스 점검 스트림이 필요합니다. 10개의 시스템에는 45개의 스트림이 필요합니다. 통합 플랫폼을 통한 허브 및 스포크 패턴은 기하급수 성장을 선형 확장으로 줄입니다. ✅ 예: 연결된 시스템이 8개인 조직이 28개의 지점 간 통합에서 8개의 허브 및 스포크 연결으로 전환하여 서비스 점검 스트림을 71% 줄입니다. |
| 통합 운영 지원 비용 | ✅ 지원 및 문제 해결 비용은 통합 수와 함께 증가합니다 - 각 통합은 모니터링 인프라, 경고 구성, 실행 문서, 사고 대응 기능이 필요한 잠재적인 장애 지점을 생성합니다. 초기 개발 외 통합 TCO에 지속적인 지원 비용 포함 ✅ 예: 지속적인 모니터링, 문제 해결, 사고 대응을 위해 연간 초기 개발 비용의 15-20%로 모델링된 통합 지원 비용 |
안티 패턴
| 찾을 위치 | 불만 사항 |
|---|---|
| 모든 내역 데이터는 무기한으로 활성 저장소에 유지됩니다. | ⚡️ 비즈니스 근거 없이 예산을 소비하는 스토리지 증가 조직은 수용력 소비 데이터 또는 보관 전략이 성장률을 줄일 수 있는지 여부를 분석하지 않고 매년 추가 저장소를 구매합니다. ⚡️ 수리: 활성(0 |
| Partial Copy 템플릿에는 필터링 없이 모든 객체가 포함됩니다. | ⚡️ 테스트와 관련이 없는 내역 데이터와 함께 5GB 용량을 사용하므로 전략적 데이터 선택으로 부분 복제본 사용을 현저하게 낮은 비용으로 활성화할 경우 전체 복사본 구입을 강제 적용 ⚡️ 수리: 테스트 요구 사항을 분석하고 지난 12~18개월간의 데이터만 포함하고 테스트 시나리오에 불필요한 대용량 개체를 제외하는 선택적 부분 복사 템플릿을 만듭니다. |
| 통합은 모든 레코드를 15분마다 폴링하여 변경 사항을 확인합니다. | ⚡️ 설문의 95%가 변경 사항을 찾지 못할 경우 매일 5백만 건의 API 호출을 사용하여 불필요한 쿼리에 대한 API 용량을 낭비합니다. API 제한에 도달할 위험을 유발하고 합법적인 통합이 완료되지 않도록 방지 ⚡️ 수리: 실제 변경 사항이 발생할 경우에만 API 호출을 사용하는 변경 데이터 수집 또는 플랫폼 이벤트로 폴링 패턴을 대체하여 API 사용량을 95% 이상 절감합니다. |
| 통합은 각 레코드 유형에 대해 순서대로 별도의 API 호출을 수행합니다. | ⚡️ 배치 접근 방식에 비해 API 소비량을 5~10배로 곱합니다. 단일 복합 통화가 충분할 경우 주문당 8개의 API 호출을 사용하는 주문 처리 ⚡️ 수리: 단일 API 호출에 복합 API 배치 관련 작업을 구현하여 트랜잭션당 호출 8개에서 트랜잭션당 호출 1개로 소비를 줄입니다(87% 할인) |
| 모든 개발 팀을 위해 구매한 전체 사본 Sandbox | ⚡️ 부분 복사가 대부분의 테스트 요구 사항을 충족할 경우 곱하기 비용은 5배입니다. 전체 사본은 부분 사본보다 5~10배 더 비용이 소요되며, 새로 고침은 매월에 불과 5일마다 수행됩니다. ⚡️ 수리: 프로덕션 전 UAT 및 성능 검증에만 전체 사본을 예약합니다. 개발에 Developer Pro를 사용하고 통합 테스트를 위해 대상 데이터 템플릿과 부분 복사 |
| 볼륨 모델링 없이 “무료 API 계층”을 기반으로 한 통합 승인 | ⚡️ 예상 트랜잭션량이 2개월에 무료 계층을 초과하므로 예산 또는 TCO 분석에 포함되지 않은 놀라운 연간 비용 $15,000 ⚡️ 수리: 확장 예상을 포함하여 예상 트랜잭션 볼륨을 기반으로 타사 API 비용을 모델링합니다. 승인 전 통합 TCO에 플랫폼 수수료, 트랜잭션당 비용, 초과 비용 포함 |
| 제한 예외가 발생할 경우에만 API 사용량이 모니터링됩니다. | ⚡️ 압박을 받으면 반응형 소방 및 비상 아키텍처 변경을 만듭니다. 최적화 기회가 식별되기 전에 제한으로 중단 발생 ⚡️ 수리: 통합 수준 귀속, 최대 사용량 분석, 성장 예상으로 사전 예방적 API 모니터링 대시보드를 구현합니다. 최적화를 위한 리드 시간을 제공하는 70% 및 85%와 같은 예제 사용 임계값에 경고 설정 |
| 사용 가능한 개발자가 있으므로 맞춤형 문서 생성 | ⚡️ 초기 빌드 80,000달러의 맞춤형 개발 + AppExchange 옵션(사용자당 월 15달러(사용자 100명에 대해 연간 18,000달러)의 연간 유지보수 15,000달러는 빠른 배포, 공급업체 유지보수 및 5년 동안의 TCO 절감 ⚡️ 수리: 원본 기능에 대한 맞춤형 개발 전에 AppExchange 솔루션을 평가합니다. 서비스 점검, 플랫폼 호환성, 지원 비용을 포함하여 구축 및 구매 비교 3~5년 TCO 모델 |
| 일시 프로젝트 샌드박스가 정규 상태로 변환되는 이유 없음 | ⚡️ Sandbox 확산은 비즈니스 가치 없이 예산을 소비합니다. 조직이 적절한 수명 주기 관리를 통해 10개가 실제 개발 요구를 충족할 경우 20개 이상의 Sandbox가 누적됩니다. ⚡️ 수리: 갱신 사유가 필요한 Sandbox 만료 정책을 구현합니다. 문서화된 삭제 날짜 및 만료 검토를 위한 자동 경고가 포함된 Sandbox 추적 |
마지막 업데이트 날짜: 2026-06-08