はじめに
Databricks でクラスターを立ち上げる際にワーカーノードでスポットインスタンスを利用することも多いかと思います。
執筆時点では明示的にすべてオンデマンドインスタンスを使うような設定にしていない限り、デフォルトでスポットインスタンスを使うような設定になっています。
非常に便利ではあるもののメリット・デメリットもあるかとは思いましたので、私自身の実体験も交えながら今回 Tips として残しておきます。
前提条件
本記事では Databricks on AWS 前提で話していますが、他クラウドでも考え方はそこまで変わらないかと思います。
スポットインスタンスとは
スポットインスタンスは AWS クラウドのなかで、使われていない余ったリソースのことを借りる仕組みのことです。
オンデマンドのインスタンスよりも大幅に安い価格で利用可能になることがメリットにはなりますが、インスタンスの需要が高まると突如リソースが回収されて使えなくなることがあります。
そのため、途中で止まっても問題のないデータ処理やバッチ作業、検証用のアプリケーションに向いています。コストを抑えたいときや一時的な計算作業に便利な選択肢です。
実際に体験したこと
Databricks の Job や Delta live tables を活用して、ETLパイプラインを定期的に稼働させていました。
1回あたりの処理時間は通常約30分程度ではありますが、時々処理完了に倍近くの1時間かかったりすることがありました。
特にエラーが起きるわけでもなく、ソースコードなどその他の設定も何も変えておらず、処理するデータ量も毎回大きく変動するわけではないため時々起きるこの現象に不思議に思っていました。
ある時クラスターの Event log をチェックすると、倍近く処理時間がかかっている実行に対してのみスポットインスタンスが落ちていることに気づきます。
試しにスポットインスタンスを利用せず、パイプラインをすべてオンデマンドインスタンスを利用して実行するようにしたら処理時間は安定しました。
考察
もしDatabricks上で実行中のパイプラインでスポットインスタンスが途中に落ちた場合、欠けたワーカーノードの復旧と、再実行も自動的に行われてその分処理時間がのびてしまうのではと考えられます。
そのため、以下のような場合だとスポットインスタンスを控えてオンデマンドインスタンスを利用した方がよさそうです。
- 大規模なパイプライン
- 許容可能な処理時間がシビアに決められている
- 中断率の高いインスタンスタイプを使っている
- こちらで中断率は確認可能
インスタンス料金を安くすませるためにスポットインスタンスを使っているにも関わらず、処理時間が倍になりその分従量課金される金額が大きくなってしまえば本末転倒になりますね。。
逆に上記で当てはまれないような、一時的な作業などにはスポットインスタンスが向いているかと思います。
まとめ
Databricks ではクラスターの復旧や、パイプラインの再実行等も色々とよしなに自動的に行ってくれるので非常に便利ではありますが、何か問題があった際に遅れないようにこういった具体的な例もひとつ知っておくのもいいかと思います。
Databricks ではシステムテーブルに蓄積されるログ等も豊富なので、それらとアラート機能を活用して問題を検知していく仕組みもいいかと思います。