はじめのProfessional Cloud Data Engineer認定取得講座㉑Cloud StorageのAutoclass、Dataflow Primeの垂直スケーリング、Wranglerについて説明します！

今回も、Professional Cloud Data Engineer認定取得するために、私が勉強した内容をアウトプットしていきます。

今回は、Cloud StorageのAutoclass、Dataflow Primeの垂直スケーリング、Wranglerについて説明します！

ぜひ、最後までご覧いただけると嬉しいです！

Cloud StorageのAutoclass

Autoclassは、バケット内のオブジェクトへのアクセスパターンに応じて、ストレージクラスを自動的に最適化してくれる機能です。

主な目的は2つあります。

1. コスト削減：長期間アクセスされていないデータを、自動的に安価なストレージクラス（Nearline、Coldline、Archiveなど）へ移動させ、保管コストを削減します。
2. パフォーマンス維持：データに再びアクセスがあった際には、即座にStandard ストレージへ戻し、読み取りパフォーマンスの低下を防ぎます。

これにより、開発者は複雑なライフサイクルポリシーを手動で設定・管理する手間から解放され、ストレージ運用の自動化を実現できます。

Autoclassの仕組みと挙動

Autoclassがどのようにオブジェクトを管理するのか、その具体的な振る舞いを説明します。

オブジェクトの初期配置

Autoclassが有効なバケットに追加されたオブジェクトは、常にStandard ストレージとして保存されます。たとえアップロード時に別のストレージクラスを指定しても、その指定は無視され、Standard ストレージとして扱われます。

移行ルール：アクセス頻度に応じた自動遷移

Autoclassの核となるのが、アクセス頻度に基づくストレージクラスの自動移行ルールです。

※：ターミナルストレージクラス（最もコールドなクラス）としてArchiveが設定されている場合に適用されます。Nearlineに設定している場合は、30日未アクセスでNearlineに移行された後、それ以上コールドなクラスにはなりません。

その他の重要な注意点

• 128 KiB未満の小さなオブジェクトは、アクセス頻度に関わらず常にStandard ストレージに保持され、コールドストレージへは移行しません。
• オブジェクトのメタデータの読み書きは「アクセス」とは見なされず、ストレージクラスの移行トリガーにはなりません。
• 削除（バージョニングにより保持）されたオブジェクトは、復元されるまでストレージクラスは変更されません。復元されるとStandard ストレージに戻ります。
• クラスの移行は非同期で実行されるため、条件を満たしてから実際に移行が完了するまでには遅延が発生する可能性があります。

料金体系について

Autoclassを利用する際は、通常のストレージ料金に加えて、以下の料金要素を理解しておく必要があります。

• 管理料金 (Management Fee)：Autoclassが有効なバケット内のオブジェクト量に応じて発生する料金です。
• 有効化料金 (Enablement Fee)：Autoclassを有効化する際に一度だけ課金されます。
• 操作料金：オブジェクトの読み書きなどの操作は、常にStandard ストレージの料金が適用されます。また、Autoclassによるクラス移行（例: Nearline → Standard）が発生した際にも、クラスA操作相当の料金がかかる場合があります。

これらの追加料金があるため、Autoclassによって得られるコスト削減効果が、これらの料金を上回るかどうかを検討することが重要です。

既存バケットへの導入と設定変更

有効化

既存のバケットでAutoclassを有効にすると、バケット内の全オブジェクトがStandard ストレージに移行されます。この移行処理後、30日間アクセスがなければ、そこからNearline ストレージへの移行が開始されます。

無効化

Autoclassを無効化すると、オブジェクトの自動移行は停止します。各オブジェクトは、その時点のストレージクラスを保持し続け、以降は手動での管理が必要になります。なお、一度無効化すると、1日間は再有効化できません。

ターミナルストレージクラスの変更

Autoclassがデータを移行する最もコールドなクラス（NearlineまたはArchive）は変更可能です。

• Archive → Nearlineに変更：ArchiveやColdlineにあるオブジェクトは、Nearlineに移行されます。
• Nearline → Archiveに変更：Nearlineにあるオブジェクトは、通常の移行ルールに従い、アクセスがなければ将来的にColdline、Archiveへと移行します。

Autoclassはどんな時に使うべき？

Autoclassは万能ではありません。利用に適したシナリオと、そうでないシナリオを理解しましょう。

