AWS Glue StudioでVisual ETLの編集作業をする際はインタラクティブセッションの課金に注意しよう
初めに
先日AWS Glue StudioのVisual ETLを利用した検証記事を執筆させて頂きました。
Glue Studio自体初めて使うので事前に料金はある程度確認しており、ジョブが最低2DPUで動かさないといけないし最初の何回かはデフォルトの10DPUなので多少料金は嵩むかな？と思っていたら思ってたより料金がかかっていたので少しびっくりしてました。
※ とは言いつつ1日検証して$6ちょっとなので実数値で見れば極端に高くはないが違和感という感じ。
料金明細を確認したところちょっと思ったのと違う場所に料金がかかっており、今後気をつけないと個人で検証するには思ったよりすごい料金がかかってるんだけど！！！になりそうだったので懺悔メモとして残しておきます。
Glue Studio(Visual ETL利用)の料金
ざっくり料金ページはここになります。
...主にETLジョブとインタラクティブセッションが該当するのですが色々な項目があり初めて触る人はパッと判断するのは難しそうです。
今回の実際の請求ベース(初めにセクション)で見ると主にかかってる項目は以下の通りです。あくまで今回の設定(ほぼデフォルト)であり実際の設定や利用により異なる点はご注意ください。
- Sparkのジョブ実行による課金(Visual ETL画面右上のRunを押す等でジョブを実行)
- Glue 5.1以下であれば$0.44/DPU、Glue 6.0以降であれば$0.308
- $0.44 per DPU-hour for each Apache Spark or Spark Streaming job, billed per second with a 1-minute minimum
- $0.308 per DPU-hour for each Apache Spark or Spark Streaming job, billed per second with a 1-minute minimum (Glue version 6.0 and above)
- Glue 5.1以下であれば$0.44/DPU、Glue 6.0以降であれば$0.308
- インタラクティブセッションによる課金(今回の問題)
- Glue 5.1以下であれば$0.44/DPU、Glue 6.0以降であれば$0.308
- $0.44 per DPU-hour for each Apache Spark or Spark Streaming job, billed per second with a 1-minute minimum
- $0.308 per DPU-hour for each Apache Spark or Spark Streaming job, billed per second with a 1-minute minimum (Glue version 6.0 and above)
- Glue 5.1以下であれば$0.44/DPU、Glue 6.0以降であれば$0.308
DPUはざっくりGlueでSparkを取り扱う処理ワーカーの基本単位(4vCPU/8GB RAM)でこれが１時間実行される場合の料金です。
該当ジョブの設定でGlue 6.0を利用、Worker typeをG 1X(4vCPU/16GB RAM)、ワーカー数を２(最小値)で30分ジョブが走るとすると$0.308 * 1(DPU) * 2(worker) * 0.5(h)で$0.308発生します。
前日実行した小規模なテスト用ジョブですと起動時間を含めても１〜2分程度でそこまでの回数起動してないので料金はかからない想定でした。改めて明細を見てもこの部分は$0.62程です。
大きくかかったのは見落としていたインタラクティブセッションによるものとなります。
ビジュアルエディタ自体には料金は発生しないが...
この料金どこで発生したかと言いますとVisual ETLによる編集画面となります。
エディタの利用自体には料金はかからないのですが画面を開いた瞬間にインタラクティブセッションが発生し、明示的にこのウィンドウを表示している間＋αその料金が発生します。
今回初めて触るサービス＋メモを兼ねてのブログを作成して長期開きっぱなしにしていたため必要以上にここでコストが発生していました。
探してみると弊社内でもVisual ETL側ではなくNotebook側で同じことをやっていた先駆者様がいらっしゃるようでした...。先駆者はいるもののやらかさないとそれに辿りつかないので難しいですね...。
インタラクティブセッションはVisual ETL上ですと実際に指定したデータをサンプルとして読み込み保存した際等のデータのプレビュー表示や出力スキーマの補完自動推定等をやってくれます。
セッション中は入力するデータを変えたり、各種途中の加工処理を変えた場合に各種コンポーネト部分をいい感じに変えてくれるのでETLの調整を素早く行うことができます。
非常に便利ではあるのですがデータソースの配置の設定を済ませた状態でエディタを開くと自動的に開始するため、初めて触る人は意識せずに料金を発生させてしまう可能性があります。
幸いGet Startedから開いたばかり等でノードが何も配置されていない状態では開始せず、またその状態からノードを配置しただけでは開始しないのでその点は安心です(逆に言えば最初ちょっと触って料金かからずもうちょっと触ってみようかの時に踏み抜く可能性はちょっと怖いのですが)。
先ほど記載した先駆者様のTipsで有効な対策はこちらにも同様に横展開可能...と思いきやVisual ETLの場合はスクリプトを直接触れず取れない対策もあるため被害を軽減する方法は限定されます。
余分なコスト発生の軽減に向けて意識しておくと良さそうなこと
Glue 6.0以上の利用に切り替える
現在Get Startから作成した場合デフォルトではGlue 5.1となっております。
先に記載させていただきましたがGlue 5.1以下からGlue 6.0(現在の最新)ではDPUあたりの料金が異なり、これだけで時間あたり30%ほどのコストカットが可能となります($.44/DPU→$0.308/DPU)。
中の各種ミドルウェアのバージョン等変わる部分もあるためどのバージョンを使うかはプロジェクトによるかと思いますが、初めて触ってみます、検証で使ってイメージ掴みたいですということであれば6.0にしておくことでこれだけでコスト削減になります。
セッションは"アイドル"になってから30分でタイムアウトになる
先に記載したNotebookの事例ではスクリプト側で%idol_timeoutを設定することでそもそものタイムアウト時間を短縮できたようですが、Visual ETLの場合はスクリプトを触れないのでこの設定ができません。
一応ジョブの詳細画面でジョブ自体のタイムアウト時間設定はあったのですが、あくまでジョブの設定でインタラクティブセッション側には作用しませんでした(1分ほどに短縮して画面を閉じてみたけど継続)。
https://docs.aws.amazon.com/ja_jp/glue/latest/dg/job-editor-features.html
非常に大きなデータセットがあり、データのプレビュー用のデータのクエリに 15 分以上かかる場合、リクエストはタイムアウトします。データプレビューには 30 分の IDLE タイムアウトがあります。これを軽減するために、データセットのサイズを小さくして、データプレビューを使用できます。
現時点で新規のVisual ETLを開始した場合は"アイドル"タイムアウトは30分固定の仕様となっているようです。なので画面を閉じてさえしまえば最悪30分でインタラクティブセッションは停止します。
注意する点としてはあくまでアイドルタイムアウトですので画面を開きっぱなしにしたりするとこのセッション止まりませんし、ちょっと作業して別のことをやったりするとタイマーがリセットされます。
なのでインタラクティブセッションを張っている状態で画面でもたついてると30分(1800秒)を超えて動き続けます。
検証で触るような温度感であれば、不要な時にセッションを停止するというよりは必要な時だけセッションを立ち上げるという意識でいた方が良さそうです。セッション自体はデータプレビューなどのEnd Sessionから行えます。
画面表示直後等で自動でセッションが開始された直後はプレビューが一度表示されるまで終了できないのですが、ここで読み込まれるデータが大きいと終了できるまでに時間がかかるので少し注意が必要かもしれません。
いろいろな作業を並行していると開いてる状態に気づかず放置してしまうリスクもあるので、閉じることを意識しましょう。
このタイムアウト自体は弄れなさそうなので基本的には注意するくらいになってしまいます。多発するようであれば別の仕組みで定期的にインタラクティブセッションを落とすような仕組みを自前で用意した方が良さそうです。
また具体的な条件は見つけられなかったのですが同じETLの編集画面を開くと基本的には以前のセッションが使われるようですがある程度時間を空けてアクセスすると、以前のセッションがアクティブで残ってるのにも関わらず新規のセッションが張られる場合がありました。前のセッションが落ちるまで２本分のセッションの金額がかかるので注意が必要そうです。
Glue Usage Profilesの利用は難しそう
AWS GlueにはUsage Profileというものがありこれを利用することで利用可能なワーカーやセッションタイムアウトのデフォルト値最小値最大値等もろもろを定義することができます。
割り当て単位は作成した対象のIAMユーザやIAMロールのタグとしてglue:UsageProfileというタグでプロファイル名を指定すれば良いという形なので、同じアカウント内で複数環境が同居するようなケースでも検証用で使うユーザには小さいワーカーかつ短いタイムアウト許容値とし、本番用は大きなワーカーかつ長いタイムアウトを許容するような柔軟な設定が可能です。
お、これ使えば対策できやん。
と思ったのですがエラーとして許容しているタイムアウト値外の値が指定されているエラーが発生し、実際にセッションが立ちあがろうとした形跡もなかったので、現時点の仕様としてはアイドルタイムアウト30分を固定で立ち上げるというのは回避できない仕様のようです。
逆に言えばこの値を小さめの値にしておけば設定を変更しない限りVisual ETL上でセッションが立ち上がらないので無用なコストは発生しないのですが、それはそれで編集にかなり制限がかかるので実務向けとしては利用は難しそうです。
(なんらかをトリガーに数値や割り当てプロファイルを変えるような仕組みを自前で作ればできるかもしれないが...)
終わりに
Glue StudioのVisual ETLで不用意にコストを発生させてしまった懺悔を兼ねた記録となりました。
Visual ETLは機能としてSpark理解しなくてもある程度のETL構築ができる便利なサービスですが、ジョブの実行だけではなくそれを実現するためのプレビュー等でSparkが走っているのを忘れてはいけません。
Notebookであればパラメーターで制御できるものの、こちら場合はそのパラメーターは触れない関係で「注意する」という対策しかなく、それも人が関与する以上100%ではないので、少し毛色は違いますがマネージド領域が増える分のコストとして割り切るなり、管理者側でそれをなんとかするための仕組みを実装する(管理コスト↑)で割り切らないといけなさそうです。
