よくある質問

以下は、Adobe Experience Manager Guidesによる公開ワークフロー、スケーリング動作、インフラストラクチャパフォーマンスの管理方法に関する詳細なインサイトを提供する、よくある質問への回答のリストです。 Experience Manager Guidesを使用した大規模公開向けの大規模法人ユーザー、管理者およびドキュメントチームを対象としています。 この図は、Experience Manager Guides公開アーキテクチャの全体的なワークフローを示しています。

Experience Manager Guidesは、1 日にいくつの公開リクエストを実行できますか?

Experience Manager Guidesが 1 日に処理できる公開リクエストの数は、コンテンツのサイズとタイプによって異なります。 設定に従って、システムではプロセッサーコアごとに 1 つの公開ジョブが許可されます。 現在の設定では、20 個の公開ジョブを並行して実行できます(2 個のポッド×それぞれ 10 コア)。

実稼動環境が自動スケールされると、ポッドが 4 までスケールされると、この数が 40 個の同時パブリッシュジョブに増える可能性があります。

キューに入る前に同時に実行できる公開リクエストの数

  • 最小(デフォルト):20 個の公開ジョブ(2 つのポッド)
  • 最大(拡大/縮小):40 個の公開ジョブ(4 つのポッド)

この数は、サーバー全体の負荷によって異なる場合があります。 他のバックグラウンド Sling ジョブが実行中の場合、それらは処理コアを共有するので、同時実行性が 20 未満に低下する可能性があります。

複数のパブリッシングリクエストを実行すると、.dita ファイルの編集など、他のアプリケーション機能に影響はありますか?

パフォーマンスに何らかの影響が生じる場合がありますが、通常は最小限です。 ほとんどの処理は IO ランタイム(サーバーレス公開サービス)で行われますが、AEM インスタンスは依存関係の生成とステータスポーリングのために主に I/O 操作を実行します。 その結果、AEM内でのCPUの使用率は引き続き低く、オーサリング/編集のエクスペリエンスにはほとんど影響しません。

Experience Manager Guidesでは、500 KB を超える SVG や.dita ファイルなどの大きなファイルやグラフィックをどのように管理しますか?

大きなファイルはすべて圧縮され、JCR (Java コンテンツリポジトリ)に保存されます。 IO ランタイムは、公開を開始する前に完全な zip パッケージを取得します。 複数の大きなファイル(例:それぞれ 500 KB)を処理する場合でも、パッケージ化と並列 I/O 処理が最適化されているので、ダウンロードや転送の速度に大きな影響はありません。

Experience Manager Guidesで使用される公開インフラストラクチャおよび設定とは何ですか?

Experience Manager Guidesでは、公開にコンテナ化されたサーバーレスのマイクロサービスを使用します。 パブリッシュサービスの新しいバージョンはそれぞれ、Docker イメージとしてリリースされ、Adobe Cloud Environment に自動的にデプロイされます。 この設計により、次のことが保証されます。

  • お客様専用のインフラストラクチャ保守は不要
  • パブリッシングの要求に対応するための自動スケーリング
  • 迅速なアップデートと最小限のダウンタイム

オーバーロードが原因でパブリッシュキューまたは管理システムがクラッシュした場合、他のAEMの機能は影響を受けますか?

いいえ、Experience Manager Guidesは、フォールトトレラントアーキテクチャで構築されています。 公開キューが過負荷になった場合、リクエストは自動的に再試行され、追加の負荷を処理するために自動スケールがポッドに送られます。 特定のしきい値を超えると、安定性を維持するために負荷スロットルが適用されます。 その他のアプリケーション領域(オーサリング、レビュー、アセット管理)には影響しません。

Experience Manager Guidesの負荷が高い状態を特定できるモニタリングツールやログアクセスはありますか(Jenkins のモニタリングと同様)。

いいえ。現在、内部監視ツールへのアクセス権がありません。 Adobeの社内チームの場合、監視は次を使用して行うことができます。

  • ログおよびエラートラッキング用の Splunk
  • ポッドレベルのパフォーマンスとスケーリング動作を確認するための Kubernetes (K8s) CLI

