Adobe Commerce / Magento Open Sourceのフロントエンドの課題をどうするか〜その4
今回は「Adobe Commerce / Magento Open Sourceのフロントエンドの課題をどうするか〜その3」の最後で予告した通り、「ヘッドレス構成での課題」について解説していきたいと思います。
ヘッドレス構成の課題とは
前回の記事の最後で、ヘッドレス構成の課題を以下の通りあげました。
- APIアクセスが引き起こす負荷
- 決済連携
- 開発・維持コスト
今回はこれらの課題について解説していきたいと思います。
APIアクセスが引き起こす負荷
Adobe Commerce / Magento Open Sourceの場合、VarnishまたはFastlyをアプリケーションサーバーの前に設置することが多くなります。
もちろんほかのCDNサービスなどを利用いただいても構わないのですが、ここではVarnishとFastlyに絞って解説をしていきます。
（ビルトインのフルページキャッシュ機能も大枠ではVarnishやFastlyに準じます）
キャッシュサーバーがキャッシュするリクエストは限定されている
VarnishとFastlyが使用する設定ファイルはVCLと呼ばれる独特の言語で書かれています。
この設定ファイルの中には、VarnishとFastlyが各HTTPメソッドに対してどのような振る舞いをするかが定義されています。
例えばVarnish用の場合は、以下のように書かれています。
if (req.method != "GET" &&req.method != "HEAD" &&req.method != "PUT" &&req.method != "POST" &&req.method != "TRACE" &&req.method != "OPTIONS" &&req.method != "DELETE") {/* Non-RFC2616 or CONNECT which is weird. */return (pipe);}# We only deal with GET and HEAD by defaultif (req.method != "GET" && req.method != "HEAD") {return (pass);}
この定義内容では、該当しないHTTPメソッドのリクエストを受け付けた場合に、アプリケーションサーバーにリクエストをpipeまたはpassすることを意味しています。
どちらもアプリケーションサーバーにリクエストを通す点は同じですが、
- pipeはリクエストとレスポンスを素通しする
- passはvcl_backend_fetchからvcl_deliverを通るが結果をキャッシュしない
という違いがあります。
このあたりの状態遷移についてはVarnish Softwareの公式サイトの図がわかりやすいと思います。
いずれにしてもVCLの定義上はGETとHEAD以外のHTTPリクエストはキャッシュが利用できないため、すべてのリクエストがアプリケーションサーバーへなだれ込んできます。
Adobeの公式ドキュメントでも以下のように触れられていますが、GETリクエストのみがキャッシュ可能です。
Only queries submitted with an HTTP GET operation can be cached. POST queries cannot be cached.
単純なクエリであればGraphQLの場合はGETでも利用できますが、各種条件や認証パラメータなどを含めていくとPOSTリクエストでなければ処理できなくなってきます。
そうなるとVarnishやFastlyではGraphQLリクエストが全くキャッシュされなくなり、アプリケーションサーバーの負荷が高止まりすることになります。
決済連携
決済連携、特にクレジットカード決済においては以下の実装上の要件が求められています。
- カード情報の非通過・非保持（トークン化含む）
- EMV 3Dセキュアの導入
既に多くの決済代行サービスではこれらの機能が提供されていますし、ECサイト側での実装も求められています。
2024年3月14日に公開された、クレジット取引セキュリティ対策協議会のクレジットカード・セキュリティガイドライン5.0版では、以下のように述べています。
特に、2025 年 3 月末までに、原則、全ての EC 加盟店に EMV 3-D セキュアの導入を求めていくにあたっては、加盟店への周知と併せて消費者であるカード会員の理解・協力を得るための周知・啓発への取組が強く求められる。
トークン化の実装は誰が行うのか
カード情報の「非通過・非保持」を実現するために導入された、トークン化。
基本的に実装する場所としてはフロントエンド側、特に支払い方法選択やカード番号登録の箇所になると思います。
ヘッドレス構成でないAdobe Commerce / Magento Open Sourceの場合は、決済エクステンションのフロントエンド実装で対処します。
ヘッドレス構成の場合は、一体誰が実装すればよいのでしょう？
決済エクステンションが実装しようとしても、フロントエンド側の実装方法は多岐にわたるため、予測することは困難です。
ヘッドレス構成を取りたい場合は、トークン化の処理をフロントエンド側で別実装する認識が必要だと思います。
EMV 3Dセキュア時の画面遷移
多くの日系の決済サービスの仕様では、3Dセキュア認証時に以下のような流れが起きます。
- 決済申し込みリクエストの送信
- 決済サービスまたはカード会社の用意する認証画面を表示
- 3Dセキュア認証処理の実行
- ECサイト側への3Dセキュア認証結果伝達
- 与信・売上処理実施
ヘッドレス構成でない場合は、この一連の流れはAdobe Commerce / Magento Open Source側で調整できます。
ヘッドレス構成の場合、どちらのアプリケーションがなんの処理を担当するかを整理・調整しておく必要があります。
それによって決済連携そのものの実装方法も変わってくる可能性があり、既製のエクステンションが利用できないケースも起こり得ます。
開発・維持コスト
最後はコストです。
ヘッドレス構成で運用する場合、単純にコストが増えます。
- Adobe Commerce / Magento Open Sourceの構築・維持費
- フロントエンドアプリケーションの構築・維持費
がそれぞれ必要になるからです。
これはフロントエンドアプリケーションをスマートフォン・タブレット向けのアプリに置き換えても同じです。
Adobe Commerce / Magento Open Sourceのためだけに新たにフロントエンドを別立てする、といった構成は単純にコストが増えるだけなのでおすすめできません。
それならばいっそのこと、ハイパフォーマンスなテーマを利用して構築するほうがよほどコストパフォーマンスが良いと思います。
特にAdobe Commerceの場合はAEMやその他CMSとの連携という話題が多いように感じます。Magento Open Sourceと異なりライセンス費用がかかるため、
- 何のためにAdobe Commerceに対してAPI連携したいのか
- 本当にヘッドレス構成にする必要があるのか
という点は十分検討したほうが良いと思います。
まとめ
今回はAdobe Commerce / Magento Open Sourceをヘッドレス運用する際の課題について解説しました。
- APIアクセスが引き起こす負荷
- 決済連携
- 開発・維持コスト
といった課題を取り上げています。
なお、
課題がある ＝ ヘッドレス運用できない
というわけではなく、構築時にこれらの議題についてきちんと議論・検討することが重要です。
よくないケースとしては、検討が不十分なままプロジェクトが進行してしまうことだと思います。
次回予告
次回は「Core Web Vitalsのスコアをあげたい」という要望に対してのアプローチについて解説します。
