ビッグデータって本当にビッグなんだな【S3料金算出】
初めに
現状の機械学習パイプラインだと2カ月以上前のデータは削除されていて、何かミスがあったり確認したいことがあっても再現できない状況だった。
そこで、特徴量データと推論結果のバックアップを保持するためにまずコストを試算しようという話に。
絶賛AWSの資格勉強中だった私は喜んで試算させてほしいと手を挙げて今に至っています。
学び
- MLOpsの全体像を把握でき、自分がその一部を触れる環境に入れることを把握した
- S3の料金体系が「ストレージ料金 + リクエスト料金 + 取得データ容量」で決まることを理解した
- データ容量が小さいと何使っても大した金額にならない
- 保存データが500TBを超えたら大規模データといえるっぽいことを知りビッグデータのビッグさを実感した
やったこと
やったことは下記。
- 何を調べ/考え/成果物とすべきかという今回やることの全体像を把握
- 現状のパイプラインがどうなっているのかの把握
- 理想として何があるといいんだっけ？を思案
- S3料金計算
それぞれやったことを言語化していく。
全体像を把握
新しいことに挑戦するときは「目的、ゴール、手段」を明確にすることにしているのでそこからスタート。
目的は「どのデータを何に保存するとコスト・運用ともに最適化されるのかを考え提案すること」に決定。
ゴールは「現状と理想のギャップを把握すること」「それを埋めるには何が必要か把握すること」「それを埋めたときにかかるコストがいくらか把握すること」
...毎回「何をするか」を考えるときコンサルのように構造化してクリティカルなものから考えたいと思いつつ、誰でも思いつくようなことしかできないことに悩んでいたりします。
手段は「MLOpsのベストプラクティスを調べる」「現状のパイプラインをソースコードから読み解く」「AIに相談しながらギャップを把握・コストを試算する」
記事ではこれを頭でバシッと考えて走ったように書いていますが、実際は上記の６割程度が見えた時点で走り出している気がします。
「知らないこと多いしとりあえずやること見えたしやってみるか」の精神ではありますが、これがいいのか悪いのか判断がつかないことも悩みです。
状況によりけりだと思いつつ、どの状況ならこれ、という判断軸が自分の中に作り切れていない感覚です。
現状のパイプラインがどうなっているのか
現状はオフライン学習、バッチ推論モデルなのでハイパラ調整をしてLightGBMでモデルを作成、そのまま推論って流れ。
オンライン推論ならデータドリフトやモデル劣化があるからモデルレジストリを作りバージョンを管理しながらモデルを切り替えていく、という運用になりそうだなと思いつつ、
毎月定期的にデータの時間軸をずらして学習しているからこれらの問題はなさそうだしオンライン学習のように新しいデータが来るわけじゃないからモデルレジストリの必要性は低そうと判断。
ただやはり特徴量データと正解ラベル、推論結果がないと何もできなくなると思いそれらの保存は決定。
モデルそのものを保存したほうがいいかな？と思ったがシード値を固定しているから同じモデルは作ろうと思えば作れそう。
また、モデルを保持しておいて再度、もしくは新しいデータを推論する、という使い方はバッチ推論においてはなさそうだなと思い不要なのではと判断。要相談。
上記をバックアップ取ろうと思ったが思わぬところで致命的なものを発見。
正解ラベルとなる実績値を導く2要素がそのまま特徴量として入っていました。
ターゲットリーケージなのかな？こいつはターゲットそのものやそれを知っているからこそ計算できる情報が特徴量に入ること、って説明が多い気がしていて。
と思いAIに聞くと第三のパターンとして実績値を導ける値が特徴量に入ることも該当するそう。
思いがけず根本的な問題を見つけてしまいましたが、これ報告すればモデル構築に携われるのでは？とわくわくしています。
理想として何があるといいんだっけ？を思案
最初これをここでやろうと思ったのですが、現状把握と一緒にやったのであまりやりませんでした。
計画しても無駄になることが多々あり計画精度を上げていきたいなと思う所存。
S3料金計算
「特徴量データと正解ラベル」「推論後のデータ」の2つをバックアップを取ることにしたので、それらをどのくらいの期間どうやって保存するかを検討しました。
どのくらいバックアップ取るのが普通かわからなかったので「1カ月」「3か月」「半年」「1年」の4パターンを想定。
使い方として何かエラーがあった時の手戻りで使用することが考えられたので意外と低頻度アクセスかなと仮説を持ちました。
私が想像できていない使い方を考慮して「Standard」「Standard-IA」「OneZone-IA」「Glacier Instant Retrieval」の4ストレージタイプで試算しました。
月一以上でアクセスするならStandard、それ以下でかつ可用性が欲しいならStandard-IA、数時間から数日アクセスできないときができてもいいならOneZone-IA、3か月に1回程度しか触らないならGlacierって感じ。
データ容量の計算方法は1レコードの大まかなバイト数を試算して列数かけてCSVファイルの容量を出し、その後parquetで1/5に圧縮する想定で計算しました。
parquetは大まかに見ても1/10くらいには圧縮できるらしいのですが、企業的にはコストを大きく見積もって考えたほうがいいかなと思い控えめな圧縮率を想定。
月70GBくらい。これが毎月追加されてくる。
本当は実際のファイルをparquetで圧縮して容量を見たほうが正確なのですが、データが大きくSnowflakeとjupyterの連携に時間がかかるため諦めました。
AWSの料金は下記を参考に試算。
計算式は「GB単価データ容量 + 取得GB単価取得データ量 + リクエスト単価*回数」
したらばStandardですら1年バックアップ保存で21USD程度。
3000円くらい？お小遣いかな？
データ取得料金もGlacierですら月12回取ったとしても0.00024USD。
なんでこんなに安いんだ？計算ミスった？と思いましたがStandardの料金を見て納得しました。50TB未満ってめっちゃデータ小さい部類なんですね。
70GBなんていうデータ量はビッグデータ名乗るにはちょっと恥ずかしいレベル...
ビッグデータのビッグさを感じました。
それでも今回やるべきことは完了して、個人的にはStandardかStandard-IAのどっちかで良さそうっすねどのくらいの頻度でアクセスしそうです？と聞くだけでいいなと感じています。
多分IAでいいと思うけど、いかんせんコストが安すぎて逆に差別化しづらいという結果に。
とはいえAWSの料金試算がどうされているのか経験を積めたのはうれしいです。
感想
いや～仕事片付いてよかった～～～
ただ今の試算だとS3しか使わない想定になっており、もしSnowflakeやAthenaなどを使うとなったら追加でお金がかかりそう。
もっと早く気づけば今日中に聞けたのに...
来週頭に確認しなければ...
ということで、少しもやもやしていますが、休日はこれを思い出さないことを祈って今日は寝ます。
お疲れ様でした。
Discussion