はじめに
こんにちは。計測プラットフォーム開発本部バックエンドチームの佐次田です。普段はZOZOMATやZOZOMETRYなどの計測技術に関わるシステムの開発、運用に携わっています。
本記事では計測システムにおける計測データの管理方法を進化させた点についてご紹介します。
目次
計測プラットフォーム開発本部 バックエンドチームとは
計測プラットフォーム開発本部バックエンドチームは、ZOZOMAT、ZOZOGLASS、ZOZOSUITによって採集される計測データにまつわるバックエンド開発を担うチームです。アプリやブラウザに対するクライアントAPIや、ZOZOTOWN内部のマイクロサービスのAPIにおいて、徹底的に低レイテンシにこだわりを持つことと、高可用性を保つことを目指しています。
ユビキタス言語
本記事を読む上で必要なユビキタス言語は以下の通りです。
3Dデータ
3Dデータは、被計測者の体型などを3次元で表現するデータです。ZOZOSUITやZOZOMATなどで共通の計測技術を利用して生成されるデータであり、計測時点での身体情報の3D表示を可能とします。ZOZOSUITの場合は被計測者の体型を、ZOZOMATの場合は被計測者の足型を3Dで表現します。
計測箇所
計測箇所は計測の対象となる各部位のことを指します。ZOZOSUITの場合は腕周りや首周り、ZOZOMATの場合は足幅や足長など複数箇所を計測箇所として定義しています。
計測値
計測箇所ごとに計測された数値データを計測値として扱います。
ZOZOMETRYとは
ZOZOMETRYとは、事業者の採寸業務を効率化し、採寸が必要な服の売上拡大やコスト削減に貢献するサービスです。多様な業種のビジネスニーズに応えられるよう、計測箇所を柔軟に選択できます。ファッションに限らず、フィットネスや医療、スポーツなど幅広い業種に対応できるように設計されています。
ZOZOMETRYのコア機能
ZOZOMETRYのコア機能として、身体計測を実現する機能と、計測データの管理機能があります。身体計測の機能は計測技術により手軽に高精度な計測を実現する機能であり、直近のリリースによりZOZOSUITの着用無しでも計測が可能となりました。計測データの管理機能は計測データの保存、参照、エクスポートなどを行う機能で、計測データの管理を効率化し、より重要な業務に集中できるように設計されています。しかし、身体計測の機能を顧客企業向けに提供するには計測箇所の柔軟なカスタマイズが必要であり、これまでの構成では難しい問題がありました。初めに既存プロダクトにおいてどのような構成で身体計測の機能を提供していたかと、ZOZOMETRYにおいて計測箇所をカスタマイズするために必要だった構成についてご紹介します。
計測箇所のカスタマイズに関する課題
ZOZOMETRYではビジネスニーズに合わせて顧客企業ごとに計測箇所の柔軟なカスタマイズを行えることが重要でした。既存プロダクトでは固定の計測箇所を定義していたため、顧客企業ごとの要望に対応することが難しい状況でした。例えば、ウエストという計測箇所は顧客企業によってはウエストを腰骨の位置から何センチ上で定義しているなど細かな差異があり、1つのウエストという定義では個別の要求に対応できない課題がありました。
計測処理はアプリ内に内包されているSDKにより行われており、内部的には身体をスキャンする処理と計測値を算出する処理が行われています。この構成の場合、計測箇所を追加・編集するにはアプリの更新が必要でした。
計測処理をサーバーが担当する解決アプローチ
計測箇所をカスタマイズ可能とするため、3Dデータの生成と計測値を算出する責務をアプリとサーバーで分離するアプローチを取りました。具体的な方法は割愛しますが、計測値の算出処理をサーバー側に移動することで、計測箇所の追加や更新によるアプリの更新が不要になる想定でした。
システム構成図
既存プロダクトとZOZOMETRYでのシステム構成図の比較は以下の通りです。
既存プロダクトのシステム構成
ZOZOMETRYにおけるシステム構成
システム構成の変更点
アプリ内で行っていた計測値の算出処理をサーバーが担当するように変更しました。また、3Dデータと計測値の保存先はユースケースに合わせて分離する構成を取りました。
計測セットを元に計測箇所をカスタマイズする
計測セットは先述のカスタマイズした計測箇所をさらに顧客企業ごとに必要な計測箇所のまとまりとして定義する機能であり、これにより計測ごとに必要な計測箇所を顧客企業が自由に編集できるようにする機能です。ドメインモデルとしては、以下のような構成となっています。
計測セットのドメインモデル
計測シーケンスの概要
サーバーは計測セットに含まれる計測箇所を元に計測値の算出処理を行います。このアプローチにより、顧客機能のビジネスニーズに合わせた計測処理の提供が可能となりました。
3Dデータと計測値の保存先を分離する
既存プロダクトでは3Dデータと計測値を単一の保存先に格納、管理していましたが、3Dデータと計測値はそれぞれ異なる特性を持っており、それぞれの特性に合わせた最適な保存先を検討する必要がありました。3Dデータは不変である特性を持ち、一度作成されると変更されることがありません。扱いとしてはファイルや画像などと同様に管理することが良いと考え、管理にはAWSが提供するS3を利用しました。S3については多くの記事で紹介されているためここでは割愛しますがパフォーマンスとセキュリティ、可用性の面で優れており、3Dデータの管理に適していると考えました。計測値は3Dデータとは異なり、計測データを管理するコア機能において参照されるユースケースが多くあります。計測を一覧表示する機能や、計測データをCSVエクスポートする機能など、計測値を参照し結合して返す必要がありました。そのため、計測値の管理にはリレーショナルデータベースであるRDSを採用することにしました。
3DデータをAPIサーバーで管理する課題
3Dデータの管理にS3を利用することを決定しましたが、3DデータのS3へのアップロード、ダウンロードをAPIサーバーを経由して行うことに課題がありました。
ペイロードのサイズが大きい
3Dデータはサイズが大きいため、被計測者に計測データを返す際のパフォーマンスが課題でした。ZOZOMATについては3Dデータの送信に対して通信プロトコルを変更するアプローチで対応しました。詳細については下記の記事をご参照ください。
通信プロトコルを変更することで一定の効果を得ましたが、API経由のスキャンデータのアップロードに時間がかかるなどサイズが大きいことによる課題は残り続けていました。
GC(Garbage Collection)によるパフォーマンスの低下
私たちバックエンドチームではプログラミング言語にScalaを採用しています。技術戦略については下記の記事をご参照ください。
既存プロダクトでは3Dデータを参照するたびにAPIサーバーを経由してデータを取得します。もちろん、計測データを専用に扱うサーバーを別で建てるように分離することも検討しましたが、初期の設計では立ち上げ期という事情も働き、モノリシックな構成でローンチしています。ScalaはJVM上で動作するためメモリの解放時にGCが発生します。サイズの大きな3Dデータをメモリに繰り返しロードすることでGCも頻発し、パフォーマンスに影響を与える問題がありました。
署名付きURLによる解決アプローチ
署名付きURLとは
署名付きURLはAWS S3バケットに対して一時的なアクセス権限を付与するURLです。これにより、特定のオブジェクトに対して指定された時間内に限り、読み取りまたは書き込みの操作が可能です。
APIサーバーを経由せずに3Dデータのやり取りを可能とする
3Dデータはサイズが大きいためAPIサーバーを経由せずにクライアントとデータのやり取りをすることが重要となりました。署名付きURLを利用することで、APIサーバーに負荷をかけずセキュアにS3へのアップロードを実現できます。
署名付きURLを利用した3Dデータのアップロード
APIサーバーを経由する場合
署名付きURLを利用した場合
クライアントとサーバーのやり取りは署名付きURLの発行手続きのみとなり、3DデータのアップロードはクライアントとS3の間で直接行われます。このアプローチによりAPIサーバーの負荷を軽減し、APIサーバーのスケーリングに依存せずデータのやり取りが可能となりました。
署名付きURLを利用した3Dデータのダウンロード
APIサーバーを経由する場合
署名付きURLを利用した場合
アップロードと同様に、クライアントとサーバーのやり取りは署名付きURLの発行手続きのみとなり、3DデータのダウンロードはクライアントとS3の間で直接行われます。ダウンロードの場合は署名付きURLをstatus code 302で返し、ダウンロード用のリンクにリダイレクトするようにクライアントに返します。これにより、ブラウザが自動的にリダイレクトを処理するため、クライアント側での実装負担を削減できます。
署名付きURLを利用したメリット
署名付きURLを利用することで以下のメリットがありました。
- パフォーマンスの向上
- 3DデータをAPIサーバーを経由せずにやり取りすることで、APIサーバーの負荷が軽減されました
- コストの削減
- APIサーバーを経由せずに3Dデータがやり取りできるため、サーバーリソースの節約が可能となりました
- APIサーバーの実装をシンプルに
- 署名付きURLを利用することでAPIサーバーの実装がシンプルになり、開発やメンテナンスが容易になりました
一方で、署名付きURLを用いたデメリットとして、クライアントでは1回のアップロード操作に対して、署名付きURLの発行リクエストと実際のデータアップロードリクエストの2回のリクエストを処理する必要があります。署名付きURLを多く使用する場合はクライアントの処理が煩雑になるため、実装に注意が必要です。
まとめ
ビジネスニーズに合わせて計測処理をサーバーで管理することで、計測箇所の追加や変更のニーズに対応可能となりました。3Dデータと計測値を分離し、それぞれの特性に応じた最適な管理方法を検討しました。また、クライアントとサーバー間の3Dデータの受け渡しに署名付きURLを活用することでAPIサーバーの負荷を軽減しました。
ZOZOMETRYはローンチ後も引き続き機能追加をしており、計測データの管理方法について検討を続けていきたいと考えています。
最後に
計測プラットフォーム開発本部バックエンドチームでは、グローバルに計測技術を開発していくバックエンドエンジニアを募集しています。ご興味のある方は、以下のリンクからぜひご応募ください！