適しているケース

• アクセスパターンが予測不能で、ホットとコールドが頻繁に入れ替わるデータ。
• 最初は頻繁にアクセスされるが、時間経過とともにアクセスが減少していくログデータなど。
• ライフサイクル管理の手間を削減し、運用を自動化したい場合。

避けた方がよいケース

• データの大部分が常にアクセスされる、または全くアクセスされない（アーカイブ専用）など、アクセスパターンが固定的な場合。
• Autoclassの管理料金などの追加コストが、ストレージクラス最適化によるコスト削減効果を上回ってしまう場合。

運用上の注意点とモニタリング

Autoclass導入後は、その動作を正しくモニタリングすることが推奨されます。

• Cloud Monitoring：autoclass/transition_operation_count（移行回数）やautoclass/transitioned_bytes_count（移行データ量）といった指標で、移行の状況を可視化できます。
• ライフサイクルルールとの競合：Autoclass有効化中は、ストレージクラスを変更するライフサイクルルール (SetStorageClass) は設定できません。
• 非互換性：階層型名前空間が有効なバケットでは、Autoclassは利用できません。

Cloud StorageのAutoclassのまとめ

Cloud StorageのAutoclassは、オブジェクトのアクセス頻度に応じてストレージクラスを自動で最適化し、コスト削減と運用負荷の軽減を両立させる強力な機能です。

ただし、独自の料金体系やいくつかの制約があるため、自身のユースケースのアクセスパターンやコストモデルを分析した上で、導入を検討することが成功の鍵となります。変動的なアクセスパターンを持つデータの管理に悩んでいる方は、ぜひ一度Autoclassの導入を検討してみてはいかがでしょうか。

Dataflow Primeの垂直スケーリング

Dataflowでパイプラインを運用していると、「突然のデータスパイクでメモリが足りなくなり、ジョブが失敗してしまった」「安全のために大きめのメモリを確保しているが、コストが気になる」といった課題に直面することがあります。

これらの課題を解決する強力な機能が、Dataflow Primeに搭載された垂直スケーリング (Vertical Autoscaling) です。この記事では、垂直スケーリングの仕組みから設定方法、運用の注意点までを分かりやすく解説します。

Dataflow Primeと垂直スケーリングとは？

Dataflow Primeは、Dataflowの運用をさらに自動化・効率化するための新しいモードです。その中核機能の一つが垂直スケーリングです。

従来のDataflowのオートスケーリングは、ワーカー（VM）の数を増減させる水平スケーリングでした。それに対し、垂直スケーリングはワーカー1台あたりのメモリ量を動的に調整します。

これにより、メモリ不足（Out-of-Memory, OOM）によるジョブの失敗を防ぎつつ、リソースを過剰に確保することなく、コスト効率の高いパイプライン運用を実現します。垂直スケーリングは水平スケーリングと連携して動作し、リソースの全体最適化を図ります。

垂直スケーリングの動作原理

垂直スケーリングは、ストリーミングパイプラインとバッチパイプラインで挙動が異なります。

ストリーミングパイプラインでの動作

• デフォルトで有効：Dataflow Primeを利用するストリーミングジョブでは、垂直スケーリングは自動的に有効化されます。
• 動的なスケールアップ/ダウン：ワーカーのメモリ使用状況を常に監視し、必要に応じてメモリを増やしたり（スケールアップ）、減らしたり（スケールダウン）します。
• スループットへの一時的な影響：スケーリング時には、新しいメモリ構成を持つワーカーに置き換えられるため、一時的にスループットが低下する可能性があります。
• 水平スケーリングとの協調：垂直スケーリングが作動すると、水平スケーリングは最大10分間停止します。これは、両者が競合して不安定になるのを防ぐための設計です。

バッチパイプラインでの動作

• デフォルトで無効：利用するには、明示的に有効化オプションを指定する必要があります。
• OOMをトリガーにスケールアップ：4回のOOMエラー発生を検知すると、メモリを増強します。
• スケールダウンはしない：バッチジョブでは、一度スケールアップしたメモリ構成は、ジョブが終了するまで維持されます。スケールダウンは行われません。

リソースの制約

