アーキテクチャ: マイクロサービスを使用したスケーラブルなコマース ワークロード

この記事では、Google Cloud でマイクロサービスを使用してスケーラブルなコマース プラットフォームを構築するときに使用できる一連のアーキテクチャ アプローチについて説明します。

小売コマースの要件とマイクロサービス

増え続けるコンシューマ デバイスやプラットフォームからの需要に対応するため、小売コマース ワークロードは多数のクラウド ネイティブな機能を必要とします。

  • 通常、このようなデプロイは、グローバルな顧客ベースに対応するためマルチ リージョンである必要があります。
  • また、ある程度の自動スケーリングやスケジュールされたスケーリング、繁忙期のピーク需要に対応するためのスケールアップ、需要の低下に合わせてインフラストラクチャ コストを削減するためのスケールダウンをサポートしている必要があります。
  • 小売コマースのデプロイでは、市場の需要の変化に対応できるように、お客様に対して迅速かつ効率的に機能を提供できる必要があります。
  • お客様側の機能に開発者が集中して取り組むことができるようにするため、マネージド インフラストラクチャを利用する必要もあります。
  • さらに、このようなデプロイは、一元的に保護、管理する必要があります。

マイクロサービスは、これらのすべての要件に適しています。個々のマイクロサービスは、互いに独立してデプロイ、スケーリングできます。このため、新しい機能を迅速に導入できます。特定のビジネス機能やニーズに合わせて、サービスを小規模なものにモジュール化し、サービス間を疎結合にして編成できます。マイクロサービスではサービス ディスカバリを利用できます。また、シンプルなメカニズム(HTTP など)を使用して、さまざまなデバイスから容易に接続できます。

バックエンド アーキテクチャ

小売コマースのワークロードの場合は、マイクロサービスを、お客様側のユーザー エクスペリエンスを構築するために必要な個々の機能に編成します。たとえば、特定の商品のメタデータを取得(およびオプションでキャッシュ)する商品メタデータ サービスや、特定のお客様向けの商品価格を取得する商品価格処理サービスなどです。

マイクロサービスは REST API を介してクライアントに公開され、クライアント アプリケーションは API ゲートウェイを介して REST API と通信します。

次の図は、コマース指向のバックエンド マイクロサービス アーキテクチャの例を示しています。

バックエンド マイクロサービス アーキテクチャを示す図

フロントエンド アーキテクチャ

小売コマース ワークロードにおけるお客様側ユーザー エクスペリエンスには通常、レスポンシブ ウェブ アプリケーションが含まれており、これはしばしばプログレッシブ ウェブアプリとして提供されます。また、オプションでネイティブ モバイル アプリケーションが含まれます。前述のバックエンド アーキテクチャと組み合わせて、バックエンド API とサービスに対応し通信する複数のフロントエンド コンポーネントを組み合わせて、アプリケーションを構築します。

次の図は、コマース指向ウェブ アプリケーションのフロントエンドの例を示しています。

コマース指向のウェブ アプリケーションのフロントエンドを示す図

データ ストレージ

小売コマース ワークロードは、複数のデータカテゴリを保持する必要があります。カテゴリは次のとおりです。

  • 商品カタログ: 商品の属性(名前、説明、色、サイズなど)。
  • 購入者プロフィール: 顧客データ(名前、年齢、嗜好、請求先住所、配送先住所など)。
  • 購入者トランザクション: お客様の購入内容に関する情報(購入商品、購入日など)。
  • クリックストリーム データ: ウェブサイト内で購入者がたどった経路を追跡する情報。
  • 商品の画像と動画: 特定の商品に関連するメディア(商品提供者のコンテンツ、顧客提供のコンテンツなど)。
  • 評価とクチコミ: 商品に関するお客様からのフィードバックと意見。
  • 商品在庫: 在庫の有無と新品の予定入荷日に関するデータ。

次の表に、各データカテゴリと Google Cloud ストレージ メカニズムの対応を示します。

