現在表示中:

コンテンツとアプリケーション - 移行かアップグレードか

主に考慮する点は、以下のいずれを実行するかです。

  • 配置済みの既存のインストールをアップグレードする。
  • 現在のシステムのコンテンツを新規インストールに移行する。

旧バージョンから最新バージョンに移行する場合、次の 2 つのオプションがあります。

  • パッケージマネージャーを使用して、旧システムから新システムにすべてのコンテンツおよびアプリケーションコードをエクスポートします。
  • 配置済みの旧システムをアップグレードします。ほとんどの場合、このオプションが推奨されます。

ターゲットメトリックの設定

メトリックは、Web サイトの品質の量的な測定を定義するのに使用されます。基本的には、パフォーマンスの達成目標の定義です。

多数のメトリックを定義できますが、その多くは、パフォーマンスと同時性に関する目標を定義するものです。特に、量的に示すことが難しく、感情によって評価される傾向にある次のような要素について定義します。

  • 「Web サイトの現在の速度が遅すぎる」 - 低速になるのはいつか。
  • 「同僚がログインすると、すべてが停止する」 - システムでサポートされる同時ユーザー数は何人か。
  • 「検索時にシステムが停止する」 - どのような種類の検索要求がシステムに影響を及ぼすか。
  • 「ファイルのダウンロードに長く時間がかかる」 - (標準ネットワーク条件下で)許容されるダウンロード時間はどれくらいか。

プロジェクト開始時のターゲットメトリックは、次のように定義されます。

  • 提供する Web サイトの予想されるサイズを示す
  • 達成目標の最低限の品質を示す
  • これらの要素を実際に測定する方法を定義する

ターゲットメトリックを定義する際は、常に以下のような注意が必要です。

  • 高く設定しすぎると、全く達成できない可能性がある
  • 低く設定しすぎると、変化がわからなくなる可能性がある
  • 繰り返し、一貫して測定できるようにする
  • 測定する要素同士でバランスを取る
  • テスト環境と関連のあるメトリックもあるが、その一部は実稼働環境の Web サイトでも測定可能および再現可能である必要があるので、実稼動のシナリオを反映させる必要がある
  • Web サイトに対する重要性に従ってメトリックの優先順位を付ける
  • メトリックを現実的に監視できるセットに制限する

これらのメトリックは、プロジェクトの開発時に必要に応じて更新したり、調整したりできます。プロジェクトが正常に実装されたら、これらのメトリックを使用してインストール環境を制御したり、継続中の操作に必要なサービスレベルの監視や維持を行ったりすることができます。

適切に使用すれば、これらのメトリックは便利なツールとなります。無責任に使用すると、時間を浪費する要因となります。常に測定対象、測定方法および測定理由について把握しておく必要があります。

注意:

このセクションでは、基本原則および考慮事項について説明します。インストール環境によって、実際の測定値は異なります。

すべての基礎となるプロジェクトデザイン

測定されるメトリックはすべて、何らかの形でプロジェクトのデザインの影響を受けます。逆に、多くの問題で最善の解決方法はデザインを変更することです。

したがって、デザインを決定する前にターゲットメトリックを定義する必要があります。デザインの決定前に定義した要素を基に、デザインを最適化できます。プロジェクトの開発後は、基本的なデザインの原則に変更を加えるのが困難になります。

Web サイトの構造を作成する際には、AEM Web サイトで推奨される構造に従います。以下の問題や原則を理解していることを確認してください。

  • Web サイトのコンテンツの構造
  • テンプレートおよびコンポーネントの動作
  • キャッシュの動作
  • コンテンツのパーソナライズによる影響
  • 検索機能の動作
  • コンパクトで、無駄のない HTML コードを作成するための CSS および関連するテクノロジーをどの程度使用できるか

デザインがガイドラインに従っていないと感じる場合、またはデザインの影響が不確かな場合は、プログラミングフェーズまたはコンテンツの入力を開始する前に、これらの問題を明確にします。

インフラストラクチャ

インフラストラクチャを定義または評価するには、以下のようなターゲット値を定義すると役に立ちます。

  • 1 日あたりの訪問者数(平均値および最大値)
  • 1 日あたりのヒット数(平均値および最大値)
  • 使用可能に設定されている Web ページの数
  • Web コンテンツのボリューム

使用時の状況、および Web サイトの戦略的意義に応じて、以下の項目がインフラストラクチャの評価や選択に役立ちます。

  • サーバーの数
  • AEM インスタンス(オーサーおよびパブリッシュ)の数

