現在表示中:

注意:

このページでは、AEM の推奨されるトポロジについて説明します。クラスター化機能およびその設定方法について詳しくは、Apache Sling Discovery API のドキュメントを参照してください。

MicroKernel は、AEM 6.2 の永続性マネージャーとして機能します。ニーズに合わせた MicroKernel の選択は、インスタンスの目的と検討しているデプロイメントタイプによって決まります。

以下の例は、最も一般的な AEM 設定で推奨される使用法を示しています。

デプロイメントのシナリオ

単一の TarMK インスタンス

このシナリオでは、単一の TarMK インスタンスを 1 台のサーバーで実行します。

これは、オーサーインスタンスのデフォルトのデプロイメントです。

chlimage_1

メリット:

  • シンプル
  • メンテナンスが容易
  • 良好なパフォーマンス

デメリット:

  • サーバーの能力の制限を超えたスケーラビリティはない
  • フェイルオーバー機能はない

TarMK コールドスタンバイ

単一の TarMK インスタンスが、プライマリインスタンスとして機能します。プライマリのリポジトリは、スタンバイフェイルオーバーシステムにレプリケーションされます。

また、リポジトリ全体がフェイルオーバーサーバーに定期的にレプリケートされるので、コールドスタンバイメカニズムをバックアップとして使用することもできます。フェイルオーバーサーバーは、コールドスタンバイモードで実行されます。これは、インスタンスの HttpReceiver のみ実行していることを意味します。

chlimage_1

メリット:

  • シンプル
  • 優れた保守性
  • パフォーマンス
  • フェイルオーバー

デメリット:

  • サーバーの能力の制限を超えたスケーラビリティはない
  • 1 台のサーバーがほとんどの時間アイドル状態
  • フェイルオーバーは自動ではない(外部で検出されるまで、フェイルオーバーシステムは要求の提供を開始できない)

注意:

TarMK コールドスタンバイを使用した AEM の設定方法について詳しくは、この記事を参照してください。

注意:

この TarMK の例のコールドスタンバイデプロイメントでは、フェイルオーバーサーバーに定期的にレプリケートされるので、プライマリインスタンスとスタンバイインスタンスの両方が個別にライセンスされている必要があります。ライセンスについて詳しくは、アドビの一般ライセンス条件を参照してください。

TarMK ファーム

複数の Oak インスタンスを、それぞれ単一の TarMK インスタンスと共に実行します。TarMK リポジトリは独立しており、同期が維持されている必要があります。

オーサーサーバーが各ファームメンバーに同じコンテンツを公開することによって、リポジトリの同期が維持されます。詳しくは、レプリケーションを参照してください。

AEM Communities の場合、ユーザー生成コンテンツ(UGC)はレプリケーションされません。TarMK ファームで UGC をサポートするには、AEM Communities に関する考慮事項を参照してください。

これは、パブリッシュ環境のデフォルトのデプロイメントです。

chlimage_1

メリット:

  • パフォーマンス
  • 読み取りアクセスに対するスケーラビリティ
  • フェイルオーバー

単一のデータセンターで高可用性を確保するための MongoMK フェイルオーバーを備えた Oak クラスター

このアプローチは、単一のデータセンター内の 1 つの MongoDB レプリカセットにアクセスする複数の Oak インスタンスを示しています。MongoDB のレプリカセットは、ハードウェアまたはネットワークに障害が発生した場合に高可用性と冗長性を提供するために使用されます。

chlimage_1

メリット:

  • AEM インスタンスのスケールが可能
  • データレイヤーの高可用性、冗長性、自動フェイルオーバー

デメリット:

  • TarMK ほどのパフォーマンスは得られない

複数のデータセンターにわたる MongoMK フェイルオーバーを備えた Oak クラスター

このアプローチは、複数のデータセンターにわたる 1 つの MongoDB レプリカセットにアクセスする複数の Oak インスタンスを示しています。MongoDB のレプリケーションでは、複数のデータセンターを使用する場合にも同じ高可用性と冗長性を提供しますが、さらにデータセンターの停止に対処する機能も追加されました。

chlimage_1

メリット:

  • AEM インスタンスのスケールが可能
  • データレイヤーの高可用性、冗長性、自動フェイルオーバー(データセンターが停止した場合も含む)

