[レポート] RET207 次世代のEコマースアーキテクチャ #reinvent

はじめに

re:invent2018で行われたセッション「RET207 Next-Generation e-Commerce Architectures」を聴講してきたのでレポートとしてまとめます。

本セッションの内容は以下になります

In this session, we review the most modern e-commerce architectures, patterns, and technologies that are being used by digital innovators. We examine micro-services as well as event-driven and event-sourced architectures. We provide examples of how these patterns are implemented on AWS, and we review the benefits of each one. Learn how to select a pattern for your workload and which combination of AWS services can be used to build them. We use real-world customer examples so you can see the practical applications of these patterns.

セッションの登壇者は次の方々です

• Bastien Leblanc氏 - Solutions Architect , AWS Solutions Architecture , Amazon
• Charles Wilkinson氏 - Head of Architecture , River Island

セッションレポート

アジェンダ

• 既存の小売店を近代化する
• 次世代Eコマースシステムの構築
• Eコマースイベントソーシング

そして結論と次のステップへ

最初に：Eコマースにはさまざまな大変なことが潜んでいる

規模は顧客によって異なる

大規模なイベントや顧客増加によって持続的に成長するパターン

例) Amazon.comのBlack FridayやPrime Dayなど

僅かな成長をするが、時には非常にピーキーなアクセスが有るパターン

例) Missguidedのソーシャルイベントによる活性化

• スケールを適用
• アップグレード＆適応
• 可観測性
• 将来の証明

あなたはピークをうまくコントロールできますか？

規模に合わせたアップデート、アップグレード、そしてスケールの適応できますか？

それらを解決する従来の方法

• 新しいサーバーを購入する
• 余計な接続を拒否する
• より大きなものを構築する

私達はよりよい方法を見つけなければなりません

既存の小売店を近代化する

既存の小売システムを近代化する

小売業者が通常使用する古典的なEコマースアプリケーションは以下のようなものがあります

• IBM WebSphere Commerce
• Oracle ATG Web Commerce
• SAP Hybris

これらの多層アプリケーションなレガシーなEコマースアプリケーションは、原則的に適用されます

代表的なEコマース多層アーキテクチャ

データベースに問題を抱えている

データベース

原則

• 高可用性な
• 信頼性のある
• スケーラブル可能な

ものを必要とされている。

データベースのコンポーネントを近代化する

• (可能なら)オープンソースに移行する
• マネージドデータベースを使う(Amazon RDS)
• Multi A-Zへの移行
• より多くのリードレプリカの利用

アプリケーションレイヤー

アプリケーションのコンポーネントを近代化する

• パイプラインでデプロイする
• オートスケーリンググループでmax=1でも弾力性をもたせる
• Eコマースアプリをオートスケールするための指標を決める
  • CPU
  • 毎分の注文数
  • 同時セッション数
  • 同時に利用するユーザー数

Piksel Retail (AWS 上でSAP Hybrisで構築)の例

こちらのブログで紹介

Bespokeの行なったRiver Islandの.Net stackの例

次世代Eコマースシステムの構築

なぜ新しいEコマースシステムが必要なのか

• 変化するビジネスモデルからのプレッシャー
• 6ヶ月変更のないウェブサイト
• 多くの企業がそれらの凍結期間を延長している

これらのビジネス損失は大きい

• スケール
• アビリティー
• 数多くの小さな変更への対応を、より多くの稼働時間を確保しながら行う

これらが必要となってくる

次世代Eコマースのアーキテクチャ原則

• 将来を見越した
• ビジネス指向な
• 費用対効果の高い
• 分離することができる(マイクロサービス化)
• 最適化された運用ができる(可能ならば自動化)

次世代のEコマース、どこから始めれば？

使命：ビジネスのアジリティーを高める

典型的なEコマースアプリの機能

検索、カタログ、コンテンツ、価格、オーダー、支払い、プロモーション、在庫、顧客プロフィール、カートとチェックアウト、製品MDM...

次のステップ

• 既存の巨大なシステムを分解する
• 独立してサービスを構築する
• サービスをAPIとして公開する
• ビジネスイベントを公開する
• 機能に焦点を当てた技術設計をする

