마지막 업데이트: 2024년 4월 19일
당사는 고객 조직의 지속적인 성장에 대비하기 위해 인스턴스를 새로 고쳐 데이터 센터에서 인스턴스 지원 인프라를 업그레이드합니다. 서비스 점검 결과 고객 인스턴스가 새로운 데이터 센터로 이동되고 고객 인스턴스 이름이 변경될 예정입니다. 그 결과 고객이 Salesforce에 기대하는 성능과 동일한 수준을 조직에 지속적으로 제공할 수 있습니다.
저희의 모범 사례를 준수한다면 서비스 점검이 원활하게 이루어질 것입니다. 다음은 인스턴스 새로 고침 서비스 점검에 관한 몇 가지 자주 묻는 질문입니다.
참고: 이 문서는 정보 목적으로만 제공되며 법적 또는 기타 구속력 있는 계약의 일부가 아닙니다. 이 문서에서 설명하는 정책과 사례는 Salesforce의 단독 재량에 따라 변경될 수 있습니다.
자주 묻는 질문
1. 인스턴스 새로 고침이란 무엇이며 이에 따른 혜택은 무엇입니까?
Salesforce는 고객 조직의 지속적인 성장에 대비하기 위해 인스턴스를 새로 고침하여 데이터 센터에서 인스턴스 지원 인프라를 업그레이드합니다. 이 서비스 점검 결과 고객 인스턴스가 새로운 데이터 센터로 이동되고 고객 인스턴스 이름이 변경될 예정입니다. 그 결과 고객이 Salesforce에 기대하는 성능과 동일한 수준을 조직에 지속적으로 제공할 수 있습니다.
2. 인스턴스 새로 고침을 준비하기 위해 어떤 작업을 수행해야 합니까?
아래의 모범 사례를 검토하고 이번 서비스 점검에 대비하십시오. 모범 사례를 따르지 않는다면 최종 사용자가 서비스 점검 완료 후 Salesforce에 액세스하지 못할 수도 있습니다.
모범 사례 목록:
i. 내 도메인 활성화
ii. 비인스턴스별 참조에 하드 코딩된 참조 업데이트
iii. 모든 Salesforce IP 주소에 액세스 허용
iv. 표준 서비스 점검 기간 동안 활동 계획
예기치 않은 서비스 중단을 방지하려면 다음 절차를 수행해야 합니다.
i. 하드 코딩된 참조의 경우(예: na1.salesforce.com) 상대, 비인스턴스별 URL로 업데이트하십시오(예: login.salesforce.com).
ii. 사용자나 팀 또는 회사에서 특정 IP 범위 또는 데이터 센터에 대한 액세스를 제한하도록 회사 네트워크 설정이나 이메일 보안 필터를 설정한 경우 당사의 최신 IP 범위에 대한 액세스를 허용해야 합니다. 포함할 IP 범위에 대한 자세한 내용은 허용할 Salesforce IP 주소 기사를 참조하십시오.
iii. 서비스 점검 기간 전에 내 도메인을 구현하십시오.
iv. 서비스 점검 후 통합 문제가 발생할 경우 통합을 새로 고칠 수 있도록 준비합니다.
v. 서비스 점검 기간 후에 로그인 페이지에 "서비스 점검 진행 중" 경고가 계속 표시되면 DNS 캐시를 새로 고칠 준비를 합니다.
vi. 인증서를 로컬로 캐시하는 경우 Trailblazer Community의 인증서 변경 그룹에 가입하여 최신 인증서를 받으십시오.
3. 인스턴스 새로 고침 동안 읽기 전용 모드로 이용할 수 있습니까?
예. 서비스 점검 기간 중에 읽기 전용 모드를 이용할 수 있습니다. 읽기 전용 모드에서 허용되는 사항에 관한 자세한 내용은 읽기 전용 모드 개요 기사를 참조하십시오.
4. SFO(Salesforce for Outlook) OAuth 토큰이 인스턴스 새로 고침의 영향을 받습니까?
a. 인스턴스 새로 고침 후 사용자가 SFO에서 자동으로 로그아웃되고 설정 마법사를 통해 다시 로그인하라는 메시지가 표시됩니다.
b. 서비스 점검 이후 SFO에 다시 로그인하는 중에 문제가 발생하면 Salesforce for Outlook OAuth 재인증 기사의 단계를 따르십시오.
c. SFO에 대한 추가 질문은 Salesforce for Outlook 및 Email Connect Trailblazer Community 그룹에 게시하십시오.
5. 인스턴스 새로 고침 이후 이메일 로그를 볼 계획이라면 서비스 점검 기간 전에 이메일 로그를 요청해야 합니까?
a. 아니요. 이메일 로그는 중앙에 저장되며 인스턴스 새로 고침 후에도 사용할 수 있습니다. 따라서 서비스 점검 기간, 사이트 전환, 인스턴스 새로 고침 또는 조직 마이그레이션 전에 요청할 필요가 없습니다.
6. 인스턴스 새로 고침 서비스 점검이 Sandbox 새로 고침에 영향을 미칩니까?
a. 인스턴스 새로 고침 서비스 점검을 시작하기 전에 Sandbox 새로 고침 대기열이 4시간 동안 일시 중단됩니다.
b. 대기열이 일시 중단되었을 때 조직이 Sandbox 새로 고침을 수행하는 중이면 Sandbox 새로 고침이 중단됩니다. Sandbox 새로 고침 작업은 인스턴스 새로 고침 서비스 점검이 완료된 24시간 후에 다시 시작됩니다(중단된 작업을 재개하는 것이 아님).
7. 서비스 점검 후에 통합을 다시 시작해야 합니까?
a. 통합을 반드시 다시 시작해야 하는 것은 아니지만 인스턴스 새로 고침 서비스 점검 후 통합에 문제가 발생하면 문제 해결을 위해 가장 먼저 통합을 다시 시작하는 것이 좋습니다.
b. 서비스 점검 기간 이후 통합을 다시 시작하면 통합이 새 데이터 센터의 IP 주소를 감지할 수 있는 DNS 조회 캐시가 삭제됩니다.
c. 통합을 다시 시작하는 단계는 각각의 통합에 따라 다를 수 있습니다. 개발자와 함께 통합의 특정 단계를 확인하시기 바랍니다. AppExchange에 나열된 많은 통합은 로그인/재시작에 대한 지침도 포함되어 있습니다.
8. 현재 [인스턴스].salesforce.com 및 [인스턴스]-api.salesforce.com에서 사용하는 인증서를 이동할 새 인스턴스에서 사용할 수 있습니까?
9. 동일한 임시, 루트 및 아웃바운드 customer-to-Salesforce 인증서를 새 인스턴스에 사용해야 합니까?
그렇습니다. 임시 및 루트 인증서는 동일하게 유지됩니다. 또한 SAML, SSO 및 APEX에 사용되는 아웃바운드 인증서는 바뀌지 않습니다.
10. Email-to-Case 또는 Email-to-Apex의 라우팅 주소가 인스턴스 새로 고침에 의해 영향을 받습니까?
a. 아니요. Email-to-Case 또는 Email-to-Apex의 라우팅 주소는 인스턴스 새로 고침에 의해 영향을 받지 않습니다.
b. 기존 이메일 서비스 주소로 메일을 보내면 주소를 변경할 필요 없이 새로 고침 이후에 계속 전달됩니다.
11. 서비스 주소(Email-to-Case, Email-to-Apex, Email-to-Salesforce, reply2chatter 등)에 대한 이메일은 인스턴스 새로 고침 이후 지연됩니까?
일부 이메일이 지연될 수 있습니다. 인스턴스를 새로 고치는 동안, 앱 서버를 사용할 수 없으며 Salesforce 메일 서버에 이메일이 보류됩니다.
새 인스턴스가 활성화되고 나면 새 메일이 즉시 발송되고 대기열에 지정된 메일은 다음 시도 시 전달됩니다. 인스턴스를 사용할 수 없는 시간은 대기열에 지정된 메시지가 재시도될 때까지의 시간에 영향을 줍니다.
12. 내 새 인스턴스에 인스턴스 새로 고침 이후의 내 이전 인스턴스와 동일한 릴리스 서비스 점검 기간이 적용됩니까?
예.
13. 내 새 인스턴스에 인스턴스 새로 고침 이후의 내 이전 인스턴스와 동일한 기본 시스템 서비스 점검 기간이 적용됩니까?
예.
14. 인스턴스 새로 고침을 선택하면 조직 ID가 변경됩니까?
아니요.
15. 인스턴스 새로 고침을 거부할 수 있습니까?
아니요. 새로 고침으로 식별된 인스턴스의 모든 조직은 이동합니다.
16. 인스턴스가 새로 고쳐진 후 '기존' 데이터 센터의 데이터는 어떻게 됩니까?
인스턴스 새로 고침이 성공적으로 완료되면 기존 데이터 센터에서 인스턴스를 호스팅했던 하드웨어를 중단합니다. 조치를 취한 절차에 따라 기존 데이터 센터에 데이터가 유지되며 규제 준수 및 보안 요구사항을 충족합니다. Salesforce는 신뢰를 무엇보다 소중하게 여깁니다.
17. 인스턴스 새로 고침은 타사 CDN(Content Delivery Networks) 사용에 영향을 미칩니까?
예. 타사 CDN을 구현한 경우 다음의 조치를 취해야 합니다.
a. "customer.my.salesforce.com" 도메인을 가속화하고 있는 경우 원본을 업데이트하고 구성을 서비스 점검 전에 CDN 내의 스테이징으로 푸시해야 합니다. 프로덕션에 배포하기 전에 서비스 점검이 끝나는 즉시 예상대로 직접 액세스 및 스테이징 작업을 테스트해야 합니다.
b. VisualForce 또는 ContentForce 도메인(예: 고객--c.$NA10.content.force.com)도 가속화하고 있는 경우 customer.my.salesforce.com 및 VisualForce 및/또는 ContentForce 도메인(예: $customer--c.NA10.content.force.com 및 $customer--c.NA42.content.force.com)에 대한 원본 및 새로운 인스턴스 모두를 포함하는 새로운 SSL 인증서를 받아야 합니다.
i. 그런, 다음 타사 CDN 제공업체와 해당 인증서를 공유하고 배포해야 합니다.
ii. SSL 인증서를 배포한 후 새로운 VisualForce 및/또는 ContentForce 호스트 이름 및 세 가지 끝점에 대한 원본으로 CDN 구성을 업데이트하고 스테이징으로 푸시해야 합니다.
iii. 프로덕션에 배포하기 전에 서비스 점검이 끝나는 즉시 예상대로 직접 액세스 및 스테이징 작업을 테스트해야 합니다.
참고: 새로운 인증서를 획득하고 타사 CDN 공급업체와 함께 작업하는 과정은 수일이 소요될 수 있습니다. 따라서 분할 또는 마이그레이션을 시작하기 최소 2주 전에는 프로세스를 시작하십시오.
참고: Akamai를 사용하는 MyDomain.my.salesforce.com, MyDomain.lightning.force.com, MyDomain--c.documentforce.com, MyDomain--PackageName.visualforce.com, MyDomain--c.InstanceName.content.force.com, or MyDomain--PackageName.InstanceName.visual.force.com 호스트 이름에 대한 특별 가속을 보유한 경우 서비스 점검 전에 원본을 업데이트하고 CDN 내에서 구성을 스테이징으로 푸시해야 합니다. 프로덕션에 배포하기 전에 서비스 점검이 끝나는 즉시 예상대로 직접 액세스 및 스테이징 작업을 테스트해야 합니다. 이는 희귀한 구성입니다. 정확한 의미를 이해할 수 없는 경우 내 조직에 적용되지 않습니다.
이 특별 가속 유형은 Salesforce Edge 네트워크로 대체됩니다. Salesforce는 일반적으로 이 유형의 기존 특별 구성에 호스트 이름을 추가하는 것을 지원하지 않으며 향후에는 Salesforce 지원과 협력하여 Salesforce Edge 네트워크를 마이그레이션하고 Salesforce R&D가 특별 가속에 사용되는 DNS 구성 재정의를 제거하도록 할 것입니다.
18. 인스턴스 새로 고침은 타사 통합에 영향을 미칩니까?
타사 통합은 인스턴스 새로 고침 이후 예상대로 기능해야 합니다. 그러나 내 도메인을 활성화하면 인스턴스 새로 고침 이후 하드 코딩된 참조의 리디렉션 관련 시간이 줄어들 수 있으며 따라서 적극 권장됩니다.
19. Salesforce 서비스 점검에 관련된 다음 주제에 대한 자세한 내용을 어디에서 확인할 수 있습니까?
a. 하드 코딩된 참조 업데이트 FAQ 기사
i. 조직에서 하드 코딩된 참조를 찾기 위한 도구
ii. 하드 코딩된 참조
iii. 이메일 스레드 ID
iv. WSDL
v. 인증서
vi. Live Agent
b. Salesforce 서비스 점검 중 내 조직은 어떤 영향을 받습니까? 기사
i. 주별 내보내기
ii. 실제 삭제
iii. 파트너 포털
c. Salesforce IP 범위 기사
i. IP 범위
ii. 이메일 설정
20. Live Agent 또는 SOS 구현이 있는 경우 어떻게 합니까?
웹 페이지 또는 인증서에 Live Agent 끝점 URL에 대한 하드 코딩된 참조가 있는 경우 인스턴스 새로 고침, 조직 마이그레이션 또는 사이트 전환이 Live Agent/SOS 기능에 영향을 줄 수 있습니다. 영향을 최소화하려면 모범 사례를 따르고 끝점에 하드 코딩된 참조를 사용하지 마십시오. 또한 설정의 배포 페이지에서 복사한 배포 코드의 끝점 URL을 업데이트하십시오. 제공해드린 배포 코드에는 새로 할당된 서버로 리디렉션할 수 있는 기능이 있지만 새로 고침이 완료되는 즉시 끝점을 업데이트해야 합니다. Live Agent 끝점과 하드 코딩된 끝점이 의미하는 내용에 대한 자세한 정보는 Live Agent 서버(끝점 URL)가 변경되었고 이제 Live Agent 채팅은 더 이상 작동하지 않습니다 기사를 검토하십시오.
21. Salesforce는 고객에게 인스턴스 새로 고침 서비스 점검을 어떻게 전달합니까?
a. Salesforce는 고객이 예정된 서비스 점검 기간을 사전에 알고 대비하기 위해 조치가 필요한 서비스 점검 활동을 모든 고객에게 알립니다. 인스턴스 새로 고침 서비스 점검 전에 Salesforce는 이메일을 통해 제품 및 서비스 알림을 관리자(‘모든 데이터 수정’ 및 ‘모든 사용자 관리’ 권한이 있는 사용자)에게 전송합니다. 자세한 내용은 제품 및 서비스 알림 기사를 참조하십시오.
b. 이메일 알림 외에도 Salesforce는 고객에게 영향을 미치는 서비스 점검을 요약하여 서비스 전달(Hyperforce) 데크에 있는 Trailblazer Community에 게시합니다.
c. 모든 서비스 점검 기간은 trust.salesforce.com에 게시됩니다.
22. 멀티 테넌트 아키텍처에 대해 더 자세히 알아보려면 어떻게 해야 합니까?
a. Salesforce 아키텍처 이해 내역을 완료합니다.
b. 추가 정보는 Salesforce 개발자가 작성한 멀티 테넌트 아키텍처 블로그 게시물을 참조하십시오.
23. 인스턴스 새로 고침은 이전에 예정된 활동(주별 내보내기, Apex 작업 등) 및 Apex 콜 아웃에 어떠한 영향을 미칩니까?
진행 중인 활동은 인스턴스 새로 고침 전에 일시 중지되고 인스턴스 새로 고침 후에 다시 시작됩니다. 인스턴스 새로 고침 중에 예정된 활동은 서비스 점검이 완료된 후에 시작됩니다.
인스턴스 새로 고침 이전에 시작된 Apex, 배치 Apex, REST API, SOAP API 및 대량 API 작업의 일부 하위 집합에서는 서비스 점검 기간 후에 오류를 반환할 수 있습니다. 서비스 점검 기간 후에 이전에 예정된 작업의 오류를 수신하는 경우 작업을 다시 시작하면 예상했던 결과가 반환됩니다. 가장 원활한 환경을 위해 인스턴스 새로 고침을 완료한 후 대규모 또는 장기 실행 작업 일정을 조정하는 것이 좋습니다.
서비스 점검 중에 외부 서비스에 대한 Apex 콜 아웃이 계속 실행되고, 이로 인해 Salesforce 응용 프로그램에 대한 후속 DML 콜이 실행되는 경우가 자주 발생하므로 응용 프로그램이 읽기 전용 모드일 때 의도한 프로그램 플로와 관련하여 문제가 발생할 수 있습니다. 읽기 전용 모드에서는 이러한 콜 아웃이 실행되지 않도록 하는 것이 좋습니다. 이러한 콜 아웃 방지 방법에 대한 자세한 정보는 읽기 전용 모드에서 Apex 콜 아웃을 참조하십시오.
24. Trust 알림이 새 인스턴스로 전달됩니까?
a. 인스턴스 새로 고침의 경우: 인스턴스를 새로 고치기 전에 Salesforce에서 소스 인스턴스의 기존 구독자가 대상 인스턴스에 자동으로 구독됩니다. 인스턴스가 두 인스턴스로 분할되는 경우 구독자는 두 대상 인스턴스 모두에 구독되며 빠른 시일 내에 구독 기본 설정을 업데이트해야 합니다.
b. 조직 마이그레이션의 경우: 조직 마이그레이션 후 구독 설정이 자동으로 업데이트되지 않습니다. 새 인스턴스가 가장 관련성이 높은 상태 업데이트를 계속 수신하도록 알려주는 즉시 구독 설정을 업데이트하는 것이 좋습니다.
25. Heroku도 사용하는 경우에는 무엇을 고려해야 합니까?
다음 Heroku 기사를 검토하십시오. https://help.heroku.com/0HFMVV4B/what-do-i-need-to-do-about-my-upcoming-salesforce-instance-refresh
26. 대용량 플랫폼 이벤트 및 변경 데이터 수집에 대해 고려해야 할 점은 무엇입니까?
a. 특정 Salesforce 서비스 점검 활동(예: 조직 마이그레이션 및 인스턴스 새로 고침)을 수행하기 위해서는 조직이 다른 데이터 센터 또는 다른 하드웨어 스택으로 재배치해야 합니다. 해당 작업을 진행하는 동안 물리적으로 데이터를 옮기고 다른 하드웨어에서 응용 프로그램을 작동하는 소프트웨어를 실행합니다. 이벤트 버스가 분산되어 있으며 비동기식이므로, 인스턴스 새로 고침 전에 게시된 모든 이벤트를 마이그레이션할 수 없습니다.
b. 인스턴스 새로 고침은 서비스 점검 전후 실시간 배달에 영향을 미치지 않습니다. 그러나 72시간 전체 이벤트 보존 기간은 유지되지 않습니다. ReplayID는 이벤트 스트림에서 특정 이벤트가 게시된 지점을 고유한 방식으로 식별하며, 조직의 새 위치는 물리적으로 다르므로 새로 게시된 이벤트의 ReplayID 값은 마이그레이션 또는 인스턴스 새로 고침 전에 게시된 이벤트와 아무런 관련도 없습니다. 플랫폼 이벤트 및 변경 이벤트 구독자에는 스트리밍 API(CometD) 클라이언트, empApi Lightning 구성 요소, Pub/Sub API 클라이언트, 이벤트 릴레이, Apex 트리거, Flow 등이 포함됩니다.
참고 항목: 플랫폼 이벤트 개발자 가이드: 읽기 전용 모드로 이벤트 게시
27. 내 조직에서 Einstein Bots를 활성화한 경우 어떤 조치를 취해야 합니까?
인스턴스 새로 고침 후 설정의 Einstein Bots로 이동한 다음, Einstein Bots 기능을 비활성화한 후 다시 활성화하십시오. 그러면 Einstein.AI에 대한 신규 조직 인증이 트리거됩니다.
28. 이벤트 로그 데이터가 보존되며 인스턴스 새로 고침 후 사용할 수 있습니까?
아니요. 대부분의 데이터는 마이그레이션됩니다. 조직 마이그레이션 전에 처리되지 않은 모든 로그 데이터는 새 인스턴스에서 이용할 수 없습니다. 이벤트 모니터링은 모니터링 이벤트를 채우기 위해 로그 데이터 및 밤에 시작되는 배치 프로세스에 의존하므로, 마이그레이션이 시작되면 마이그레이션 시작일부터 종료일까지의 데이터가 새로운 위치의 조직에 추가되지 않습니다.
29. 추가 질문이 있는 경우 어떻게 합니까?
a. 또한 Trailblazer Community의 공식: Salesforce 인프라 그룹에 질문을 게시하여 다른 Salesforce 사용자와 공동 작업할 수 있습니다.
b. 추가 질문은 Salesforce 도움말을 통해 지원 부서에 문의할 수 있습니다.
30. 알려진 문제
000387056

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.