データサイエンティストの生産性を高めるキスモのクラウド資源の使い方
こんにちは！キスモインターン生の岡野です。
5月にインフラのインターンが1人増えまして、オンプレに関してはある程度お願いしてしまい、僕自身は現在クラウドの管理に注力しています。
5月から7月くらいでAWSの現状把握からTerraformを利用したコード化、DevOps系作業としての自動化および今回ブログで紹介するクラウド資源のオンデマンドな運用に着手していました。
本記事に載せる内容以外の部分についても今後紹介していけたらなと思います！
なんでクラウド資源？？？
前回のブログにも記述したようにキスモでは現状、機械学習にはオンプレミスの資源を利用しています。
しかし、おかげさまで案件も少しずつ増えてまいりまして計算資源が少し足りないという状況となってしまいました。この時に省力化をもう一段階進めようという話になりました（現状のオンプレはRancher 2.0を利用していることもあり、ぽちぽち作業が少し多い）。k8sをもっと柔軟に使う施策についてももっと進めていけたらなと思いますがすぐにどうこうなるという話ではなさそうです。
以上の理由からキスモではクラウド資源も併用しようという結論に至りました。
キスモで実現したいインフラ管理
1コマンドで終わる環境構築
これに尽きるわけです。
データサイエンティストがやりたい仕事はデータの処理であって、環境構築であったりAWSコンソールのぽちぽち作業ではありません。TerraformとCIツールを使って自動化していたとしてもプルリクを投げて承認をもらうという作業が付きまといます。そもそもJSONを書いてもらうのさえ得策だとは考えません。
このことからキスモで目指すべきインフラというのは「コマンド1つ入力したら環境構築がされていて、データが揃っているという環境を作り出すこと」です。
なお、これにはセキュリティ的なメリットも副次的に発生します。
具体的にはデータサイエンティストにIaaSインスタンスの作成や削除に関わる権限を直接与えなくていいという点です。この部分をアプリケーション側で吸収することが可能で、ミスがミスじゃなくなる環境づくりに向けて前進しているなと実感しました。
機能要件
とはいえこんなものを作るのは正直言って時間がかかるなぁという印象を受けたので、ある程度要件を簡易化して作業を行いました。その中で実現したものが以下のものです。
- 前処理を行なったデータのあるディレクトリを指定すると起動するインスタンスにデータがアップロードされる。
- インスタンスはコマンドから指定可能。
- ローカルの環境は可能な限り汚さない。
- 作成完了、作業終了時にSlackに通知が飛ぶ。
- 使っていない資源を見つけてアラートを出す。
非機能要件
機能以外のところでも目指した部分はいくつかありますのでご紹介します。
- "pay as you go"を最大限に実現する。
- インフラエンジニアがいなくても運用可能。
- 拡張、開発が容易。
実現方法
AWSが提供しているFaaSであるLambdaを利用してシステムの構築を行いました。
アーキテクチャはこんな感じです！
FaaSを利用することで起動等のアプリケーションの運用コストをほぼ0にしました。
100万リクエストあるいは400 GB-秒のメモリ割り当てまでは無料で運用できるというのはかなり嬉しい部分です。
具体的にはPythonのAWS用SDKであるboto3やawscliを利用することで実装がなされています。アーキテクチャ的にはデータのアップロードとインスタンスの起動は分かれているのですが、実際には1コマンドにまとめてあります。
全体として、認証情報は環境変数や外部からのマウント、クラウド資源に権限を直接アタッチすることで実現しています。結果として、ソースコードやリポジトリに認証情報は一切含まれず、セキュアな状態が保たれています。
awscliの使い方
awscliはPythonで実装されているので、多くのPython環境を行き来するデータサイエンティストが利用するのはあまり得策ではないと考えました。そこでコンテナを利用することで環境が汚れることを回避しています。具体的にはローカルからデータをS3に与える際に利用しています。
インスタンス起動
データはハードコーディング的に埋め込むことはせず、環境変数で定義しています。環境変数にはインスタンス起動時に実行されるシェルスクリプトであるユーザデータも含みます。なお、改行等の扱いが面倒臭かったためにシェルスクリプトは一旦BASE64にエンコードしています。このユーザデータを利用してS3にあるデータの取得や流動的な部分の環境の構築を行なっています。
開発するにあたり、環境変数やユーザデータの定義が少しずつ面倒臭くなったためにユーザデータは独立ファイルに切り離し、デプロイスクリプトに含め、自動的にLambda用の形式に変換されるようにしています。なお、デプロイにはlambda-uploaderを利用しています。
Slack通知
通知にはSlackを利用しました。社内にチャット文化は根付いていますし、メンションされた場合にはチャットを見るということは徹底されています。ここに通知を貯めればひとまず問題ないと判断しています。
SageMaker、なぜ使わない？
この辺りまで来るとAWSを使っているのになぜSageMakerを使わないのかという話になってきます。
これについてはサービスとして継続的に利用している機械学習モデルでないことや、現在キスモで利用している省力化手法とSageMakerの相性があまり良くなかったという理由が挙げられます。とはいえめちゃくちゃ大きな問題というわけではないですし、SageMaker自体はとても便利なものであるということに違いはないので将来的に利用しているという可能性は多いにあるのかなという印象を持っています。
利用方法
現状はこんなような形で利用してもらっています。 場合によってはインタラクティブにしないかもしれないですが、その辺りは方針を見定めて決めていければいいなと思っています。
動作監視について
これに関しては現状は最低限となっています。具体的には毎時メモリ利用率の監視をしています。メモリ利用率が閾値を割った場合に処理を行います。これについては勤務中と勤務外で挙動は分かれるようになっています。これもLambdaで実装しています。
勤務中→Slackに該当ユーザ向けのメンションを送信する。
勤務時間外→2回連続でメモリ利用率が低かった場合にインスタンスを停止する。
なお、停止インスタンスに関しては勤務時間になると起動するようになっています。現状は出力ファイルが一意に定まるわけではないみたいなので推論終了時にS3にアップロードしてインスタンス削除という方法に関しては実装できていません。
勤務時間外のLambdaはステートを利用した処理が必要になってくるわけですが、これに関してはS3を利用しています。理由としては処理に速度が求められないことから価格面を最優先したためです。他の方法だとLambdaマネージドのキャッシュやElastiCache、DynamoDBを使うような解決策があります。
これからの開発について
最低限利用できる状態としては現在のものでも提供されていますが、実現しなければならないものはまだまだいくつも存在します。
具体的には、
- 金銭見積もり機能の実装。
- OSイメージのコード化およびCI。
- 機械学習実行環境としてのコンテナ利用。
というようなことが挙げられます。
今後もデータサイエンティストが使いやすい技術資本を作っていけたらなと思います。
おわりに
今回はキスモの社内省力化に向けて行なってきたクラウド資源の利用方法について紹介しました。
FaaSやコンテナを駆使したクラウドネイティブな基盤構築ができたんじゃないかなと自分では思っています。
それではまた、何かまとまれば技術発信できればいいなと思っています。
ここまでお読みいただき、ありがとうございました！
