Campaign Classic: 하드웨어 크기 조정 권장 사항

설명 description

환경
Adobe Campaign Classic v7

문제/증상
이 문서에서는 온프레미스 데이터 센터 또는 가상화된 클라우드 환경에서의 Adobe Campaign Classic v7 배포에 대한 일반적인 권장 사항을 제공합니다. 이러한 유형의 배포( )는 잡종 또는 중간 소싱 를 사용하면 Campaign 마케팅 인스턴스와 마케팅 데이터베이스가 운영상의 통제 하에 놓이고, Adobe Cloud Messaging 서비스를 사용하여 이메일, SMS 또는 SMPP 메시지를 전송하고 이메일 열기, 바운스 및 클릭 추적 데이터를 수집합니다.

주의 -  이 문서는 일반적인 예제 안내서로만 제공됩니다. Campaign 프로젝트를 시작하기 전에 Adobe Campaign Adobe 계정 팀과 함께 정확한 배포 크기를 측정해야 합니다. 이 작업이 완료될 때까지 인프라 또는 하드웨어를 확보하거나 배포하지 마십시오.

마케팅 인스턴스는 모든 마케팅 활동을 유도하고 모든 수신자 데이터와 캠페인에서 반환된 분석 데이터를 저장하는 Adobe Campaign 아키텍처의 일부입니다. 마케팅 인스턴스는 Adobe Campaign 서비스를 실행하는 일련의 온-프레미스 서버와 관계형 데이터베이스입니다.

주의 -  완전히 호스팅된 Adobe Campaign 인스턴스(Adobe Cloud Service에 배포된 인스턴스)를 사용하는 경우에는 이 문서의 정보가 적용되지 않습니다.

소프트웨어 호환성에 대한 자세한 내용은 호환성 매트릭스.
시나리오
배포 다이어그램 및 하드웨어 크기 조정 권장 사항은 다음과 같은 세 가지 대표적인 시나리오에 대해 제공됩니다.

  1. 보통 크기 - 시스템에서 5백만 활성 수신자
  2. 큰 크기 - 시스템의 2천만 활성 수신자
  3. 엔터프라이즈 - 5,000만 활성 수신자, 트랜잭션 메시지

가정
이 문서에서는 세 가지 시나리오 모두에 대해 다음 사용 유형을 가정합니다.

  • 대형 이메일 캠페인은 일주일에 두 번, 활성 수신자의 약 50%에게 전송됩니다.
  • 직접 메일은 시스템의 각 수신자에 대해 매월 한 번씩 생성됩니다.
  • SMS 메시지는 매월 활성 수신자의 약 10%에게 전송됩니다.
  • 각 수신자를 정의하는 데이터베이스 스키마는 한 개의 추가 테이블로 확장되었으며, 각 수신자에 대해 약 200바이트의 데이터가 포함되어 있습니다.
  • Adobe Campaign 상호 작용 모듈은 발신 이메일에 오퍼를 추가하는 데 사용됩니다.
  • 이메일 추적 데이터는 90일 동안 Campaign 시스템에 유지됩니다.

해결 방법 resolution

일반 지침
Campaign은 데이터베이스 중심 애플리케이션으로 데이터베이스 서버 성능이 매우 중요합니다. 워크플로우, 세그먼테이션, 데이터 업로드 추적, 인바운드 상호 작용, 분석 및 기타 활동을 실행하면 모두 데이터베이스 활동이 생성됩니다. 일반적으로 이러한 작업의 크기와 빈도는 데이터베이스 서버의 크기를 결정합니다.

마케팅 인스턴스의 애플리케이션 서버에는 워크플로우를 실행하고 Campaign 콘솔 사용자의 요청을 포함한 SOAP API 호출에 응답할 충분한 CPU와 메모리가 필요합니다. CPU 요구 사항은 복잡한 오퍼 규칙을 사용하는 아웃바운드 상호 작용을 사용하는 워크플로우, 사용자 지정 Javascript를 실행하는 워크플로우 및 높은 트래픽 수준의 웹 애플리케이션에 중요할 수 있습니다.

