On-Premise Campaign Classic(v6.1 または v7)デプロイメントのハードウェア要件を予測するための一般的なガイドライン。

概要

このドキュメントは、on-premise データセンターまたは仮想化されたクラウドの環境で Adobe Campaign Version 6/7 のデプロイメントのための一般的なガイドラインが記載されています。このタイプのデプロイメントは、「ハイブリッド」または「ミッドソーシング」と呼ばれ、Campaign マーケティングインスタンスとマーケティングデータベースを運用管理に配置し、Adobe Cloud Messaging サービスを使用して電子メール、SMS、または SMPP のメッセージを送信し、電子メールの開封、バウンス、およびクリック追跡データを収集します。


マーケティングインスタンスはすべてのマーケティングアクティビティを推進し、キャンペーンで必要なすべての受信データと分析データを保存する Adobe Campaign アーキテクチャの一部です。マーケティングインスタンスは、Adobe Campaign サービスを実行する一連の on-premise サーバーとリレーショナルデータベースです。


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

ソフトウェアの互換性は互換性マトリクスに記載されています。

シナリオ

配置図とハードウェアサイズの推奨は、次の 3 つの代表的なシナリオで提供されます。

  1. 適切なサイズ-システム内に 1,000,000 人のアクティブな受信者。
  2. 大きなサイズ-システム内に 10,000,000 人のアクティブ受信者、および
  3. エンタープライズ-トランザクションメッセージングのある、25,000,000人のアクティブ受信者。

前提

このドキュメントでは、3 つのシナリオすべてに対し、次の使用形態も前提としています。

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

一般的なガイドライン

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

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

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

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

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

リバースプロキシ

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

プロキシをシステムでデプロイする場合、このドキュメントで説明されているすべてのシナリオには、次のハードウェア推薦条件で十分です:2G + デュアルコア CPU hz-4- GB の RAM、RAID 1、2×80GB HDD。

注意:

Adobe Campaign には、IIS または Apache に埋め込むことができるリバースプロキシが含まれています。上記のハードウェア推奨条件は、Adobe Campaign リバースプロキシを使用した場合にのみ適用されます。

ロードバランサー

Appservers のロードバランサはアクティブ/パッシブ設定で設定され、HTTPS がプロキシで終了します。Web サーバーの負荷分散装置は、アクティブ/アクティブ設定で設定され、HTTPS がプロキシで終了します。

Adobe では、導入環境で Adobe Campaign サーバーに中継できる URL パスのリストを提供しています。

アーキテクチャ

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

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

AC_SMALL

アプリサーバー 2 には、アプリサーバー 1 と同じ送信接続があります。読みやすさのために省略されました。

ボリュームの予測

チャンネル コメント
アクティブな受信者 1,000,000
Email 4,200,000/月
ダイレクトメール 1,000,000/月
モバイル SMS 100,000/月
毎日の電子メールのピークボリューム 500,000

これらのボリュームの場合、Adobe Campaign アプリケーションは、Adobe Campaign Client ユーザーとワークフローの実行に関するすべての機能を提供します。1,000,000 人のアクティブな受信者とこの電子メールのボリュームの場合、アプリケーションサーバー負荷は CPU や I/O インテンシブではなく、負荷の大半は、データベースにあります。

Adobe Campaign Web サーバーは、安全なゾーンに表示されます。

Web & アプリケーションサーバー

このシナリオは、次の仕様を含む 4 つのマシンに Adobe Campaign をインストールすることを推奨しています。

3Ghz + クアッドコア CPU、4- GB の RAM、RAID 1、2 × 80GB HDD

これらのシステムは、Campaign コンソールユーザーを直接サポートし、キャンペーンワークフローを実行するマーケティングインスタンス Application Server を作成します。この機能は、ネットワーク接続型ストレージ(NAS)ファイルシステムを共有し、フェイルオーバーを有効にするために、2 台の同じサーバーにデプロイされます。

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

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

アプリケーションサーバーでのディスク容量の消費は、サードパーティのサービスプロバイダー(例えば、ダイレクトメール用の印刷会社など)、または Web サイトからの登録や環境設定の更新のようなインポートされたフラットファイルのサイズと保持に依存し、CRM やマーケティングシステムから行います。

データベース

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

3Ghz + 4-core CPU、16-GB RAM、RAID 1、2 x 64-GB SSD または RAID 10、4 x 64-GB SSD。

メモリの見積もりは、大規模なキャンペーンを行うために、約 500,000 人の受信者の完全なキャッシング、およびワークフローを実行し、トラッキングデータをインポートし、その他の同時に行われるアクティビティのための RDBMS バッファの完全なキャッシングが行われることを想定しています。

3 カ月の保持期間に基づき、すべての Adobe Campaign の技術データ(キャンペーン、トラッキング、実行中のテーブルなど)を格納するためにデータベースで必要なディスク容量が、7GB であると予測されています。トラッキングデータの保持期間を 6 か月に指定した場合、データベースのサイズが約 9.2 GB 増加し、保持期間を 12 か月に指定すると、データベースサイズが 11 GB に増えます。受信者のデータはこの環境で約 1GB 消費されます。