アーキテクチャ設計の実装

これらの原則は、いくつかの選択肢をもたらす

マイクロサービス化

イベントオブジェクトの交換

Amazon SQSやAmazon MQ、もしくはAmazon Kinesisを使う？

データ保存

データベースを使う？データストアを使う？

稼働リソース

どこで、どうやってEコマースアプリケーションを動かす？

Eコマースアプリの稼働リソースの選定

原則

• フレキシブル
• 大規模に対応
• 費用対効果の高い
• 効率的にアプリケーションがデプロイできる

コンテナ化

Amazon ECSないしAmazon EKS

サーバレス化

AWS Lambdaないし AWS Step Functions

ここでAmazon API GatewayはEコマースシステムでは重要なサービスとなる

River Islandのサーバレスアーキテクチャ

• Kinesisでイベントを受け流す
• Lambdaで処理を実行
• Oracle DBからのイベントをAmazon API Gatewayで受ける
• イベントによってはLambdaを使ってDockerなどのコンテナで処理
• 個人情報はLambdaで処理して浄化だああ

マイクロサービス化

原則

• ゆる～い組み合わせ
• APIもしくはメッセージのパターンによってのみ連携
• 1つに1つのビジネス機能をもたせる

それらは

• Amaon API Gateway
• Amazon SQS
• Amazon Kinesis

で実現される

Amazon SQSを使うか？Amazon Kinesisを使うか？

Amazon SQS

• 安く済ませることが可能
• アカウントを超えて動作が可能になる
• オートスケーリングのサポートがある

Amazon Kinesis

• 複数のコンシューマにデフォルトで対応
• 大規模な可用性がある
• Lambdaとうまくやっちゃうよ

保存領域：データストアを使うか？データベースを使うか？

原則

• オープンで拡張性があること
• クラウドネイティブであること
• マルチリージョン対応であること
• スケールできること

Amazon Aurora

• つよいスキーマ
• 他のRDMSからの移行が容易
• AWSとの心w背が高い
• マルチリージョンに対応

Amazon DynamoDB

• DynamoDB ストリームが使える（便利
• マルチリージョンに対応
• 低いレイテンシー
• サーバーレス

Amazon S3

• イベントを突っ込む
• データレイクとしてつかえる
• 非構造なデータを保存できる

River Islandの選択

Aurora for MySQLを使っている、これがメイン。

Amazon DynamoDBをKVSとして使っている（こいつのストリームをkinesisに流す

いくつかのチームはPostgreSQLを使ってるよ（すきだから

データレークとしてS3を使ってる

Eコマースイベントソーシング

Martin Fowler氏は言った。

"The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself."

https://martinfowler.com/eaaDev/EventSourcing.html

Eコマースにおけるイベントソーシング

原則

• イベントオブジェクト すべてのイベントをキャプチャされなければならない
  • KinesisもしくはSQSを使う
  • 保存するのはS3
• シーケンシャル イベントオブジェクトを格納し、それらを参照可能で、さらに再実行可能でなければならない
  • S3にすべて貯める 朗報です、これらをAmazon Redshiftや、Amazon Athena、Amazon EMRなどから直接参照することができます。
  • スケジュールを組んでスナップショットを取る リプレイ回数は制限する
  • 逆依存関係

結論

次世代のEコマースをAWSで実現するならこうだ！

次は何する？Eコマースプラットフォームを構築しよう

• カスタマーとビジネス構築から始めよう
• 移行計画を立てよう
• オンプレミス環境から移行しよう
• ビジネス機能を選んで次世代の物を作り、積み重ね、それを繰り返そう
• 成功を評価しよう
• 小さく始めてビッグに育てる

まとめ

弊社では、現在prismatixとしてEコマース向けの基盤を提供開始していますが、今回の次世代Eコマースアーキテクチャに則り機能設計及び実装されております。

それぞれのマイクロサービスを独立して作ることで、小さなビジネスを大きく成長させることができるという認識の方向性は、正しいものだと言えそうですね。

サービスについて詳しく聞きたい、相談したいなどありましたら、ぜひお問い合わせをよろしくお願いいたします。