Campaign 웹 애플리케이션은 마케팅 인스턴스 앱 서버나 별도의 웹 서버 시스템에 배포할 수도 있습니다. 웹 애플리케이션 워크로드가 중요한 워크플로우 및 Campaign Console 사용자와 충돌하므로, 핵심 Campaign 기능이 양호한 성능으로 안정적으로 실행될 수 있도록, 웹 애플리케이션 및 인바운드 상호 작용을 별도의 서버에 배포할 수 있습니다.

보안과 가용성을 위해 Adobe은 비즈니스 사용자가 생성한 트래픽에서 인터넷 트래픽을 분리하는 것을 권장합니다. 이러한 이유로 다이어그램에는 웹 서버(Web1 및 Web2를 마주보는 인터넷)와 앱 서버(App1 및 App2를 처리하는 비즈니스 프로세스)의 두 가지 서버 그룹이 포함되어 있습니다.

상업용 이메일 보낸 사람이 기능적 옵트아웃 웹 페이지를 갖는 것은 법적 요구 사항입니다. Adobe은 장애 복구 시나리오에 대해 각 그룹 서버에 중복 시스템을 사용하는 것을 권장합니다. Adobe Campaign이 옵트아웃 페이지를 호스팅하는 경우 특히 그렇습니다.


역방향 프록시
Campaign 아키텍처는 HTTP(HTTPS)를 통해 SSL을 사용하여 마케팅 인스턴스와 Adobe 클라우드 메시징 간에 통신하여 높은 보안을 적용합니다. DMZ(demilitarized zone) 서브넷에서 역방향 프록시를 사용하여 마케팅 인스턴스 서버와 데이터베이스를 격리하고 보호함으로써 보안, 안정성 및 가용성을 보장합니다.


로드 밸런서
앱 서버의 로드 밸런서는 프록시에서 HTTPS가 종료된 활성/수동 구성으로 설정되었습니다. 웹 서버의 로드 밸런서는 프록시에서 HTTPS가 종료된 활성/활성 구성으로 설정됩니다.

Adobe은 배포 환경에서 Adobe Campaign 서버로 릴레이할 수 있는 전용 URL 경로 목록을 제공합니다.


아키텍처
일반적인 아키텍처는 볼륨에 관계없이 거의 동일합니다. 보안 및 고가용성 요구 사항에는 최소 4대의 서버가 필요합니다. 즉, WebApps를 사용하지 않는 경우 2대의 서버가 필요합니다. 구성의 차이는 주로 CPU 코어 및 메모리와 같은 하드웨어 구성에서 차이가 난다.

시나리오 1: 보통 크기 배포

예상 볼륨

채널
볼륨
활성 수신자
5백만
이메일
월 420만
다이렉트 메일
100만/월
모바일 SMS
100,000/월
일일 최대 이메일 볼륨
500

이러한 볼륨의 경우 한 쌍의 Adobe Campaign 애플리케이션 서버 시스템이 Adobe Campaign 클라이언트 사용자 및 워크플로우 실행을 위한 모든 기능을 제공합니다. 500만 명의 활성 수신자와 이 이메일 볼륨의 경우 애플리케이션 서버 워크로드는 CPU 또는 I/O 집약적이지 않습니다. 대부분의 스트레스는 데이터베이스에 있습니다.

Adobe Campaign 웹 서버는 보안 영역에 표시됩니다.


웹 및 애플리케이션 서버
이 시나리오에서는 다음 사양을 사용하여 4개의 시스템에 Adobe Campaign을 설치하는 것이 좋습니다.

3Ghz+ 쿼드 코어 CPU, 8GB RAM, RAID 1 또는 10, 80GB SSD 2개

이러한 시스템은 Campaign 콘솔 사용자를 직접 지원하고 캠페인 워크플로우를 실행하는 마케팅 인스턴스 애플리케이션 서버를 만듭니다.

