物流支援サービスを支えるAWSサーバーレスアーキテクチャ戦略

AWS API Lambda Serverless DynamoDB

OGP

はじめに

こんにちは。SRE部BtoBチームの蔭山です。Fulfillment by ZOZO（以下FBZ）で提供しているAPIシステムの運用及び監視を担当しております。

FBZではAWS Lambdaを主軸としてAWSが提供しているフルマネージドサービスのみを利用するサーバーレスアーキテクチャを採用し、構築・運用してきました。今回は実際にどのようにサーバーレスアーキテクチャを活用してサービスを構築・運用・監視しているかご紹介します。

これからサーバーレスアーキテクチャを活用してサービスを構築されようとしている方の参考になれば幸いです。

なぜサーバーレスを採用したのか

FBZはZOZOTOWNとブランド様が運営されている自社ECサイト間でリアルタイムに在庫情報を連携し、ZOZOTOWNと自社ECサイトでの在庫の一元管理を実現するAPIサービスです。そのため、マスタであるZOZOTOWNの在庫情報を如何に素早く自社ECサイトへ連携できるかが重要な要素の1つです。

ZOZOTOWNではZOZOWEEKをはじめとしたセールやイベントが1年を通して開催されています。その最大トラフィック量は他のアパレルECサイトを見廻しても群を抜いているものになります。このようなイベントで発生する商品や在庫などの最新情報をブランド様が管理する自社ECへリアルタイムで連携していくには、どのようなトラフィックでもスケーラブルに対応できる堅牢なシステムが必要となります。実際にFBZをローンチする上では以下のポイントをクリアしておく必要がありました。

  • ZOZOTOWN・自社ECサイトのセール時の急激なトラフィック増加にも耐え、問題なくサービスを稼働できること
  • バッチによる大量データ更新・連携を問題なく、かつ高速に完了できること

上記のポイントを低コストでクリアするために、当時浸透し始めていたFaaSであるAWS Lambdaを主要とするサーバーレスアーキテクチャを採用しました。

システム構成

冒頭でもご紹介しましたが、FBZ APIはAWSが提供しているフルマネージドサービスのみで構成しています。実際には以下のようなサービスを利用しています。

  • Lambda
  • API Gateway
  • S3
  • DynamoDB
  • Elasticsearch Service
  • SQS
  • SES
  • Cognito
  • CloudFormation
  • CloudWatchメトリクス
  • CloudWatch Logs
  • X-Ray
  • CloudFront
  • AWS WAF
  • Amazon VPC

上記に挙げたようなAWSのフルマネージドサービスを最大限活用しながら、約500ものLambda関数を持つサービスを運用しています。実際にどのように活用しているかはこのあと詳しく解説していきます。

イベントドリブンなアーキテクチャ

基本となるアーキテクチャとしてイベントドリブンなアーキテクチャを採用しています。イベントドリブンなアーキテクチャについて、実際にFBZで稼働している商品情報の連携を元に説明します。

イベントドリブンな商品同期アーキテクチャ図

  1. Lambdaを起動しZOZOTOWNから取得した商品情報をS3バケットに保存
  2. S3バケット保存によるイベントからLambdaが起動し、ECカートシステムが取り込みやすいよう商品情報をパースしてDynamoDBのテーブルへ保存
  3. DynamoDBテーブルへの登録イベントからLambdaが起動し、Elasticsearchへ商品情報を保存

このようにイベントの数珠つなぎによってAWS上の各データストアへ商品情報が登録されます。ECカートシステムが公開されているFBZのAPIを利用し自社ECシステムへ最新の商品情報が連携される仕組みです。

セキュリティ

FBZ APIは自社ECサイトをご利用いただいたお客様の配送情報も取り扱っているため、お客様の大切な個人情報を漏洩させないようセキュリティ面は厳重な対策がされている必要があります。実際にはAWS WAFを利用してAPIへの接続管理やDDoS攻撃を代表とするサイバー攻撃対策を行っています。またCognitoでのユーザー認証やAPIのエンドポイント単位での認可を実現しています。

APIのセキュリティ

また、DynamoDBやElasticsearch Serviceに含まれる本番環境の個人情報を開発者が必要ない時に閲覧できないよう、以下の制限対策も実施しています。

  • DynamoDBのテーブルにAWSコンソール画面やAWS CLIからアクセスできないようにIAMポリシーによるテーブル単位での閲覧・編集制限
  • Elasticsearch Serviceのドキュメントに外部から参照できないようにPrivateサブネットへの配置
  • Kibanaへ必要ない人が閲覧できないようにCognitoによるユーザー認証

データストアの保護

アプリケーション管理

Serverlessアプリケーションの管理フレームワークとしてServerless Frameworkを利用しています。テンプレート上に必要なAWSサービスのリソース定義を記載し、Serverless Frameworkを介してリリースすることによってAWS上に定義されたリソースを展開する仕組みとなっています。

同様のServerlessアプリケーションの管理ツールとしてはAWSが提供しているSAMがありますが、SAMと比べて以下の点で優れていると考え現在も利用しています。

また各アプリケーションが利用するようなAWS VPCなどの環境単位での共通リソースは、別途CloudFormationでテンプレート管理しています。これによりほぼすべての構成・設定値をコードで管理している状態となっています。

またCI/CDの環境としてCodeBuildを利用しています。アプリケーションの静的解析やカバレッジ計測のような開発支援からアプリケーション・インフラのリリース、APIのE2Eテストに至るまですべてCodeBuild上で実行しています。

CI/CDフロー

サービス監視

