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

はじめに

本記事はAWS re:Invent 2018のセッション「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コマースはとても大変
 顧客は常に増加し続けている
 Amazonのトラフィック。毎年右肩上がりに増えている
  Black FridayとかPrime Dayとか...
 アクセスはとてもピーキー。バーストする

重要なチャレンジ
 スケール可能
 規模に合わせたインフラのアップグレード
 アクセス予測
 特徴の分析
 ピークアクセスをハンドリング出来ていますか?

レガシーなEコマースシステム
 新しくて大きなサーバの購入
 ゴミトラフィックの削除
 課題がたくさんある

リテールシステムのモダナイズ
 クラシックなりテールシステム
  WebSphere Commerce、Oracle ATG Web Commerce、SAP Hybris
 n-Tier アーキテクチャ
  ロードバランサ、フロントエンドサーバ、アプリケーションサーバ、データベース
  データベースが分散出来ず可用性を担保出来ない、リスキー
 データベースのモダン化
  高可用性、信頼性、スケーラブルの確保
  可能ならオープンソースDBに
  マネージドなデータベースを利用
  MultiAZで構成
  リードレプリカの利用
 アプリケーションのモダン化
  パイプラインでデプロイ
  オートスケーリンググループでResiliency: max=1に(オートヒーリング)
  適切なオートスケールの設定
   CPU、オーダー、セッション、ユーザー
 SAP Hybris on AWSの例
  全てMulti-AZのAuto Scalingで構成
  アプリケーションのデプロイはTerraformとPackerを利用
  レイヤー間はELBで分散
  可用性の高いAuroraを採用、データ共有はEFS
  レイヤーで分けることで機能拡張も負荷分散も容易
  Hosting SAP Hybris Commerce on AWS with Piksel Retail
 River Island bespoke .NET stack
  Webサーバ、アプリケーションサーバ、Solrを全てMulti-AZのAuto Scalingで構成

次世代Eコマース
 ビジネスの中心を変更することに対するプレッシャー
 6ヶ月も変更していなかったWebサイト
 停止期間中のビジネス損失
 スケーラブルとアジリティの確保
 最小限の変更・停止が必要
 アクセス予測ができること
 コストエフェクティブであること
 分離可能なマイクロサービスであること
  大規模な一つのシステムはコストも高い
  小さく分離することで開発コストも維持コストも削減出来る
 運用が最適化されること

どうやって始めるか?
 ミッション・ステートメント:ビジネスのアジリティを高めること
 ケーパビリティ
  検索、カタログ、料金設定、支払い、商品管理、カートとチェックアウト、顧客情報管理...
 ネクストステップ
  既存のモノリシックなシステムを分解する
  独立したサービスを構築する
  サービスをAPI化して公開
  ビジネスイベントで公開
  全体よりも各ケイパビリティを意識してデザイン
 マイクロサービス化するための検討
  イベントのシステム間連携をどのように実現するか
   SQS?MQ?Kinesis?
  ストレージの選定。S3?データベース?
  アプリケーションを動かすコンピュートリソースの選定
   フレキシブルで大きなアクセスにも対応可能なこと
   コストエフェクティブであること
   効率的にアプリケーションがデプロイ出来ること
   コンテナ(ECS、EKS)、サーバレス(Lambda、Step Functions)
  Eコマースは多様なイベントが発生する
   適切な処理をするための選定をしましょう
 River Islandでのサーバレス
  イベントストリームとしてKinesisを採用
  Lambdaで各種処理を実行
  Eコマースの各種イベントがKinesisを経由してLambdaで処理される
  OracleからのプッシュイベントをAPI Gatewayを経由してKinesisへ
  イベントによってはLambda経由でコンテナで処理
  PII(Personally identifiable information)データをLambdaで処理してクリーン化
 イベント連携
  ゆるく連携
  API連携かメッセージング連携のパターンがある
  SQSとKinesisの使い分け
   SQS
    チープに使える
    アカウントを横断してアクセス可能
    オートスケーリングに対応可能
   Kinesis
    マルチコンシューマーにデフォルトで対応
    大規模アクセスにも対応
    Lambdaとの連携が容易
 S3 or データベース
  オープンで拡張性があること
  クラウドネイティブ
  マルチリージョンでアクセス可能
  スケールできること
  3つの選択肢。Aurora、DynamoDB、S3
   Aurora
    他のDBからの移行が簡単
    AWSの各種サービスとの連携が容易
    マルチリージョン対応可能
    強いスキーマを持つ
  DynamoDB
   マルチリージョン、低レイテンシ、サーバレス
   DynamoDB streamsが使える
  S3
   データレイクとして利用
   非構造データを格納 
  River Islandの選択
   Aurora for MySQLを利用
   KVSとしてDynamoDBを採用
   S3をデータレイクとして活用
   幾つかのチームではPostgreSQLを使ってる

Eコマースのイベントオブジェクト
 Event Sourcingの引用
 全てのイベントをキャプチャする
  Kinesis or SQS、S3にストア
 全てのイベントを格納し検索可能に、再現も可能に
  全てのイベントをS3に→Redshift,Athena,EMR等で検索可能

サマリ
 スタティックなコンテンツはS3に
 API Gateway経由でCompute(コンテナ、サーバレス)を使う
 Messagingを活用(SQS/Kinesis)
 ストレージは多様な選択肢から選択
 オンプレミスステムをマイグレーションまたはリフト&シフトでAWSへ
 Start small and Think Big   

さいごに

AWSの活用としてはベーシックではありますが有効的なアーキテクチャの紹介でした。