DMZ의 역방향 프록시는 Adobe Campaign 웹 서버에 대한 트래픽 밸런스를 조정합니다. 프록시 시스템에 Adobe Campaign 소프트웨어 스택을 설치할 필요가 없으며 역방향 프록시 소프트웨어나 네트워크 장비를 사용할 수 있습니다.

구독 옵트인/옵트아웃 및 환경 설정 센터 기능은 Campaign 또는 자체 웹 사이트에서 제공할 수 있습니다. 웹 사이트에서 이 기능을 구현하도록 선택하는 경우 환경 설정 및 구독 정보가 Campaign 마케팅 데이터베이스에 전파되도록 해야 합니다. 이 작업은 일반적으로 Campaign 워크플로우에서 자동으로 업로드하는 추출 파일을 만드는 방식으로 수행됩니다.

애플리케이션 서버의 디스크 공간 소비는 서드파티 서비스 공급자(예: DM용 인쇄 공급업체)와 교환한 파일의 보존 기간, 웹 사이트의 구독 또는 환경 설정 업데이트나 자체 CRM 또는 마케팅 시스템에서 추출한 파일 등 가져온 플랫 파일의 크기 및 보존 기간에 따라 다릅니다.


데이터베이스
데이터베이스 서버에 대한 하드웨어 권장 사항은 다음과 같습니다.

3Ghz+ 4코어 CPU, 16GB RAM, RAID 1 또는 10, 128GB SSD 최소

메모리 예상은 대규모 캠페인 시작에 대해 약 50만 명의 수신자의 전체 캐싱과 워크플로우 실행, 추적 데이터 가져오기 및 기타 동시 작업을 위한 RDBMS 버퍼 공간을 가정합니다.

모든 Adobe Campaign 기술 데이터(캠페인, 추적, 작업 테이블 등)를 저장하는 데 데이터베이스에 필요한 디스크 공간은 3개월의 보존 기간을 기준으로 약 35GB인 것으로 추정됩니다. 추적 데이터를 6개월 동안 보존하도록 선택하면 데이터베이스 크기가 약 40GB로 증가하고 12개월 보존으로 데이터베이스 크기가 약 45GB로 증가합니다. 수신자 데이터는 이 환경에 약 5GB를 사용합니다.

주의 - 이 예상 값에는 추가 고객 데이터가 포함되지 않습니다. 고객 데이터의 추가 열 또는 테이블을 Adobe Campaign 데이터베이스에 복제하려는 경우 추가 디스크 공간 요구 사항을 예측해야 합니다. 또한 업로드된 세그먼트/목록은 크기, 빈도 및 보존 기간에 따라 더 많은 저장소가 필요합니다.

웹 및 애플리케이션 서버 이 시나리오에서는 Adobe이 다음 사양을 사용하여 4개의 컴퓨터, 2개의 애플리케이션 서버 및 2개의 웹 서버에 Adobe Campaign을 설치하는 것이 좋습니다.

_3Ghz+ 쿼드 코어 CPU, 8GB RAM, RAID 1 또는 10, 80GB SSD_애플리케이션 서버는 Campaign 콘솔 사용자 및 캠페인 워크플로우 실행을 직접 지원합니다. 이 기능은 고가용성을 위해 동일한 서버 두 대에 배포되며, NAS(Network-Attached Storage) 파일 시스템을 공유하여 페일오버를 지원합니다.이 웹 서버들은 시스템에서 천만 명의 활성 수신자들을 지원하는 Campaign 웹 애플리케이션을 호스팅한다.

을(를) 참조하십시오 시나리오 1: 보통 크기 배포 프록시, 환경 설정 센터/구독 처리 및 디스크 공간 사용에 대한 추가 정보를 확인하십시오.  데이터베이스 데이터베이스 서버에 대한 하드웨어 권장 사항은 다음과 같습니다.

