AEM バージョンのアップデート

はじめに

AEM as a Cloud Service では、継続的統合および継続的配信（CI／CD）を使用して、プロジェクトが確実に最新の AEM バージョンで稼働できるようになりました。つまり、ユーザーに対するサービスが中断されることなく、実稼動インスタンスとステージングインスタンスが最新のAEMバージョンに更新されます。

メモ

実稼働環境へのアップデートに失敗した場合、Cloud Manager はステージング環境を自動的にロールバックします。これは、アップデート完了後、ステージング環境と実稼働環境の両方が必ず同じ AEM バージョンであるようにするために、自動的に行われます。

AEMバージョンのアップデートは、次の 2 種類があります。

  • AEM メンテナンスアップデート

    • 日単位でリリースされる可能性があります。
    • 主にメンテナンス目的で、最新のバグ修正やセキュリティアップデートなどを含みます。
    • 変更が定期的に適用されるので、影響は最小限に抑えられます。

  • 新機能アップデート

    • 予測可能な月次スケジュールでリリースされます。

AEM のアップデートは、複数のステップを含む集中的かつ完全に自動化された製品検証パイプラインを経て行われるため、実稼働環境にあるシステムへのサービスが中断されることはありません。ヘルスチェックは、アプリケーションのヘルスを監視するために使用されます。AEM as a Cloud Service のアップデート中にこれらのチェックが失敗した場合、リリースは続行されず、アップデートがこの予期しない動作を引き起こした原因をアドビが調査します。

製品テストと顧客機能テストは、製品のアップグレードや顧客コードのプッシュが実稼働システムを破壊するのを防ぎますが、AEM バージョンのアップデート中にも検証されます。

メモ

カスタムコードが実稼動環境ではなくステージングにプッシュされた場合、次回の AEM アップデートでは、それらの変更が削除され、実稼動環境に対して正常に行われた最後の顧客リリースの git タグが反映されます。したがって、ステージングでのみ使用可能なカスタムコードを再度デプロイする必要があります。

複合ノードストア

ノードのクラスターであるオーサリングインスタンスの場合も含め、ほとんどの場合、アップデートでダウンタイムは発生しません。Oak の複合ノードストア機能により、ローリングアップデートが可能です。

この機能を利用すると、AEM で複数のリポジトリを同時に参照できます。ローリングデプロイメントでは、新しい緑色の AEM バージョンには、古い青色の AEM バージョンとは異なる独自の /libs（TarMK ベースの不変リポジトリ）が含まれていますが、どちらも、/content、/conf、/etc などの領域を含んだ DocumentMK ベースの共有の可変リポジトリを参照しています。青色バージョンにも緑色バージョンにも独自の /libs のバージョがあるので、ローリングアップデート中に両方ともアクティブにでき、青色が完全に緑色に置き換わるまで両方ともトラフィックを処理します。

このページ