パフォーマンス

評価可能なパフォーマンスの要素がいくつかあります。

  • 個々のページの応答時間。以下を考慮します。
    • オーサー環境での応答時間
    • パブリッシュ環境での応答時間
  • 検索要求での応答時間

この節とパフォーマンスの最適化を併せて読むと、実際のパフォーマンス測定技術の詳細を把握できます。

個々のページの応答時間

Web サイトが訪問者の要求に応答するまでにどの程度の時間がかかるかは、非常に重要な問題です。

当然、応答時間は個々の要求によって異なりますが、平均的なターゲット時間の値を定義することはできます。この値が達成可能かつ維持可能な数値と証明されれば、Web サイトのパフォーマンスを監視したり、潜在的な問題の進行を示すのに使用できます。

オーサー環境とパブリッシュ環境でのターゲットの違い

オーサー環境とパブリッシュ環境では、対象ユーザーが異なるので、目標とする応答時間が異なります。

  • オーサー環境

    この環境は、コンテンツの入力および更新をおこなう作成者が使用する環境なので、以下のように設定することが必要です。

    • コンテンツページとそのページの個々の要素を更新する際に多数の要求を生成する少数のユーザーに対応する
    • コンテンツを Web サイトにできるだけ早く展開し、生産性を最大限に高める
  • パブリッシュ環境

    この環境にはユーザーが使用できるコンテンツが含まれ、次のような特徴があります。

    • 速度は重要であるが、多くの場合、オーサー環境より遅くなる
    • 多くの場合、以下のような追加のパフォーマンス強化メカニズムが適用される
      • コンテンツのキャッシュ
      • ロードバランシングの適用

ターゲット応答時間の設定

以上に基づき、どうすれば達成可能な(平均)応答時間を決定できるでしょうか。多くの場合は次のような経験によります。

  • 過去の Web サイトの経験
  • AEM の使用経験
  • 平均応答時間以上の値を持つ複雑なページの認識(可能であれば、これらのページを個別に最適化する必要がある)

ただし、(制御下にある状況では)以下のガイドラインを適用できます。

  • ページに対する要求の 70 %は、100 ms 未満で応答する必要があります。
  • ページに対する要求の 25 %は、100 ~ 300 ms 未満で応答する必要があります。
  • ページに対する要求の 4 %は、300 ~ 500 ms 未満で応答する必要があります。
  • ページに対する要求の 1 %は、500 ~ 1,000 ms 未満で応答する必要があります。
  • どのページについても、応答時間が 1 秒を超えてはいけません。
    以上の数値は、次の条件を前提としています。
    • パブリッシュ環境で測定される(オーサー環境や CFC のオーバーヘッドではない)
    • サーバー上で測定される(ネットワークオーバーヘッドを考慮しない)
    • キャッシュされない(AEM 出力キャッシュや Dispatcher キャッシュがない)
    • 多数の依存ファイル(HTML、JS、PDF など)を伴う複雑な要求のみ
    • 他のシステム負荷なし

いくつかのメカニズムを使用して応答時間を監視できます。

  • AEM request.log を使用した応答時間の監視

    パフォーマンス分析の開始点として最善なのが要求ログです。数ある情報の中でも、このログを使用すると個々の要求の応答時間を確認できます。詳しくは、パフォーマンスの最適化を参照してください。

  • HTML コメントを使用した応答時間の監視

    HTML コメントを使用すると、各ページのソース内に次のように応答時間の情報を含めることができます。

    </body> </html>v <-- サーバーによるこのページのレンダリング所要時間は 58 ミリ秒 --> 検索要求の応答時間

検索

検索要求は、以下の両方の点で、Web サイトに重大な影響を与える可能性があります。

  • 実際の検索の応答時間
    • 高速な検索機能が、Web サイトの品質目標です。
  • 全般的なパフォーマンスへの影響
    • 検索機能は、(巨大である可能性の高い)コンテンツのセクションや、特別に抽出されたインデックスをスキャンする必要があるので、この機能が最適化されていないと、システム全体のパフォーマンスに影響する可能性があります。

検索要求のターゲット設定についても、以下に応じて経験に基づいておこないます。

  • AEM の使用経験
  • 他の目標と比較した、検索が使用される回数の評価
  • 使用する永続性マネージャー
  • 使用する検索インデックス
  • 検索機能の複雑さ。検索用語が 1 語のみ許可される基本的な検索機能は、AND/OR/NOT を使用して複雑な検索ステートメントを作成できる高度な検索よりも速くなります。