이 배포에는 자체 웹 사이트 및 애플리케이션에서 제공되는 메시지 센터 호출도 포함됩니다.  웹 및 애플리케이션 서버 Adobe 이 시나리오에서는 다음과 같이 4개의 시스템에 Adobe Campaign을 설치하는 것이 좋습니다.

**- 애플리케이션 서버

3Ghz+ 쿼드 코어 CPU, 8GB RAM, RAID 1 또는 10, 80GB SSD 2개

을(를) 참조하십시오 시나리오 1: 보통 크기 배포 프록시, 환경 설정 센터/구독 처리 및 디스크 공간 사용에 대한 추가 정보를 확인하십시오.  데이터베이스 데이터베이스 서버에 대한 하드웨어 권장 사항은 다음과 같습니다.

_3Ghz+ 8코어 CPU, 96GB RAM, RAID 1 또는 10, 1.5TB SSD 최소_메모리 예상은 대규모 캠페인 실행에 대해 약 12,500,000명의 수신자의 전체 캐싱과 워크플로우 실행, 추적 데이터 가져오기 및 기타 동시 활동을 위한 RDBMS 버퍼 공간을 가정합니다.모든 Adobe Campaign 기술 데이터(캠페인, 추적, 작업 테이블 등)를 저장하는 데 데이터베이스에 필요한 디스크 공간은 3개월의 보존 기간을 기준으로 약 700GB인 것으로 추정됩니다. 추적 데이터를 6개월 동안 보존하도록 선택하면 데이터베이스 크기가 약 1.2TB로 증가하고 12개월 보존으로 데이터베이스 크기가 약 2TB로 증가합니다. 수신자 데이터는 이 환경에 약 50GB를 사용합니다.

