このガイダンスでは、マイクロサービス、API ファースト、クラウドネイティブ SaaS、およびヘッドレスアプリケーションの MACH の原則を使用して、AWS 上の複数のシステムをシームレスに統合します。ユニファイドコマースは、顧客と接するすべてのタッチポイントを網羅し、チャネルに関係なく統一されたエクスペリエンスを提供し、マルチチャネルアプローチのサイロを解消します。このガイダンスを導入することで、マーケティングと業務を連携させ、一貫したブランドエンゲージメントを実現して顧客満足度を向上させ、支持率を高めることができます。
アーキテクチャ図
[アーキテクチャ図の説明]
ステップ 1
フロントエンドアプリケーション (ヘッド) は、共通の一連のマイクロサービスと、AWS AppSync などの API レイヤーの背後で抽象化される他のアプリケーションを使用して、ヘッドレスアプリケーションを作成します。
ステップ 2
Amazon DynamoDB や Amazon Neptune などの一般的なマイクロサービスは、フロントエンドエクスペリエンスアプリケーションを強化するアプリケーションロジックとデータを提供します。これらは通常、小売業者のオファーを、競合他社のオファーと差別化するサービスを提供します。
ステップ 3
Software-as-a-Service (SaaS) アプリケーションは、特に小売業者のサービスが差別化されていない場合に、成熟したエバーグリーンアプリケーションロジックを提供するために使用されます (可能な場合)。
ステップ 4
また、従来の商用オフザシェルフ (COTS) アプリケーションを、Amazon Elastic Compute Cloud (Amazon EC2) や Amazon Relational Database Service (Amazon RDS) などの AWS のサービスにデプロイして、まだ SaaS として利用できない、あるいは、まだマイクロサービスに分解されていないアプリケーションサービスを提供することもできます。
ステップ 5
オンプレミスの倉庫管理システム、エンタープライズリソースプランニング (ERP)、財務ソフトウェアなどの既存の記録システムや位置情報を利用するシステムも、集約 API の背後で統合されています。
ステップ 6
すべてのマイクロサービスとアプリケーションは、Amazon EventBridge カスタムイベントバスに発行され、ルールを使用して分離されたアプリケーションによって消費されるイベントを生成します。
ステップ 7
アプリケーションのデータとイベントは、リアルタイムおよび履歴の分析とレポートのために、Amazon Simple Storage Service (Amazon S3) や Amazon Athena などのデータプラットフォームにストリーミングされます。
ステップ 8
動的なコンテンツとマーケティングオファーのパーソナライゼーションは、リアルタイムイベントに基づいており、顧客が選択したエンゲージメントチャネルでプッシュされます。機械学習は、予測とインテリジェントなインサイトを生成するためのソースとしてデータレイヤーを使用します。
ステップ 9
機械学習は、予測とインテリジェントなインサイトを生成するためのソースとしてデータレイヤーを使用します。
Well-Architected Pillars
AWS Well-Architected フレームワークは、クラウドでシステムを構築する際に行う決定の長所と短所を理解するのに役立ちます。フレームワークの 6 つの柱により、信頼性が高く、安全かつ効率的で、費用対効果が高く、持続可能なシステムを設計および運用するためのアーキテクチャのベストプラクティスを学ぶことができます。AWS マネジメントコンソールで無料で提供されている AWS Well-Architected Tool を使用し、各柱の一連の質問に回答することで、これらのベストプラクティスに照らしてワークロードを確認できます。
上記のアーキテクチャ図は、Well-Architected のベストプラクティスを念頭に置いて作成されたソリューションの例です。完全に Well-Architected であるためには、可能な限り多くの Well-Architected ベストプラクティスに従う必要があります。
-
運用上の優秀性
提案されたアーキテクチャはマネージドサービスを活用するため (可能な場合)、大規模に実行できます。従来の COTS アプリケーションは、Amazon CloudWatch アラームとログとともに、Amazon EC2 インスタンスのメトリクスを活用します。Auto Scaling グループとマネージド Amazon RDS は、障害から回復できます。
-
セキュリティ
このアーキテクチャはマネージドサービスを利用するため (可能な場合)、Amazon S3 暗号化データ、スコープダウンされた IAM ロール、保管中の Amazon DynamoDB 暗号化などのセキュリティのベストプラクティスに従うとともに、AWS がセキュリティに関する責任の大部分を負います。強力な ID は、消費者には Amazon Cognitoを通じて、オペレーターには IAM ロールを通じて強制されます。CloudWatch Logs と AWS CloudTrail はトレーサビリティを提供し、Amazon GuardDuty、AWS Security Hub、中心的な SIEM などの組織全体の機能と併用できます。
-
信頼性
マネージドサービスを利用すると、デフォルトで高い信頼性を実現できます。Amazon S3 と Amazon DynamoDB のストレージの冗長性、Amazon SageMaker インスタンスのスケーリング、Amazon Redshift、Amazon Athena、Amazon SageMaker Canvas、Amazon Pinpoint、Amazon Personalize、AWS AppSync、Amazon EventBridge も設計によって高い可用性を備えています。問題が発生した場合は、同じパイプラインを使用して Amazon S3 の未処理イベントからデータを再生できます。イベントは、EventBridge のアーカイブおよび返信機能を使用して再生することもできます。コンテナアーキテクチャは、AWS Fargate 上で実行される Amazon Elastic Container Service(Amazon ECS) または Amazon Elastic Kubernetes Service (Amazon EKS) のいずれが選択されたかに基づいて、水平方向にスケールし、キャパシティの需要に動的に適応します。
-
パフォーマンス効率
スケーリングは可能な場合、AWS Lambda、 DynamoDB、SageMaker エンドポイント、Amazon Redshift などの AWS サーバーレスサービスの利用に基づいて行われます。
-
コストの最適化
マネージドサービスとサーバーレスサービスは、利用時のみに料金が発生するように設計されているため、これらを利用することでアーキテクチャのコストを最小限に抑えることができます。
-
持続可能性
提案されるアーキテクチャは、可能な場合にはマネージドサービスとサーバーレスサービスを利用して、必要なときにのみ実行する持続可能なアプローチを採用しています。AWS の Customer Carbon Footprint Tool を使用して、影響の合計値を取得できます。
実装リソース
AWS アカウント内で実験および使用するための詳細なガイドが提供されています。ガイダンス構築の各段階 (デプロイ、使用、およびクリーンアップを含む) は、デプロイに向けて準備するために詳細に検討されています。
サンプルコードは出発点です。これは業界で検証済みであり、規範的ではありますが決定的なものではなく、内部を知ることができ、開始に役立ちます。
関連コンテンツ
免責事項
サンプルコード、ソフトウェアライブラリ、コマンドラインツール、概念の実証、テンプレート、またはその他の関連技術 (私たちの担当者から提供される前述のものを含む) は、AWS カスタマーアグリーメント、またはお客様と AWS との間の関連文書契約 (いずれか該当する方) に基づき、AWS コンテンツとしてお客様に提供されるものです。お客様は、この AWS コンテンツを、お客様の本番アカウント、または本番データもしくはその他の重要なデータで使用すべきではありません。お客様は、サンプルコードなどの AWS コンテンツを、お客様固有の品質管理手法および基準に基づいて、本番グレードでの使用に適したテスト、セキュリティ確保、および最適化を行う責任を負います。AWS コンテンツのデプロイには、Amazon EC2 インスタンスの実行や Amazon S3 ストレージの使用など、AWS の課金対象リソースを作成または使用するための AWS 料金が発生する場合があります。
本ガイダンスにおける第三者のサービスまたは組織への言及は、Amazon または AWS と第三者との間の承認、後援、または提携を意味するものではありません。AWS からのガイダンスは技術的な出発点であり、アーキテクチャをデプロイするときにサードパーティのサービスとの統合をカスタマイズできます。