この記事は Enigmo Advent Calendar 2022 の 19 日目の記事です。

こんにちは、Webエンジニアの平井です。普段はSELLチームに所属していてBUYMAにおける出品者側の機能開発を担当しています。今回は、最近リリースしたカタログシステムをサーバレスアーキテクチャで開発したので利用した技術や学びについて書きたいと思います。

サーバレスアーキテクチャ

そもそもサーバレスアーキテクチャとは何でしょうか。人によって解釈は異なるかと思いますが、私はイベント駆動型のプログラム実行環境を利用してアプリケーションを開発するアーキテクチャだと理解しています。システムを開発していく上でサーバーを意識する必要が無いという特徴があります。ざっくりメリットとデメリットは以下が挙げられます。

メリット

サーバーを構築する手間が省けて、開発者がアプリケーションの開発に専念できる。
リソースの利用料金はコードを実行した時間に対して課金される。アイドル時間は課金されない。

デメリット

利用できる言語が限られている。
実行時間制限
- Lambdaだと最大15分

カタログシステムとは

次に今回開発したカタログシステムについて説明します。カタログシステムはBUYMAのカタログ出品機能のためのシステムです。カタログ出品機能は、出品者に対してBUYMA側で用意したカタログを提供することで、出品者の出品作業の効率化、高品質な画像の提供を目的としています。カタログ出品の大まかな流れは以下になります。

撮影チームが商品を撮影、画像をクラウドにアップロード
オペレーションチームが色名、型番の確認、サイズの計測を実施
1,2の情報をカタログシステムのAPI経由でデータ保存
4で保存したデータをAPIでBUYMA側に提供
BUYMA上のカタログ出品画面から出品者が適当なカタログを選択して、出品

以上の流れの3,4の部分(カタログデータの新規作成/更新、提供)をカタログシステムが担当していて、弊社のクラウドサービス利用実績よりAWS上に構築しました。

システム設計

詳細は省略していますが、以下がアーキテクチャ図になります。カタログデータ新規作成/更新はGoogle App ScriptからAPI経由で実行され、図の上部が該当部分です。カタログデータ提供もAPI経由で実現しています。

技術スタック

次にカタログシステムの開発に利用した技術、主にAWSのサービスについて紹介します。

サーバレスフレームワーク

まず、サーバレスフレームワークについてはSAMを利用しました。サーバレスフレームワークとはサーバレスアプリケーションを構築する上でInfrastructure as Codeを実現するためのものです。今回利用したSAMの特徴は以下になります。

サーバレスアプリケーション構築用のオープンソースフレームワーク
YAMLファイルでリソース管理
CloudFormation構文を拡張してサーバレスアプリケーションの構築が簡単になっている

サーバレスフレームワークにはSAMを含めて代表的な3つのサービスがあり、それぞれのメリット・デメリットは以下だと考えています。

SAM
- メリット
  - CloudFormationを抽象化したものなので, CloudFormationを知っていたら書きやすい。
- デメリット
  - 構文が若干冗長
serverless
- メリット
  - AWS, GCP, Azureで利用できる。
- デメリット
  - serverless独自の構文を覚える必要がある。
AWS CDK
- デメリット
  - ブログラミング言語で設定を記載できるが、可読性がyamlに比べると低い
  - ローカルでのテスト実行には、SAMを使う必要がある。やり方

今回、開発チームにCloudFormationの経験があるエンジニアが居た点、マルチクラウドに対応する必要がない点、ローカル環境での実行が簡単な点よりSAMを選択しました。

APIは一般的なAPI GatewayとLambdaの構成です。工夫した点としてはAPI GatewayとSwaggerのyamlファイルを連携してAPI定義するようにしました。以下のようにSwaggerで定義したyamlファイルのパスを指定することで連携できます。SwaggerでAPI定義するようにしたことでAPIを追加するためにはAPI定義yamlファイルを更新する必要があるため、API追加によるドキュメントの更新漏れを防ぐことができます。

Resources:
  Api:
    Type: AWS::Serverless::Api
    Properties:
      DefinitionBody:
        'Fn::Transform':
          Name: 'AWS::Include'
          Parameters:
            Location: api.yaml

カタログデータ新規作成、更新処理

カタログデータの新規作成、更新処理部分にはAWS Step Functionsを利用し、Lambdaをワークフロー的に実行しています。 AWS Step Functionsはワークフロー管理サービスでjsonでワークフローを定義します。AWS Step Functionsを導入してみて感じたメリット、デメリットは以下になります。

メリット

Step FunctionsのGUIがリッチである。
- ワークフローの全体像、各タスクの進行状況、ログ、成功状況がわかりやすい。
Lambdaを分割することで各Lambdaの凝集度が高まり、メンテナンス性があがる。
各Lambdaのリトライ設定が簡単。

デメリット

途中のLambdaで失敗した際のデータ整合性を考慮する必要がある。

個人的にはGUIがリッチな点が特に好きで、データ作成、更新処理に何か不具合がある際は基本的にこのGUIからデバッグを開始するため、デバッグが効率的になるようにタスク成功時の出力内容や失敗時の例外メッセージの内容を工夫して実装しました。以下が処理詳細画面で、左のアイコンをクリックすることで各タスクのInput, Outputも確認できます。

学び

最後に開発して得た学びについて書きたいと思います。まず、サーバレスアーキテクチャで開発して体感した良かった点、悪かった点は以下になります。

良かった点

開発者だけで構築できるリソースが多く、管理が不要なので開発体験が良かった。
AWSを利用した過去のユースケースが多く、参考にする情報に困らなかった。
- 公式ドキュメント
- Serverless Land

悪かった点

コードの共通化が難しい
- Lambda Layerを使えば可能そう。
- 今回の場合各Lambdaに共通するモデル定義は共通化したかった。

また、今回LambdaはPythonで開発しましたが開発初期は普段利用しているRubyとの言語的違いが原因で開発に時間がかかりました。 Lambdaの内58%がPythonを利用しているという情報を知り、メインの潮流に乗ったほうが良いと判断してPythonを選択しましたが、特にPythonを利用して良かった点が無かったのでスケジュールがかなりタイトな場合は普段慣れている言語を使ってもよいと思いました。

以上になります。

明日の記事の担当はエンジニアの池田さんです。お楽しみに

株式会社エニグモすべての求人一覧

hrmos.co