ハードウェアサイズについての推奨事項

概要

注意

この記事は、一般的なサンプルガイドとしてのみ提供されています。 Campaign プロジェクトを開始する前に、Adobe Campaignカスタマーサクセスマネージャーに相談して、デプロイメントの正確なサイズを測定する必要があります。 禁止 インフラストラクチャまたはハードウェアを取得またはデプロイします。

このドキュメントでは、オンプレミスのデータセンターまたは仮想化クラウド環境でのAdobe Campaign Classic v7 の導入に関する一般的な推奨事項を示します。 このタイプのデプロイメント ( ハイブリッド または ミッドソーシング​を使用すると、Campaign マーケティングインスタンスとマーケティングデータベースを操作上の制御の下に配置し、Cloud Messaging サービスを使用して E メール、SMS または SMPP メッセージを送信し、E メールの開封、バウンス、クリック追跡データを収集します。

マーケティングインスタンスは、Adobe Campaignアーキテクチャの一部で、すべてのマーケティングアクティビティを推進し、キャンペーンから返されるすべての受信者データと分析データを保存します。 マーケティングインスタンスは、Adobe Campaign Services を実行するオンプレミスサーバーのセットとリレーショナルデータベースです。

注意

完全にホストされたAdobe Campaignインスタンス (AdobeCloud Servicesにデプロイされる ) を使用している場合、このドキュメントの情報は適用されません。

ソフトウェアの互換性については、 互換性マトリックス.

シナリオ

デプロイメント図とハードウェアのサイズに関する推奨事項は、次の 3 つの代表的なシナリオで提供されます。

  1. モデレートサイズ — システム内の 500 万人のアクティブな受信者
  2. — システム内のアクティブな受信者は 2,000 万人
  3. 大規模法人 - 5,000 万人のアクティブな受信者、トランザクションメッセージ

前提

このドキュメントでは、3 つのシナリオすべてについて、次のタイプの使用方法も想定しています。

  • 大規模な E メールキャンペーンは、アクティブな受信者の約 50%に週 2 回送信されます
  • ダイレクトメールは、システムの受信者ごとに 1 ヶ月に 1 回生成されます
  • SMS メッセージは、毎月、アクティブな受信者の約 10%に送信されます
  • 各受信者を定義するデータベーススキーマは、1 つの追加テーブルで拡張されています。このテーブルには、各受信者に対して約 200 バイトのデータが含まれています
  • Adobe Campaignインタラクションモジュールは、送信メールにオファーを追加するために使用されます
  • E メールトラッキングデータは、Campaign システムに 90 日間保持されます

一般的なガイドライン

Campaign はデータベースを中心としたアプリケーションであり、データベースサーバーのパフォーマンスが重要です。 実行中のワークフロー、セグメント化、トラッキングデータのアップロード、インバウンドインタラクション、分析および他のアクティビティはすべて、データベースアクティビティを生成します。 一般に、これらの操作のサイズと頻度によって、データベースサーバーのサイズが決まります。

マーケティングインスタンスのアプリケーションサーバーでは、ワークフローを実行し、Campaign コンソールユーザーからのリクエストを含む SOAP API 呼び出しに応答するのに十分な CPU とメモリが必要です。 CPU 要件は、複雑なオファールールでアウトバウンドインタラクションを使用するワークフロー、カスタム JavaScript を実行するワークフロー、高トラフィックレベルの Web アプリケーションを使用するワークフローでは、大きな影響を与えます。

Campaign Web アプリケーションは、マーケティングインスタンスアプリサーバーまたは別の Web サーバーシステムにもデプロイできます。 Web アプリケーションのワークロードは重要なワークフローや Campaign コンソールのユーザーと競合するので、Web アプリケーションとインバウンドインタラクションを別々のサーバーにデプロイして、コア Campaign 機能を高いパフォーマンスで確実に実行できます。

セキュリティと可用性のため、Adobeでは、インターネットのトラフィックを、ビジネスユーザーが生成したトラフィックから分離することをお勧めします。 このため、図には次の 2 つのサーバーグループが含まれています。Web サーバ(Web1 と Web2 に接続するインターネット)と App サーバ(App1 と App2 を処理するビジネスプロセス)

商用 E メールの送信者が機能的なオプトアウト Web ページを持つことは法的要件です。 Adobeでは、フェイルオーバーシナリオで、各グループサーバに冗長マシンを使用することをお勧めします。 これは、Adobe Campaignがオプトアウトページをホストする場合に特に当てはまります。

リバースプロキシ

Campaign アーキテクチャは、HTTP 経由の SSL(HTTPS) を使用してマーケティングインスタンスとAdobeCloud Messaging 間の通信を行うことで、高いセキュリティを強化します。 マーケティングインスタンスサーバーとデータベースを分離し、保護するために、「非武装地帯」(DMZ) サブネットでリバースプロキシを使用することで、セキュリティ、信頼性、可用性が適用されます。

ロードバランサー

アプリサーバーのロードバランサーは、アクティブ/パッシブ設定で設定され、プロキシで HTTPS が終了します。 Web サーバーのロードバランサーは、アクティブ/アクティブ構成で設定され、プロキシで HTTPS が終了します。

Adobeには、デプロイメント環境でAdobe Campaignサーバーに中継できる URL パスの排他的なリストが用意されています。

アーキテクチャ

一般的なアーキテクチャは、ボリュームに関係なくほぼ同じです。 セキュリティと高可用性の要件により、最低 4 台のサーバが求められます。WebApps を使用しない場合は 2 台のサーバー 設定の違いは、主に CPU コアやメモリなどのハードウェア構成によって異なります。

シナリオ 1:適度なサイズのデプロイメント

推定ボリューム:

チャネル ボリューム
アクティブな受信者 500 万
メール 420 万/月
ダイレクトメール 100 万/月
モバイル SMS 100,000/月
1 日のピークメール量 500

これらのボリュームでは、Adobe Campaignアプリケーションサーバーシステムのペアは、Adobe Campaignクライアントユーザーとワークフローの実行に対してすべての機能を提供します。 500 万人のアクティブな受信者とこの E メールボリュームの場合、アプリケーションサーバの負荷は CPU や I/O を集中的に消費しません。ストレスのほとんどはデータベースにあります。

Adobe Campaign Web サーバーは、セキュアゾーンに表示されます。

Web およびアプリケーションサーバー

このシナリオでは、次の仕様で、4 台のマシンにAdobe Campaignをインストールすることをお勧めします。

3Ghz+クアッドコア CPU、8-GB RAM、RAID 1 または 10、2 x 80-GB SSD

これらのシステムは、マーケティングインスタンスアプリケーションサーバーを作成します。このサーバーは、Campaign コンソールのユーザーを直接サポートし、キャンペーンワークフローを実行します。

DMZ の負荷分散トラフィックのリバースプロキシをAdobe Campaign Web サーバーに送信します。 プロキシマシンにAdobe Campaignソフトウェアスタックをインストールする必要はありません。リバースプロキシソフトウェアまたはネットワーク機器を使用できます。

サブスクリプションのオプトイン/オプトアウトおよびプリファレンスセンターの機能は、Campaign または独自の Web サイトで提供できます。 この機能を Web サイトに実装する場合は、環境設定と購読情報が Campaign マーケティングデータベースに反映されるようにする必要があります。 通常は、キャンペーンワークフローによって自動的にアップロードされる抽出ファイルを作成することでおこなわれます。

アプリケーションサーバーでのディスク容量の消費は、サードパーティのサービスプロバイダー(ダイレクトメール用の印刷ベンダーなど)と交換するファイルの保持期間、Web サイトからの購読や環境設定の更新、独自の CRM やマーケティングシステムからの抽出などのインポート済みフラットファイルのサイズと保持に依存します。

データベース

データベースサーバのハードウェアの推奨事項は次のとおりです。

3Ghz+ 4 コア CPU、16-GB RAM、RAID 1 または 10、128GB SSD 以上

メモリの予測値は、大規模なキャンペーン開始で約 500,000 人の受信者のフルキャッシュと、ワークフローの実行、トラッキングデータのインポート、その他の同時アクティビティのための RDBMS バッファー領域を想定しています。

Adobe Campaignのすべての技術データ(キャンペーン、トラッキング、作業用テーブルなど)を保存するためにデータベースで必要なディスク容量は、3 ヶ月の保持期間に基づいて約 35 GB であると推定されます。 トラッキングデータを 6 か月間保持する場合、データベースのサイズは約 40 GB に増加し、12 か月の保持ではデータベースのサイズが約 45 GB に増加します。 受信者データは、この環境で約 5 GB を消費します。

注意

この見積もりには、追加の顧客データは含まれません。 追加の列または顧客データのテーブルをAdobe Campaignデータベースにレプリケートする場合は、その追加のディスク容量要件を見積もる必要があります。 アップロードされたセグメント/リストも、サイズ、頻度、保持期間に応じて、より多くのストレージが必要になります。

また、1 日に処理される情報の量が多いので、データベースサーバの IOPS が重要であると考えてください。 例えば、ピーク日に、合計 500,000 人の受信者をターゲットにしたキャンペーンをデプロイできます。 Adobe Campaignは、各キャンペーンを実行するために、約 1,200 万件のレコード(配信ログテーブル)を含むテーブルに、50 万件のレコードを挿入します。 キャンペーンのデプロイメント中に許容可能なパフォーマンスを提供するために、Adobeでは、このシナリオで最低 60,000 個の 4 KB のランダム読み取り/書き込み IOPS を推奨しています。

シナリオ 2:大規模な導入

推定ボリューム:

チャネル ボリューム
アクティブな受信者 2,000 万
メール 42 百万/月
ダイレクトメール 1000 万/月
モバイル SMS 1,000,000/月
1 日のピークメール量 5,000,000

Web およびアプリケーションサーバー

このシナリオでは、Adobeは、次の仕様のAdobe Campaignを 4 台のマシン、2 台のアプリケーションサーバー、2 台の Web サーバーにインストールすることを推奨します。

3Ghz+クアッドコア CPU、8-GB RAM、RAID 1 または 10、80-GB SSD

アプリケーションサーバーは、Campaign コンソールユーザーとキャンペーンワークフローの実行を直接サポートします。 この機能は、高可用性を実現するために 2 台の同一サーバに導入され、NAS(Network-Attached Storage) ファイル・システムを共有してフェイルオーバーを可能にします。

Web サーバーは、システム内の 1,000 万人のアクティブな受信者をサポートする Campaign Web アプリケーションをホストします。

参照: シナリオ 1:適度なサイズのデプロイメント プロキシ、プリファレンスセンター/サブスクリプションの処理、ディスク容量の使用に関するコメントを追加しました。

データベース

データベースサーバのハードウェアの推奨事項は次のとおりです。

3Ghz+ 8 コア CPU、64-GB RAM、RAID 1 または 10、320-GB SSD x 2、RAID 10、640GB SSD 最小

メモリの予測値は、大規模なキャンペーン起動用に約 5,000,000 人の受信者のフルキャッシュと、ワークフローの実行、トラッキングデータのインポート、その他の同時アクティビティ用の RDBMS バッファ領域を想定しています。

すべてのAdobe Campaignの技術データ(キャンペーン、トラッキング、作業用テーブルなど)を格納するためにデータベースで必要なディスク容量は、3 か月の保持期間に基づいて約 280 GB であると推定されます。 トラッキングデータを 6 か月間保持する場合、データベースのサイズは約 450 GB に増加し、12 か月の保持ではデータベースのサイズが約 900 GB に増加します。 受信者データは、この環境で約 15 GB を消費します。

シナリオ 3:Message Center を使用した Enterprise デプロイメント

推定ボリューム:

チャネル ボリューム
アクティブな受信者 5,000 万
メール 1 億 8 百万/月
ダイレクトメール 25 百万/月
モバイル SMS 2,5 百万/月
トランザクションメッセージ 2,5 百万/月
1 日のピークメール量 2,500 万

5,000 万人の受信者をサポートするデプロイメントは、基本的に シナリオ 2:Campaign Web アプリケーショントラフィックは Campaign Web サーバーにルーティングされるので、大規模なキャンペーンの起動後の Web トラフィックのバーストは Campaign ワークフローやクライアントコンソールユーザーに影響しません。

このデプロイメントには、Web サイトやアプリケーションから実行される Message Center 呼び出しも含まれます。

Web およびアプリケーションサーバー

このシナリオでは、Adobeは、次のように、4 台のマシンにAdobe Campaignをインストールすることをお勧めします。

  • アプリケーションサーバー
    2 台のシステム、3Ghz+クアッドコア CPU、8-GB RAM、RAID 1 または 10、80-GB SSD

  • Web サーバー
    2 台のシステム、3Ghz+クアッドコア CPU、16-GB RAM、RAID 1 または 10、80-GB SSD

アプリケーションサーバーは、Campaign コンソールユーザーとキャンペーンワークフローの実行を直接サポートします。 この機能は、高可用性を実現するために 2 台の同一サーバに導入され、NAS(Network-Attached Storage) ファイル・システムを共有してフェイルオーバーを可能にします。

Web サーバーは、システム内の 1,000 万人のアクティブな受信者をサポートする Campaign Web アプリケーションをホストします。

参照: シナリオ 1:適度なサイズのデプロイメント プロキシ、プリファレンスセンター/サブスクリプションの処理、ディスク容量の使用に関するコメントを追加しました。

データベース

データベースサーバのハードウェアの推奨事項は次のとおりです。

3Ghz+ 8 コア CPU、96-GB RAM、RAID 1 または 10、1.5TB SSD 以上

メモリの予測値は、大規模なキャンペーン起動用に約 12,500,000 人の受信者のフルキャッシュと、ワークフローの実行、トラッキングデータのインポート、その他の同時アクティビティ用の RDBMS バッファー容量を想定しています。

すべてのAdobe Campaignの技術データ(キャンペーン、トラッキング、作業用テーブルなど)を格納するためにデータベースで必要なディスク容量は、3 か月の保持期間に基づいて約 700 GB であると推定されます。 トラッキングデータを 6 か月間保持する場合、データベースのサイズは約 1.2 TB に増加し、12 か月の保持ではデータベースのサイズが約 2 TB に増加します。 受信者データは、この環境で約 50 GB を消費します。

前提条件の変更に関するガイドライン

これらのシナリオに対して行われた前提は、ハードウェアの推奨事項と導入アーキテクチャに大きな影響を与えます。 このセクションでは、様々な前提に関するガイドラインを説明します。 要件を満たす具体的な推奨事項については、Adobe Campaignコンサルティングチームにお問い合わせください。

  • 受信者数
    アクティブな受信者には、ストレージ領域とデータベースバッファ領域の両方が必要なので、より多くの受信者は通常、データベースサーバー上でより多くのメモリと CPU 容量を必要とします。 受信者自身にとってストレージの増加は比較的小さいものの、E メールキャンペーン用に保持されるイベントトラッキングデータにとって重要な場合があります。

  • メールキャンペーンサイズ
    キャンペーンの起動頻度は、データベースサーバーの CPU 要件に影響を与えます。 ダイレクトメール送信、インバウンドインタラクション、その他のワークフローと組み合わせて、E メールキャンペーンのセグメント化操作を行うと、データベースサーバーに大きな負荷がかかります。

  • ダイレクトメールの頻度
    ダイレクトメールの頻度は、データベースサーバーの CPU 要件に影響を与える可能性があります。 キャンペーンの起動や他のワークフローと組み合わせて、ダイレクトメールのセグメント化操作は、データベースサーバーに大きな負荷をかけます。

  • SMS メッセージボリューム
    E メールキャンペーンのサイズと同様に、SMS メッセージの量では、オンプレミスにある Campaign サーバーに大きな負荷がかかりません。読み込みは、主にクラウド上のAdobeCloud Messaging サーバーでおこなわれます。 E メールやダイレクトメールなどの SMS キャンペーンをセグメント化すると、マーケティングデータベースに大きな負荷がかかる可能性があります。 したがって、SMS キャンペーンの開始頻度とセグメント化の複雑さは、SMS メッセージの量よりも関連性が高くなります。

  • データベーススキーマの複雑さ
    各アクティブな受信者のデータ量には、ストレージ容量とデータベースバッファ容量の両方が必要なので、一般的に、より多くの受信者はデータベースサーバー上でより多くのメモリと CPU を必要とします。 複雑なスキーマでは、セグメント化用に結合するテーブルも多くなるので、セグメント化操作の実行時間が大幅に長くなり、データが複数のテーブルに分散される場合に、より多くのデータベース CPU とメモリが必要になります。

    データベースサーバーのメモリは、データベースバッファプールが、すべての受信者データと、ワークフローを実行するための一時テーブルに加え、他のデータベース操作の余白を含む十分な大きさになることを確認して推定します。

  • アウトバウンドインタラクションの使用状況
    バッチモードでのインタラクションのルールは、計算の複雑さをすべてデータベースに引き継ぐワークフローで評価されます。 データベースでの主な取り組みの要因は、1 回のエンジン呼び出し中に計算された適格なオファーの合計数です(ターゲットサイズ X、N 個のベストオファーを維持する前の受信者あたりの平均オファー数)。 データベースサーバの CPU 速度は、パフォーマンスの第 1 の要因です。

  • インバウンドインタラクションまたは SOAP API の使用
    インバウンドインタラクションルールとオファーはマーケティングデータベースで評価され、データベースサーバーリソース(特に CPU)が大量に必要となります。 インバウンドインタラクションまたは SOAP API を多く使用する場合は、実行中の Campaign ワークフローから作業負荷を分離するために、別々の Web サーバーが必要になります。

  • トラッキングデータ保持期間
    トラッキングデータの保持期間を 90 日以上に増やすと、データベースの容量が増え、新しいトラッキングデータを大きなテーブルに挿入するので、システムの速度が低下する可能性があります。 トラッキングデータは、90 日後にキャンペーンをセグメント化する場合は役に立たないので、保持期間を短くすることをお勧めします。

    受信者マーケティングエクスペリエンスの長期的な分析が必要な場合は、トラッキングデータをAdobe Analyticsまたは他の分析システムに移動する必要があります。

仮想化

すべての Campaign サーバは仮想化に適しています。 適切な可用性とパフォーマンスを確保するために、いくつかの問題に対処する必要があります。

  • フェイルオーバー設定
    クラスタ化されたサーバ(負荷分散プロキシの下の冗長なアプリケーションサーバなど)は、ハードウェア障害が発生した場合に両方の VM が停止しないように、別のハードウェアにデプロイする必要があります。

  • I/O 設定
    ストレージデバイスを失ってもデータが失われないように、推奨される RAID 構成は、データベースのセキュリティを維持する必要があります。

  • I/O パフォーマンス
    データベースストレージの推奨 IOPS 評価は考慮する必要があります。 Amazon EC2 などのクラウドサービスは、必要なパフォーマンスを提供しない場合があるので、慎重に評価する必要があります。 例えば、Amazon EC2 プロビジョニングされた SSD ボリュームの評価は、現在、それぞれ 20,000 IOPS です。 詳しくは、 Amazonドキュメントしたがって、4 ボリュームの RAID 構成は 80,000 IOPS と評価され、十分ではない可能性があります。

Adobeでは、Adobe Campaignの仮想化導入に関して、システムを実稼動環境に移行する前にパフォーマンステストを実施することを推奨しています。

関連トピック

このページ