重要:この予測に追加の顧客データは含まれていません。追加の列や顧客データを Adobe Campaign データベースに複製する予定がある場合は、追加のディスク容量要件を予測する必要があります。アップロードされたセグメント/リストでは、サイズ、頻度、保持期間に応じて、より多くの記憶領域が必要になります。

また、毎日処理される情報量が少ないので、データベースサーバーの IOPS は重要です。例えば、ピーク日に、合計 500,000人の受信者をターゲットとするキャンペーンを展開することもできます。各キャンペーンを実行する場合、Adobe Campaign は約 12,000,000 人の記録(配信ログテーブル)を含むテーブルに 500,000 人の記録を挿入します。キャンペーンのデプロイメント中に許容できるパフォーマンスを提供するために、アドビではこのようなシナリオを確保するため少なくとも60,000の任意の読み取り/書き込み IOP 4KB を推奨します。

シナリオ2:大規模のデプロイメント

AC_Medium

アプリケーションサーバー 2 はアプリケーションサーバー 1 と同じ発信接続を持ちます。読みやすさのために省略されました。

ボリュームの予測

チャンネル コメント
アクティブな信者 10,000,000
Email 42,000,000/月
直接メール 10,000,000/月
モバイル SMS 1,000,000/月
日常電子メールの容量ピークに達する 5,000,000

Web & アプリケーションサーバー

このシナリオでは、アドビは Adobe Campaign を 4 台の機器にインストールすることを勧める。2 つのアプリケーションサーバーと 2 つのウェブサーバーには、次の仕様がある。

3Ghz+ quad-core CPU, 8-GB RAM, RAID 1, 2 x 80-GB HDD

アプリケーションサーバーは、Campaign コンソールユーザとキャンペーンワークフローの実行を直接にサポートする。この機能は、ネットワーク接続型ストレージ(NAS)ファイルシステムを共有し、フェイルオーバーを有効にするために、2 台の同じサーバーにデプロイされます。

ウェブサーバーはシステムに1000万のアクティブな受信者をサポートする Campaign ウェブアプリケーションをホストする。

プロキシ、プレファレンスセンター/サブスクリプション処理についてもっと多くのコメントおよびディスク容量の使用を了解したいと、シナリオ1を参照してください。

データベース

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

3Ghz+ 8-core CPU, 64-GB RAM Ÿ RAID 1, 2 x 320-GB SSD または RAID 10, 4 x 320-GB SSD

メモリ評価は大きなキャンペーンを起動するために約5,000,000受信者の完全なバッファを仮設して、ワークフロー実行、データ追跡とその他の並行アクティビティのために RDBMS バッファ容量を加える。

3か月の保留期間に基づいて、すべての Adobe Campaign 技術データ(キャンペーン、トラッキング、ワーク表など)を保存するためにデータベースに要求されたディスク容量は 140 GB であると予期された。トラッキングデータを6か月保留すると、データベースのサイズが 242GB に増加し、12か月保留すると、データベースのサイズが 446 GB に増加する。受信者データはこの環境に約 7GB を消耗する。

シナリオ3:メッセージセンターとのエンタープライズ展開

AC_Large

アプリケーションサーバー 2 はアプリケーションサーバー 1 と同じ発信接続を持ちます。読みやすさのために省略されました。

ボリュームの予測

チャンネル コメント
アクティブな受信者 25,000,000
Email 108,000,000/月
ダイレクトメール 25,000,000/月
モバイル SMS 2,500,000/月
Message Center 2,500,000 のトランザクションメッセージ/月
毎日のメール容量ピーク 2,500,000

受信者 25,000,000 人のデプロイメントでは、シナリオ2に示されているものと本質的に同じです:Campaign Web アプリケーショントラフィックは Campaign Web サーバーにルーティングされるため、大規模なキャンペーン起動後の Web トラフィックのバーストは、キャンペーンワークフローやコンソールユーザーに影響を与えません。

このデプロイメントには、メッセージセンターの呼び出しも含まれており、独自の Web サイトやアプリケーションから継承されます。

アプリケーションサーバー

このシナリオでは、以下のように Adobe Campaign を 4 台のコンピューターにインストールすることをお勧めします:

アプリケーションサーバー

2つのシステム、3Ghz+ quad-core CPU、8-GB RAM, RAID 1、2 x 160-GB HDD

Web サーバー

2 つのシステム、3Ghz+ クアッドコア CPU、16-GB RAM、RAID 1、2 x 80-GB HDD

アプリケーションサーバーは、Campaign コンソールユーザとキャンペーンワークフローの実行を直接にサポートする。この機能は、ネットワーク接続型ストレージ(NAS)ファイルシステムを共有し、フェイルオーバーを有効にするために、2 台の同じサーバーにデプロイされます。

ウェブサーバーはシステムに1000万のアクティブな受信者をサポートする Campaign ウェブアプリケーションをホストする。