サービスを運営していくにあたって、システムの監視は切っても切り離せないものです。もちろんFBZのようにフルマネージドサービスのみで構成したサービスでも同様となります。実際にFBZでは下記のようなサービス監視を実施しています。

  • CloudWatchメトリクスによる異常値検知
  • Lambda/API Gatewayから出力されたログを解析し、PagerDutyやDatadogのような外部サービスへ連携

AWSの各サービスではCloudWatchメトリクスへ稼働状況が収集されています。収集されたデータから異常値が検知された場合、Slackへ通知されます。その通知を受け運用担当者が対応するフローとなっています。

ログ解析によるサービス監視については過去に記事を公開しているのでぜひ御覧ください！ techblog.zozo.com

サーバーレスでメリットに感じたこと

FBZのシステム構成の一部を紹介してきましたが、ここからはこのようなフルマネージドサービスのみで構成されたサービスを実際に運用して感じたメリット・デメリットについてご紹介します。

まず、サーバーレスのメリットだと感じている点を代表して3点紹介します。

  • スケーラブルなサービスの実現
  • データリカバリの容易さ
  • サービス開発への集中

スケーラブルなサービスの実現

サーバーレスアーキテクチャを採用した理由として挙げていましたが、結果としてZOZOTOWNの様々なイベントに対してスケーラブルなサービスを構築できた点です。過去にZOZOTOWNでのセール開催時に大量の商品・在庫情報が差分として上がってくるケースがありました。そのような同時に発生する膨大なデータ連携でも自社ECサイトへリアルタイムに連携することが可能なシステムとなっています。

データリカバリの容易さ

イベントドリブンなアーキテクチャでLambda関数を分割しているため、有事の際のデータリカバリが容易な点もメリットだと考えています。もしZOZOTOWNからの商品データ取得に何かしらの理由で失敗した場合でも、指定のS3バケットへ再取得したデータを配置することでその後の自社ECシステムへの連携まで自動的にリカバリされます。また非同期起動のLambda関数は処理が失敗した場合に間隔を開けて自動でリトライする仕組みがあります。ネットワーク起因の一時的な問題などもリトライによって自動で解決してくれる点はサーバーレスならではだと感じています。

サービス開発への集中

サーバーなどのインフラ管理をAWSが管理するマネージドサービスを利用することでなくし、サービスに携わるエンジニアがビジネスロジックの開発に集中できる点です。実際にFBZではインフラ面を管理する専任メンバーはおらず、開発エンジニア全員でマネージドサービスの設定管理やサービス開発を行う環境となっています。

サーバーレスでデメリットに感じたこと

ここまでサーバーレスでのメリットを挙げてきましたが、もちろんメリットだけでなくデメリットも存在しています。ここでも代表して3点紹介します。

  • Lambdaの実行時間の制限
  • RDBを利用しづらいアーキテクチャ
  • ミドルウェアアップデートへの強制的な追従

Lambdaの実行時間の制限

現在、Lambdaは1処理あたり最大15分まで処理を行うことができます。APIサービスとしての利用ではまず問題になることはないのですが、連携ファイル生成など時間がかかる処理はデータ量によっては15分では終わらないケースもあります。アプリケーション側の処理ロジックを見直して解決できることもありますが、それで解決できるケースはごく一部でした。FBZでも実際に15分以上かかる処理もあり、その場合はAWS BatchやStep Functionsといった別マネージドサービスで実行するように実装しています。Lambdaに限らず、各マネージドサービスそれぞれに上限値は存在しますので制限値を確認しながら設計を進めていくことが大切なポイントだと思います。

RDBを利用しづらいアーキテクチャ

一般的なWebサービスですとMySQLやPostgreSQL、SQL Serverに代表されるようなRDBをデータストアとして利用されているケースが多いかと思います。LambdaのようなFaaSでは水平スケールを得意としているため、LambdaからRDBへの接続はコネクションを枯渇してしまうためアンチパターンとされています。データを検索する場面ではDynamoDBだと細やかな要件を満たすことが困難だったこともありElasticsearchを利用し対応しています。ただ、販売成績など売上データを集計する場面においてはElasticsearchでもFBZ要件を満たすことが困難であり、ロジックの開発が必要でした。RDBであればクエリで実現可能な部分に対し、アプリケーション側で対応するために開発コスト増となる場面もありました。

ですが、最近だとLambdaのようなFaaSでも利用しやすいようAWSでのRDS Proxyのような仕組みもありますので今からサービスを構成していくにはRDBの採用も視野に入れやすいかと思います。

ミドルウェアアップデートへの強制的な追従

マネージドサービスの利点としても良く挙げられますが、クラウドベンダー側でミドルウェアのアップデートは自動的に行われます。そのため、サービス開発を進めながら自動アップデートによってサービスダウンしないよう適宜アプリケーション側もアップデート対応を進めなければならない点はデメリットでもあると感じています。実際に過去Lambdaでとあるランタイムのリリースが廃止され、緊急でバージョンアップ・リリース対応したケースもありました。こういった事象が発生しないようにするためにも、常日頃から情報のキャッチアップが必要なのはもちろんのこと、AWSから来る事前通知の連絡先と現場への展開フローの整備をおすすめします。

まとめ

以上、サーバーレスアーキテクチャでどのようにサービスを構築し運用・監視しているか、またサーバーレスアーキテクチャならではのメリット・デメリットついて紹介しました。

ZOZOテクノロジーズでは、AWSのマネージドサービスを最大限利用しながらBtoB事業のさらなる拡大に取り組んでいただける仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！

tech.zozo.com

カテゴリー