マルチテナント機能と同時開発について

はじめに

複数のチームが同じAEM環境にコードをデプロイする場合、他のチームの足を踏むことなく、可能な限り独立してチームが作業できるようにするために従う必要があるプラクティスがあります。 完全に排除することはできませんが、これらのテクニックはチーム間の依存関係を最小限に抑えます。 同時開発モデルを成功させるには、開発チーム間の良好なコミュニケーションが重要です。

さらに、複数の開発チームが同じAEM環境で作業する場合、ある程度のマルチテナント性が発揮される可能性が高くなります。 AEM環境で複数のテナントをサポートしようとする際の実践的な検討事項、特にガバナンス、運用、開発を管理する際に直面する課題に関しては、多くの点が書かれています。 この論文では、マルチテナント環境でのAEMの実装に関する技術的な課題の一部を紹介しますが、これらの推奨事項の多くは、複数の開発チームを持つ組織に適用されます。

AEMは複数のサイトをサポートし、1つの環境に複数のブランドをデプロイすることもできますが、真のマルチテナント性を提供しない点に注意する必要があります。 一部の環境設定およびシステムリソースは、常に、環境にデプロイされているすべてのサイトで共有されます。 この論文では、これらの共有リソースの影響を最小限に抑えるためのガイダンスを提供し、これらの領域でのコミュニケーションとコラボレーションを効率化するための提案を提供します。

メリットと課題

マルチテナント環境の実装には、多くの課題があります。

有効なタイプには以下が含まれます。

  • 技術的な複雑さの追加
  • 開発のオーバーヘッドの増加
  • 共有リソースへの組織間の依存関係
  • 運用の複雑さの増大

直面している課題にもかかわらず、マルチテナントアプリケーションを実行すると次のような利点があります。

  • ハードウェアコストの削減
  • 今後のサイトの市場投入までの時間を短縮
  • 今後のテナントの導入コストの削減
  • ビジネス全体にわたる標準的なアーキテクチャと開発プラクティス
  • 一般的なコードベース

ビジネスで真のマルチテナントが必要で、他のテナントの知識がゼロで、共有コード、コンテンツ、一般的な作成者がいない場合は、個別のオーサーインスタンスが実行可能な唯一のオプションです。 開発作業の全体的な増加は、インフラストラクチャとライセンスコストの削減と比較して、このアプローチが最適かどうかを判断する必要があります。

開発テクニック

依存関係の管理

Mavenプロジェクトの依存関係を管理する場合、すべてのチームがサーバー上の特定のOSGiバンドルの同じバージョンを使用することが重要です。 Mavenプロジェクトが誤って管理された場合に何が起こるかを説明するために、次の例を示します。

プロジェクトAはライブラリのバージョン1.0、foo;に依存します。fooバージョン1.0は、サーバーへのデプロイメントに埋め込まれます。 プロジェクトBはライブラリのバージョン1.1、foo;に依存します。fooバージョン1.1は、デプロイメントに埋め込まれます。

さらに、このライブラリでAPIがバージョン1.0と1.1の間で変更されたとします。この時点で、これら2つのプロジェクトの1つが正しく動作しなくなります。

この問題に対処するために、すべてのMavenプロジェクトを1つの親リアクタープロジェクトの子にすることをお勧めします。 このリアクタプロジェクトは、次の2つの目的を果たします。必要に応じて、すべてのプロジェクトの構築とデプロイメントを同時に実行でき、すべての子プロジェクトの依存関係宣言が含まれます。 親プロジェクトは依存関係とそのバージョンを定義し、子プロジェクトは必要な依存関係のみを宣言し、親プロジェクトからバージョンを継承します。

このシナリオでは、プロジェクトBで作業するチームがfooのバージョン1.1の機能を必要とする場合、開発環境でこの変更がプロジェクトAを壊すことがすぐに明らかになります。この時点で、チームはこの変更について話し合い、プロジェクトAを新しいバージョンと互換性を持たせるか、プロジェクトBの代替ソリューションを探すことができます。

これにより、これらのチームがこの依存関係を共有する必要がなくなるわけではありません。ただ、問題を迅速かつ早期に強調するだけで、チームはリスクについて話し合い、ソリューションに合意できます。

コードの重複を防ぐ

複数のプロジェクトで作業する場合は、コードが重複しないようにすることが重要です。 コードの複製により、欠陥の発生の可能性、システムの変更に伴うコスト、コードベースの全体的な剛性が向上します。 重複を防ぐために、共通ロジックを複数のプロジェクトで使用できる再利用可能なライブラリにリファクタリングします。