プロキシ、プレファレンスセンター/サブスクリプション処理についてもっと多くのコメントおよびディスク容量の使用を了解したいと、シナリオ1を参照してください。

データベース

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

3Ghz+ 8 コア CPU、96-GB RAM、RAID 1、2 x 768-GB SSD または RAID 10、4 x 768-GB SSD

メモリは、大規模なキャンペーンの打ち上げに約 12,500,000 人の受信者のフルキャッシングを前提とし、加えて、ワークフローの実行、トラッキング・データのインポート、およびその他の並行アクティビティのための RDBMS バッファ容量を想定しています。

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

仮定を変更するためのガイドライン

これらのシナリオで想定される前提条件はすべて、ハードウェアの推奨および展開アーキテクチャに大きな影響を及ぼします。ここでは、様々な状況におけるガイドラインについて説明します。お客様の要件を満たすための具体的な推奨事項については、Adobe Campaign コンサルティングチームにお問い合わせください。

受信者数

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

電子メールキャンペーンのサイズ

キャンペーンの頻度は、データベースサーバーの CPU 要件に影響を及ぼします。電子メールキャンペーンのセグメンテーション操作は、ダイレクトメール、インバウンドインタラクション、およびその他のワークフローと組み合わされて、データベースサーバーに大きな負荷を与えます。

直接メールの頻度

直接メールの頻度は、データベースサーバーの CPU 要件に影響することがある。キャンペーン起動とほかのワークフローと結合して、直接メールのセグメント化操作はデータベースサーバーに重大な負荷を掛ける。

SMS メッセージボリューム

電子メールキャンペーンのサイズと同様、SMS メッセージのボリュームは、オンプレミス内部の Campaign サーバーに大きな負荷をかけない;負荷は主にクラウド上の Adobe Cloud メッセージサーバにある。電子メールや直接メールなど、SMS キャンペーン用のセグメンテーションは、マーケティングデータベースに重大な負荷をかけることができる。したがって、SMS キャンペーン起動の頻度とセグメンテーションの複雑さは、SMS メッセージのボリュームより関連性が高い。

データベーススキーマの複雑さ

各アクティブな受信者のデータ量は、ストレージ容量とデータベースバッファー容量の両方を必要とする。したがって、普通は多くの受信者はデータベースサーバー上もっと多くのメモリと CPU を要求している。複雑なスキーマには、多くのテーブルがセグメントと結合することが要求されるので、セグメントの処理がより遅くなれ、且つデータが複数のテーブルに交叉展開されるときに、より多くのデータベース CPU とメモリが要求される。

データベースサーバーのメモリは、データベースバッファープールが大きくてすべての受信者データが含められるように確保し、ワークフローを実行するための一時的なテーブルを加え、他のデータベース操作のためのマージンなどを加えることによって予期されている。

アウトバウンドインタラクションの使用

アウトバウンドインタラクションルールとオファーは、マーケティングインスタンスアプリケーションサーバーのワークフローに評価され、アプリケーションサーバーの CPU とメモリが必要になる。複雑なインタラクションルールや多数のオファーは大量の CPU を要求することができる。

インバウンドインタラクションまたは SOAP API の使用

インバウンドインタラクションルールとオファーはマーケティングデータベースに評価され、大量のデータベースサーバーリソースが必要になる。特に CPU が必要である。インバウンドインタラクションまたは SOAP APIs を大幅に使用する場合、実行中の Campaign ワークフローからワークロードを分離する別々のウェヴサーバーが必要になる。

トラッキングデータ保留期間

90日を超えるトラッキングデータの保留期間を増やすと、新しいトラッキングデータが大きなテーブルに入るので、より多くのデータベース保存が必要になり、システムの速度も低下になる。トラッキングデータは90日後にキャンペーンセグメントに使用されない場合、保留期間を短縮することを勧める。

受信者のマーケティング体験を長期分析する必要がある場合、トラッキングデータを Adobe Analytics または別の分析システムに移動する必要がある。

仮想化

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

フェイル-オーバー設定

クラスター化されたサーバー、例えば、プロキシの下の負荷が均一で過剰なアプリケーションサーバーは、ハードウェア障害が発生した場合に、両方の VM がダウンしないように、別々のハードウェアにデプロイされる必要がある。

I / O 設定

データベースセキュリティのために、すべての推奨される RAID 設定を維持する必要がある。これにより、ストレージデバイスの損失がデータの損失を起こさない。

I / O パフォーマンス

データベースストレージの推奨 IOPS レーティングを、順守する必要があります。Amazon EC2 などのクラウドサービスでは、必要なパフォーマンスが得られない場合があるので注意して評価する必要があります。たとえば、Amazon EC2 がプロビジョニングした SSD ボリュームは、現在、それぞれ 20,000 IOPS と評価されています(http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html を参照)。ボリューム4の RAID 構成は80,000 IOPS と評価されますが、これは十分ではありません。

Adobe では、システムを実稼働環境に投入する前に、Adobe Campaign の仮想化展開のパフォーマンステストを推奨しています。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー