Google Cloud 上でデジタル コマース プラットフォームを構築する方法

※この投稿は米国時間 2022 年 2 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

次世代デジタル コマース プラットフォームの構築をお考えですか？そんな方に朗報です。この記事では、Google Cloud 上で e コマース プラットフォームをモダナイズする 3 種類の方法について説明します。どの方法が正しいとか間違っているとかはありません。お客様のチームと現在のインフラストラクチャに適した経路からスタートし、完全にモタナイズされたプラットフォームを目指して作業を進めることができます。その前に、15 分間の動画をご覧になりたい方は、こちらをご覧ください。?

デジタル コマース プラットフォームのモダナイゼーションには、ヘッドレス コマース、自社構築、すぐに使える、という 3 つの主要なアプローチがあります。

これらのツールを詳しく見ていきましょう。

1. ヘッドレス コマース 

小売店であれば、魅力的で差別化されたショッピング体験を提供するためにフロントエンドを所有し、管理し、商品カタログやカート機能、価格設定、プロモーション、配達、アカウント管理などの機能については、すぐに使えるバックエンドのコマース構築ブロックを使用したいと考えるかもしれません。

ヘッドレス コマースのアプローチでバックエンドとフロントエンドを切り離すと、チームは簡単に対応できるようになります。

• バックエンドのスキルを必要とせず、バックエンドの処理に影響を与えることなく、お客様向けサイトの更新（例: 季節ごとのキャンペーンに対応）を行うことが可能。

• 買い物客とのインタラクション データ（＝自社データ）を活用し、そのデータを使って購買行動の分析情報を得ることで、データドリブンでパーソナライズされた提案を活性化し、売上コンバージョンを向上することが可能。

• セキュリティやその他の規格を遵守しながら、フロントエンドのアップデートを機敏に行うことが可能。

• フロントエンドにアップデートを適用する際、エンドツーエンドのクライアント エクスペリエンスのために一貫したパフォーマンスを維持することが可能。

Google ISV パートナーである Commercetools をバックエンドに、Cloud Run または Google Kubernetes Engine （GKE）をフロントエンドとして、Google Cloud 上でヘッドレス コマースを実装した場合のアーキテクチャ例を紹介します。このサンプル アーキテクチャの詳細については、この短いチュートリアルを参照して、インテグレーションの手順を確認してください。

2. Google Cloud で独自のコマース プラットフォームを構築

自社構築方式では、AI / ML ツールやデータ管理ツールなど、Google Cloud のビルディング ブロックを使用して独自のソリューションを組み立てます。この方法を実行するには、大きく分けて 3 つの方法があります。

a. 既存のソリューションをそのまま移行するのを、既存のソリューションを自社のデータセンターで運用するのではなく、Google Cloud でホスティングすることによって行います。これにより、クラウド化に必要な変更を最小限に抑えることができますが、マイクロサービス アーキテクチャの利点は得られません。

b. 既存のソリューションをマイクロサービス アーキテクチャに移行（および改善）するのを Google Cloud のコンテナとマネージド サービスを利用して行います。この方法は、既存のソリューションをそのまま移行するよりも多くの変更を必要とします。しかし、一度移行すれば、メンテナンスの容易さ、柔軟性、スケーラビリティの向上など、クラウドネイティブ、コンテナ化されたアーキテクチャの利点を実感できます。GKE を利用したコマース プラットフォームの移行と改善のためのアーキテクチャのサンプルを以下に示します。

c. アーキテクチャを完全にモダナイズする。例えば、GKE や Compute Engine を使用して Google Cloud に移行したとします。あるいは、モダナイズされたコマース プラットフォーム全体をゼロから構築している場合もあります。その後、どのようにモダナイズされた完全なコンテナ化されたマイクロサービス アーキテクチャに進んでいきますか？  アーキテクチャの全貌はこちらの 動画で確認していただきたいですが、ここでは概要を紹介します。

4 つのレイヤに分かれた小さなサービスでプラットフォームを実装することを考えます。

• プレゼンテーション レイヤ- SPA（シングルページ アプリケーション）のビルダーとコンテンツ。

• サービスレイヤ - セッション、検索、アカウント、在庫、注文などのサービス。

• ストレージ レイヤ - サービスに関するお客様のストレージの選択。例えば、在庫や商品には CloudSQL や Cloud Spanner、ユーザー セッションにはFirestoreなど、サービスの種類によって異なる場合があります。

• キャッシュ レイヤ - ストレージ レイヤに再度問い合わせることなく、最近問い合わせたデータにアクセスするために Memorystore を使用できる、一時的なキャッシュ。

このアーキテクチャは、 最も柔軟なオプションであることに加え、組織に以下のような利点を提供します。

• マイクロサービスを独自に開発、スケールし、トラフィックの急増に対応するとともに、TCO を削減する。

• 他のサービスに影響を与えることなく、いつでも新しいサービスを追加し、デプロイすることが可能。

• 異なるチームが異なる言語で異なるサービスに取り組む。

• データ プラットフォームとコマース プラットフォームの間にクローズド ループを確立し、お客様の行動をよりよく理解し、パーソナライズされたエクスペリエンスを提供する。

Google Cloud 上の既製の SaaS（Software-as-a-Service）ソリューションの利用

既製品のアプローチでは、Google Cloud 上でホストされている Shopify や BigCommerce などの既存の SaaS ソリューションを使用します。この方法は、あまりカスタマイズを必要としない場合に有効です。アナリティクス 360 を含む Google Cloud の機能や性能を活用し、お客様に関する分析情報を得て、ソリューションで生成されたデータを分析できます。

次のステップ

どのようなアプローチに魅力を感じますか？そのために、Google はいくつかのリソースを作成しました。

• ? アプローチとそれぞれのサンプル アーキテクチャを紹介する動画を見る。

• ? ヘッドレス コマースドキュメントを読む

• ?‍? 詳細な ヘッドレス コマースのチュートリアルを試す

• ? 最新のデジタル コマース プラットフォームをゼロから立ち上げる

これらのリソースに関するご意見をお聞かせください。Twitter の@pvergadiaでシェアするか、会話を始めてください。