オブジェクト 非リレーショナル リレーショナル 倉庫
Cloud Storage Cloud Datastore Cloud Bigtable Cloud SQL Cloud Spanner BigQuery
画像
動画
カタログ
プロファイル
請求書
クリックストリーム
料金
トランザクション
在庫
評価
トランザクション
在庫
評価
アナリティクス
ウェアハウス

商品カタログ

商品カタログでは、商品に一連の属性(名前、説明など)が設定されています。ただし、商品カタログの多様化に伴い、個々の属性の数も増加していきます。新しい商品カテゴリごとに独自の属性セット(商品のサイズと色、タイプとモデルなど)があり、これらの属性を検索やフィルタリングに使用できます。

したがって、商品カタログの最も適切な保存オプションは、NoSQL ドキュメント指向データベースです。このデータベースには柔軟なスキーマがあり、カテゴリ別またはオブジェクト別の属性を格納できます。このようなユースケースに対応できるのが、フルマネージド NoSQL ドキュメント指向データベースである Datastore です。Datastore で、オブジェクトをエンティティとして格納すれば、各エンティティで、JSON 構造のようにネストされた Key-Value のペアをサポートできます。Datastore は複数の Google Cloud リージョン内で利用可能であり、常時稼働サービスとして実行されます。

商品メディア

商品カタログ内の各商品には、商品提供者からの画像または動画を組み込むことができます。また、お客様から提供された画像や動画を組み込むこともできます。これらのアセットは、スケーラブルなオブジェクト ストレージ システムに格納できます。このようなストレージ システムでは、アセットを直接ウェブ アプリケーションやモバイル アプリケーションに配信できます。Cloud Storage は、複数リージョン間でデータを処理できるマネージド オブジェクト ストレージ サービスです。Cloud Storage は、ニーズに応じて異なるレベルのデータアクセスと可用性を提供します。高いパフォーマンスを実現するために、Cloud CDN は Google のグローバル分散エッジ ロケーションを利用して、Cloud Storage から提供されるコンテンツの配信にかかる時間を短縮します。つまり、エンドユーザーに可能な限り近い位置に静的アセットが配置されるため、ダウンロードのレイテンシを最小限に抑えられます。

購入者プロフィール

購入者プロフィールは、整合性のある一連の属性で構成されており、多次元であることがよくあります。たとえば、一部のお客様は配送先住所や支払い方法を複数設定しており、各支払い方法に個別の請求先住所が設定されていることがあります。

購入者プロフィールは、複数のテーブルを使用してリレーショナル データベースに格納できます。その一方で、NoSQL ドキュメント指向データベースを使用してお客様のプロフィールを保存することもできます。この場合、購入者プロフィールを、特定のお客様のデータをすべて保持する単一リッチ オブジェクトとして格納できます。このようなユースケースに対応できるのが、フルマネージド NoSQL ドキュメント指向データベースである Datastore です。

評価とクチコミ

お客様が残した商品評価とクチコミは、比較的単純なデータセットで構成されているので、さまざまなストレージ メカニズムを使用してこの情報を保持できます。一般的には、商品 ID、顧客 ID、評価値、クチコミ テキストなどのフィールドを含むリレーショナル スキーマを使用します。このデータを格納するには、Cloud SQL または Spanner のいずれかを使用できます。ほとんどのユースケースでは、評価およびクチコミデータを格納するのに最適なシステムは Cloud SQL です。アプリケーションで高いトランザクション スループットと水平スケーラビリティが必要な場合は、Spanner が最適です。使用するデータベース サービスの詳細については、ストレージ オプションの選択をご覧ください。

トランザクションと請求書

