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

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

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

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

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

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

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

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

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

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