Cloud Publishing Microservice のアーキテクチャとパフォーマンス分析

この記事では、新しい Cloud Publishing マイクロサービスのアーキテクチャとパフォーマンス番号に関するインサイトを共有します。

クラウド上の既存の公開ワークフローに関する問題

DITA パブリッシングは、使用可能なシステムメモリーとCPUに依存する、リソースを大量に消費するプロセスです。 公開者が多数のトピックを含む大きなマップを公開する場合や、複数の同時公開リクエストがトリガーされる場合、これらのリソースの必要性はますます高まります。

新しいサービスを使用していない場合、すべての公開は同じAEM Cloud Server を実行している同じ Kubernetes （k8）ポッドで行われます。 一般的な k8 ポッドには、使用できるメモリとCPUの量に制限があります。 AEM Guides ユーザーが大きなワークロードや並列ワークロードを公開している場合、この制限は急速に超過する可能性があります。 設定された制限を超えてリソースを使用しようとすると、AEM Cloud インスタンス自体に重大な影響を与える可能性があるポッドが、K8 から再起動されます。

このリソースの制約が、クラウド上で複数の同時大規模な公開ワークロードを実行できる専用サービスを考え出す主な動機でした。

クラウドでの公開ワークフローについて詳しくは、​ 公開ワークフローとスケーラビリティに関する FAQ を参照してください。

新しいアーキテクチャの概要

このサービスは、App Builder、IO イベント、IMS などのAdobeの最先端のクラウドソリューションを使用して、サーバーレスの製品を作成しています。 これらのサービスは、それ自体が Kubernetes や Docker などの広く受け入れられている業界標準に基づいています。

新しいパブリッシュマイクロサービスへの各リクエストは、一度に 1 つのパブリッシュリクエストのみを実行する分離された Docker コンテナで実行されます。 新しい公開リクエストを受信した場合に備えて、複数の新しいコンテナが自動的に作成されます。 リクエストごとに 1 つのこのコンテナ設定により、マイクロサービスは、セキュリティリスクを招くことなく、顧客に最高のパフォーマンスを提供できます。 これらのコンテナは、公開が終了すると破棄され、未使用のリソースが解放されます。

これらすべての通信は、JWT ベースの認証および承認を使用したAdobe IMSによって保護され、HTTPS 経由で実行されます。

{width="600"}

パフォーマンス分析

ここでは、マイクロサービスのパフォーマンス番号を示します。 古いクラウドアーキテクチャには同時公開や非常に大きなマップの公開に問題があったため、マイクロサービスのパフォーマンスとAEM Guides オンプレミス製品のパフォーマンスを比較します。

オンプレミスで大きなマップを公開している場合は、Java ヒープパラメーターの調整が必要になる場合や、メモリ不足のエラーが発生する場合があります。 クラウドでは、マイクロサービスは既にプロファイルされており、最適な Java ヒープやその他の設定が標準で用意されています。

1 つの公開をクラウドとオンプレミスで実行中

クラウドとオンプレミスでの複数の公開の実行

その他のメリット

マイクロサービスに送信する正しい公開コンテンツを取得するには、各公開リクエストの一部をAEM インスタンスで実行する必要があります。 新しいクラウドアーキテクチャでは、古いアーキテクチャと同様に、AEM ワークフローの代わりにAEM ジョブを使用します。 この変更により、AEM Guides管理者は、他のAEM ジョブやワークフロー設定に影響を与えることなく、クラウド公開キューを個別に設定できます。

新しいパブリッシュマイクロサービスの設定方法について詳しくは、​ マイクロサービスの設定 ​ を参照してください。