E コマースサイト構築のパターン
Embedded Files
E コマースサイトは顧客との重要なタッチポイントです。顧客体験（カスタマー エクスペリエンス、CX）を高めるためには、商品検索や商品詳細などを軽快に動作させることで、スムーズな購買体験ができるようにします。そのためには、レスポンスタイムを可能な限り少なくするなどのパフォーマンスが求められます。
E コマースサイトはアクセス数が急激に増加することに配慮する必要があります。例えば人気商品の発売、テレビ番組や CM での紹介、SNS 上での話題性など、予測し切れない場合も含まれます。そのため静的コンテンツやキャッシュの活用、スケーラビリティのあるデータベースの選択などが必要です。
また顧客属性に合わせた商品のリコメンドやクーポンの配信を行うことで、コンバージョン率を高めることができます。そのためマーケティングアナリティクスや CRM（Customer Relationship Management、顧客関係管理）との関連度が高い領域となります。E コマースサイトからユーザーデータやユーザー行動データを Firebase と Google アナリティクス を利用して取得し、ユーザーごとのデータをベースとしたセグメントの作成、または機械学習を活用した予測結果を適用するなどといったアクションを実施します。
商品データの文脈では、E コマースサイトでカートに入れられた商品の在庫を確保するため、店舗ごとの在庫情報のリアルタイム性が求められます。在庫管理システムとのシームレスな連携を行うことで、顧客が確実に商品を購入できるような購買体験の提供を目指します。
クラウドとのハイブリット環境を使って可用性が高く
スケーラブルな E コマースサイトを構築するパターン
クラウドとのハイブリット環境を使って可用性が高く
スケーラブルな E コマースサイトを構築するパターン
解決する課題・使い所
COVID-19 の影響により特定の商品の需要が急激に上昇し、既存の E コマースサイト全体に影響を与えるような事態が 2020 年の前半に多く発生いたしました。今後も人気商品の予約や、抽選販売など、特定の商品に対する急激なアクセス増が想定されるため、そうしたアクセスを適切に処理できるかが、E コマースサイト全体の安定性を高める上で重要な課題です。本項では既存の E コマースサイトに与える影響を最小にするために、急激なアクセス増がみこまれる商品については特設サイトという形で、トラフィックを分けるパターンについて解説します。
アーキテクチャ
可用性が高くスケーラブルな E コマースサイトのアーキテクチャとして、特定商品のみを特設サイトに分離するパターンと、既存の E コマースサイトのフロントエンドのボトルネックを解消する 2 つのパターンについて解説します。
はじめに特定商品のみを特設サイトに分離するパターンのアーキテクチャです。分離された特設サイト側で、SSO、商品マスタ DB、 ショッピングカート、予約投入、在庫設定管理画面など、E コマースサイトとして稼働するための一通りの機能を実装します。特設サイトでうけた予約注文については既存の E コマースサイトに投入させる仕組みを構築します。バッチシステムによる投入や、手動による連携作業にするかは、既存の E コマースサイトは要件にあわせた判断が必要になります。
Bot によるアクセスは、Google Cloud の reCAPTCHA、Cloud Armor による対応が可能になります。
次は、既存の E コマースサイトのフロントエンドのボトルネックを解消するパターンです。 DB は既存 E コマースサイトのものを利用し、最低限の工数で上流のボトルネックを解消します。Google Cloud の reCAPTCHA や Cloud Armor の WAF 機能を使うことで Bot や DoS 攻撃への対応を迅速に実現することが可能です。Google Cloud の強力なネットワーク、コンピュートリソース を簡単に利用しながらも、将来的にはハイブリッドクラウドソリューション Anthos や Oracle ソリューション を活用した既存環境・Google Cloud の両方でモダナイズが可能になります。
利点
どちらのパターンにおいても、既存の E コマースサイトに大幅な改修を加えることなく、Google Cloud の強力なネットワーク、コンピュートリソース を利用することができるようになります。将来的なマルチクラウド環境への移行も、Anthos ソリューションを適用することで、オンプレとパブリッククラウドの利点を最大限活かしたアーキテクチャが実現できます。
注意事項
特定商品のみを特設サイトに分離するパターンにおいては、予約注文の情報を既存 E コマースサイトに同期する方法や頻度について個別に検討が必要になります。既存 E コマースサイト側の機能や、予約注文の処理に対する要件に応じて、開発範囲を適切に決定する必要があります。
既存の E コマースサイトのフロントエンドのボトルネックを解消するパターンにおいても、バックエンドのデータベース側でボトルネックが発生しないか、フロントエンド側のトラフィックを既存 E コマースのキャパシティで処理することができるかの検証が別途必要になります。
関係するデザインパターン
E コマース サイトのホスティングのパターン
E コマース サイトのホスティングのパターン
解決する課題・使い所
一般的に Web サイトは「静的」または「動的」の 2 種類のコンテンツをホスティングする方法があります。E コマースサイトのホスティングについてはいずれも必要となり、いかに静的コンテンツを増やし、動的コンテンツを最小限に減らすかが重要です。
E コマースサイトでは、何万件もの商品画像を扱う場合があります。このような商品画像は CDN （Content Delivery Network）のキャッシュ機能を活用することで、インフラコストを最小化するとともに、ユーザーがいち早く画像を閲覧できるようにパフォーマンスを最適化します。
E コマースサイトは急激なアクセス増加が発生した際にも顧客にコンテンツを確実に届けるため、なるべく CDN でキャッシュしている静的コンテンツのみでレスポンスできるような構成を取ることを目指します。一方で、商品検索やペイメントといった、ユーザーの操作によってコンテンツが動的に変化するページは動的にホスティングする必要があります。
このパターンは E コマース全体のうち、CDN およびフロントエンドレイヤーのホスティングについて解説しています。下図の青いエリアにあたります。
アーキテクチャ
Web サイトをホスティングする場合、Cloud Load Balancing を利用する構成を取ります。Cloud Load Balancing では設定を有効化することで Cloud CDN の機能（キャッシュ）を利用することができるようになります。Cloud Load Balancing のバックエンド サービス（オリジン）をそれぞれ配置します。Cloud Load Balancing が持つパスルーティングの機能を使い、アクセスされるパスによって静的コンテンツのオリジンを返すか、動的コンテンツのオリジンを返すかを振り分けます。
HTML、JavaScript、CSS、画像などの静的なコンテンツは Cloud Storage に格納し、動的なコンテンツは Compute Engine などのコンピューティング サービスにリクエストが渡るようにします。本パターンではリファレンスとして Compute Engine と Cloud SQL の組み合わせによって表現しています。
利点
静的コンテンツと動的コンテンツを、コンテンツの特性やキャッシュの計画によって振り分けることができます。動的コンテンツを生成するコンピューティング リソースへのリクエストを最小限に抑え、キャッシュを活用することで、インフラコストを抑え、コンテンツ配信のパフォーマンスを最適化することができます。
注意事項
Cloud CDN のキャッシュ コントロールを、キャッシュ対象のコンテンツの特性に合わせて適切に設定してください。適切にキャッシュ コントロールができていないと、コンテンツのリアルタイム性が失われたり、逆に過剰なリクエスト処理となる可能性があります。例えば、カート内の商品一覧ページやクーポン ページなどはキャッシュすべきではありません。
関係するデザインパターン
参照文献
Page updated
Report abuse