注意:

Amazon Web Services などのプラットフォームでアービターをホストする必要がある場合は、アービターが投票プロセスにのみ参加し、追加のデータを格納しないように設定することをお勧めします。

注意:

この記事で説明する MongoDB アーキテクチャの概念について詳しくは、MongoDB のレプリケーションに関するページを参照してください。

MicroKernel:どちらを使用すべきか

利用可能な 2 つの MicroKernel 間での選択に際して考慮する必要がある基本ルールは、TarMK はパフォーマンスのために設計されているのに対して、MongoMK はスケーラビリティのために使用されるということです。

要件に最適なタイプのデプロイメントを確立するために、以降に示す意思決定のフローチャートを使用できます。

アドビでは、すべてのデプロイメントのシナリオ(AEM のオーサーインスタンスとパブリッシュインスタンスの両方)で顧客が使用するデフォルトの永続性テクノロジーとして、TarMK を強くお勧めします。ただし、次に示す事例を除きます。

オーサーインスタンスで TarMK ではなく AEM MongoMK を例外的に選択する場合

永続性バックエンドとして TarMK ではなく MongoMK を選択する主な理由は、水平方向へのインスタンスの拡張です。つまり、2 つ以上のアクティブなオーサーインスタンスを常に実行し、MongoDB を永続性ストレージシステムとして使用します。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では同時に実行されるすべてのオーサリングアクティビティをサポートできなくなっているためです。

新しいサイトの運用開始後の正確な同時実行モデルを予測するのはほぼ不可能です。そのため、アドビでは、MongoMK と 2 つ以上のオーサーアクティブノードを使用するかどうかを評価する際に次の条件を考慮することをお勧めします。

  1.  1 日に接続する名前付きユーザーの数(数千人以上)
  2.  同時ユーザーの数(数百人以上)
  3.  1 日あたりのアセット収集のボリューム(数十万件以上)
  4.  1 日あたりのページ編集のボリューム(数十万件以上)(Multi Site Manager やニュースフィードの収集などによる自動化された更新を含む)
  5.  1 日あたりの検索のボリューム(数万件以上)

注意:

Tough Day を使用すると、デプロイ済みのハードウェア設定のコンテキストにおける顧客のアプリケーションのパフォーマンスを評価できます。このツールについて詳しくは、ここを参照してください。

通常、MongoDB を使用した最小限のデプロイメントには次のトポロジが含まれます。

  • 1 つのプライマリノードと 2 つのセカンダリノードで構成された MongoDB レプリカセット。各 MongoDB インスタンスは、各ノード間の遅延が 15 ミリ秒未満の可用性ゾーンで実行されます。
  • リーダーノードとリーダー以外のノードを 1 つずつ含む(どちらのノードも常にアクティブです)オーサーインスタンスのクラスター。各オーサーインスタンスは、MongoDB のプライマリインスタンスとセカンダリインスタンスが実行されているそれぞれのデータセンターで実行されます。

また、アセットまたはバイナリが MongoDB 内に格納されないように、共有ファイルシステムまたは Amazon S3 にデータストアを設定することを強くお勧めします。これにより、デプロイメント内で最適なパフォーマンスを確保できます。

2 つ以上のオーサーインスタンスのクラスターを含む MongoDB レプリカセットをデプロイするその他のメリットの 1 つとして、オーサーインスタンス、MongoDB レプリカまたはデータセンター全体で障害が発生した場合に、最小限のダウンタイムで自動的にリカバリできる点が挙げられます。そうは言っても、TarMK ではなく MongoMK を選択するのは、単にリカバリ要件だけが理由ではないはずです(制御されたフェイルオーバーメカニズムを備えた最小限のダウンタイムを実現するソリューションは TarMK でも提供されます)。

デプロイメントの最初の 18 ヶ月間に前述の条件を満たすことができないと思われる場合は、最初に TarMK を使用して AEM をデプロイし、後から(前述の条件を適用する際に)設定を再評価して、TarMK をそのまま使用するか、MongoMK に移行するかを最終的に判断することをお勧めします。

パブリッシュインスタンスに TarMK ではなく AEM MongoMK を選択する例外的な場合