パフォーマンスの低下に気づいた場合は、Adobe サポートに問い合わせて調査および分析を開始してください。

公開リクエストをマイクロサービスにディスパッチする前にどのような処理が行われますか。

マップコンソールの「プリセット」タブから公開リクエストをトリガーすると、次の手順が行われます。

  1. システムはリクエストを受け入れ、ベースラインプリセットと条件付きプリセットを検証します。
  2. AEMは、すべての適格な DITA アセットと依存関係を集計します。
  3. これらのアセットは、zip パッケージにバンドルされています。
  4. サーバーレス公開サービスは、Docker コンテナを起動し、アセットをダウンロードして、公開処理を実行し、生成された出力アーティファクトをExperience Manager Guidesに戻します。

このワークフローにより、信頼性が高く、分離されたスケーラブルなパブリッシングの実行が保証されます。

マイクロサービスコンテナでのマップの公開を開始するまでに、マップにはどのくらいの時間がかかりますか?また、この時間を定義する要因は何ですか?

公開リクエストは通常、マイクロサービスコンテナにディスパッチされるまで数分かかります。 この最初の時間は、AEM内の依存関係の集計に使用されます。

サーバーレス公開サービスでリクエストを受け取った後の合計公開時間は、次の条件によって異なります。

  • DITA マップのサイズ
  • トピックとメディアアセットの数
  • 条件付きコンテンツとフォーマットルールの複雑さ

大きいマップや複雑なマップは、パブリッシュに比例して時間がかかる場合があります。

Experience Manager Guidesは、公開リクエストを(先着順ではなく)キュー内で優先順位付けできますか?

現在、すべての公開ジョブは同等に扱われ、先着順(FCFS)モデルに従います。 現在利用可能な優先順位付けメカニズムはありません。

ただし、今後のリリースでは、キュー最適化の強化の一環として、優先順位付けロジック(ジョブのサイズやビジネスの重要性に基づくなど)を導入できる可能性があります。

Experience Manager Guidesはリクエストを公開するための自動スケーリングをどのように処理しますか?

Experience Manager Guides パブリッシュインフラストラクチャは、負荷に基づく自動スケーリングをサポートしています。 公開需要が増加した場合:

  • 追加のポッド(コンテナ)は自動的に実行されます。
  • 各ポッドは、複数の公開ジョブを並行して処理できます。
  • 負荷が軽減されると、ポッドはスケールダウンして、コストとパフォーマンスを最適化します。

これにより、高可用性、一貫性のあるパフォーマンス、ピーク負荷時の最小キュー時間が確保されます。

公開ジョブが失敗またはタイムアウトした場合

一時的な問題(ネットワークの中断、サービスのタイムアウトなど)が原因で公開リクエストが失敗した場合:

  • これは、公開サービスで設定された再試行ロジックに基づいて自動的に再試行されます。
  • ログとエラーメッセージは、診断目的でバックエンドで取り込まれます。
  • 失敗ステータスを表示し、必要に応じて、マップコンソールから手動で公開を再試行できます。

パブリッシュジョブの進行状況を監視またはトラッキングできますか?

はい。Experience Manager Guidesでは、マップコンソールの「プリセット」タブで、次のようなリアルタイムのジョブステータスのアップデートが提供されます。

  • ジョブの開始と完了時間
  • 現在のステージ(結果の圧縮、ディスパッチ、公開、アップロード)
  • エラー通知(ある場合)

これにより、ジョブの進行状況を理解し、潜在的な遅延を特定できます。

Experience Manager Guidesの公開パフォーマンスを向上させるベストプラクティスには何がありますか。

最適な公開速度を確保するには、次のベストプラクティスに従います。

  • 不必要に大きな画像ファイルや参照されていないトピックを避ける
  • ベースラインを使用した公開範囲の制限
  • DITA マップの階層を管理しやすく、適切に構成する
  • ピーク以外の時間帯に大量の公開をスケジュールする
  • 条件付きフィルターを効果的に使用して、処理負荷を軽減します
recommendation-more-help
11125c99-e1a1-4369-b5d7-fb3098b9b178