• メモリの範囲：デフォルトでは、ワーカーあたりのメモリは6 GiB～16 GiBの範囲で調整されます（GPU利用時は12 GiB～26 GiB）。
• 対象リソース：スケーリングの対象はメモリのみです。CPUやディスクは自動で変動しません。
• サポート対象外：A100 GPUを利用するプールや、VPC Service Controlsが有効な環境ではサポートされない場合があります。

導入のメリット

垂直スケーリングを導入することで、以下のような大きなメリットが得られます。

• OOM耐性の向上：予期せぬデータ量の増加でメモリ使用量が急増しても、自動でメモリを増強してジョブの失敗を防ぎます。
• リソース効率の改善：常に最大メモリを確保しておく必要がなくなり、必要な時に必要な分だけリソースを使用するため、無駄なコストを削減できます。
• 手動チューニング負荷の軽減：開発者は最適なメモリサイズを事前に計算・設定する手間から解放され、パイプラインのビジネスロジック開発に集中できます。
• 柔軟性の強化：水平スケーリング（ワーカー数）と垂直スケーリング（ワーカーの性能）を組み合わせることで、あらゆる負荷変動に対して柔軟に対応できます。

注意点と運用のヒント

垂直スケーリングは強力な機能ですが、利用にあたっては以下の点を理解しておくことが重要です。

• 一時的なパフォーマンス低下：ワーカーの置き換えが発生するため、スケーリング中はスループットの低下や処理の遅延が起こり得ます。
• メモリ上限：設定された上限メモリに達してもOOMが解消しない場合、ジョブは失敗します。その際は、パイプラインの設計自体の見直しが必要です。
• CPUはスケールしない：メモリ不足は解消できても、CPUがボトルネックになるケースでは効果が限定的です。
• バッチでのスケールダウンなし：バッチジョブでは、一度スケールアップした高メモリ構成がジョブ終了まで続くため、コストに影響する可能性があります。

どんな時に使うべきか？

• 推奨：メモリ使用量の変動が激しい、または予測が困難なワークロード。
• 非推奨：メモリ使用量が常に安定しており、事前に最適なリソース量を固定できるワークロード。

Dataflow Primeの垂直スケーリングのまとめ

Dataflow Primeの垂直スケーリングは、メモリ要件が変動するパイプラインの安定性とコスト効率を劇的に向上させる機能です。

OOMエラーに悩まされている方や、リソースのサイジングを自動化したい方は、ぜひこの機能を活用してみてください。ただし、一時的なパフォーマンスへの影響や各種制約も理解した上で、自身のワークロードに合っているかを判断することが成功の鍵となります。

Wrangler

ETLパイプラインを構築する際、最も時間と手間がかかる工程の一つが「データ準備」です。元データのフォーマットが不揃いだったり、不要なデータが含まれていたり、欠損値があったりと、そのままでは後続の処理に利用できないケースは少なくありません。

この面倒なデータ準備作業を、視覚的かつ対話的に行えるようにするのが、Cloud Data Fusionに組み込まれた強力なツールWranglerです。

この記事では、Wranglerの基本機能から実践的な使い方、注意点までを網羅的に解説します。

Wranglerとは何か？

Wranglerは、Cloud Data Fusion Studio内で利用できる、視覚的なデータ準備（データラングリング）ツールです。本格的なETLパイプラインにデータを取り込む前に、データのクレンジング、整形、変換といった前処理を、プレビュー画面で結果を確認しながら対話的に行うことができます。

最大の利点は、サンプルデータ（通常は最大1000レコード）に対して変換処理を試行し、その結果をリアルタイムで確認できる点です。これにより、本番の巨大なデータセットに処理を適用する前に、ロジックの妥当性を確実に検証できます。

Wranglerを構成する主要な用語

Wranglerを使いこなす上で、まずは基本となる用語を理解しましょう。

Wranglerの基本的な使い方フロー

Wranglerを使ったデータ準備は、以下のステップで進めるのが一般的です。

1. データソースへの接続
   あらかじめData Fusion上で、BigQueryやCloud Storageなど、処理したいデータが格納されているソースへの接続（Connection）を設定しておきます。
2. データの読み込みとプレビュー
   Wranglerを開き、設定した接続先からデータを読み込みます。この時、全データではなくサンプルデータ（最大1000件）がワークスペースに表示されます。
