9 分
h1
style
article-header-section

この記事では、Adobe Developer App Builder を通じてAdobe Commerce の拡張性を再考し、カスタム PHP の大部分をよりスケーラブルなアーキテクチャに置き換えることで、実際の本番環境での長期的な成長を目的にデザインされた、スケーラビリティ、安定性、保守性を向上させる方法について説明します。

概要

長年にわたり、PHP の拡張性は、Adobe Commerce のカスタマイズの基盤となってきました。ただし、クラウドネイティブアーキテクチャが成熟するにつれ、より優れた代替手段も提供されるようになります。ヨーロッパの大手モビリティおよび金融サービスプロバイダー向けの最近の実装では、従来の Adobe Commerce モジュール開発の大部分を、アドビのクラウドネイティブ拡張プラットフォームである App Builder に置き換えました。これは、ランタイムアクション（サーバーレス関数）、イベント、API を活用することで、よりスケーラブルで保守性の高いソリューションを実現しました。この記事では、この決定の背後にある理由、アーキテクチャ構造、そこから得られた知見について詳しく説明します。

概要

Adobe Commerce での API ファーストのアプローチは、コアとなる Adobe Commerce プラットフォームの外部でクラウドネイティブアプリとして実行した場合に最もメリットのある機能を評価し、これらの機能を最初に移行することで、段階的に導入できます。

このプロセスにより、次のような明確な成果が得られました。

このバランスにより、ネイティブロジックとチェックアウト関連のロジックを Commerce に近接させながら、統合、検証、バックグラウンド処理、オーケストレーションを、スケーラビリティ、分離性、導入の柔軟性が最大限に発揮される App Builder にオフロードできました。

結果として得られたアーキテクチャ（App Builder 拡張機能のみを示す以下の図を参照）は、このハイブリッドアプローチを反映しています。Adobe Commerce はトランザクションのコアであり、App Builder は統合と自動処理の基盤として機能します。この戦略では、イベント駆動型フローと API メッシュ（アドビの API オーケストレーションサービス）を通じて、ID（SSO）、PIM、ERP、サードパーティサービス、カスタムビジネスロジックを接続します。

デフォルトの代替

アーキテクチャウォークスルー：ハイブリッドモデルの仕組み

ソリューションの中核を成すのは Adobe Commerce で、カタログ、価格設定、買い物かご、チェックアウト、注文処理など、その得意とする機能を担っています。Commerce ランタイム内での不要なカスタマイズを回避して、トランザクションコアをクリーンで安定した状態に維持しました。

このコアに関するすべての要素（ID、データ検証、可用性ロジック、バックグラウンド処理、サードパーティ統合）は、App Builder と Adobe API メッシュを通じて処理されます。

買い物客のエクスペリエンスは、新しい Commerce ストアフロント（Edge Delivery Services を活用）に基づいて作成されています。

1. エントリレイヤー：CDN、Commerce ストアフロント、ID

通常の web サイト訪問者からのすべてのトラフィックは、最初に CDN + Edge Delivery Service に到達します。これにより、リクエストがバックエンドシステムに到達する前に、最適なパフォーマンス、セキュリティ、グローバル配信が確保されます。

認証は Keycloak SSO を通じて処理され、次を介して統合されます。

このアプローチの主なメリット

デフォルトの代替

2. オーケストレーションレイヤー：Adobe API メッシュ

Adobe API メッシュは、統合アーキテクチャのコアを成し、プラットフォームに関与するすべてのビジネスシステム間の一元的なオーケストレーションと通信のハブとして機能します。

EDS フロントエンドや Adobe Commerce がこれらの各システムと直接ポイントツーポイント統合を確立する代わりに、すべての通信は API メッシュを通じてルーティングされます。

Adobe API メッシュを使用する主なメリット

3. ストアフロントと SSO レイヤーで使用される App Builder サービス

これらのサービスは、Adobe Commerce ではなく、Commerce ストアフロントと SSO レイヤーにより直接使用されます。これにより、重要なビジネスロジックを Commerce ランタイムから独立して動作できます。

お客様データレシーバー（SSO → App Builder）

このサービスは、ストアフロントや Commerce のパフォーマンスに影響を与えることなく、SSO レイヤーからお客様データを受信および同期します。App Builder を使用すると、安全な処理、非同期スケーラビリティが確保され、Adobe Commerce でのデプロイメント依存関係がなくなります。

顧客ごとの製品の可用性（ストアフロント → App Builder → PIM）

製品の可用性は、リクエストが Commerce に到達する前に、顧客のコンテキストと PIM データに基づいてリアルタイムに解決されます。App Builder を使用すると、このロジックを個別に拡張でき、Commerce を外部依存関係による大きな負荷から保護します。

デフォルトの代替

会社データ検証（Dun & Bradstreet）（ストアフロント → App Builder → サードパーティ）

検証は、App Builder + API メッシュを介してストアフロントから直接トリガーされ、サードパーティサービスを使用して検証されます。これにより、外部サービスの待ち時間やエラーが Adobe Commerce から完全に分離されます。

デフォルトの代替

