インターンでAWS ECSを使って機械学習プログラムを自動化した話 | Geppoプロダクトブログ

こんにちは！従業員のコンディション変化発見ツールのGeppoで6月から2ヶ月ほどインターンとして働いていた中村哲史です。

Geppo - 個人と組織の課題を見える化するツール

現在、南カリフォルニア大学3年生でコンピューターサイエンスとビジネスを勉強しています。

今回はインターン期間中にやったことの中で一番苦労した、機械学習を用いたデータ分析の自動化について書いていきます。
データ分析の内容自体は自分で作ったものではないのでここでは触れず、あくまでプログラムの自動化部分に集中しようと思います。

動機

データサイエンティストがせっかく機械学習を使用したデータ分析プログラムを開発したのに、プログラムの専門性の高さから開発した本人しか使い方が分からないという問題がありました。

そこで、モデルの学習および学習済みモデルを用いた解析を自動化し、結果をデータベースに保存しておくことでプロダクトチームの誰でも分析結果を有効活用できるようにしました。

構成の検討

今回の件では前提条件として、
・モデルの学習に使用するデータや分析対象のデータがAWS Redshiftに保存されている
・これらデータをAWSのプライベートネットワークの外に出すのはセキュリティリスクがある
ということからAWS内で完結できる自動化の方法を探りました。

結果として、以下4つの案が出てきました。
・AWS Lambdaのファンクションとしてデータ分析プログラムを入れておき、CloudWatchから定期的に実行
・EC2のインスタンスを作成し、その中で定期的にデータ分析を実行
・ECSタスクでEC2インスタンスを使用しDockerコンテナ化された分析プログラムを定期的に実行
・ECSタスクでFargateを使用し、Dockerコンテナ化された分析プログラムを定期的に実行

クラウドの知識がゼロの状態からリサーチを始めた僕からすると、どの案も苦労して考えついた思い入れのある案だったのですが、1つに選ばなければいけないということなので、仕方なく案を比較しました。

ECSでFargate案はサーバー管理の手間がかからず運用が楽です。また、計算リソースもタスクによって柔軟に割り当てでき無駄がありません。Dockerコンテナを使うことで使用できる言語やミドルウェアの幅が広いため、拡張性も抜群です。コスト面でも、自動解析を実行するときにだけコンテナを立ち上げ、タスクが終了後にコンテナも停止するため、余分な料金がかかりません。

上記の通り、様々な面で他の案よりも優れているECSでFargateを使用する方法を取ることになりました。

開発

最終的な自動化の構成は以下の画像の通りです。

CloudWatchが全体のコントロールをしており、イベントルールを使用して定期的にECSタスクを実行します。

ECSタスクが呼び出されると、ECR内にDockerイメージ化として保存されている分析プログラムをECSが読み込みDockerコンテナを立ち上げます。
分析プログラムが終了次第、コンテナも終了してECSタスク完了となります。

この一連のECSタスクの起動から終了までをCloudWatchがもう一つのイベントルールを使用して監視、異常を検知するとLambdaを通してSlackに通知するという仕組みです。

こうしてグラフにしてしまうと単純な構成に見えてしまいますが、実際の開発は苦悩の日々でした。

イカツイ技術を手なずける

インターン期間中に取り組むプロジェクトを決めかねている時、上司の方から
「AWS上でモデルの学習を自動化してほしい。データはRedshiftに入ってるから」と言われ、ポカーンとしたのを覚えています。
大学2年が終わったばっかの若造からすると何言ってんだこの人状態でした。

AWSに加えて、今まで名前は知ってたけど何か難しそうだからいいや、で全く触れてこなかった技術（SQLとかDockerとか）が数多く必要なことがわかり、絶望感に苛まれていました…

ただ、しっかり正面から向き合ってドキュメントを読んでいくと、思っていたほど難しくなかったりして。周りのエンジニアの方達の助けもあって、なんとかプロジェクトが進んでいきました。

名前からして難しそうな技術たちを理解して、実際に何かを作り上げた経験や、大概の技術は思ってるより怖くないんだと感じれたことは本当にいい経験になりました。

ローカルテスト環境は最初に作ろうね、最後じゃなくて

データベースなんて触ったことすら無かった僕は、なんかよく理解してないまま触ったらデータ飛んじゃいそうとか勝手に思っていました。

なので上司からの複数にわたる「テストのためにローカルでデータベース建てたら？」という助言を華麗にかわし、毎テストをAWSで行い、結果大量の時間を無駄にすることに。

Dockerイメージ内のPythonファイルを一行変えるだけで、
・Dockerイメージを作り直す（Dockerfileの書き方が微妙で5分）
・AWS ECRにイメージをアップロードする（5分）
・ECSタスクを実行し、テスト（さらに5分）
という工程を作り上げてしまい、1テストに合計15分ほどかかるという・・・

15分かけてテストしたプログラムが誤字でこけた時の絶望感は凄かった・・・
まあその待ち時間を使って、Tableauとじゃれていたので大分Tableauが上手くなりました。結果オーライです。

開発終了後、他のエンジニアの方達がすぐに動作確認できるよう、結局ローカルでデータベースを作ることに・・・
テスト、サクサクになりました。
しかもやってみたら意外と簡単でした。

教訓：ローカルテスト環境作りましょうね、最初に

〜〜〜〜〜〜〜〜〜

結論として、データ分析の自動化には成功。
毎朝Slackでバグ通知が来ていないことを確認しては、胸を撫でおろしています。

上に書いた開発経験だけでなく、まともに働いたことが無かった学生の僕からすると働くということ自体が面白い経験でした。

何かを作ってはレビューされ、そこから改善を繰り返すというのは短期的な宿題やテストがベースの大学では中々味わえない経験であり、とても勉強になりました。
知識も経験もゼロの僕に色々と挑戦させてくれたGeppoの方々には感謝しかないです。

大学に戻ったら今回の経験を自慢しようと思ってます。俺、SQL書けるんだぜ。Dockerコンテナ作れるんだぜ。みたいな。

訂正：タイトルが間違って「ECR」になっていたので「ECS」に直しました。