Architecture Example ①：車のボディへの塗装噴霧コントロール

本記事はMakuake Product Team Advent Calendar 2018の23日目の記事です。
今日は僕の誕生日です。誕生日の7時間をかけて書きました。笑

最初にdata lake managementの話をしたいので、ちょっとWEBから外れた話をします。（話題にする箇所のプロトコルはRESTですので許してください）車のボディにカラーを噴霧塗布する装置がありますが、その噴霧を最適化するための機械学習型コントローラの話です。

ここでしない話

以下は話題が組み込みに寄りすぎるんで割愛します。

噴霧機のコントロールI/Fの話
噴霧状況と、塗布クオリティを確認するセンサーのI/Fの話

塗料のデリケートさに関連するパラメータ

塗料は本当にデリケートで、どんなに均一に塗られた麺を見ても、X-Lay Scannerで見ると少なからずまだら模様になっています。こうしたマダラの薄いところから錆が浮いてきたり、厚いところの塗装がペラっと剥がれてきたり、ということが経年劣化とともに起こるのですが、均質な塗装は互いが補完しあって長持ちするとされており、そうした状態を目指して自動車の塗装工場では塗布機に様々な工夫が凝らされています。

天気
気温
湿度
定着照度
室内照度
ボディの表面温度
直前に塗布した塗料の付着率

など、様々なパラメータを解析しながら最適な噴霧量と噴霧圧を決めています。こうした噴霧クオリティの最適化を自動化するために、機械学習型を導入するというプロジェクトでした。サーモセンサー・X-Rayグラフ・Weather API・照度計など、様々なセンサーやpublic APIなど、様々なセンサーと接続し、データを集めます。昔はどんなセンサーもSerial接続でしたが、今はほぼみんなREST APIを持っています。便利な時代になったもんです。最終的な性能要件では、10秒単位で噴霧量と噴霧圧をコントロールし続けるとの希望です。

data lakeは要件の違う分起こすことになるが、解析自体はゆっくりでいいため、Proximateの段階で分けたりはしない。

性能要件の実現ジャーニーと切り分け

こうしたシステムの場合、要望として出る性能要件とセンサリングからのインプットを真に受けてストレートに実現しようという形ばかりが正解であるとは限りません。要は

入口：様々なセンサーのデータを取得している
出口：10秒単位で状況に応じた噴霧の最適化ができている

という点さえ克服できればいいわけです。あとは、エンジニアの自由です。これを実現するため、また、秒単位でドンドン蓄積していくデータを有効活用するため、という２軸があって、機械学習の導入が決まりました。具体的には以下の様なステップを設計します。

もれなく）センサーからのデータを収集
研究対象）データをモデリングしてdata lakeを生成し、raw dataはバックアップへ（バックアップはブラッシュアップが済んだら捨てる想定）
研究対象）噴霧データへのCalculate
正確性・回復性）噴霧コントローラ（1のデータも利用）
もれなく）噴霧状況のフィードバック → 1に戻る

こうした角度で設計をあらかじめ済ませておくと、どこを先に固く作って、どこを柔らかく始めれば良いかが見えてきます。また、１、４、５などの性能傾向が固い箇所は、それに合わせたアーキテクチャを採用し、できうる限り中に閉じた状態でシンプルに作り、他のシステムとの疎結合化を図ります。

黄色い箇所は実装の早い段階でArchitecture freezingし、ほぼ変更を加えない形とした。

||| 構造図 |||

data lake management

data lakeは「データを活用できる状態にすること」です。どう活用できる状態になっているべきなのかを管理するのがdata lake managementです。アーキテクチャ上は、溜まっているデータそのものに意味も価値もなくて、data lakeが済んだ状態で初めて価値が出ます。なので出自が同じデータでも、その活用の方向性や頻度によって、全く違う保存の仕方を複数のdata storeに対して行うことがよくあります。これは、入れたデータを万能に活用できるデータストアがまだ存在しないからです。データストアそれぞれが特徴的な性能傾向を有している2018年では、アプリケーションエンジニアにはそれらをうまく使い分ける動きが求められます。僕はよくdataの用途と傾向に合わせて

Faced（今目の前）
Proximate（計算しないでそのまま使う）
Calculatable（計算前のゴミ箱手前）
Calculated（計算後の即戦力）
Trash（ゴミ）

の4つのstatusを認識します。これをセンサーデータに当てはめるとこうなります。

Faced
- 室内照度
- ボディの表面温度
- 直前に塗布した塗料の付着率
Proximate
- 定着照度
- 天気
- 気温
- 湿度
Calculatable / Calculated
- 定着照度
- 天気
- 気温
- 湿度
- 室内照度
- ボディの表面温度

必ずしもmeceには分かれません。というか、meceには基本なりません。活用目的が違うと、データは別なものと捉えるべきだからです。そしてmeceでなければ、当然data to lakeに可逆性もありません。こうしたdataのライフサイクルがはっきりしているシステムはdata lakeが作りやすい。逆にいうと、データの活用を前面に押し出していきたいシステムであればあるほど、このデータ収集から活用までのステップを明確にすることが大切です。そして、ブラッシュアップポイント（変更が著しく性能に影響する箇所）をできるだけ小さく切り出すこと。これが、層の深いdata lake managementを求められるシステムアーキテクチャ設計のコツです。

この記事はシリーズです。

一緒に「世界をつなぎ、アタラシイを創る」エンジニアを募集しております。ご興味持っていただけた方は、「各種エンジニア募集！クラウドファンディングMakuake」からご連絡ください。