Amazon Web Services ブログ
ビジネスアジリティを加速する AWS のアーキテクチャ part 2 – Unified Commerce on AWS
前回の記事では、ビジネスのユースケースに合わせてすぐに利用できる AWS Applictions と数多くのユースケースをカバーして開発の工程を削減できる AWS Solutions / Solutions Guidance をご紹介しました。この記事では、流通小売業のビジネス課題に対応した Solutions Guidance「AWS でのユニファイドコマースに関するガイダンス ( Guidance for Unified Commerce on AWS ) 」をご紹介します。
Eコマース／ユニファイドコマース
新型コロナウイルス感染症 (COVID-19 ) の影響で売上高が拡大した E コマース / EC の分野では、先進的な企業はリアル店舗やアプリを含めた統一した体験を提供するユニファイドコマースを通して顧客体験を向上させることに取り組まれています。小売業者がリアル店舗、ECサイト、アプリメンバーシップなど複数の販売チャネルを消費者に向けて用意する販売戦略がオムニチャネル戦略ですが、それぞれのチャネルにおいて消費者へ “統一された ( Unified ) ” 購買体験を提供することを目指す考え方がユニファイドコマースです。
Amazon は 2022年5月にロサンゼルスで Amazon Style というファッションのリアル店舗をオープンしましたが、Amazon Style で提供する顧客体験は ECとリアル店舗を融合したユニファイドコマースのよい例と言えます。Amazon Style の店舗では、展示エリアは限られているので色やサイズを絞った商品を展示しています。しかし、アプリで商品タグについた QR コードを読みとると EC の様により多くのバリエーションの商品と在庫情報を確認することができます。アプリで試着を予約すると選択した商品が試着室に用意されるのはECの自宅配送のような便利さがあります。試着室で実物を身につけることができるのは、リアル店舗特有ですが、タブレットにはECサイトの様に自分の購買や試着の履歴から個人向けに提案されるレコメンデーションが表示され、そこからまた別の商品を試着をすることができます。この様に複数のチャネルがあるだけでなく、各チャネルの良いところを組み合わせた顧客体験を提供する所にユニファイドコマースの強みがあります。（スマートストア／リアル店舗の顧客体験の向上については、こちらのブログで詳しく紹介しています。）
ユニファイドコマースのためのアーキテクチャ
統一された顧客体験を提供するために、それを支える EC やバックエンドにはどの様なことが求められるでしょうか？まず、消費者との接点であるモバイルアプリ、店頭のタブレット、店舗の POS 端末など、様々なチャネルから顧客の行動履歴やオペレーションのデータをリアルタイムで受け取る必要があります。そして、チャネルが様々であっても、注文や在庫などの複数の拠点から随時更新される情報は最新の正しい値を特定できる様にデータを一元管理し、各チャネルからのリクエストに応じてリアルタイムに情報を返す必要があります。このような要件を満たすアーキテクチャを 1 から考えるのは非常に難しいですが、AWS のベストプラクティスと多くの事例をもとに作られている Solutions Guidance を活用することで検討を早める事ができます。ユニファイドコマースについては、「AWS でのユニファイドコマースに関するガイダンス 」を参考にすることができます。詳しく見ていきましょう。
AWS でのユニファイドコマースに関するガイダンス
ソリューションガイダンスのウェブページは、ガイダンスの概要、アーキテクチャ図と番号付きで構成要素の解説が提示されています。このガイダンスの概要には「マイクロサービス、API ファースト、クラウドネイティブ SaaS、およびヘッドレスアプリケーションの MACH の原則を使用して、AWS プラットフォーム上の複数のシステムをシームレスに統合します。」と記載されており、「複数のチャネルからのデータをどのようにリアルタイムに統合するか？」という課題に対して、MACHアーキテクチャを採用することで実現するということを示しています。
MACH アーキテクチャとは、Microservices、API、Cloud Native、Headless の頭文字から取られており、ビジネスの機能別に開発できるようなマイクロサービスで設計し、機能間の連携はAPIを通して行い、クラウドの柔軟性やスケーラビリティを活用し、フロントエンドはヘッドレスな設計にすることでバックエンドのロジックと切り離して疎結合とする、という原則に基づいたアーキテクチャです。このガイダンスで例示しているアーキテクチャもこのMARCの原則に基づいて構成されています。（詳細は AWSも参加している MACH Alliance も参照ください。）
フロントエンド、内部・外部システムとの連携
アーキテクチャ図の上部には「Customer Engagement（顧客接点）」として、ゲームコンソール、コンタクトセンター、モバイルアプリ、EC サイトが汎化された図として記載されています。ここは、Headless の考え方で、プレゼンテーション層となるフロントエンドの部分は、ゲーム端末でもモバイルアプリでも、POSやそのほかのSaaSであっても、実装の詳細は問わずにAPIを経由することでバックエンドと連携できるようになっている（疎結合である）事を示しています。
「1」の部分では、モバイルアプリを SPA で構築する場合に利用される Amazon CloudFront、Amazon S3 や、WEB や POS のアプリケーションとして、AWS Lambda、Amazon DynamoDB が例示されており、それらが AWS AppSync を介して、インターネット上の SaaS や、自社で開発した AWS 上のバックエンドサービス（Common microservices)、パッケージとして導入しているシステム(COTS Applications) 、オンプレミスの基幹系システムと連携しています。
AWS AppSync はマネージドな GraphQL のサービスで、複数の API やデータソースにまたがるリクエストを一つのエンドポイントで処理することができ、フロントエンドから見たバックエンドへの複雑なアクセスを抽象化したり、サブスクリプションの機能によって更新されたデータをリアルタイムに取得することができます。最近、注目を集めている生成系 AI のサービスの様に、最新のテクノロジーが SaaS として提供されることも多いため、「3」で示される様に インターネット 上の SaaS や、逆に「5」で示される様にオンプレミスの ERP の様な、頻繁な変更は行われないが重要なシステムとも連携できるようになっている点もポイントです。
バックエンドのマイクロサービス
「2」で「Common microservices」として示される様に、商品、価格、顧客のような、個別の機能をマイクロサービスとして実装すると、システムを最適にスケールすることができます。例えば、複数のフロントエンドから顧客サービスが頻繁に参照され、負荷が高いといった場合には、顧客サービスに対してのみリソースを追加するといったことができます。機能追加のための開発もサービス単位で実装とリリースをすることができるので、ダウンタイムを短縮したりビジネスへの対応速度を早めたりすることができます。（詳細はホワイトペーパー「AWSでのマイクロサービスの実装」も参照ください。）
イベント駆動設計によるリアルタイムのサービス連携
その一方で、機能別に分離されたサービスであっても注文の状態や顧客への案内など複数のサービスを跨いで、一連の処理を並行して行う必要もあります。そのような場合には、「6」で示されるように、イベントバスのマネージドサービスである AWS EventBridge を使い、イベント駆動型のアーキテクチャで対応することができます。例えば、モバイルアプリでお客様が商品を購入したら、その「注文」というイベントを EventBridge の Event Bus に送信します。EventBridge はそれを受けて、設定されたルールに応じて指定されるターゲット(サービス) へ処理を渡します。そして、注文のイベントを受信した場合には、注文番号をメール送信のサービスへ渡して注文内容の確認メールを送信させ、並行して在庫の引当や発注を管理するサービスへも情報を連携して商品手配を進めることができます。
「8」では、そう言ったイベント処理の中で、 個人別のレコメンデーションのための AI サービスである Amazon Personalize や、カスタマジャーニーに合わせたメッセージを Email、SMS など複数の手段で送信できる Amazon Pinpoint を使用できる事を示しています。例えば、Amazon Personalize では、リアルタイムの操作を加味したレコメンデーションを作成することができるので、モバイルアプリやECサイトで直前に閲覧した履歴を加味したレコメンデーションを表示することもできますし、Pinpoint では、注文を確定した時、カートに商品が入ったままログアウトした時、お客様が店舗に来店したことをアプリが検知した時に、お客様の設定に合わせて Email、SMS、プッシュ通知のいずれかで案内を送信するといったことができます。
これらの流れで取得できる各種データは、毎時や日次のバッチ処理ではなく、注文処理ひとつひとつが発生するイベント単位でデータ分析基盤に連携させることができるため、リアルタイムのデータを分析することができます「7」。時系列データを元にした予測を扱う AI サービスの Amazon Forecast を利用して、発注数を最適化するための需要予測を行ったり、Amazon Sagemaker を使った機械学習による予測や分析を行ったりことで、さらなる顧客体験の向上に活用することができます「9」。
Well-Architected Pillers
Solutions Guidance の最後には「Well-Architected Pillars」という項目があります。これは、AWSがお客様との取り組みの中で、AWSクラウドを活用する上でのベストプラクティスをまとめた「Well-Architected Framework 」に基づきこのアーキテクチャをレビューしたものです。運用の優秀性、セキュリティ、信頼性、パフォーマンス、コストの最適化、持続可能性の6つの柱の観点から、アーキテクチャで採用しているサービスやデザインパターンを評価しています。例えば、このアーキテクチャではパッケージソフトウェアを使用する必要あるところ以外では、Amazon EC2 は利用せずにサーバレスサービスである Lambda や DynamoDB を使うことでパフォーマンス効率を最適化し、マネージドサービスである Amazon ECS 、 Amazon Redshift などを使用することで信頼性を向上させていることを説明しています。
実現に向けて
ご紹介した Unified Commerce on AWS はユニファイドコマースを実現するための、ベストプラクティスに則った汎用的なアーキテクチャを示しています。実環境では、関連する EC や基幹システムの構成は多岐にわたり、様々な経緯で導入されたシステム群が複雑に連携しながら運用されているので、いきなり全てをこのガイダンスに合わせてそのまま再構築したり、費用対効果を満たした上で、期待したビジネス効果を得られるかの判断を事前に行うのは難しいでしょう。
多くのお客様で実践されいる、おすすめのアプローチは、ビジネス効果が最も期待される箇所から部分的、段階的に取り組むことです。例えば、消費者向けの複数あるチャネルの中で、会員基盤を強化することがビジネス施策として最も重視され、既存の会員管理のシステムにも課題があるとすれば、そこから取り組むのが良いかもしれません。会員情報を管理するアプリやウェブサイトをヘッドレス化することから始める、もしくはリリースサイクルやスケーラビリティが課題になっているバックエンドのいくつかの機能にフォーカスして、その部分を独立したマイクロサービスとして切り出す、ストラングラーパターンと呼ばれる対応方法をとることができます。効果が高い部分を切り出して対応することで、ビジネスへの効果を早く出すことができ、対応するチームではそこで学習したノウハウを次の機能の開発に生かすことができます。
まとめ
この記事では、流通小売業で DX の推進に活用できる Solutions Guidance の中でも、ユニファイドコマースを実現するためのアーキテクチャ「 AWS でのユニファイドコマースに関するガイダンス 」をご紹介しました。MACH アーキテクチャに基づき、最先端の機能を取り入れるために SaaS や 基幹システムとの連携を含んだアーキテクチャで AWS のサーバレス／マネージドサービスを活用することで高いパフォーマンス効率や信頼性を実現することができます。このガイダンスが提案するアーキテクチャの利点が皆様の課題解決と一致する場合は、ビジネスに最も価値を発揮できそうな箇所から取り組んでみてはいかがでしょうか。
ソリューションアーキテクト 多田 雅哉