【レポート】RET304: Amazon Freshを強化するサーバーレスアーキテクチャを採用してリテール顧客へ迅速に対応 #reinvent #RET304

ウィスキー、シガー、パイプをこよなく愛する大栗です。

本記事はAWS re:Invent 2017のセッション「RET304 - Rapidly Respond to Demanding Retail Customers with the Same Serverless Architecture That Powers Amazon Fresh」のレポートです。

登壇者

登壇者は、Amazon FreshのソフトウェアエンジニアとAWSにシニアSAの方です。

• Fernando Dingler - Software Development Engineer, Amazon Fresh
• Gowri Balasubramanian - Sr Solutions Architect, AWS

レポート

このセッションに期待すること

• AWSにおける小売企業のユースケース
• サーバーレスアーキテクチャの紹介
• AWS Lambsa、Amazon API Gateway、Amazon DynamoDBの概要
• Amazon Freshのサーバーレスアーキテクチャ

AWSにおける小売業務 - キーとなる利点

• アプリケーション開発を迅速にし、ビジネスの差別化にフォーカスする
• オンデマンドなスケールで時期的なピークや変動に対応（例えばブラックフライデー）
• ITコスト全体を低減する - 設備投資から運用コストモデルへ、さらにAWSマネージドサービスを通して運用コストを最小化
• グローバルな地域をまたがって顧客へリーチする
• アジャイルなアプローチでデータ分析を実装する

小売業でフォーカスするエリア

• Eコマース
• Big Data/分析
• デジタル・カスタマー・エクスペリエンス

サーバーレスへの進化

• クラウド内の仮想サーバ０（Amazon EC2）
• クラウド内のコンテナ（Amazon ECS）
• クラウドとサーバーレス

なぜサーバーレスプラットフォームなのか？

1. インフラストラクチャの管理がない：ビジネスロジックにフォーカス
2. コスト効果が高く効率的：使った分だけ支払う
3. 継続的なスケーリング：ワークロードに応じた自動的なスケール

サーバーレスアーキテクチャのコンポーネント

• 入力
  • ストリームデータ
  • API
  • イベントソース
• 処理：AWS Lambda
  • トリガーベースLambdaファンクション
• 出力
  • データの永続化
  • 統合ポイント

サーバーレスWeb/Mobileアプリケーション

AWS Lambdaを動かす

• イベントソース
• Lambda関数
• サービス（なんでも）

Lambdaのプログラミングモデル

• 自分のコードを持ち込める
• シンプルなリソースモデル
• 監視とロギング
• ステートレス

Lambdaのデプロイオプション

• CodeCommit
• CodeBuild
• AWS CloudFormation
• Amazon CloudWatch
• X-Ray
• CodePipeline

Amazon API Gatewayの利点

• 複数のマイクロサービスの統一化されたAPIフロントエンドを構築
• DDoS防御とバックエンドシステムへのスロットリング
• リクエストの認証と認可

Amazon API Gatewayを動かす

• 構築
• パブリッシュ
• 設定
• セキュア
• メンテナンス
• 監視

APIの呼び出しフロー

RDB 対 NoSQL？

• SQL
  • ストレージのための最適化
  • 正規化/関係モデル
  • ケース特有のクエリ
  • 垂直スケール
  • OLAPに良い
• NoSQL
  • コンピュートのために最適化
  • 非正規化/階層構造（柔軟なスキーマ）
  • インスタンス化されたビュー
  • 水平スケール
  • OLTPをスケールするために作られた

Amazon DynamoDBの利点

• 高い可用性と耐久性
• スケールする一貫性のある速度
• 完全にマネージド
• セキュア
• AWS Lambda、Amazon Redshiftなどと統合されている
• コスト効果がある

DynamoDBの機能概要

• スケーラビリティ
• パフォーマンス
• セキュリティ
• 管理性
• 開発プラットフォーム

Amazon Fresh のサーバーレスアーキテクチャ

ここからはAmazon FreshのFernando Dingler氏のターンです。

以前のAmazon Freshのプロセスには問題がありました。このようにトートが大量に届いてしまうことがありました。

以前のプロセス

1. カスタマーがサービスを呼ぶ
2. 手動で輸送チームにチケットを出す
3. カスタマーの住所へのピックアップをスケジュールする
4. ドライバーがトートをピックアップする

より良い答え

カスタマー -> ドライバー

要件

• 市場投入までの時間
• 管理されたインフラストラクチャ
• コスト効果が高い

アーキテクチャ概要

ユースケース１ - 的確化確認

ユースケース2 - ピックアップ要求のスケジュール

ユースケース3 - レポーティング

トートのピックアップ - データレイヤー

• アクセスパターン
  1. カスタマIDと住所からピックアップ要求を取得
  2. カスタマIDから全てのピックアップ要求を取得
  3. 時間範囲からピックアップ要求を紹介

正しいキャパシティを選択するには

1. アクセスパターンを特定する
2. アイテムサイズを特定する
3. 負荷とトラフィックを推定する

書き込みキャパシティの例

• 10 TPS
• 3KB
• 最小 30Unit、最大 60Unit

DynamoDBのベストプラクティス

• データが分散するパーティションキーを選択する
• データアクセス要件の全てを満たすグローバルセカンダリインデックス（GSI）を使用する
• ワークロードとアイテムサイズを基にキャパシティを推定する
• DynamoDB Auto Scalingで散発的なスパイクトラフィックに対応する
• DocumentClientを使ってJSONオブジェクトとスロットル例外のリトライに対応する
• CloudWatchで監視する

トートのピックアップ - Lambda実行モデル

• 同期
• 非同期

Lambdaの監視

• Errors
• Invocation duration
• Throttled invocations

Lambdaのベストプラクティス

• 設計
  • ユースケースごとのファンクション vs モノリシックな大きなLambdaファンクション
  • コアリジックから分離されたLambdaハンドラ（エントリポイント）
  • 環境変数を使って運用パラメータを渡す
  • 必要が無い限りLambdaのVPC配置を避ける
• 運用
  • スロットルとエラーにCloudWatchアラームを設定する
  • 非同期呼び出しのエラーハンドリングにデッドレターキューを使用する
  • 並列数の制限を意識する：アカウントごと、リージョンごとの制限

トートのピックアップ - APIレイヤー

• Lambdaのスムーズな統合
• セキュア（https）
• APIキーを使ったクライアントごとにリクエストのトラッキング
• ステージ
• スロットリングと使用プラン

プロビジョニングとマネージメント

CloudFormationで構築と更新を行う

IAM Role、DynamoDBテーブル、Lambdaファンクション、APIエンドポイント、Amazon S3バケット

結果

• より良いカスタマエクスペリエンス
• 数百時間：月間のカスタマーサービスを抑制
• 3ヶ月：小さなチームの開発成果
• 3.7時間：SDEごと、週ごとの運用作業を抑える

さいごに

日本にも展開されているAmazon Freshの裏側を覗けました。奇を衒わずに、標準的なサーバーレスアーキテクチャを採用して成果を上げていることがわかったセッションでした。