Amazon Web Services ブログ

Wind Mobility がサーバーレスデータアーキテクチャを構築した方法

Wind Mobility の BI 部門の責任者である Pablo Giner 氏によるゲスト投稿です。

ここ数年、都市部におけるマイクロモビリティが注目を集めています。汚染指数が歴史的な高さとなっていることから、世界中の都市や企業が規制を導入し、状況を改善するための幅広い解決策に取り組んできました。

Wind Mobility では、近距離移動のための都市部における交通手段を世界中の都市に提供することにより、通勤者の生活をより持続可能かつ便利なものにすることに注力しています。

Wind Mobility では、ユーザーの要求に合わせてサービスをスケーリングし、経済的かつ環境的に実行可能な方法でサービスを提供しています。実際に使用される数よりも多くの電動キックボードを配置することで都市が混雑するのを避けるために、電動キックボードがひとまとまりで配置される数を最適化し、ユーザーが必要とする場所の近くに、かつ、ユーザーが必要とするときに電動キックボードを配置します。

これを実現するにはどうすればよいでしょうか? その答えは、業務を最大限に最適化する、ということです。そのためには、さまざまな条件下でのユーザーの行動について十分な情報を得て、まとまって配置される電動キックボードがどの程度の需要に対応できるのかを理解する必要があります。

急成長を支えるスケーラビリティと柔軟性

当社では、この課題を解決するに先立ち、ユーザーによるアプリケーションとのインタラクション、ユーザーの需要、電動キックボードからの IoT 信号、運用メトリクスなど、さまざまなソースからデータを収集する必要があることを認識していました。収集された多数のデータセットを分析し、実用的な洞察を抽出するには、データレイクを構築する必要がありました。大まかな目標は明確でしたが、対象となる範囲はそれほど明確ではありませんでした。新しい市場の開拓を続けつつ、当社は事業の拡大に懸命に取り組んでいました。急速な成長と拡大により、消費する必要のあるデータの量を予測することが非常に困難になりました。また、当社では、成長を支える新しいマイクロサービスを立ち上げました。その結果、より多くのデータソースの取り込みが必要となりました。当社がアジャイルに活動することを実現し、かつ、迅速な採用が可能な、当社の成長に対応できるアーキテクチャが必要でした。サーバーレスアーキテクチャがこれらのニーズを満たすのに最適であることが判明したことから、当社は、完全にサーバーレスのインフラストラクチャの設計を開始しました。

最初の課題は、現場での電動キックボード、モバイルアプリからのイベント、運用メトリクス、およびパートナー API からのデータの取り込みと保存でした。当社は、AWS Lambda を使用して、運用データベースとモバイルアプリの変更をキャプチャし、イベントを Amazon Kinesis Data Streams にプッシュします。これにより、リアルタイムでアクションを実行できます。また、Amazon Kinesis Data Firehose を使用して、当社が分析に使用する Amazon Simple Storage Service (Amazon S3) にデータを書き込みます。

Amazon S3 にアクセスし、最も一般的なユースケースに従って適切にパーティション分割した後 (当社は、データソースに応じて、日付、地域、およびビジネスラインでパーティション化しました)、データプロファイリング (構造、内容、および相互関係の理解のため) およびアドホック分析を行うためにこのデータをクエリする方法を見つける必要がありました。そのために、データをカタログ化するために AWS Glue クローラーを選択し、AWS Glue データカタログから読み取ってクエリを実行するために Amazon Athena を選択しました。しかし、当社では、アドホック分析とデータプロファイリングは、当社のチームでは比較的散発的なタスクです。なぜなら、データ処理のコンピューティング時間のほとんどは、実際には複数のデータソースをデータウェアハウスに変換し、生データを統合し、モデリングし、新しい属性を追加し、データ要素を選択することに費やされており、これらが分析と予測のニーズの 95% を占めているからです。

この部分に多くの労力が割かれています。日々生成される数百万の電動キックボードおよびユーザーイベント (毎秒 300 を超える数のイベント) を解析して、実用的な洞察を抽出します。当社は、このタスクを実行するために AWS Glue を選択しました。主な ETL ジョブは、新しく追加された生イベントデータを Amazon S3 から読み取り、Apache Spark を使用して処理し、Amazon Redshift データウェアハウスに結果を書き込みます。AWS Glue は、需要に合わせてスケーリングする当社の能力において重要な役割を果たします。慎重な評価とテストの結果、当社は、AWS Glue ETL ジョブがすべてのニーズを満たし、インフラストラクチャの調達と管理から解放してくれるものであるとの結論に至りました。

アーキテクチャの概要

次の図は、現在のデータアーキテクチャを表しており、2 つのサーバーレスデータ収集、処理、およびレポートパイプラインを示しています。

  • Amazon Relational Database Service (Amazon RDS) および MongoDB の運用データベース
  • IoT およびアプリケーションイベント、その後にデータプロファイリング用の Athena、レポート用の Amazon Redshift が続きます