このカスタマイズの計画および統合は、プロジェクトの最初の時点からおこなう必要があります。監視には次のメカニズムを使用することができます。

  • AEM request.log を使用した検索応答時間の監視

    この場合も、request.log を使用することで、検索要求の応答時間を監視できます。詳しくは、パフォーマンスの最適化を参照してください。

  • 検索応答時間の測定のプログラム化メカニズム

    検索要求に関して収集する情報、および検索要求のパフォーマンスをカスタマイズするには、プロジェクトのソースコードに情報収集を含めることをお勧めします。詳しくは、パフォーマンスの最適化を参照してください。

並行性

Web サイトは、オーサー環境とパブリッシュ環境の両方で多数のユーザー/訪問者に公開されます。ユーザーの数は通常、テスト時に使用したユーザー数より多くなりますが、同時に変動があり、予測が困難です。パフォーマンスへの悪影響を意識せずに作業できる同時ユーザー/訪問者数の平均値を考慮して、Web サイトをデザインする必要があります。この場合も request.log を使用して、同時実行をテストできます。詳しくは、パフォーマンスの最適化を参照してください。

同時ユーザー数のターゲットは、環境のタイプによって異なります。

  • オーサー環境

    • 通常、同時ユーザー数は正確に予測できます。(全員が同時にアクティブになることはないと考えられますが)作成者数の合計を把握することができます。
  • パブリッシュ環境

    • この環境では予測がより困難ですが、ターゲット値を選択する必要があります。この場合も、現在の Web サイトの経験と、新しい Web サイトの現実的な予測に基づいて選択します。
    • 特別なイベント(例えば非常に人気のあるコンテンツを新規公開する場合)では、予測を超えたり、(イベントのチケットの発売時に報道されると)処理能力を超えることもあります。

処理能力とボリューム

関連するメトリックについて説明する前に、いくつかの用語の大まかな定義を示します。

  • ボリューム

    • システムが処理および提供する出力の量です。
  • 処理能力

    • システムがボリュームを提供する能力です。
    • 以下の表に示すように、測定される処理能力とボリュームは各手順で異なります。最高のパフォーマンスを得るために、各手順で処理能力をボリュームと一致させ、処理能力とボリュームをすべての手順で共有するようにします。例えば、要求ごとにサーバーでナビゲーションを計算する代わりに、クライアントコンピューターで計算したり、キャッシュに配置したりできます。
  • 処理能力とボリューム

    対象/場所  処理能力  ボリューム
    クライアント ユーザーのコンピューターの計算能力。 ページレイアウトの複雑さ。
    ネットワーク ネットワーク帯域幅。 ページ(コード、画像など)のサイズ。
    Dispatcher キャッシュ Web サーバーのサーバーメモリ(メインメモリおよびハードドライブ)。 Web サーバー(メインメモリおよびハードドライブ)。キャッシュされたページの数とサイズ。
    出力キャッシュ Communiqué サーバーのサーバーメモリ(メインメモリおよびハードドライブ)。 出力キャッシュ内のページの数とサイズ、ページあたりの依存関係の数。Dispatcher キャッシュを使用すると、このボリュームが少なくなります。
    Web サーバー Web サーバーの計算能力。 要求の量。キャッシュを使用すると、このボリュームが少なくなります。
    テンプレート Web サーバーの計算能力。 テンプレートの複雑さ。
    リポジトリ リポジトリのパフォーマンス。 リポジトリから読み込まれたページの数。

その他のメトリック

以上の節では、定義される主なメトリックについて説明しました。

特定の要件によっては、単独で、または上記の分類を考慮に入れて、追加のメトリックを定義すると役に立つ場合があります。

ただし、Web サイトのすべての側面を測定および定義しようとせずに、正確な核となるメトリックを少数設定し、簡単にかつ確実に機能させることを推奨します。Web サイトは、その本来の性質により、ユーザーの手に渡るとすぐに変化し進化します。

受け入れテスト

受け入れテストは、以下を確認するためにおこないます。

  • プロジェクトが顧客の要求を満たしている

  • 顧客がプロジェクトを受け入れている

受け入れテストの計画および設計が早いほど、最終的なデプロイが容易になります。受け入れテストは、顧客および品質保証チームと共に定義する必要があります。

