Adobe Commerce 2.4.8へのアップグレードで、実際に壊れるもの

Adobe Commerce 2.4.8のシステム要件ページ（新しいタブで開きます）は、どのバージョンで動かすべきかを教えてくれます。ただし、そのバージョン更新のどれが静かにスケジュールを一週間吹き飛ばすのかまでは書かれていません。後者は、実際にこの移行を何件かこなして初めて見えてくる部分です。2.4.6から移行するお客様のために実施してきたなかで分かったことを、ここにまとめます。

環境の全体像

内部的には、単なるバージョン番号以上の重みを持つものがいくつかあります。PHP 8.1のサポートは非推奨ではなく削除であり、段階的な猶予期間はありません。Elasticsearchも同じ話で、OpenSearchは選択肢のひとつではなく、唯一サポートされる検索エンジンになりました。主要なサードパーティライブラリも引き上げられ（Monologは3.x、PHPUnitは10、Composerは2.8以上へ）、さらにAdobeは新規インストールとアップグレードにおける既定のインデクサーモード（新しいタブで開きます）を「Update on Save」から「Update by Schedule」へ変更しました。通常運用中の負荷を下げ、性能上のボトルネックを減らすことが狙いです。

実際にスケジュールを食いつぶすのはどこか

上に並べたバージョン番号は、どれも難所ではありません。難所は一貫して、サードパーティのモジュールと拡張機能が壊れることです。

PHP 8.3と8.4は8.1より型の扱いが厳格で、Monolog 3.xは古いコードが想定していない形でインターフェイスを変更しました。PHP 8.1では単に雑なだけで済んでいたコードが、8.3や8.4では警告ではなく致命的エラーを投げ始めます。厳格な型付けに合わせて更新されないまま残っていた古い自社モジュールやマーケットプレイスの拡張機能は、当社が手がけたほぼすべてのアップグレードで、最大の時間を奪う要因でした。対処はたいてい、ベンダーのパッチを待つか、自分たちで拡張機能をフォークするか、最悪の場合はまるごと差し替えるかのいずれかになります。そして、そのどれに当たるのかは、実際に動かしてみるまでたいてい分かりません。

率直な助言をひとつ。ほかの作業に手をつける前に、すべてのサードパーティ拡張機能をPHP 8.3/8.4互換性の観点で棚卸ししてください。最後ではなく、最初にやることです。スケジュールを吹き飛ばす可能性がもっとも高い工程であり、しかも環境が整う前から着手できる工程でもあります。

4件のアップグレードで実際に起きたこと

これは机上のリスクではありません。当社はこれまで2.4.8へのアップグレードを4件実施しましたが、パターンは毎回同じでした。平均して、導入済み拡張機能の10件中9件が、ストアが再び正しく動くまでにパッチを必要としています。FirebearやAmastyといった、名の通った実績あるプロバイダーの拡張機能も、単一案件での不運ではなく、これらのプロジェクト全体で一貫して壊れました。ここは冷静に受け止めておく価値があります。評価が高く、活発に保守されているベンダーであっても、初日から互換性が保証されるわけではありません。しかも、問題はサードパーティのコードだけではありません。当社が自分たちで書き、自分たちで保守している社内向けのカスタム拡張機能も、2.4.8で動かすためにパッチが必要でした。このアップグレードで無傷でいられるコードは、誰のものであれ存在しません。

バージョン更新に潜むその他の落とし穴

移行の途中で不意を突かれる前に、知っておく価値のあるものが3つあります。

• MySQL 8.4の外部キー検証は、既定でより厳格になりました。 restrict_fk_on_non_standard_key が最初から有効になっており、MySQL 8.0では何も言われなかった非標準キー前提のカスタムテーブルや古いモジュールが壊れます。
• PHPの null 引数の扱いも厳しくなりました。 PHP 8.1では黙って通っていた、null を受け付けない内部関数の引数への null の受け渡しは、軽くても非推奨通知、重ければ型エラーになります。
• ElasticsearchからOpenSearchへの移行は設定フラグではありません。 実際のサーバー構築、インデックスマッピングの作業、そして本番投入前のテストが必要です。それを省くと、カタログ検索の不具合をQAではなくお客様から知らされることになります。

これからアップグレードを計画するなら

拡張機能の棚卸しから始め、そこに十分な工数を確保してください。10件中9件にパッチが必要というのが目安として妥当なら、「互換性の確認」は出発前の軽い点検ではなく、独立した工程です。固有のスケジュールを持ち、自分たちの手の届かないベンダー側の遅延というリスクも抱えています。

もうひとつ、早めに予定へ入れておくべきことがあります。Adobeのサポート予約は、実際にアップグレードを始める予定日の少なくとも7日前に取っておいてください。移行の途中で何かがおかしくなったとき、Adobeのサポートチームは本当に頼りになります。ただし、まさに必要になったその瞬間に予約枠を待つ羽目にはなりたくないはずです。

アップグレードそのものが終わっても、そこで完了と考えないでください。すべての機能とすべての連携を、影響がありそうなものだけでなく、新しい環境に対して再テストする必要があります。これだけ大きなバージョン跳躍は、下層の依存関係を広範に触ります。「デプロイはきれいに通ったのだから問題ない」と考えることが、不具合がQAではなく本番に流れ出る典型的な経路です。

当社は、まさにこうしたカスタムモジュールとレガシーなデータベース構造を抱えたエンタープライズのAdobe Commerceのお客様に対して、この移行を実施してきました。Adobe Commerceのアップグレードをご検討中でしたら、ご相談ください。

---

出典：Adobe Commerce システム要件（新しいタブで開きます）および2.4.8リリースノート（新しいタブで開きます）（Adobe Experience League）、ならびに当社が4件のアップグレードで得た知見。