評価やクチコミと同様に、さまざまなストレージ メカニズムを使用して、購入者のトランザクションと請求書または注文の詳細を保持できます。トランザクションを格納するデータベース システムは、ACID セマンティクス、特に書き込みをアトミックに commit できる機能をサポートしていなければなりません。Datastore、Cloud SQL、Spanner はすべて、アトミック操作をサポートしています。ほとんどのユースケースでは、書き込み操作間でデータが一貫して構造化されているため、トランザクションにはリレーショナル システムが適しています。ストレージ システムの選択は、SQL システムと NoSQL システムのどちらが使いやすく感じるかという点、そして選択したデータベースに合わせてアプリケーションをカスタマイズできる能力に大きく依存します。

請求書も、NoSQL データベースまたはリレーショナル データベースを使用して保存できます。選択するシステムは、ダウンストリームのユースケースに応じて決まります。最近のコマース ワークロードでは、請求書や注文の詳細を保持するために Datastore のような NoSQL ドキュメント指向データベースがしばしば利用されます。これは、請求書のすべての状態を 1 つのリッチ オブジェクトとして格納できるためです。従来型のコマース ワークロードには、Cloud SQL または Spanner も適切な選択肢となります。

トランザクションと請求書に使用するデータベース サービスの詳細については、ストレージ オプションの選択をご覧ください。

完全にクラウドベースの環境の場合、トランザクション データと請求書データはすべてクラウド インフラストラクチャ内に格納されます。一方、ハイブリッド環境で作業する場合は、クラウド環境とオンプレミス環境の間でデータを同期する必要があります。ハイブリッド シナリオでは、トランザクション データと請求書データは通常、オンプレミス インフラストラクチャに格納されます。その場合、カスタム アプリケーション、Pub/Sub、またはデータベース レプリケーションの組み合わせを使用して、バックエンド システムをクラウドデータ インフラストラクチャと同期できます。

クリックストリーム データ

お客様のトラフィックに関するデータはしばしば、Google アナリティクスなどの分析パッケージを使用してキャプチャされます。ただし、このようなナビゲーション データ(クリックストリーム データ)をリアルタイムで収集したい場合があります。

クリックストリーム データをキャプチャするにはさまざまな方法があります。一例として、Google Cloud を使用したサーバーレス ピクセル トラッキングを使用する方法があります。クリックストリーム トラッキング用に作成されたデータセットは非常に大きくなる傾向があり、機械学習や予測分析のソースとしてしばしば使用されます。このタイプのデータは通常、Bigtable などの NoSQL ワイドカラム システムに格納されます。Bigtable は、大規模なデータセット(最大で数百ペタバイト)に対応し、低レイテンシかつ高スループットを実現することから、このようなユースケースに適しています。

商品在庫

商品が入手可能であるかどうかに関するデータは、全体的な顧客エクスペリエンスにおいて非常に重要です。在庫データは多くの場合、商品 SKU、最新の在庫状況、在庫追加予定日を含むデータセットで構成されます。ただし、このデータがアプリケーションで使用される通常の方法を考えると、ストレージ メカニズムで、在庫レベルを正確に反映するためトランザクションとアトミック操作がサポートされている必要があります。Datastore、Cloud SQL、Spanner はすべて、アトミック操作をサポートしています。ほとんどのユースケースでは、書き込み操作間でデータが一貫して構造化されているため、在庫データにはリレーショナル システムが適しています。使用するデータベース サービスの詳細については、ストレージ オプションの選択をご覧ください。

トランザクション データの場合と同じく、完全にクラウドベースの環境では、在庫データはすべてクラウドデータ インフラストラクチャ内に格納されます。ハイブリッド環境で作業する場合は、クラウド環境とオンプレミス環境の間でデータを同期する必要があります。ハイブリッド シナリオでは、在庫データは通常、オンプレミス インフラストラクチャに格納されます。その場合、カスタム アプリケーション、Pub/Sub、またはデータベース レプリケーションの組み合わせを使用して、バックエンド システムをクラウドデータ インフラストラクチャと同期できます。

デプロイ アーキテクチャ