プロジェクトの最初の時点ですべての詳細を定義できないとしても、最初の定義について議論し、合意を得る必要があります。受け入れテストは、システムの基本的な要件(機能およびパフォーマンス)に基づいて行われると考えられます。

プロジェクトの編成

あらゆるプロジェクトと同様に、できるだけ早い時期に基本原則を確立することが重要です。以下のような項目が含まれます。

  • 役割

    役割は明確に定義し、プロジェクトに関わる全員に知らせる必要があります。また、以下の役割を特に強調して知らせることをお勧めします。

    • 意志決定者
    • 連絡窓口
  • 責務

    • 各役割に対して、プロジェクトに関連した責務を明確に定義すると、混乱を防ぐことができます。
  • 関与

    できるだけ早く関係者を関与させることで、プロジェクトのステークホルダーになるように働きかけ、成功に向けての意欲を向上させることができます。

    • 顧客側では、毎日システムを使用する必要のある作成者が含まれます。
    • 自社のプロジェクトチーム内では、品質保証の担当者も含まれます。顧客の要件をより理解することで、より適切にテストを計画できます。
  • 伝達経路

    • この経路を過度に形式化する必要はありませんが、特定の定義によって、主要なメンバーが常に情報を把握し、最新情報に精通しているようにする必要があります。外部の組織とのコミュニケーションには、一定の注意を払う必要があります。
  • プロセス

    定義するプロセスは、個々のプロジェクトによって異なります。この場合も、プロセスを簡潔にするために、以下を考慮します。

    • 設計代理店やサードパーティソフトウェア供給業者など、すべてのサードパーティとやり取りするためのプロセス(および伝達経路)を定義します。
    • 通常、顧客はプロジェクト管理やレポートに関する独自の手順やツールを所有しています。
  • 追跡ツール

    バグやタスクなど、プロジェクトに関する情報を追跡できる多くのツールがあります。詳しくは、使用する可能性があるツールの概要を参照してください。

    • ここでの主な注意点は、情報の 1 つのコピーのみを保持し、情報(および使用しているツールへのアクセス)を共有することです。これにより保守が容易になり、不一致を避けることができます。
  • 適用範囲

    次のような様々なレベルで、プロジェクトの対象を明確に定義します。

    • 個々のリリース(反復的なリリースプロセスが使用されている場合。配信されるのが顧客か社内のテストチームかは関係しない)。
    • AEM プロジェクト。
    • サードパーティのソフトウェア、そのソフトウェアがテストに及ぼす影響、組織的な問題、その他多くのことを含む、プロジェクト全体。
    • プロジェクトの範囲内にないものを示すことが役に立つ場合もあります。混乱や誤認を回避できますが、基本的な問題での使用に限定されます。
  • レポート

    レポートする情報、形式、頻度およびレポート先を明確に定義します。

  • 用語

    • 使用される略語/顧客固有の用語を定義します。
  • 仮定

    • あらゆる想定事項を定義します。

この情報は、プロジェクトハンドブック内で定義できます。また、Wiki の使用も、継続的な変化に効率よく対応するために役立ちます。 どの場所で定義する場合も、重要な点は以下のとおりです。

  • 情報を定義し、保持する。
  • 情報を、それに関連のあるメンバー全員に明確に伝える。標準的なプロジェクト管理方法ではありますが、役割定義が明確であるかや、伝達が良好であるかによって、プロジェクトの成否が左右されるということを繰り返し肝に銘じてください。
  • バグ追跡や問題追跡など、追跡される情報は、1 つのバージョンだけを保持する。

プロジェクトフェーズ

以下の節に、AEM プロジェクトを初めて実装する際に使用されるマイルストーンおよびフェーズの概要の例を示します。実際に作業対象として選択するモデルは、プロジェクトの概念、予算、タイムラインなどによって異なります。

注意:

時間単位は理論上のものです。

概要

ここでは、標準 AEM プロジェクトの新規実装(またはバージョン)に関する概要を紹介します。多くの場合、これらのプロジェクトにはデザインのリニューアルも含まれます。

メインフェーズは次のとおりです。

  • セールスプロセスから引き継がれます。
  • 顧客アプリケーションを実装します(開発)。
  • 顧客サイトにインフラストラクチャ(および関連プロセス)をインストールして設定します(インフラストラクチャ)。
  • コンテンツを作成(または移行)します(コンテンツ)。
  • 運営に引き継ぎます(メンテナンス/サポート)。
  • リリースをフォローアップします。