パブリッシュインスタンス用に MongoMK をデプロイすることはお勧めしません。ほとんどの場合、デプロイメントのパブリッシュ層は、TarMK を実行する、完全に独立したパブリッシュインスタンスのファームとしてデプロイされます。このパブリッシュインスタンスの同期は、オーサーインスタンスからコンテンツをレプリケーションすることで維持されます。この「何も共有しない」アーキテクチャは、パブリッシュインスタンスに適しており、パブリッシュ層のデプロイメントを水平方向に直線的に拡張できます。また、ファームのトポロジによっても、アップデートやアップグレードをパブリッシュインスタンスに周期的に適用するというメリットがもたらされるので、パブリッシュ層に対する変更の際にダウンタイムが発生しません。

これは、複数のパブリッシャーがある場合は常にパブリッシュ層で MongoMK クラスターを使用する AEM Communities には該当しません。JSRP を選択する場合は(Communities コンテンツのストレージを参照)、選択された MK(MongoDB や RDB など)に関係なく任意のパブリッシュ側クラスターが適切であるように、MongoMK クラスターが適切です。

MongoMK を使用して AEM をデプロイする際の前提条件と推奨事項

AEM 用の MongoMK デプロイメントを検討する場合の一連の前提条件と推奨事項があります。

MongoDB デプロイメントの必須の前提条件

  1. AEM を熟知したアドビのコンサルタントまたは MongoDB のアーキテクトの支援のもとで、MongoDB デプロイメントのアーキテクチャとサイジングをプロジェクトの実装に含める必要があります。
  2. 既存の、または新しい MongoDB 環境を適切に維持および保守できるように、MongoDB の専門知識をパートナーまたはカスタマーチーム内で共有しておく必要があります。
  3. 商用バージョンまたはオープンソースバージョンの MongoDB(AEM ではどちらもサポート可)のデプロイを選択できますが、MongoDB のメンテナンスとサポートの契約を MongoDB Inc. から直接購入する必要があります。
  4. AEM と MongoDB の全体的なアーキテクチャおよびインフラストラクチャについて明確に定義し、アドビの AEM アーキテクトによる検証を済ませておく必要があります。
  5. MongoDB を含む AEM デプロイメントのサポートモデルについて確認しておく必要があります。

MongoDB デプロイメントの重要な推奨事項

  • MongoDB for Adobe Experience Manager に関する記事を参照してください。
  • MongoDB の本番チェックリストを確認してください。
  • このページから、MongoDB の認定クラスにオンラインで参加できます。

注意:

前述のガイドライン、前提条件および推奨事項に関するその他のご質問については、アドビのカスタマーケアまでお問い合わせください。

AEM Communities に関する考慮事項

AEM Communities のデプロイを計画しているサイトでは、パブリッシュ環境から Communities メンバーが投稿した UGC を処理するために最適化されたデプロイメントを選択することをお勧めします。

共通のストアを使用すると、UGC の一貫した表示を確保するために、オーサーインスタンスとその他のパブリッシュインスタンスとの間で UGC をレプリケートする必要がありません。

 

デプロイメントに最適な永続性のタイプを選択する際に役立つ、一連の意思決定のフローチャートを次に示します。

オーサーインスタンス用のデプロイメントタイプの選択

chlimage_1

パブリッシュインスタンス用のデプロイメントタイプの選択

chlimage_1

注意:

MongoDB はサードパーティソフトウェアであり、AEM ライセンスパッケージには含まれていません。詳しくは、MongoDB のライセンスポリシーページを参照してください。

AEM デプロイメントを最大限活用するために、アドビは、プロフェッショナルサポートを受けられる MongoDB Enterprise バージョンのライセンスを取得することを推奨しています。

このライセンスには、標準レプリカセットが含まれます。このレプリカセットは、1 つのプライマリインスタンスと 2 つのセカンダリインスタンスで構成されており、これらのインスタンスは、オーサーとパブリッシュのいずれのデプロイメントにも使用できます。

MongoDB でオーサーとパブリッシュの両方を実行したい場合は、個別の 2 つのライセンスを購入する必要があります。

詳しくは、MongoDB for Adobe Experience Manager のページを参照してください。

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

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