공개 클라우드로 마이그레이션 FAQ dc-faq
Adobe은 기존 데이터 센터를 사용 중단합니다. Campaign Classic 인스턴스를 Public Cloud Amazon Web Services(AWS)로 전송해야 합니다. 이 이니셔티브에 대해 자세히 알아보세요.
다음은 이 프로젝트, Campaign 환경에 미치는 영향 및 기타 유용한 리소스에 대한 일반적인 질문 세트입니다.
기타 문의 사항은 고객 지원 Adobe에 문의하십시오.
인프라의 영향
다음은 데이터베이스 및 인프라에 미치는 전역 영향입니다.
-
데이터베이스가 변경됩니까? 새 데이터베이스의 버전은 무엇입니까? 어떤 운영 체제를 사용합니까?
Adobe은 최적의 조건에서 Adobe Campaign 서비스를 제공하기 위해 가장 적합한 데이터베이스 관리 엔진을 선택하고 배포할 수 있는 권한을 보유합니다.
또한 최상의 보안 수준을 유지하기 위해 Adobe은 인프라와 관련된 세부 정보를 제공하지 않습니다.
-
데이터가 손실될 위험이 있습니까?
데이터베이스는 레거시 데이터 센터에서 덤프되고 Public Cloud(AWS)에서 복원됩니다. 새 데이터 센터에서 다시 시작하면 마이그레이션 전의 정확한 상태에서 애플리케이션이 다시 시작됩니다. 일부 예약된 작업이 지연되는 것 외에는 사용자에게 차이가 없습니다.
-
기존 데이터 센터와 공용 클라우드 간에 패키지 크기에 차이가 있습니까?
현재 데이터베이스 크기, 디스크 크기 등을 기반으로 새 패키지 정의를 사용하여 공용 클라우드(AWS)에서 프로비저닝하고 있습니다. 예를 들어 고객이 기존 데이터 센터에 애플리케이션 서버가 한 개 있는 경우 패키지 정의를 기반으로 Public Cloud(AWS)에 애플리케이션 서버가 두 개 있을 수 있습니다.
-
빌드 번호 또는 Campaign 버전이 변경됩니까?
첫 번째 단계로, 마이그레이션과 동일한 Campaign Classic 빌드를 유지할 것입니다.
추가 단계에서는 최신 Campaign Classic GA 빌드로 업그레이드합니다. 자세한 정보는 이 페이지를 참조하십시오.
-
마이그레이션 후 문제를 해결하기 위한 계획은 무엇입니까?
운영 시스템을 마이그레이션하기 전에 광범위한 테스트를 수행합니다. 그러나 문제가 발생하면 고객 지원 Adobe이(가) 주 연락 창구로 남게 됩니다. Adobe은 필요한 경우 고급 지원을 제공하기 위해 전문가 팀을 구성했습니다.
전달성에 미치는 영향
IP, 차단 목록, 하위 도메인 및 URL에 대한 전역 영향은 아래에 나와 있습니다.
-
허용 목록에 추가하다의 IP는 어떻게 처리됩니까? Campaign에서 들어오는 트래픽에 대해 고객이 새 IP 주소를 허용 목록에 추가하다에 추가해야 합니까?
Adobe 서버의 IP 주소가 변경됩니다. 따라서 고객은 시스템에 새 IP 주소를 허용 목록에 추가하다에 추가해야 할 수 있습니다.
-
SFTP/FTP 액세스를 위해 허용 목록에 추가하다에 추가된 포트를 어떻게 처리합니까?
SFTP 구성(허용 목록에 추가하다 데이터의 공개 키 + IP)이 레거시 데이터 센터에서 공개 클라우드(AWS)로 이동됩니다. 고객으로부터 예상되는 작업이 없습니다.
-
IP를 변경하시겠습니까?
Adobe 서버의 IP 주소가 변경됩니다. 따라서 고객은 새로운 IP 주소를 시스템에 있는 허용 목록에 추가하다에 추가해야 할 수 있습니다.
-
하위 도메인 위임은 어떻게 처리됩니까?
기존 하위 도메인이 기존 데이터 센터에서 공용 클라우드(AWS)로 이동됩니다. 이 부분은 Adobe 전달성 팀이 마이그레이션 프로세스의 일부로 처리합니다.
note note NOTE 전달성 팀의 참여는 계약을 기반으로 하며, 고객은 전달성 참여와 관련된 정보를 Adobe 담당자에게 문의해야 합니다. Adobe은 마이그레이션 후 새 Public Cloud(AWS) 서버에서 구성이 실행되고 있는지 확인하는 데 필요한 테스트를 안내합니다.
-
마이그레이션이 추적, 리소스 및 웹 응용 프로그램에 대한 새 URL을 생성합니까?
아니요. 기존 URL은 그대로 유지됩니다.
-
하위 도메인이 Neolane.net에서 campaign.adobe.com으로 변경됩니까?
마이그레이션 후
neolane.net
과(와)campaign.adobe.com
이(가) 모두 준비됩니다. 간단하게 하기 위해: neolane.net 을 Public Cloud(AWS)의 새 인스턴스로 리디렉션하므로 고객이 변경할 필요가 없습니다. -
IP 준비 방법은 무엇입니까?
우선 Adobe 전달성 은 플랫폼의 전달성 상태를 평가하고 새 IP로 전환하는 계획을 권장합니다
마이그레이션 후에는 준비 작업이 필요하지 않습니다. 예외가 있을 수 있으며, 이 경우 고객 지원 Adobe이 고객에게 연결됩니다.
다만 이 같은 영업은 Go-Live 때 이뤄지는 초기 램프 업과 달리 사업상 투명하다는 방침이다.
마이그레이션이 완료되면 Campaign 인스턴스의 전송 IP는 완전히 달라집니다. 원활한 전환을 보장하기 위해 Adobe은 이전 IP에서 새 IP로 점진적으로 트래픽을 전환하여 새 전송 IP의 램프 업을 구현합니다.
-
허용 목록에 추가하다 URL을 통해 이동하시겠습니까?
예. 이 파일은 소스에서 새 인스턴스로 복사되는 서버 구성 파일에 저장됩니다.
-
커뮤니케이션을 브랜딩하는 데 사용하는 위임된 하위 도메인에 어떤 영향을 미칩니까?
마케팅 통신에 사용되는 하위 도메인은 동일합니다. 단, 구현에 따라 클라이언트 측에서 조치가 필요합니다.
- Adobe으로 하위 도메인을 위임하는 경우(기본값) Adobe에서 모든 변경 사항을 처리하여 원활한 전환을 보장합니다.
- CNAME 설정(예외)의 경우 클라이언트는 Adobe과 함께 변경 사항을 구현하도록 요청받습니다.
구성 및 연결에 미치는 영향
허용 목록에 추가하다의 IP에 대한 참고 사항 config
Public Cloud로 마이그레이션하면 Adobe Campaign 애플리케이션 서버용 새 IP가 제공되므로 IP를 변경하면 Adobe 서버와 정보 시스템 간의 연결에 영향을 줄 수 있습니다.
다음 두 가지 경우를 살펴보겠습니다.
-
인바운드 트래픽: 시스템 또는 Adobe Campaign 서버에 대한 다른 타사에서 시작된 모든 네트워크 활동입니다. 구성은 Adobe에 의해 처리된 다음 마이그레이션 도중 레거시에서 퍼블릭 클라우드로 복사됩니다. 그런 다음 마이그레이션 후에도 인바운드 트래픽에 대한 연결이 그대로 유지되며 고객 측에서 작업을 수행할 필요가 없습니다
-
아웃바운드 트래픽: Adobe Campaign 서버에서 정보 시스템 또는 다른 타사(예: SMS 공급자)에 대해 시작하는 모든 네트워크 활동. 조직 내 보안 정책에 따라 IP를 변경하는 경우 정보 시스템 또는 기타 제3자의 허용 목록 작업이 필요할 수 있습니다
전역 영향
아래에 구성, 다른 시스템 및 제품과의 연결, API 및 시간대에 미치는 전역 영향을 나열했습니다.
-
마이그레이션이 외부 계정에 대한 연결에 영향을 줍니까?
예. 예를 들어, 타사 통합, SMS 공급자는 새 Adobe Campaign 애플리케이션 서버 IP 주소를 허용 목록에 추가하다에 추가해야 합니다.
-
마이그레이션이 Genesis 커넥터를 사용하는 Adobe Analytics 연결에 영향을 줍니까? Adobe Analytics 측의 허용 목록에 추가하다에 Campaign IP 주소를 추가하는 것은 어떻습니까?
Adobe Campaign 애플리케이션 서버의 IP 주소가 변경됩니다. 이 단계는 마이그레이션 후 Adobe 고객 지원 센터에서 처리됩니다.
-
마이그레이션이 다른 Adobe 솔루션(AEM, Target 등)과의 연결에 영향을 줍니까?
통합은 허용 목록에 추가하다와 웹 서비스 계정 구성에 선언된 IP 주소의 조합입니다. 이는 Adobe 고객 지원 센터에서 담당하며 소유하게 됩니다.
애플리케이션 서버의 IP가 변경될 때 외부 솔루션에 필요한 IP 주소가 허용 목록에 추가하다에 있습니다. 이 정보가 제공됩니다. 통합의 다른 부분은 IMS 기반이며 그대로 작동해야 합니다.
-
IMS 통합을 위해 조직 ID에 첨부되지 않은 고객은 어떻게 됩니까?
IMS가 없는 고객에게는 조직 ID가 인스턴스에 연결됩니다.
-
다중 브랜딩 구성이 마이그레이션의 영향을 받습니까?
하위 도메인 및 모든 관련 구성이 기존 데이터 센터에서 공용 클라우드(AWS)로 올바르게 이동/리디렉션되는 즉시 영향을 주지 않습니다.
-
API 연결이 마이그레이션의 영향을 받습니까?
Adobe 서버의 IP 주소가 변경됩니다. 따라서 고객은 새로운 IP 주소를 시스템에 있는 허용 목록에 추가하다에 추가해야 할 수 있습니다.
허용 목록에 추가하다의 IP에 대해 자세히 알아보세요.
-
마이그레이션 후 모든 JavaScript 메모리 구성 매개 변수가 올바르게 설정되었는지 확인하시겠습니까?
이전 데이터 센터에서 공용 클라우드(AWS)로 인스턴스 구성을 복사하므로 마이그레이션 후 이러한 값이 유지됩니다.
-
특정 파일 확장명에 액세스할 수 있는 위험이 있습니까?
고객은 글꼴 파일, Outlook 모임 파일을 공용 리소스 폴더에 로드할 수 있도록 허용할 수 있습니다. 이 구성은 현재
config-<instance>.xml
파일에서 수행됩니다. 이 파일은 구성 파일과 함께 복사됩니다. -
새 서버에서 시간대가 변경되고 있습니까? 고객이 현재 시간대를 유지할 수 있습니까?
새 서버 위치에 따라 변경될 수 있습니다. 그러나 고객은 현재 시간대를 유지할 수 있습니다.
Adobe Campaign Classic v7의 시간대 관리에 대해 자세히 알아보기.
보안 및 권한
Public Cloud(AWS)로 마이그레이션하면 고객 환경이 필요한 모든 보안 요구 사항을 최신 상태로 유지하게 됩니다. 여기에는 다음이 포함됩니다.
- 정기적으로 최신 OS 및 보안 패치 적용
- 고객별 인프라 격리
- 로드 밸런서, 네트워크 보안 규칙, 스토리지 암호화 등의 클라우드 인프라 지원을 위한 보안 및 감사 검토 관리
권한, 인증서 및 SFTP 액세스에 미치는 영향은 아래에 나와 있습니다.
-
모든 인증서를 새 서버로 이동하시겠습니까?
예. 모든 인증서는 이 마이그레이션의 일부로 이동됩니다.
-
고객에게 새 STP 액세스 키를 요청해야 합니까?
아니요. Adobe은 새 서버에서와 마찬가지로 SFTP 액세스 키를 복사합니다.
-
SFTP 권한은 어떻게 처리됩니까?
새 SFTP 서버, 사용자, 디렉터리 및 파일의 권한 수준이 정확히 동일한지 확인하고 있습니다.
-
SFTP 연결을 설정할 수 없는 경우 고객이 계속 작동하도록 하는 해결 방법/계획은 무엇입니까?
유일한 연결 문제는 고객 측의 허용 목록에 추가하다와 관련이 있을 수 있습니다. 고객은 프로덕션으로 이동하기 전에 비프로덕션 환경에서 이 테스트가 작동하는지 확인해야 합니다.
-
이동해야 하는 데이터 센터별 허용 목록 구성이 있습니까?
아니요, 관리할 데이터 센터 특정 허용 목록에 추가하다 구성이 없습니다.
-
사용자 지정 스크립트가 새 환경에서 성공적으로 실행되는지 확인하고 있습니까?
고객 구현은 워크플로에서 사용자 지정 스크립트(Perl/Shell/Python/Java Script)를 사용하여 파일 및 폴더 등을 조작할 수 있습니다.
호스팅된 인스턴스에서 스크립트는 JavaScript 엔진을 통해서만 실행됩니다. 이러한 특정 구현으로 인해 보안 공백과 업그레이드 후 문제가 발생할 수 있습니다. 지원되지 않습니다.
-
IMS 통합을 사용하면 새 인스턴스에서 그대로 작동합니까, 아니면 추가 구성 업데이트가 필요합니까?
동일한 DNS 이름을 유지하고 있으므로 마이그레이션 후에도 그대로 작동합니다.
마이그레이션 실행
마이그레이션 중 발생하는 전역 영향은 아래에 나와 있습니다.
-
마이그레이션하는 동안 마케팅 활동을 중지하도록 계획해야 합니까?
Adobe은 기존 데이터 센터에서 애플리케이션이 종료되기 바로 전에 게재 및 워크플로우의 모든 실행을 늦추고 이상적으로 일시 중지할 것을 권장합니다. 따라서 프로세스에 "정상적으로" 일시 중지하고 진행 중인 실행 상태를 저장할 시간이 제공되므로 Cloud Server(AWS)를 쉽게 다시 시작할 수 있습니다.
-
Adobe Campaign 서비스의 다운타임이 예상됩니까?
마이그레이션은 부득이한 플랫폼 다운타임과 함께 이루어집니다. 이 계획의 목적은 이러한 가동 중지 시간을 최소화하는 데 있습니다.
데이터 센터 간의 데이터 전송은 다운타임의 중요한 경로에 있습니다. 데이터는 다음 두 가지 방법으로 저장됩니다.
- 가장 중요한 것은 데이터베이스입니다
- 애플리케이션 서버의 파일(데이터 가져오기 및 내보내기)
데이터 전송 속도를 높이려면 데이터베이스 크기를 줄이는 것이 가장 중요합니다. 제안 사항:
- 내역 데이터(게재 로그, 추적 로그 등)의 보존 기간 단축
- 다른 테이블(게재, 수신자, 사용자 지정 테이블)에서 쓸모없는 레코드 삭제
-
인스턴스 마이그레이션의 예상 가동 중지 시간은 얼마입니까?
다운타임은 고객의 데이터베이스 크기와 SFTP 파일 스토리지 크기에 따라 완전히 달라집니다. 예상 기간을 제공받으려면 고객 지원 센터에 문의하십시오.
-
기존 서버에서 보낸 메시지에 대한 정보. 링크에 항상 액세스할 수 있습니까?
마이그레이션이 실행되는 동안 이메일 링크 리디렉션이라는 하나의 서비스만 작동합니다. 모든 수신자는 이메일을 클릭하면 랜딩 페이지에 연결할 수 있습니다. 그러나 이러한 클릭은 추적되지 않으므로 마이그레이션 직전에 시작된 게재에 대한 클릭률은 평소보다 낮습니다.
-
중간 소싱/RT 환경은 어떻습니까?
MID 소싱 및 RT는 다른 호스팅된 인프라로 처리됩니다.
-
마이그레이션은 어떤 순서로 수행됩니까?
환경은 다음 순서로 마이그레이션됩니다.
- 개발 환경
- 스테이징 환경
- 프로덕션 환경
- RT 환경
- 중간 소싱 환경
-
롤백 계획은 무엇입니까?
롤백 계획은 DNS를 다시 전환하고 소스 데이터베이스를 읽기 전용에서 읽기-쓰기로 다시 설정하는 것입니다. 결국 우리는 그것을 위한 자동화를 갖게 될 것입니다.
-
마이그레이션 후에도 이전 인스턴스에 액세스할 수 있습니까?
애플리케이션 마이그레이션이 완료되면 기존 데이터 센터에서 프로세스를 다시 실행할 계획이 없습니다. 예약된 백업 프로세스가 Public Cloud(AWS)에서 실행될 때까지 임시 백업 목적을 제외하고 레거시 데이터 센터의 모든 데이터를 지울 수 있습니다.
-
Public Cloud로 마이그레이션한 후 각 인스턴스를 테스트하는 데 시간이 얼마나 걸립니까?
고객의 복잡성에 따라 스테이징 환경과 프로덕션 환경 마이그레이션 사이에 최소 1주의 제작 시간이 필요합니다.
-
새 IP를 허용 목록에 추가하다에 추가하는 작업을 누가 처리합니까?
Adobe 고객 지원 팀은 새 IP를 허용 목록에 추가하다에 추가하여 고객과 모든 타사가 새 시스템에 액세스할 수 있도록 처리합니다.