このニーズに対応するために、すべてのチームが依存し、貢献できるコアプロジェクトの開発とメンテナンスをお勧めします。 その際は、このコアプロジェクトが個々のチームのプロジェクトに依存しないようにすることが重要です。これにより、コードの再利用を促進しながら、独立したデプロイを可能にします。

コアモジュールで一般的に使用されるコードの例を以下に示します。

  • 次のようなシステム全体の構成
    • OSGi 設定
    • サーブレットフィルター
    • ResourceResolverのマッピング
    • Sling変換サービスパイプライン
    • エラーハンドラー(またはACS AEM Commons Error Page Handler1を使用)
    • 権限を区別するキャッシュ用の認証サーブレット
  • ユーティリティクラス
  • コアビジネスロジック
  • サードパーティ統合ロジック
  • オーサリングUIオーバーレイ
  • カスタムウィジェットなど、オーサリングに必要なその他のカスタマイズ
  • ワークフローランチャー
  • サイト間で使用される共通のデザイン要素

モジュラー型プロジェクトアーキテクチャ

これにより、複数のチームがに依存し、同じコードセットを更新する必要がなくなるわけではありません。 コアプロジェクトを作成することで、チーム間で共有されるコードベースのサイズを小さくし、共有リソースを不要にすることはなくなりました。

このコアパッケージに加えた変更がシステムの機能を中断しないように、上級開発者または開発者チームが監視を維持することをお勧めします。 選択肢の1つは、このパッケージに対するすべての変更を管理する1つのチームを持つことです。もう1つは、これらのリソースによって確認され、マージされたプル要求をチームに送信させることです。 ガバナンスモデルは、チームが設計し、それに従って開発者が合意することが重要です。

展開範囲の管理(&n)

異なるチームが同じリポジトリにコードをデプロイするので、互いの変更が上書きされないことが重要です。 AEMは、コンテンツパッケージ(フィルター)をデプロイする際にこれを制御するメカニズムを備えています。 xmlファイルを作成します。 フィルター間に重複がないことが重要です。 xmlファイルを使用する場合、あるチームのデプロイメントで、他のチームの以前のデプロイメントが消去される可能性があります。 この点を説明するには、次のような適切に作成されたフィルタファイルと問題のあるフィルタファイルの例を参照してください。

/apps/my-companyと/apps/my-company/my-site

/etc/clientlibs/my-companyとの比較/etc/clientlibs/my-company/my-site

/etc/designs/my-companyとの比較/etc/designs/my-company/my-site

各チームが、作業中のサイトに対してフィルターファイルを明示的に設定する場合、各チームは、互いの変更を消去することなく、コンポーネント、クライアントライブラリ、サイトデザインを個別にデプロイできます。

これはグローバルシステムパスで、1つのサイトに固有ではないので、次のサーブレットをコアプロジェクトに含める必要があります。これは、ここで行った変更がチームに影響を与える可能性があるからです。

/apps/sling/servlet/errorhandler

オーバーレイ

オーバーレイは、標準のAEM機能を拡張または置き換えるために頻繁に使用されますが、オーバーレイを使用するとAEMアプリケーション全体に影響します(つまり、すべてのテナントで機能の変更が利用可能になります)。 テナントがオーバーレイの要件が異なる場合は、これはさらに複雑になります。 ビジネスグループが連携して、AEM管理コンソールの機能と外観に合意する必要が理想的です。

様々なビジネスユニット間でコンセンサスが得られない場合、単にオーバーレイを使用しないという解決策が考えられます。 代わりに、機能のカスタムコピーを作成し、テナントごとに異なるパスを使用して公開します。 これにより、各テナントのユーザーエクスペリエンスが完全に異なりますが、このアプローチにより、実装コストとその後のアップグレード作業のコストも増加します。

ワークフローランチャー

AEMでは、リポジトリで指定した変更がおこなわれた場合、ワークフローの実行を自動的にトリガーするために、ワークフローランチャーを使用します。 AEMには、例えば、新しいアセットや更新されたアセットに対してレンディションの生成とメタデータの抽出プロセスを実行するための、いくつかのランチャーが用意されています。 マルチテナント環境では、これらのランチャーをそのまま残すことができますが、テナントが異なるランチャーやワークフローモデルの要件を持つ場合、各テナントに対して個々のランチャーを作成して管理する必要が生じる可能性が高くなります。 他のテナントのコンテンツを変更せずに、これらのランチャーをテナントの更新で実行するように設定する必要があります。 これを簡単におこなうには、テナント固有の指定されたリポジトリパスにランチャーを適用します。