가정 변경에 대한 지침 이러한 시나리오에 대한 가정은 모두 하드웨어 권장 사항 및 배포 아키텍처에 중요한 영향을 줍니다. 이 섹션에서는 다양한 가정에 대한 지침을 설명합니다. 요구 사항을 충족하기 위한 특정 권장 사항은 Adobe Campaign 컨설팅 팀에 문의하십시오.

  • 수신자 수

    활성 수신자는 저장 공간과 데이터베이스 버퍼 공간을 모두 필요로 하므로 일반적으로 더 많은 수신자는 데이터베이스 서버에서 더 많은 메모리와 CPU 용량을 필요로 합니다. 저장 공간 증가는 수신자 본인에게는 비교적 적지만 이메일 캠페인에 보관되는 이벤트 추적 데이터에 크게 영향을 줄 수 있습니다.

  • 이메일 캠페인 크기

    캠페인 실행 빈도는 데이터베이스 서버 CPU 요구 사항에 영향을 줍니다. 다이렉트 메일링, 인바운드 상호 작용 및 기타 워크플로우와 함께 이메일 캠페인을 위한 세분화 작업을 수행하면 데이터베이스 서버에 상당한 로드가 발생합니다.

  • 다이렉트 메일 빈도

    직접 메일 빈도는 데이터베이스 서버 CPU 요구 사항에 영향을 줄 수 있습니다. 캠페인 시작 및 기타 워크플로우와 함께 DM을 위한 세분화 작업은 데이터베이스 서버에 상당한 부하를 초래합니다.

  • SMS 메시지 볼륨

    이메일 캠페인 크기와 마찬가지로 SMS 메시지 볼륨은 온프레미스에 있는 Campaign 서버에 큰 로드를 배치하지 않습니다. 로드는 대부분 클라우드의 Adobe 클라우드 메시징 서버에 있습니다. 이메일 및 DM과 같은 SMS 캠페인에 대한 세분화는 마케팅 데이터베이스에 상당한 로드를 배치할 수 있습니다. 따라서 SMS 캠페인 시작 빈도와 세분화의 복잡성은 SMS 메시지 볼륨보다 더 관련이 있습니다.

  • 데이터베이스 스키마 복잡성

    각 활성 수신자의 데이터 양은 저장소 공간과 데이터베이스 버퍼 공간을 모두 필요로 하므로 일반적으로 더 많은 수신자가 데이터베이스 서버에 더 많은 메모리와 CPU를 필요로 합니다. 또한 복잡한 스키마에서는 세그멘테이션을 위해 조인할 테이블이 더 필요하므로 세그멘테이션 작업은 훨씬 느리게 실행될 수 있으며 데이터가 여러 테이블에 분산될 때 더 많은 데이터베이스 CPU 및 메모리가 필요합니다.
    데이터베이스 서버 메모리는 모든 수신자 데이터, 워크플로우 실행을 위한 임시 테이블 및 다른 데이터베이스 작업에 대한 여백을 포함할 수 있을 만큼 충분히 클 수 있도록 함으로써 추정됩니다.

  • 아웃바운드 상호 작용 사용

    배치 모드의 상호 작용에 대한 규칙은 모든 계산 복잡성을 데이터베이스에 전달하는 워크플로우에서 평가됩니다. 데이터베이스에 대한 주요 작업 요소는 한 번의 엔진 호출 동안 계산된 총 적격 오퍼 수입니다(대상 크기 X 가장 좋은 오퍼를 유지하기 전의 수신자당 평균 오퍼 수). 데이터베이스 서버 CPU 속도는 성능의 첫 번째 요소입니다.

  • 인바운드 상호 작용 또는 SOAP API 사용

    인바운드 상호 작용 규칙 및 오퍼는 마케팅 데이터베이스에서 평가되므로 중요한 데이터베이스 서버 리소스(특히 CPU)가 필요합니다. 인바운드 상호 작용 또는 SOAP API를 많이 사용하려면 작업 로드와 Campaign 워크플로우 실행을 구분하는 별도의 웹 서버가 필요합니다.

  • 추적 데이터 보존 기간

    추적 데이터의 보존 기간을 90일 이상으로 늘리면 더 많은 데이터베이스 저장소가 필요하며, 새로운 추적 데이터를 삽입하면 큰 테이블로 이동하기 때문에 시스템 속도가 느려질 수 있습니다. 데이터 추적은 90일 이후의 캠페인 세그멘테이션에 유용하지 않으므로 보존 기간을 단축하는 것이 좋습니다.
    수신자 마케팅 경험에 대한 장기적인 분석이 필요한 경우 추적 데이터를 Adobe Analytics 또는 다른 분석 시스템으로 이동해야 합니다.

가상화 모든 Campaign 서버가 가상화에 적합합니다. 적절한 가용성과 성능을 보장하기 위해 몇 가지 문제를 해결해야 합니다.

  • 장애 조치 구성

    로드 밸런싱이 적용된 프록시의 이중 애플리케이션 서버와 같은 클러스터형 서버는 별도의 하드웨어에 구축되어야 하드웨어 장애가 발생해도 두 VM이 다운되지 않습니다.

  • 입출력 구성

    데이터베이스 보안을 위해 권장되는 모든 RAID 구성을 유지해야 스토리지 디바이스의 손실로 인해 데이터가 손실되지 않습니다.

  • 입출력 성능

    데이터베이스 스토리지에 대한 권장 IOPS 등급을 준수해야 합니다. Amazon EC2와 같은 클라우드 서비스는 필요한 성능을 제공하지 않을 수 있으므로 신중하게 평가해야 합니다. 예를 들어 Amazon EC2 프로비저닝된 SSD 볼륨은 현재 각각 20,000 IOPS로 평가됩니다. 다음에서 자세히 알아보기 Amazon 설명서4 볼륨 RAID 구성의 경우 80,000 IOPS로 평가되며, 이는 불충분할 수 있습니다.

Adobe은 시스템을 프로덕션에 투입하기 전에 Adobe Campaign의 모든 가상화 배포에 대한 성능 테스트를 권장합니다.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f