初めに
こんにちわ。大田黒(おおたぐろ)です。暑い日が落ち着いてきて、秋(冬?)が来たなぁと感じるこの頃です。皆様いかがおすごしでしょうか。前回の「ABEJAの技術スタックを公開します (2019年11月版)」が公開されてからしばらく経ちました。
引き続きエンジニアの方とお話させていただく中で、
「ABEJAってよく聞くけど...実際どんなことやってるのかよくわからない」
「AIのお硬いSIerって感じなんでしょ?」
「社内は機械学習エンジニアばっかりなんでしょ...??」
といったご質問をいただくことが多いです。
今回の記事では、最新の会社や事業の状況を踏また2021年版事業・技術スタックの紹介ができればと思います。コンサルティングやプロダクト開発を両輪で進めているABEJAですが、特に今回はプロダクト事業部の提供するABEJA Insight for Retailの部分にフォーカスを当ててご紹介させていただきます。(他のプロダクトやソリューション事業部の詳しい部分はまた別記事で!)
特に、ABEJAやInsight for Retailに興味のあるエンジニアの方、ビジネスの方に読んでいただけると嬉しいですー!
会社・事業紹介
ABEJAは2012年から約9年間、機械学習・ネットワークやIoTデバイスを活用したソリューションやプロダクトの研究・開発・運用を行ってきました。200社を超えるAIコンサルティング・導入・運用実績を活かして、2021年9月現在では下記のような事業を展開しています。
AIプロダクト事業部
- ABEJA Insight for Retailの提供
- ABEJA Platformの提供
- ABEJA Platform Annotationの提供
AIソリューション事業部 (カスタマーサクセス統括部)
- DXコンサル・戦略策定・BPR
- AIアルゴリズム・モデル開発
- デジタル化・業務改革ソリューション開発
- etc
オフィスは2020年9月よりWeWork青山に拠点を移し、コロナ渦で事業を継続・拡大できるように様々な対応(リモートワークを基軸にした働き方等)を進めています。
今回は、ABEJA Insight for Retailを中心に技術スタックのご紹介ができればと思います。
※Insight for Retail以外のご紹介は次回以降の記事で執筆を予定しています。
ABEJA Insight for Retailについて
ABEJA Insight for Retailは、小売流通業向けのABEJAが提供するサービスの一つです。従来は取得の難しかった来店者の顧客属性・顧客行動等の情報。これらの情報をIoTxAI(主に画像解析)xBigDataxWebの技術を駆使する事で可視化・指標化し、お客様の店舗経営を支援しています。
事業部の開発チームでは、店舗内の映像を取得する為のカメラ設置からデータ解析をしてお客様にデータ提供するまでの一連のコンポーネントを全て社内で開発・運用しており、様々なコンポーネントが導入からデータデリバリーまでの流れを支えています。
技術スタック
全体アーキテクチャ図
Fig1: Insight for retailを構成するコンポーネント群
前回の記事(2019年の技術スタック)と比較すると、ざくっと下記のような差分があります.
- 全体的にインフラや足回りは、Kubernatesベースに変更。EKSやGKEを活用。
- データ基盤部分は、CloudComposer(Airflow) x BigQueryを基軸に再構成。
- WebダッシュボードにNext.jsを採用。
- ArgoCDを用いたデプロイプロセスに移行 (GitOpsへの移行)
- PagerDuty→OpsGenieへの移行
今回は、主要な各コンポーネントの役割・技術選定と2019年との差分部分にもフォーカスを当てつつ、改めてInsight For Retailのシステムについてご紹介できればと思います。
① 映像録画・解析システム
Fig2: 映像録画・解析システムのOverview
- 役割
- 店舗内NW機材との暗号化転送路の確立
- 店舗内IPカメラの映像録画 (NVR)
- 店舗内IPカメラ及びNW機材の監視
- 録画した映像のDeepLearningを用いた並列分散解析
映像の録画・解析システムですが、役割ベースとしては2019年公開版の記事とは大きく変わっていません。ただ、録画システム部分のインフラやコンテナ周りの足回りの構成はRancher v1→EKSに移行した事により大きく変わています。移行理由はいくつかありますが、下記が主な理由です。
- 社内でKubernatesが浸透してきて、ノウハウと技術的アセットが溜まってきた。
- 開発・運用に必要なスキルレベルを標準化し、Webワークロードと同様社内で扱いやすくしたかった
- Web系バックエンドエンジニアでも開発・運用に関与しやすい状態を作る
移行先はGKEでもEKSの両方を検討しましたが、店舗内画像解析や顔認証のエンジンが乗っているのが、ABEJA Platform及びAWSである為、クラウド・リージョン間のデータ転送量を考慮してEKSを選択しました。
Fig3: NVR部分のPOD構成 (物理機材・EKS部分の拡大)
録画部分の工夫点は、
店舗⇔クラウドNW部分・映像録画部分・IoTデバイス監視部分をコンテナベースで分離
- Separete Of Concern (関心の分離)により、各ドメインのテスタビリティと分業を加速。
- 部分的なリリースがしやすくなっている
映像録画、デバイス監視PODは、店舗⇔クラウド間の難しいNW周りを気にしなくてもOK
- 物理的に離れ論理的に壁が存在している2要素を同一のNWに乗っているように見せている (L2延伸的な)
- iptablesを用いた経路制御・NAT機能
- VXLANによるコンテナ間の通信カプセリング
- 物理的に離れ論理的に壁が存在している2要素を同一のNWに乗っているように見せている (L2延伸的な)
デバイスやNW伝送路の状態と品質を常にモニタリング。異常事態に備える。
- 要対応であれば社内サポートチームのGithubへ自動起票デバイス異常発生時の一時切り分けを自動化。
- 稼働実績に関わる情報の収集とBIツールによる可視化。細かな原因調査の効率化
- 取得データ例:IoTデバイスやNWの状態・各種品質指標、データ転送履歴等
上記の工夫により、たくさんの国内外のIPカメラの映像分析や数千台を超えるIoTデバイスの運用ができる様になっています。
解析部分のアーキテクチャは2019年から大きく変わっておらず、引き続きAIプラットフォームであるABEJA Platform上にMLモデルをサービングし、映像解析のパイプラインを構築しています。(MLモデルの性能は2019年から上がっており、お客様からご評価頂いているポイントの一つになります。)
②データ基盤部分
Fig4: データ基盤部分のOverview
- 役割
- IoTデバイスやお客様POSシステムからのデータを受け取る
- 認証認可、IPアドレス制限、RateLimit制御etc
- デバイスやデータの流れの監視
- 顧客・デバイス毎に異なるデータフォーマット(半構造化データ)の変換
- IoTデバイスやMLによる画像解析の結果を集計し、利活用できる形に変換。
- 非構造化データ・半構造化データ→構造化データへ。
- 例:店舗内の映像データ→入店イベントデータへ
- データの流れの監視
- データ品質に関わる事象が発生した場合に、サポートチームへのGithub起票
- IoTデバイスやお客様POSシステムからのデータを受け取る
Insight for Retailでは、IPカメラ以外にも店舗に設置しているセンサーがいくつかあります。代表的なモノとしては、入店カウントセンサーや棚等の前の滞在時間を測定するセンサー等です。カメラやセンサー以外にも、売上情報を取り込む為にお客様POSシステムとの連携もしています。店舗に関わる多種多様なデータが集まっている弊サービスですが、データは集めるだけでは意味がなく、お客様が意思決定シーン等で利活用できるように意味のあるデータに変換していく必要性があります。ここのデータ収集〜変換(集計等)を支えているのが、Insight for Retailのデータ基盤部分です。
- 構成技術
- Contorl Plane: ETL処理・ML適用の司令塔
- Datalake: 集計される生データの置き場
- DWH: データの集計環境
- DataMart: 集計済み・予測やクラスタリング済みデータの置き場
いくつか工夫ポイントはありますが、代表的な3つを記載します。
- 異常データや集計ロジックの異常に備え、冪等性担保 & 集計リトライが気軽にできるように
- デバイスや顧客システムのRTCが狂い西暦2036年からデータが来たり、間違えた消費税率がセットされたり等、様々な非日常が存在している。
- Airflow x BQの採用により、PythonとSQLが書けるデータサイエンスやバックエンドエンジニアであればガンガンロジックが追加・修正できるように。
- 顧客価値検証(主にSolution Problem FIT面)の検証を高速に。
- 検証・機能開発・運用フェーズの移行をシームレスに。
- Kedroを併用する事により、店舗データへのML適用をより簡単に。
- 店舗データ(来客人数・入店率・売上・年齢性別属性etc)の店舗クラスタリングや予測値がパイプライン全体で使えるようになり、顧客価値提供の幅が広がった
- ※kubeflowも良かったのですが、メンバーの学習運用コストや開発体験の観点でこちらをKedroを採用。
Insight for Retailを支えていたデータ基盤は、S3・Redshift・RDSをベースに、自作のDAGエンジンによって構成されていました。構成技術自体に問題は無いものの、より事業延伸ができる基盤のRemakeを2020年より開始し、現在ではGCPのコンポーネントを利活用した新しいデータ基盤が運用がスタートしています。
Insight for retailでは、手段としてIoTデバイスやAI・ML技術を多く利用しているサービスではありますが、データ利活用を進める為にも、データ基盤部分にも本気で取り組んでいます。
③ Webダッシュボード
Fig5: お客様が利活用するWebダッシュボード(テスト用店舗)
- 役割例
- 店舗運営に必要なデータの可視化機能の提供
- 意思決定に必要なデータ分析ができる機能の提供
- お客様が店舗内の施策を管理しやすくするための機能の提供
Webダッシュボードの役割としては、2019年からは大きく変わっていません。ただ、UIデザインや構成技術は変わっており、パフォーマンスや顧客体験面が大きく改善されています。
- Vue.js → React + Next.jsへのリプレイス
- フットプリントの削減
- 不要コードの削除
- Import部分の削除
- アセットファイルの見直し
- 不要なレンダリングの削除
- 非同期ロードの採用
- APIの見直し(リクエスト数削減)
詳しい工夫点等は、下記Qiita記事をご覧いただけますと幸いです!
その他 (全体共通部分)
インフラやアプリケーションの監視にDatadogを採用。
- インフラのメトリクスからアプリログまで一元的にして蓄積&分析できる土壌を構築
- 緊急度が高い異常はOpsgenieと連携
エラースタックトレースはSentryを採用
- バックエンド〜フロントエンドまで、アプリケーションに関わるエラーを一元的に蓄積&分析
- 顧客環境でのエラーを見逃さないようにする
ArgoCDによるGitOpsの採用
- リリース作業含めGithub上で完結。リリースに関わる変更履歴も残せるように。
- FYI: Secret等の機密情報をリポジトリに上げずに済むように、SealedSecretsといったソリューションを利用しています。
一緒に働く仲間を募集中!
現在、さらなる製品品質の向上や顧客提供価値を増やすという事に注力しており、事業を加速させる為のエンジニアを募集しております。IoT、ビッグデータ、AI(ML)に興味がある方、データを用いて顧客価値を届ける事にご興味がある方は、ぜひご一読くださいませ!!
※Ref: 下記ABEJA内でOpenになっているポジション一覧 hrmos.co
最後に
いかがでしたでしょうか。今回は、Insight for Retailを支える各コンポーネントの紹介と2019年時との差分についてご説明させていただきました。
ちなみに開発で使っている技術スタック一覧をStackShareにてまとめております。こちらもご確認いただけますと幸いです。
https://stackshare.io/abeja/abeja-insight-for-retail
「応募はしないけど、とりあえず話を聞きたいなー」でも超大歓迎ですので、その時は下記に気軽にご連絡ください!
※ちなみに、大田黒のTwitterDMにラフに連絡頂いても構いません。