注意:

アプリケーション、インフラストラクチャ、およびコンテンツを別個の(サブ)プロジェクトとして扱うことをお勧めします。

メインフェーズの詳細

次の図では、3 つのメインフェーズについて詳しく説明し、フェーズ別にいくつかの重要点を挙げています。

注意:

実稼働環境の実際の条件で調整、最適化およびユーザートレーニングができるように、プロジェクト開始をソフトローンチ(不完全な可用性、複数の繰り返し)とハードローンチ(完全な可用性 - ライブ)に分割します。

注意:

プロジェクトのライフサイクルで、実行(または評価)する必要がある可能性のあるタスクの例について詳しくは、タスクの例を参照してください。これらの表はクイックリファレンスとして示されており、たたき台として使用できますが、可能なタスクをすべて包括的に網羅した完全なリストではありません。実際のタスクのリストは、各プロジェクトによって異なります。

各カテゴリについての留意事項を次に示します。

  • 開発

    • 基本アーキテクチャを最初に定義します。
    • 開発にはいくつかの繰り返し(スプリント)を使用します。
      • 最初のスプリントは最初の全開発サイクルに相当します。
      • 最初のスプリントの結果として、テスト環境への最初の開発が行われます。
      • すべてのスプリントが実行可能な結果を持ちます。
      • スプリントごとに顧客の承認(最低限の構造テストとフィードバック)が取得されます。
    • プロジェクトの進行中に利用可能な AEM バージョンが最終的に更新されるように計画します。
    • スプリント中にテストおよび最適化が行われるように計画します。
    • 安定化および最適化フェーズを計画します。
    • 今後のリリース対象として計画している項目のログを作成します。
    • パートナーの関与と引き継ぎを計画します。
  • インフラストラクチャ

    • 基本アーキテクチャを最初に定義します。
      • パフォーマンス要件を定義します。
      • パフォーマンス目標を定義します(つまり、期待事項を明確に定義します)。
      • サイジングを含め、ハードウェアとインフラストラクチャのアーキテクチャを定義します。
      • デプロイメントを定義します。
    • 最初のスプリントと次の初期設定の準備にいくつかの繰り返しを使用します。
      • 開発環境
      • 開発プロセス
      • テスト環境
      • 開発プロセス(設定管理を含む)
    • いくつかの負荷テストを計画します。
    • スプリント中にテストおよび最適化が行われるように計画します。
    • 安定化および最適化フェーズを計画します。
    • 実稼働環境にできるだけ早期にデプロイします(運営チームにシステムのセットアップ経験を積ませます)。
    • 指定されたユーザーと定義済み役割をできるだけ早期に使用します。
    • トレーニング(管理者向けトレーニングなど)を計画します。
    • 運営への引き継ぎを計画します。
  • コンテンツ

    • 基本アーキテクチャとは次のようなものです。
      • コンテンツ階層を稼働させます。
      • コンテンツの概念を定義するのに役立ちます。
      • MSM の使用方法とレイアウトを定義します。
      • 役割、グループ、ワークフロー、および権限を定義します。
    • オフラインページの作成が有益かどうかを検討します。
    • 初期ページおよびコンテンツの早期作成を計画します(テストおよびフィードバック用)。
    • 既存のコンテンツの移行を計画します。
    • リファクタリング後の「スプリント中移行」を計画します。
    • 「コンテンツバーンダウン」(実稼働コンテンツのサイトマップ)を計画します。

時間と労力の見積もり

作成されたタスクリストに従って、(高度な)タスク定義にかかる時間および労力の初回見積もりを作成できます。この見積もりには、実行者(顧客またはパートナー)、実行内容および実行時間を示す必要があります。

以下のリストに、労力の標準的な概算および相関関係と、その結果のコストを示します。

 フェーズ 労力 
開発 コンポーネントノードごとに 2 ~ 4 時間の概算見積もりを使用すると、すべての開発要件を満たします。注意:これらは初期見積もりにのみ使用できます。経験豊富な AEM 開発者は詳細な分析をおこなう必要があります。
開発者によるテスト 開発 15 %
フォローアップ 開発 10 %
文書化 開発 15 %
JavaDoc 文書化 開発 10 %
バグ修正 開発 15 %
プロジェクト管理 進行中のプロジェクトの管理および統制にかかるプロジェクトコストの 20 %

その後の詳細な計画で、使用可能なリソースや必要なリソースを、納期やコストに関連付けることができます。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー