推奨されるデプロイメント

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

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

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

単一の TarMK インスタンス

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

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

メリット：

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

デメリット：

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

TarMK コールドスタンバイ

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

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

メリット：

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

デメリット：

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

TarMK ファーム

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

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

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

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

メリット：

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

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

このアプローチでは、複数の Oak インスタンスが単一のデータセンター内の MongoDB レプリカセットにアクセスでき、事実上、AEM オーサー環境のアクティブ-アクティブ構成のクラスターになります。MongoDB のレプリカセットを使用すると、ハードウェアまたはネットワークに障害が発生した場合に高可用性と冗長性を確保することができます。

メリット：

• 新しい AEM オーサーインスタンスで水平方向に拡張可能
• データレイヤーの高可用性、冗長性、自動フェイルオーバー

デメリット：

• シナリオによっては TarMK 使用時よりパフォーマンスが低下する可能性あり

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

このアプローチでは、複数の Oak インスタンスが複数のデータセンターをまたいで MongoDB レプリカセットにアクセスできるので、事実上、AEM オーサー環境のアクティブ/アクティブ構成のクラスターになります。MongoDB のレプリケーションでは、複数のデータセンターを使用する場合にも同じ高可用性と冗長性を提供しますが、さらにデータセンターの停止に対処する機能も追加されました。

メリット：

• 新しい AEM オーサーインスタンスで水平方向に拡張可能
• データレイヤーの高可用性、冗長性、自動フェイルオーバー（データセンターが停止した場合も含む）

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 日あたりの検索のボリューム（数万件以上）

通常、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 を選択する場合は（コミュニティコンテンツのストレージを参照）、選択した 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 をレプリケートする必要がありません。

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

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

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

Business.Adobe.com リソース

Ecommerce Integrations Automated Onboarding Style System Cms Cloud Customer Communications Asset Collections