はじめに
こんにちは、計測プラットフォーム開発本部SREブロックの近藤です。普段はZOZOMATやZOZOGLASSなどの計測技術に関わるシステムの開発、運用に携わっています。
今年の夏に、ZOZOFITというサービスがローンチされました。このサービスは米国での展開を行い、日本ではあまり目にすることのないサービス名称だと思います。 ZOZOFITをローンチするにあたり、私達のチームではアーキテクチャを設計し、システム構築をすることになりました。
本記事では、ZOZOFITの開発時に遭遇した課題と対応方法について紹介します。
目次
ZOZOFITについて
ZOZOFITは、ZOZOSUITの計測技術を利用したサービスです。2022/11時点では、体型計測および身体3Dモデルのデータ・体脂肪率の表示機能を提供しています。
ZOZOFITの大きな特徴は、ZOZOMATやZOZOGLASSと異なり、ZOZOTOWNから完全に独立したサービスであることです。
システム構成
ここでは、ZOZOFITのシステム構成を紹介します。以下にネイティブアプリから呼び出される部分にフォーカスした、システム構成図を記載します。
ZOZOFITは既存の計測系サービスと同じく、AWSのEKSを採用しています。また、その他技術スタック部分も既存サービスと揃えていますが、米国向けかつZOZOTOWNから独立したサービスというZOZOFIT独自の特徴を持っています。
この特徴により、システム構成も既存とは異なる部分が生まれました。次節以降で、これらの異なる部分が生まれた背景について説明します。
既存の計測系サービスのシステム構成については、ZOZOMATのシステム構成のブログ記事が公開されているので、気になる方はこちらの記事をご参照ください。
レイテンシを考慮したAWSのリージョンの選定
計測プラットフォームでは、シングルクラスタ・マルチテナントの構成を前提としたEKSを運用しています。こちらの運用方針については、チームメンバーのブログ記事も公開されているので、気になる方はこちらの記事をご参照ください。
ZOZOFITは米国向けのサービスですが、別のリージョンにクラスタを構築すると運用方針からは外れることになります。このため当初はGlobalAcceleratorを利用し、日本国内のリージョンにシステムを構築することも検討していました。
日本国内にシステムを構築するにあたり、性能評価の前段階として、データの越境移転について法務に確認を取りました。
結論として、米国内で最も厳しいカリフォルニア州の個人情報保護法と照らし合わせ、サービス構築時点では問題ないことがわかりました。
法律的な面での懸念事項がクリアできたので、次はシステム面での懸念事項の検証に入りました。
日本国内に構築した場合における最大の懸念はレイテンシです。物理的な距離が遠くなれば、レイテンシに影響が出るのは避けられない問題です。 私達は実際にどの程度の影響が出るか、レイテンシに関して日本国内のリージョンと米国内のリージョンで比較検証を行いました。比較検証する米国内のリージョンは、ビジネスサイド側から顧客のターゲット層をヒアリングし、オレゴン（us-west-2）を利用することになりました。
速度検証には、AWS Global Accelerator 速度比較ツールを利用しました。
docs.aws.amazon.com speedtest.globalaccelerator.aws
| 通信サイズ | ap-northeast-1（東京） | us-west-2（オレゴン） |
|---|---|---|
| 50KB |  |
 |
| 100KB |  |
 |
| 1M |  |
 |
| 2M |  |
 |
