[レポート][SVS320-R] shop.LEGO.comのサーバーレスの旅 #reinvent
こんにちは。芳賀です。 AWS re:Invent 2019に参加していますのでレポートします。
このブログは下記セッションについてのレポートです。
SVS320-R - The serverless journey of shop.LEGO.com Presented by Danilo Poccia(AWS)/Sheen Brisals(LEGO) Connecting the LEGO play experience with millions of people requires an innovative platform. This has fueled the cloud migration of the legacy e-commerce application. In this session, we walk you through the principles, the approach, the learnings, and of course the serverless technologies that made the vision a reality. We cover multiple real-world use cases such as the integration of the e-commerce platform with the tax system, and the implementation of an event-streaming platform.
レポート
今回の話は3つのパートに分かれています。
1. サーバレス化のきっかけ
2. サーバレスのパターン
3. サーバレスへの旅
サーバレス化のきっかけ
- shop.lego.com
- モノシリックなアプリケーション
- backendは、データセンター上に構築していたOracle ATG + SAP + Tax System
- frontendは、AWS上のElastic Beanstalkでnode.js + react
- 2017年のBlack Fridayに、、、
- backendのTax systemがダウンして、それに引きずり全てのシステムが利用不可になってしまった
- 2018年にTax Systemへのアーキテクチャを刷新
- Oracle ATGからAPI Gateway + Lambdaを経由してTax Systemを呼ぶようにした。
- これがサーバレス化へのきっかけ
- 2018年のBlackFridayは乗り切れた。
- 2019年7月10日に
shop.LEGO.com
をAWS上でサーバレス化
サーバレスのパターン
- サーバレスする際に幾つかのパターンがあるので、それを紹介された
- case.1: ショッピングカート
- API-Gateway と Lambda と data Storeで実現
- case.2: 購入など時間のかかる処理
- API化しつつもSQSキューを利用して、処理をし、結果を別なAPIで返却します。
- case.3:バウチャーコードの生成とユーザー通知
- API-Gateway+Lambdaでバウチャーコードの受付け
- バウチャーコードをDynamoDBへコードを格納
- S3へバウチャーを作成し、S3の署名URLを作成し、Emailで送信する
- case.4:ユーザー管理
- 顧客管理プラットフォームとやり取りするLambdaを作成した
- case.5:顧客データの動的な連携
- 新しいWebサイト/プラットフォームでも顧客データを連携する
- 新規サイトの利用を通知し、顧客管理プラットフォームから動的にデータを連携する
- case.6:商品情報の追加と更新
- SAPで作成した商品データを変換することをlambdaで実装している。
- アップデートのデータについてはsqsでキューイングして対応している
- 商品、単価、在庫と分けて更新している。
- DLQはNewRelicへ配信している
- case.7 APIドリブン
- API-Gateway+Lambdaで作っていたが、そのFunctionsは本当に必要なのか?
- LambdaではなくKinesis Firehoseを使う事でCodelessでデータを登録できる。
- データの変換やチェックにはLambdaを利用する
- ここでの話は、LEGO技術ブログに記載している
- Don’t wait for Functionless. Write less Functions instead
- case.8 ユニークな注文番号の生成
- IDの作成は、DynamoDB Atomic Counterを使っている。
- このサービスはステートフルである
- ここでの話は、LEGO技術ブログに記載している
- Sequence Numbering in Serverless via API Gateway
- case.9 Webサイトの移行によるリダイレクト管理
- CDN + ALB + LambdaでURL リダイレクト先を返す
- case.10 Webサイトマップの維持
- 定期的にS3を監視し、作業中とリリースの判断をStepFunctionsLambda?)でおこない、CDNを更新
- case.11 イベント処理の再検討
- イベントドリブンで作成してきたが冗長なイベント処理があった
- event bridgeを使う事でHub & Spokeイベントバスを構築できた
サーバレスへの旅
- シンプルなものから始めていこう
- デプロイメントなどは自動化する
- 開発やテスト、本番環境のアカウントは分ける
- ピースを当てはめるよう考える
- PoCsを使い捨てしない
- パターンの活用
まとめ
適切なサービスをチョイスし、個々のピースとして、大きなサービスをすべきである
感想
ブラックフライデーでの障害をきっかけにサーバレス化へ踏み切ったという話だったが、既存のWebサイトを運営しながら、段階的にオンプレからサーバレスへの移行を進める際のアーキテクチャがよく考えられており、いまもAWS以外のプラットフォームとのやり取りにAPI-GWなどを用いてイベントドリブンな作りになっていることに知見を感じた。
また、今回のLEGOの事例パターンはモノシリックなアプリケーションをサーバレス化する際にとても役に立つと思うので、ぜひぜひLEGOのエンジニアブログを読んでもらいたい。