バニティー URL

AEMは、ページごとに設定できるバニティーURL機能を提供します。 マルチテナントシナリオでのこのアプローチの問題点は、AEMがこの方法で設定されたバニティーURL間での一意性を保証しないことです。 2人の異なるユーザーが異なるページに同じバニティパスを設定すると、予期しない動作が発生する可能性があります。 このため、Apache Dispatcherインスタンスではmod_rewriteルールを使用することをお勧めします。このルールでは、アウトバウンドのみのResource Resolverルールと連携して設定の中心点を設定できます。

コンポーネントグループ

複数のオーサリンググループ用のコンポーネントとテンプレートを開発する場合は、 componentGroupプロパティとallowedPathsプロパティを有効に使用することが重要です。 これらをサイトデザインと効果的に活用することで、ブランドAの作成者はサイト用に作成されたコンポーネントとテンプレートのみを表示し、ブランドBの作成者は自分のコンポーネントとテンプレートのみを表示できます。

テスト

優れたアーキテクチャとオープンな通信チャネルは、サイトの予期しない領域に欠陥が入り込むのを防ぐのに役立ちますが、これらのアプローチは無害です。 このため、実稼動環境にリリースする前に、プラットフォームにデプロイされているものを完全にテストすることが重要です。 これには、リリースサイクルに関するチーム間の調整が必要で、可能な限り多くの機能をカバーする自動テストスイートの必要性が強化されます。 さらに、1つのシステムが複数のチームで共有されるので、パフォーマンス、セキュリティ、負荷テストがこれまで以上に重要になります。

運用上の考慮事項

共有リソース

AEMは単一のJVM内で動作します。デプロイ済みのAEMアプリケーションは、AEMの通常実行時に既に使用されているリソースに加えて、本質的に相互にリソースを共有します。 JVMスペース自体には、スレッドの論理的な分離はなく、AEMで使用可能な有限リソース(メモリ、CPU、ディスクi/oなど)も共有されます。 リソースを消費するテナントは、必ず他のシステムテナントに影響を与えます。

パフォーマンス

AEMのベストプラクティスに従わない場合は、通常と見なされる範囲を超えてリソースを消費するアプリケーションを開発できます。 例えば、多くの重いワークフロー操作(DAMアセットの更新など)、多数のノードに対するMSMの変更時のプッシュ操作、または高価なJCRクエリを使用してコンテンツをリアルタイムにレンダリングするなどのトリガーがあります。 これらは、必ず他のテナントアプリケーションのパフォーマンスに影響を与えます。

ログ

AEMは、共有開発シナリオでアドビのメリットを得るために使用できる、堅牢なロガー設定用の標準インターフェイスを提供します。 ブランドごとに個別のロガーをパッケージ名で指定することで、ある程度のログ分離を実現できます。 レプリケーションや認証などのシステム全体の操作は引き続き一元的に記録されますが、非共有のカスタムコードは個別に記録でき、各ブランドの技術チームの監視とデバッグの労力を軽減できます。

バックアップと復元

JCRリポジトリの性質上、従来のバックアップは、個々のコンテンツパスではなく、リポジトリ全体で動作します。 したがって、テナントごとにバックアップを容易に分離することはできません。 逆に、バックアップから復元すると、システム上のすべてのテナントのコンテンツとリポジトリノードがロールバックされます。 VLTなどのツールを使用してターゲットコンテンツのバックアップを実行したり、別の環境でパッケージを構築して復元するコンテンツをチェリーで選択したりできますが、これらは可能です
アプローチは、設定やアプリケーションロジックを容易に含まず、管理に煩雑な場合があります。

セキュリティに関する考慮事項

ACL

もちろん、アクセス制御リスト(ACL)を使用して、ユーザーグループの作成と管理が必要なコンテンツパスに基づいて、コンテンツの表示、作成および削除にアクセスできるユーザーを制御できます。 ACLとグループの管理の困難さは、各テナントが他のテナントに関する知識をゼロにすることと、デプロイされたアプリケーションが共有リソースに依存するかどうかに重点が置かれていることに依存します。 ACL、ユーザー、グループの管理を効率的におこなうために、必要な管理を行う一元化されたグループを使用し、効率とセキュリティを向上させるために、これらのアクセス制御とプリンシパルが重複(または重複しない)するようにすることをお勧めします。

このページ