Google Cloud を使用する場合は一般的に、App Engine フレキシブル環境または Google Kubernetes Engine のいずれかを使用してマイクロサービスをデプロイします。App Engine フレキシブル環境は、自動スケーリングと負荷分散機能を備え、よく使われている言語とフレームワークをサポートする、フルマネージド PaaS(サービスとしてのプラットフォーム)です。GKE は、オープンソースのコンテナ オーケストレーションおよびクラスタ マネージメント メカニズムである Kubernetes をベースに作成されています。デプロイするのにどのプラットフォームを選択するかは、必要となる柔軟性のレベルと、アプリケーション インフラストラクチャの複雑さによって異なります。

詳細については、コンピューティング オプションの選択をご覧ください。このガイドでは、両方のデプロイ オプションについて説明します。

App Engine フレキシブル環境を使用する

次の図は、App Engine フレキシブル環境を使用したマイクロサービスのデプロイ例を示しています。

App Engine フレキシブル環境を使用したマイクロサービスを含むデプロイを示す図

フレキシブル環境では、受信トラフィックに基づいて、アプリケーションを実行するインスタンスの数を自動的にスケールアップ、スケールダウンします。マイクロサービスをデプロイすると、各サービスは他のサービスからは独立してスケーリングされます。フレキシブル環境では、負荷分散リソースが自動的にプロビジョニングされ、個々のマイクロサービスのバージョンの管理とバージョン間でのトラフィックの分割の機能が提供されます。

フレキシブル環境を使用する場合、アプリケーションは、個別に開発、デプロイされた個々のマイクロサービスで構成されます。各サービスは、ネイティブ ランタイム(Java、Node.js、Python など)を使用するか、または Docker コンテナとしてパッケージ化して他の言語や環境向けのカスタム ランタイムを使用できるようにする必要があります。

フレキシブル環境のアプリケーションは、プロジェクトごとに単一のリージョンにデプロイされます。グローバル デプロイを作成するには、複数のプロジェクト(お客様のロケーションに対応するために必要なリージョンごとに 1 つずつ)を作成する必要があります。1 つのプロジェクトに含まれるマイクロサービスごとに、データ ストレージ インフラストラクチャをプロビジョニングして運用する必要があります。次に、フレキシブル環境のデプロイに対応するプロジェクトごとに、データ インフラストラクチャ プロジェクトにアクセスするためのサービス アカウント認証情報を提供します。

次の図は、グローバルなフレキシブル環境でのデプロイ用のアーキテクチャ例を示しています。

グローバルなフレキシブル環境でのデプロイを示す図

GKE の使用

次の図は、GKE を使用したマイクロサービスのデプロイ例を示しています。

GKE を使用したマイクロサービスを含むデプロイを示す図

GKE を使用する場合、各マイクロサービスには個別のデプロイおよびデプロイ ライフサイクルがあります。各マイクロサービスは Docker コンテナとしてパッケージされています。Docker コンテナは、次のいずれかの方法で Kubernetes Pod and Service としてデプロイします。

GKE では、HorizontalPodAutoscaler により、CPU 使用率に応じた自動スケーリング Pod がサポートされています。また GKE クラスタでは、GKE クラスタ オートスケーラーを使用した自動スケーリングもサポートされています。このオートスケーラーでは、飽和状態のリソースまたは十分に使われていないリソースに基づいて、クラスタが自動的にサイズ変更されます。

GKE クラスタはリージョナル リソースであり、高い可用性を必要とするデプロイでは、複数ゾーンにわたるデプロイを作成する必要があります。詳細については、マルチゾーン GKE クラスタの概要をご覧ください。

グローバルなお客様ベースに対応する必要があるデプロイでは、1 つのプロジェクト内に複数の GKE クラスタ(リージョンごとに 1 つずつ)をデプロイします。各マイクロサービスのデータ ストレージは、GKE クラスタと同じプロジェクトからプロビジョニングおよび操作されます。

次のステップ