3. ディレクティブの適用とレシピ構築
   プレビューされたサンプルデータを見ながら、必要な変換処理（ディレクティブ）を追加していきます。
   • 列のヘッダーをクリックしてドロップダウンメニューから操作を選択する (GUI)
   • Power Modeでコマンドを直接入力する (CLI) 例えば、「列名の変更」「データ型の変換」「特定の条件に合う行のフィルタリング」「個人情報列のマスキング」といった操作をディレクティブとして追加し、レシピを構築します。
4. 変換結果のリアルタイム確認
   ディレクティブを1つ追加するたびに、プレビュー画面が更新され、変換後のデータ状態を即座に確認できます。意図通りに変換されているかを確認しながら、レシピを調整していきます。
5. パイプラインへの統合
   完成したレシピを、Data FusionのパイプラインにWranglerノードとして組み込みます。これにより、パイプライン実行時に、本番データ全体に対してレシピに定義された変換処理が自動的に適用されるようになります。

Wranglerを活用するメリット

• 視覚的な検証が可能：本番実行前にサンプルデータで結果を確認できるため、手戻りが少なく、変換ロジックの品質が向上します。
• ノーコード／ローコード開発：GUI中心の直感的な操作で変換ルールを構築できるため、プログラミングスキルが高くないユーザーでもデータ準備が可能です。
• 変換ロジックの再利用性：作成したレシピは再利用可能なアセットとして管理できるため、同様の変換処理を別のパイプラインで使い回すことができます。
• データ傾向の把握：Insights機能を活用することで、処理前にデータの品質や傾向を把握し、より的確な変換方針を立てられます。

制限と注意点

Wranglerは非常に便利ですが、いくつかの制限事項も存在します。

• バッチ処理専用：Wranglerはバッチパイプラインでの利用が前提であり、ストリーミングパイプラインには対応していません。
• サンプルの偏り：プレビューは最大1000レコードのサンプルに基づいています。このサンプルがデータセット全体の特性を代表していない可能性には注意が必要です。
• 出力スキーマの手動更新：レシピを変更して列を追加・削除した場合、パイプライン上のWranglerノードの出力スキーマを手動で更新する必要があります。
• 複雑なデータ型への対応：BigQueryのSTRUCT型（構造体）など、ネストされた複雑なデータ型に対する操作は限定的であるという報告があります。

実践上のベストプラクティス

Wranglerをより効果的に使いこなすためのヒントをいくつか紹介します。

• 段階的に構築する：一度に多くの変換を適用せず、ディレクティブを一つずつ追加してはプレビューで結果を確認する、というサイクルを繰り返すことで、ミスの特定が容易になります。
• スキーマ更新を忘れない：レシピを変更したら、必ずパイプライン側のスキーマも更新する、という作業をチームのルールとして徹底しましょう。
• カスタム変換（UDD）を活用する：標準のディレクティブで実現できない複雑な処理が必要な場合は、User Defined Directive (UDD) として独自の変換ロジックを実装することも可能です。
• パフォーマンスを意識する：あまりに複雑な処理をWranglerに詰め込みすぎると、パイプライン全体のパフォーマンスボトルネックになる可能性があります。処理の責務分担を考慮しましょう。

Wranglerのまとめ

Wranglerは、Cloud Data Fusionにおけるデータ準備フェーズを、視覚的、対話的、かつ効率的に進めるための強力なツールです。ノーコード／ローコードでデータ変換を行えるため、データエンジニアだけでなく、幅広いユーザーがデータ活用の第一歩を踏み出すのを助けてくれます。

その一方で、サンプルデータに基づく挙動やスキーマ管理の必要性といった特性も理解しておくことが重要です。Wranglerを正しく活用し、データパイプライン構築の生産性を向上させましょう。

まとめ

今回は、下記３点について説明しました。

1. Cloud StorageのAutoclass
2. Dataflow Primeの垂直スケーリング
3. Wrangler

Cloud StorageのAutoclass、Dataflow Primeの垂直スケーリング、Wranglerはいずれもクラウドにおけるデータ管理や処理を効率化する重要な機能です。Autoclassはアクセスパターンに応じたストレージ最適化でコスト削減を実現します。Dataflow Primeの垂直スケーリングは、変動するメモリ要件に柔軟に対応し、安定性と効率を高めます。Wranglerはノーコードで直感的にデータ準備を行えるツールとして、データ活用を加速させます。これらを正しく理解し活用することで、クラウド基盤全体のパフォーマンスと生産性を大幅に向上できるでしょう。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログで！