エムスリーエンジニアリンググループの遠藤(@en_ken) / 佐々木です。私達はBIRというチームでアンケートシステム周りの開発を担当しています。
BIRでは、独自で実施したアンケート調査結果を使った製薬会社等のマーケティング支援する事業を行っています。 その事業の中では、調査結果をそのまま提供するだけではなく、加工することでデータの価値向上を図っており、 そのデータ加工方法として機械学習を使ったプログラムも利用しています。
今回は、そのプログラム実行を含めた全体のプロセスの改善した話を経緯も交えて紹介したいと思います。
これまでのプロセス
調査結果をもとに機械学習プログラムを用いた商品をクライアントまで納品する場合、以下の手順が必要になります。
- 調査結果のクレンジング(不正なデータの除去、整形,etc...)
- プログラムを実行
- 結果の妥当性検証
- 可視化するダッシュボード(Tableau)を作成
- 可視化結果や分析基盤(BigQuery)を用いて納品物の最終確認(QA)
2で実行しているプログラムはBIRとは別のデータ分析グループが開発・運用しており、図にすると以下のような流れとなっていました。
上記のプロセスでは、次の問題が発生していました。
チーム間のやりとり
BIRからデータ分析グループへの依頼が必要なプロセスとなっていたため、 実行までのコミュニケーションコストが高いことに加え、データ分析グループの業務量次第で結果を受け取るまで時間がかかることがありました。
実行環境
対象の機械学習の実行プログラムは、高スペックのマシンをフルに稼働させて1時間以上かかるような処理です。 例えば、疾患に関する調査結果をもとにプログラムを実行する場合、この処理を疾患の数だけ行う必要があります。 しかしながら、データ分析グループの運用環境はPoCの環境を元にし高頻度な実行を想定していなかったため、複数疾患の計算は直列で実行するしかなく、実施完了するまで日をまたぐケースも発生していました。
最終確認
5の手順で、前提となるデータのミス等がないかをBIRで確認しますが、これまでのプロセスではデータ分析グループの妥当性検証が全て終わってからデータを受け取っていたため、BIRでの結果確認開始が後ろ倒しになり、納品までのリードタイムが長くなっていました。
変更後のプロセス
こうした問題点を解消するため、以下のプロセス変更を目指すことにしました。
処理結果の妥当性検証のみは現状判断が難しいためデータ分析グループに依頼しますが、それ以外の実施はすべてBIRで行う方針としました。この変更により、以下ようなメリットが期待できました。
プログラム実行をBIRが行うことで、実行に伴うチーム間のすり合わせ作業のコミュニケーションコストを無くすことができます。唯一依頼が必要な妥当性検証は、結果を共有するのみで良いため、複雑なやり取りが不要となります。
調査結果のクレンジングから結果の格納までの処理をチーム内でコントロールできるため、一連の作業を連動させてほぼ自動化できます。
実行をBIRで行うことで、ダッシュボードの作成+最終確認を妥当性確認と並行して行うことができ、納品までの所要時間の短縮が見込めます。
加えて、プロセス改善とは異なりますが、プログラムの実行を必要なだけ並列実行できるようにすることで、実行ケース数が増えてもプログラム実行にかかる時間を一定にすることを目指しました。
実現のためにやったこと
責務の分担
改善後のプロセスでは、機械学習プログラムの実行作業もBIRで引き取ることになります。 しかしながら、実行プログラム自体の開発・メンテナンスをBIRで行うのはリソース的に難しい面があるため、引き続きデータ分析グループでメンテナンスして貰う必要がありました。 そこで、今回、実行プログラムはそのままで手を加えず、実行基盤のみBIRで構築するという方針を取りました。
具体的には、図のように、既存の実行プログラムはそのままデータ分析グループに開発をしてもらい、BIRでは、新たな実行環境の構築と、そこで実行可能になるように環境要因を吸収するラッパープログラムを作成する責務分割を行いました。
ラッパープログラムは端的に説明すれば、実行プログラムのI/Fを変えずに依存関係が内部に閉じるように作ったコンテナイメージです。 実行プログラム自体にはBIRからは手を加えないので、実行プログラムの外部仕様が変わらない限り、各チームが実行プログラム自体の開発・運用と実行環境の運用を独立して行うことができるようにしました。
実行環境
プログラム実行を並列で実行できる環境を構築するため、AWS上に実行環境を移行することとし、実行基盤としてはAWS Batchを選択しました。
AWS Batchの選択理由
AWS Batchはざっくりいうと、ECSの前段にSQSが配置されたようなサービスです。(クラスメソッドさんの記事の図がとてもわかりやすい。)
今回実行環境に求められる要件は、
- 実行環境を必要に応じてスケールできること
- 実行終了後のインスタンスの停止漏れがないこと(必要なインスタンスタイプの料金が高額で、停止漏れ時のコストが馬鹿にならないため)
でした。当初は自力でEC2を必要数立ててその上での実行を管理することも検討しましたが、停止漏れのリスクを考えるとオーケストレーション周りの管理はマネージドなサービスで行うことが妥当と判断しました。
要件を満たす上ではEC2起動タイプのECS上で構築すれば必要十分ではありましたが、AWS Batchを選択した理由は未経験のサービスに触れてみたかったという側面が大きいです。当初の目論見としては、EC2スポットインスタンス利用によるコスト低減も検討していたため、そのあたりの制御設定が簡易にできそうなことにもメリットを感じました。ただし、後述する理由により、今回のユースケースはスポットインスタンスの利用には向いておらず、こちらの恩恵は受けられませんでした。
EC2スポットインスタンスの導入可否
当初、コスト低減のためスポットインスタンスの導入を検討していました。 しかし、スポットインスタンスはその挙動として需要に応じてインスタンスが自動的に終了する可能性があります。したがって、中断しても再度割り当てたときに途中から処理を再開できるように処理を組む必要がありました。
対象の実行プログラムは中断を想定した設計にはなっておらず、今回は方針としてプログラム自体には手を入れないで実行環境のみを移植することを前提としていたため、オンデマンドインスタンスを選択することとしました。
改善結果
プロセス変更の結果、BIRの都合で機械学習プログラムの実行が可能となり、調査結果のクレンジングからダッシュボードのバックグラウンドとなるBigQueryへの連携作業までをほぼ自動化できるようになりました。 また、実行基盤の並列化が可能となったことで、プログラム実行が必要な疾患のデータ数に関わらず、同じ時間で完了するようになりました。
その結果、過去には7日程度計算時間がかかっていた商品に関して、1日で推計が終わるようになりました。 また、BIRのビジネスサイドの人間が新規にクライアントに対して商品を提案する際も、これまでは1疾患あたり最速でも4日程度のリードタイムをとっていたところが、2日程度のリードタイムを見込めば提供できることとなり、商品の提案のサイクルを劇的に早めることができました。
まとめ
チーム間にまたがったプロセスの改善し、効率的な実行環境を整えるためにやったことを紹介しました。
環境の整備によって、既存の納品プロセス自体をスムーズにできたことはもちろんですが、 機械学習プログラムの実行が手軽に可能になったことで、次期商材の検討作業にも利用されるようになっており、効果を実感しています。
技術的な面でも、触ったことがなかったAWS Batchを利用できたことに加え、 すでにあるAWSの環境ではなく普段あまりいじらないVPC構成含め全てイチから実行環境構築作業をしたこともあり、学びの多い取り組みでした。
We are hiring!!
弊社では環境を整備してチームの生産性を爆増させるエンジニアを募集してます！ 以下のURLからカジュアル面談をお待ちしています！