検証の結果、GlobalAcceleratorによる改善効果は大きいものの、日本国内のリージョンを利用した場合、米国内のリージョンを利用した場合と比較すると、おおよそ1.5倍のレイテンシとなることがわかりました。この結果を受け、サービスにおけるレイテンシへの影響を考慮し、米国のリージョンにシステムを構築することになりました。比較検証を通して、通信における物理的な距離はレイテンシに大きな影響を与えることが改めてわかりました。また、オーバヘッドの具体的な数値を出すことでリージョンをスムーズに決められました。
認証機構の構築
ZOZOFITは、ZOZOTOWNから独立したサービスのため、ユーザーの認証機構を新規に構築する必要がありました。今回の認証機構ではシステム要件として多要素認証が求められており、私達はCognitoとAuth0のどちらを採用するかについて検討しました。
どちらも認証機構としての要件を満たしますが、ZOZOFITの開発は速度を求められていたこともあり、AWS内で完結でき導入・検証が即時にできるCognitoを採用することにしました。
開発中の課題
上述したように、ZOZOFITは米国のリージョンにシステムを構築することになりました。ここでは開発中に遭遇した課題の中でも、普段利用しない日本以外のリージョンを利用したことに起因した課題と対応方法について紹介します。
米国でSMSの送信時に必要な申請
認証機構の構築を進める中で、米国でCognitoからSMSを送信するには送信元IDの取得が必要であるとわかりました。送信元IDは、SMSの送信者が誰であるかを示すIDであり、国によって送信元IDとなり得るものが異なります。
今回は、米国で送信元IDとなりえる3種類（ShortCode、10DLC、TollFreeNumber）の中から、選択することになりました。なお、AWSでは、Pinpointというサービスで送信元IDを取得できます。
| 特徴 | ShortCode | TollFreeNumber | 10DLC |
|---|---|---|---|
| フォーマット | 5-6桁 | 10桁 | 10桁 |
| 事前審査 | 必要 | 不要 | 必要 |
| 発行にかかる予想日数（審査にかかる日数は含まない) | 12週間 | 即時 | 1週間 |
| スループット | 100/秒（有料で上限を上げることが可能) | 3/秒 | 最大100/秒(後述する審査結果により変動) |
| 必須キーワード | Opt-in, opt-out, and HELP | STOP, UNSTOP(オプトアウトおよびオプトインメッセージの変更不可) | Opt-in, opt-out, and HELP |
ZOZOFITの送信元IDの要件は、簡単にまとめると以下の3点でした。
- 2週間以内に利用を開始したい
- サービスの初期フェーズのため、秒間の最大リクエスト数は30を想定
- サインアップ・サインインに利用する経路で、キャリア都合でのブロックは回避したい
各送信元IDを比較し、要件にマッチした10DLCを利用することにしました。以下で、AWSのPinpointで10DLCを送信元IDとして利用する流れを説明します。
- 企業情報の登録
- 企業情報の審査
- キャンペーンの作成
- 10DLCの番号取得
正確には2を行わなずとも10DLCの番号は取得できますが、送信数に制約がかかります。このため、商用環境での利用に向けて事前にこれらの申請作業を行いました。
具体的に、送信数に関する制約は以下の図の通りです。 審査を受けなかった場合は75msg/min、2000/dayの上限となり、ZOZOFITの商用環境で利用するには厳しい数値でした。
（図はAWS公式ドキュメントからの引用）
なお、開発用途では、送信元IDとしてTollFreeNumberを利用する方針としています。 これは開発用途では送信数が限定的であることに加え、10DLCの取得時に登録する企業情報が同一だった場合、複数アカウントでQuotaが共有されるためです。
計測プラットフォームでは環境単位でAWSアカウントを分離しています。このため、複数の環境で送信元IDとして10DLCを利用した場合、本番環境に他環境での作業が影響してしまう危険があります。この問題を回避する為、本番と検証の設定に差分が生まれることを許容しました。
SMSの送信検証
認証機構の構築が進む中で実際にSMSの送信検証を行う際に、開発者の手元にある携帯電話を利用したところ、SMSが届かない問題に遭遇しました。調査を進める中で、SMSの配信失敗のエラーログを有効化したところ、以下のエラーメッセージがログに出力されていることがわかりました。
{ "numberOfMessageParts": 1, "destination": "xxxxxxxxxxxxx", "priceInUSD": 0.00831, "smsType": "Transactional", "providerResponse": "Phone carrier is currently unreachable/unavailable", "dwellTimeMs": 72, "dwellTimeMsUntilDeviceAck": 1526 }
エラーメッセージから、送信先のキャリアにSMSがそもそも届かないのではという懸念が生まれました。この問題に対して、米国の電話番号で検証し、原因が送信側か受信側かを切り分けをしようと考えました。この調査の為、米国の電話番号を取得することになりました。
取得する電話番号は、SMSの受信ができ、開発者が容易にメッセージを確認できる必要がありました。 これらの要件を満たす、TwilioとPinpointの2つから選択することにしました。 結論としては、新規でアカウントの発行管理が不要、かつ、コード管理がしやすいPinpointを利用することにしました。
取得した電話番号で検証した際、各所でのログ出力は以下の結果となりました。
| 調査対象 | 日本の携帯電話 | 米国の携帯電話 | Pinpointで取得した電話番号 |
|---|---|---|---|
| httpサーバログ | ○ | ○ | ○ |
| アプリケーションサーバログ | ○ | ○ | ○ |
| CloudTrail（CognitoのAPIの呼び出し履歴） | ○ | ○ | ○ |
| SMSの配信エラーログ | ○ | ✖️ | ✖️ |
| SMSの配信ログ | ✖️ | ✖️ | ✖️ |
調査の結果は、米国の電話番号であってもSMSが届かない状態でした。この結果から、Cognito側の設定もしくはアプリケーションの実装の問題である可能性が高いという判断になりました。
最終的には、Cognito側の設定であるauto verifyの設定が電話番号に対して有効になっておらず、SMSの送信が行われていないことが原因でした。日本の携帯電話の番号を登録した場合はエラーメッセージが出力されていたので、SMSの送信そのものは行われていると判断していました。調査の過程で、このエラーメッセージはSMSの送信段階で出力されているのではなく、CognitoのUserPoolのデータが更新された際に行われる内部的な処理の中で出力されていることがわかりました。
なお、このトラブルを解決する過程でPinpointによって取得した番号をSNSTopicに紐づけられることがわかりました。これは検証用途でSMSのメッセージを取得する方法として活用できました。
振り返り
今回、ZOZOFITの開発では既存サービスと異なる部分があり、チームとして新しい知見獲得の機会を得られました。反面、知見のない問題に遭遇しましたが、チーム全体で前向きに対応を進めることで解決出来ました。
リージョンの選定方法やSMS送信時の制約、ユーザの認証基盤をゼロから構築したことも、開発チームにとって大きな経験となりました。
最後に付け加えると、ZOZOFITは2022年の夏にローンチするという大きな目標がありました。この大きな目標に向け、チームとして知見の低い課題に対する対応が様々な場所で求められましたが、地道に検証を行い、結果を調査することで着実に前に進められました。この結果、大きなトラブルなくZOZOFITをローンチできました。
終わりに
計測プラットフォーム開発本部では、今回紹介させていただいたZOZOFITのように、日本国内に限らず新しいサービスを開発していく予定です。
今回、ZOZOFITの開発チーム構成には触れませんでしたが、ZOZO New Zealand、ZOZO Apparel USA、ZOZOの3つの組織での共同開発となっています。技術力以外に英語によるコミュニケーション能力も求められますが、このような環境を楽しみ、サービスを一緒に盛り上げていける方を募集しています。少しでもご興味のある方は以下のリンクからぜひご応募ください。