外部 ID リダイレクトエンジン（ストアフロント → App Builder）

外部システムからのインバウンドトラフィックは、ストアフロントに入る前に App Builder を介して処理およびマッピングされます。これにより、安全なトラフィック正規化、柔軟なリダイレクトルール、Commerce コアへのリスク回避が実現します。

4. Commerce ストアフロントの事前レンダリング：UX を損なうことなく SEO を実現

AEM Commerce ストアフロントは、ブラウザーで製品データを読み込む際に JavaScript を多用する、最新のフロントエンド駆動型アプリケーションです。これにより、優れたユーザーエクスペリエンスを実現する一方で、SPA 特有の課題も生じています。

サーチエンジンのクローラーやブラウザーレスシステムは、JavaScript を安定して実行できないので、多くの場合、ほとんど空の HTML を受信します。

この課題を解決するのに、App Builder に基づいて作成された公式 Adobe ソリューションである AEM Commerce 事前レンダリングを実装しました。

アーキテクチャでの事前レンダリングの仕組み

App Builder 事前レンダリングアプリケーション：

次に、Commerce ストアフロントは、このストレージをオーバーレイソースとして使用するように設定されます。次のいずれかの場合：

JavaScript を実行することなく、実際の製品データを含む、完全にレンダリングされた HTML 応答を即座に受信します。

同時に：

App Builder がここで中核的な推進力となる理由

App Builder は、事前レンダリングプロセス全体の中央制御の基盤となります。次の内容を定義できます。

これらすべては、App Builder の設定を少し変更するだけで調整でき、メインのストアフロントや Adobe Commerce のダウンタイムは発生しません。

また、アドビでは、事前レンダリング App Builder アプリケーションのスターターキットも提供しています。これにより、非常に短期間でソリューションを本番環境に対応させ、SEO 効果を即座に向上させることができました。

このアプローチの主なメリット

5. 注文と ERP の同期：デザインによる非同期

チェックアウトと注文処理は、Adobe Commerce 内で完全に処理されるので、データの整合性とトランザクションの一貫性が維持されます。注文を作成すると、書き出しプロセスは、App Builder に基づいて作成された専用のスケジュール済み注文エクスポーターにより引き継がれます。

このエクスポーターは、ストアフロントと Commerce リクエストのライフサイクルの外部で、注文を ERP に非同期的に同期します。

このアプローチの主なメリット

デフォルトの代替

App Builder に完全に移行しない理由

アーキテクチャに関する最も初期および最も重要な決定の 1 つは、App Builder を PHP モジュールの完全な代替として扱わないことと、「これまで常に行ってきたから」という理由ですべてを PHP にデフォルト設定しないことでした。

代わりに、すべての要件に対して、次のシンプルなフィルタリングを行います。

このロジックを App Builder に移行すると、回復性と拡張性は向上するか？
アップグレードに関連付けられたメンテナンスコストは削減されますか？

PHP に残ったもの（30％）

PHP のカスタマイズは、本当に属する次の場所にのみ残しました。

これらの領域では、データベースへの直接アクセス、Commerce 内部との緊密な結合、リクエストライフサイクル制御が依然として完全に正当化されます。

App Builder に移行したもの（70％）

次のその他すべては移行しました。

これらはすべて、PHP モジュールが過去に問題を抱えていた領域です。

得られた主なメリット

ビジネスロジックと統合ロジックの約 70％を App Builder に移行することで、プラットフォームの作成、デプロイ、運用方法を根本的に変えました。その影響は、アーキテクチャの品質だけでなく、配信速度、システムの安定性、長期的なコスト制御にも顕著に表れました。

独立したデプロイメント

App Builder が統合とビジネスワークフローの大部分を処理するので、ほとんどの変更で Adobe Commerce の完全な再デプロイメントは不要になりました。統合の更新、検証、バックグラウンドプロセスは独立してデプロイできるので、次の項目が大幅に削減されます。

これだけでも、日常業務における最大の生産性向上の 1 つになりました。

最も重要な部分でのスケーラビリティ向上

以前は、次の状況においてトラフィック急増が発生していました。

これらが、Commerce のパフォーマンスに直接影響を与えていました。

現在、これらのワークロードは App Builder 内で独立してスケーリングされます。これにより、次の内容を実現できます。

真のエラー分離

最も重要な改善点の 1 つは、エラー抑制です。サードパーティシステムで待ち時間、パフォーマンス低下、停止が発生した場合：

これにより、以前はストアフロントの一部または全体のダウンタイムにつながっていた一連のインシデントシナリオ全体が効果的に排除されました。

よりクリーンなコード所有権と明確な責任

プラットフォームのアーキテクチャ境界が明確になりました。

この分離の結果：

今後を見据えたデザイン

このハイブリッドアーキテクチャは、アドビの長期的な SaaS、API ファースト、構成可能なコマース戦略と完全に整合しています。ほとんどのカスタムロジックを外部化した場合：

今日の要件を解決するだけでなく、Adobe Commerce の今後に向けて構造的に対応できるプラットフォームを作成しました。

style
article-content-section