AWS Glue で実行されている自動パイプラインを使用して、1 日に数回、データのキュレーションと変換が行われます。チームは、データの分析と機械学習 (ML) アプリケーションの構築に注力できるようになりました。

当社は、運用 KPI を視覚化して理解するのに役立つビジネスインテリジェンスツールとして Amazon QuickSight を選択しました。さらに、カスタム ML アルゴリズムを含む Docker イメージを保存するためにAmazon Elastic Container Registry (Amazon ECR) を使用するとともに、ML モデルをトレーニングし、評価し、ホストする Amazon Elastic Container Service (Amazon ECS) を使用します。モデルのトレーニングと評価が 1 日に複数回行われるようにスケジュールしています。当社は、電動キックボードの需要、コンバージョン、および流れに関するキュレーションされた入力データを使用してモデルを実行することで、特定の都市において、いつでも、まとめて配置する電動キックボードの数を最適化できるようにしています。

次の図は、データレイクからのデータが ML のトレーニング、テスト、および提供システムにどのように組み込まれるのかを表しています。最初に、デベロッパーがアプリケーションコードで作業し、変更をコミットします。これは、当社の CI/CD パイプラインによって新しい Docker イメージに組み込まれ、Amazon ECR レジストリに保存されます。これらのイメージは、Amazon ECS にプッシュされ、(これらのイメージが Amazon ECS タスクスケジューラによってトリガーされる) PROD に移行する前に、DEV および UAT 環境でテストされます。実行中に、Amazon ECS タスク (一部は需要と利用率予測モデルをトレーニングし、一部は 1 日あたりの予測および 1 時間あたりの予測を生成し、他は予測を満たすためにひとまとまりで配置する電動キックボードの数を最適化します) が設定を読み取り、Amazon S3 からデータ (以前にスケジュールされた AWS Glue ジョブによって生成されたもの) をプルし、最終的に結果を Amazon S3 に保存します。これらのパイプラインの実行は、(専用の Amazon Elastic Compute Cloud (Amazon EC2) サーバー内の) MLFlow を介して追跡され、ひとまとまりでの配置に関するオペレーションを示す最終的な結果が Kepler マップに当てはめられ、現場のオペレーターによって利用されます。

まとめ

Wind Mobility では、データを非常に重要視しています。そのため、当社は、当社が事業活動を行う業界、そして、当社の事業環境において求められるのと同程度に柔軟なデータインフラストラクチャを必要としていることから、サーバーレスを選択しました。1 年の間に、データレイク、データウェアハウス、BI スイート、およびさまざまな (本稼働している) データサイエンスアプリケーションが構築されました。これらはすべて、非常に小規模なチームで実行されました。

また、過去 12 か月間において、勢いを落としたり、アーキテクチャの一部を再設計したりすることなく、データパイプラインのいくつかを 10 倍に拡大しました。電動キックボードをひとまとまりで配置する場所を 1 週間で 2 倍にし、電動キックボードからデータをキャプチャする頻度を 10 倍に増やした際にも、サーバーレスデータアーキテクチャを問題なく拡張できました。これにより、オペレーションを簡素化し、変化に迅速に対応し、ユーザーに喜んでいただくことで、付加価値を高めることに注力できました。

当社では、複数の視点から自社の成功を測定してみました。

  • 速さ – サーバーレスでは、より高速なデプロイおよび拡張が可能です。当社では、インフラストラクチャ全体の市場投入までの時間を 2 分の 1 に短縮できたと考えています。
  • 可視性 – 世界各国におけるオペレーションを完全に可視化し、各都市のマネージャー、財務チーム、および管理委員会がアクセスできるようになっています。
  • ひとまとまりで配置する電動キックボードの数の最適化 – 当社は、お客様が今後数時間のうちに必要とする電動キックボードの数をいつでも把握できるため、需要が満たされない状況を 50% を超えて削減できます。

当社と同様の課題に直面した場合における当社のアドバイスは明白です。完全にサーバーレスに移行し、AWS で利用可能なさまざまなソリューションを利用してください。

Facebook、Instagram、LinkedIn で当社をフォローして、Wind Mobility の詳細をぜひご覧ください。

 

著者について

Pablo Giner 氏は、Wind Mobility の BI 部門の責任者です。Pablo 氏は、これまで車両関連の業務に従事してきており (オートバイレース > 車両工学 > 衝突保険 > 電動キックボードシェアリングなど)、過去数年間、データチームの形成と開発を専門としています。Wind Mobility では、データ関連部門 (データエンジニアリング + 分析 + データサイエンス) を率いており、最も誇りに思っているプロジェクトは、スマートフリートリバランシングと呼ばれる、リアルタイムで電動キックボードのひとまとまりの配置のバランスを調整する AI を利用したソリューションです。「私たちは神を信じます。他の人々にはデータが必要なのです」– W. Edward Deming