【レポート】AWS Summit Tokyo 2017：流通業界におけるデジタルトランスフォーメーションの実践 #AWSSummit

2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。

当エントリでは2017年05月31日に行われた『流通業界におけるデジタルトランスフォーメーションの実践』に関する内容をレポートしたいと思います。

• AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通りです。

デジタルトランスフォーメーション

デジタルのテクノロジーによって会社のコアとなるサービスや製品を再開発し、新しいものを創造すると定義する。

それによって、以下がもたらされる。

• 顧客との関係や顧客体験の変化
• 社内プロセス改善
• 新しい価値の提案

AWS における流通業界の実績

Amazon.com を始めとする多くの有名流通企業の実績がある

Amazon の事例

事例１：amazonfresh

サービス概要

• 生鮮食品を最大4時間でお届けするサービス
• 東京でも一部エリアでスタート
• 今回はシアトルのケースを紹介

1. オーダー
2. パイクプレイスから仕入れ
3. FCへ輸送・保管
4. オーダーに合わせて配送

Amazon.com への統合

• 2-Tier で構成していたシステム
  • 複数システムの AP サーバと共通 DB
• Amazon.com への統合と同時に SOA（Service Oriented Architecture）へ移行
  • フロントエンド（Web）はユーザー・インタフェースとなるため、レイテンシ、障害がクリティカル
  • バックエンド（カタログ、料金、オーダー、在庫管理）は短時間停止は許容。再処理できれば、OK。特にシステムの柔軟性を向上させた

pub-sub モデルの導入

• 非同期メッセージングモデルを採用
  • Producer -(Publish)-> Channel -(Subscribe)-> Consumer
  • アプリケーション間の連携を疎結合にできる
• AWS では pub-sub モデルをマネージドサービスを組み合わせて実装できる
  • Publisher -(Publish)-> SNS -> SQS -(Subscribe)-> Consumer（例えば Lambda） による実装
• SNS を利用することでトピックに追加することで既存システムに影響なく新機能を実装することができる
  • 例えば、SNS から SQS に渡して、処理するアプリケーションがあるとする
  • 一つのアプリケーションとして実装している場合、新しい機能を実装する場合に既存のアプリケーションを修正する必要がある
  • SNS を挟むことで SNS トピックに新しい SQS への配信を追加することで既存アプリケーションを改修することなく、新規アプリケーションと連携することができる

事例２：FBA（フルフィルメント by Amazon）

自社製品を Amazon.com で販売・物流利用

販売プロセス

1. 在庫商品の発送
2. 受け取り＆保管
3. お客様からの注文
4. ピック、パッキング＆配送
5. カスタマーサービス
6. 返品処理

2. の受け取り＆保管の実装をサーバーレス化

• 要件
  • 10000 トランザクション/秒
  • ホットキーの処理
  • 重複メッセージ
  • 順序が異なるメッセージ
  • 在庫量変化時の監査（トレースできるように）

効果

• 22週間の開発コスト減
  • マネージドサービスを利用
  • 監視や運用系サーバは全て AWS にオフロードすることで開発コストを減らした
• スケーラビリティを重視
  • 疎結合により柔軟性が高くすることで既存サービスに影響を与えず、新機能を実装することができる
  • マネージドサービスを利用し、オペレーションコストを削減することで本来のビジネスに注力いただく

流通システム on AWS

流通システムの構成

EC系システムの構成

• CloudFront -> ELB -> EC2(AutoScaling) -> RDS
• ポイント
  • ステートレス化（セッション管理は ElastiCache などを利用）
  • パッケージ製品の制約でステートフルであれば ELB のスティッキーセッションを有効化
  • セールなどで急激なトラフィック増が想定されれば、ELB の暖気申請を忘れずに
  • 合わせて EC2、RDSのスケールアウト/スケールアップも忘れずに

事例：Rent-A-Cent

• 家具や家電などのレンタル
• SAP Hybris を導入
• コンテナとして ECS に乗せて、コンシューマ向け、管理向けそれぞれを運用している
• Enterprise のお客様でも ECS なら Docker の運用が楽になる
• データベースは Hybris が MySQL をサポートしていることから Aurora に乗せている
• AWS WAF によりセキュリティ向上。Lambda でルールを作成している

基幹系アプリケーションの構成

• Act-Stb クラスタリング
  • パッケージ製品をクラスタリングソフトウェアで冗長化
• クラスタリングソフトウェアは AWS 対応のものを利用する
• 既存で利用中のものがあれば、製品ベンダに AWS 対応を確認する（マルチキャストの制約を受ける可能性あり）
• AWS では AutoRecovery などの自動復旧を利用することで障害時のダウンタイムを短縮できる

流通におけるデータアーキテクチャ

例えば現状

POS -> APP -> RDB -> ETL -> DWH -> BIツール -> ビジネスユーザやデータアナリストが分析

AWS での置き換え

POS -> EC2 -> S3 -> EMR -> S3 -> Redshift -> QuickSight

• S3 をデータレイクとして利用する
• S3 の耐久性・可用性や、他の AWS サービスとの連携機能がデータレイクとして向いている
• EMR で ETL して S3 に分析しやすいデータに加工することも可能
• Redshift を DWH としてクエリしやすい形でデータを持つ
• QuickSight で分析

リアルタイム性の実現

POS -> Kinesis Streams -> Kinesis Analytics -> Kinesis Streams -> Kinesis Firehose -> S3 -> Redshift -> QuickSight

だったり、

POS -> Kinesis Streams -> Kinesis Analytics -> Kinesis Streams -> Dynamo DB -> ダッシュボードアプリ

だったり、といった構成も可能。

ただ POS -> Kinesis は難しいから EC2 を挟む必要がある。

まとめ

AWS は Amazon.com という世界最大級の EC サイトが動いていることから流通業界の EC は安心して、AWS を採用できるのではないかと改めて思いました。
データ分析系も多くのサービスが用意されており、様々な組み合わせができるので自社の分析手法に合わせた構成も取れるのではないでしょうか？