はじめのProfessional Cloud Data Engineer認定取得講座㉔Cloud Composerの最適化、Cloud Composerでタスクを作成する基準、Cloud Storageのマルチリージョンとデュアルリージョンを選択する際のポイントについて説明します！

クラウド

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

今回は、Cloud Composerの最適化、Cloud Composerでタスクを作成する基準、Cloud Storageのマルチリージョンとデュアルリージョンを選択する際のポイントについて説明します！

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

Cloud Composerの最適化

Cloud Composerは強力なワークフロー管理ツールですが、DAGの書き方が非効率だと、知らないうちに環境全体に負荷をかけ、パフォーマンスの低下や意図しないエラーを引き起こすことがあります。

この記事では、Google Cloudが推奨する、より効率的で安定したDAGを設計するための重要なチェック項目とベストプラクティスをご紹介します。

なぜDAGの書き方が重要なのか？

Cloud Composerのスケジューラは、DAGフォルダにある全てのPythonファイルを常に解析し、タスクの実行計画を立てています。そのため、DAGの読み込みに時間がかかったり、非効率なコードが含まれていたりすると、スケジューラ自体のパフォーマンスが低下し、ワークフロー全体の遅延につながります。

高パフォーマンスなDAGを標準化することで、数百、数千という規模のワークフローでも安定して管理できるようになります。

DAG設計のベストプラクティスチェックリスト

1. トップレベルでの処理を避ける

DAGファイルのトップレベル（どの関数にも属さないスコープ）に重い処理を書くのは避けましょう。
スケジューラはDAGを解析するたびにこのコードを実行するため、環境全体に無駄な負荷を与えます。

悪い例
df = read_large_csv_from_gcs()  # 重いファイル読み込み
result = client.query("SELECT ...").result()

with DAG("example_dag", ...) as dag:
    ...
良い例
def process_data(**context):
    df = read_large_csv_from_gcs()
    ...

with DAG("example_dag", ...) as dag:
    process_task = PythonOperator(
        task_id="process_data",
        python_callable=process_data,
    )

2. 静的な start_date を使用する

datetime.now() のような動的な日付は避け、固定の日時を設定します。

悪い例
start_date=datetime.now()
良い例
start_date=datetime(2025, 11, 24)
補足

days_ago() は静的に評価されますが、再現性を重視する場合は固定日付を推奨します。

3. catchup=Falseを適切に設定する

過去データを遡る必要がない場合は、明示的に catchup=False を指定します。

with DAG("example_dag", catchup=False, ...) as dag:
    ...

また、max_active_runs=1 で同時実行数を制御することで、過負荷を防止できます。

4. 適切な再試行回数を設定する

default_args = {
    'retries': 3,
    'retry_delay': timedelta(minutes=5)
}

過剰な再試行は環境負荷を高めるだけでなく、根本的な障害の特定を遅らせます。

5. DAGタイムアウトを設定する

with DAG("example_dag", dagrun_timeout=timedelta(hours=2), ...) as dag:
    ...

DAG全体がハングした際に、無限にリソースを占有することを防ぎます。
また、タスク単位で execution_timeout を設定するとさらに堅牢になります。タスクがハングアップした場合に、いつまでもリソースを占有し続けるのを防ぎ、他のDAGの実行に影響を与えるリスクを低減できます。

Cloud Composerの最適化のまとめ

Cloud Composerの最適化では、DAG設計の品質が環境全体の安定性とパフォーマンスを左右します。
トップレベルでの重い処理を避け、静的な開始日時・適切な再試行・タイムアウト設定を行うことで、負荷を大幅に軽減できます。また、catchupやmax_active_runsを適切に制御することで、不要な過去ジョブや同時実行によるリソース競合を防止できます。
これらのベストプラクティスを徹底することで、Cloud Composer環境をスケーラブルかつ安定的に運用できるようになります。最終的には、効率的なDAG設計がチーム全体の開発スピードと信頼性向上につながります。

Cloud Composerでタスクを作成する基準

Cloud Composerのタスクを作成する最も重要な基準は、「アトミック（Atomic）」であること、つまり「1つのタスクは1つの責任を持つべき」という考え方です。
タスクを適切に分割することで、ワークフロー全体の信頼性・再実行性・保守性が大幅に向上します。

Cloud Composerのベストプラクティス

Cloud Composerで信頼性と保守性の高いタスクを作成するための基本は、「失敗しても安全で、どこで問題が起きたかが明確で、管理しやすい構造」を設計することです。
以下に、そのための5つのベストプラクティスを紹介します。

1. タスクはアトミックに（1タスク1責務）

1つのタスクには、1つの論理的な役割だけを持たせるのが最も重要な原則です。巨大な「何でもやるタスク」は避けましょう。

悪い例

1つのタスクで「データのダウンロード → 変換 → BigQueryロード」をすべて実行する。

良い例
  • タスク1：データをCloud Storageにダウンロード
  • タスク2：Dataflowジョブで変換
  • タスク3：BigQueryにロード

タスクをアトミックに保つことで、失敗した部分のみを再実行でき、デバッグやリカバリが容易になります。

2. タスクを冪等（べきとう）にする

タスクは、何度実行しても同じ結果になるように設計しましょう。
Composerでは自動リトライや手動再実行が行われるため、この性質は非常に重要です。

悪い例

BigQueryにデータをAPPENDする（リトライ時に重複行が増える）

良い例

BigQueryにデータをWRITE_TRUNCATEで上書きする（結果が常に同じ）

冪等性を確保することで、安全に再試行を任せられ、手動での復旧作業が不要になります。

3. 適切なオペレータを利用する

その作業に最も適した専用のオペレータを使いましょう。
BashOperatorやPythonOperatorは柔軟ですが、専用オペレータがある場合はそちらを優先します。

悪い例

BashOperatorで bq query ... を実行する。

良い例

BigQueryInsertJobOperator を使用してSQLを直接実行する。

専用オペレータは認証やログ管理が最適化されており、コードが簡潔で保守性も向上します。

4. 重い処理は外部サービスに委譲する

Composerは「指揮者（Orchestrator）」であり、「実行者（Worker）」ではありません。
CPUやメモリを大量に消費する処理は、外部サービスに任せましょう。

悪い例

PythonOperatorでPandas処理を実行して巨大なCSVを変換。

良い例

ComposerからDataflow・Dataproc・Cloud Runのジョブを起動する。

これによりComposer環境の安定性を保ち、ワークフロー全体の信頼性を向上させます。

5. タスク間のデータ受け渡しは賢く行う

タスク間で少量のデータを共有する場合はXComを使えますが、大量データのやり取りには不向きです。

＜補足＞

XCom の概要

  • 正式名称：Cross-Communication（クロス・コミュニケーション）
  • 目的：DAG 内の異なるタスク間で、データを一時的に共有する
  • データの保存先：Airflow の メタデータベース（例：PostgreSQL、MySQL）
  • 想定されるデータ量：数 KB 程度の小さなデータ

悪い例

数GBのデータをXComで受け渡す。

良い例

  • 少量のメタデータ（ファイルパス・ジョブIDなど）→ XComで共有
  • 大量データ → Cloud Storageに保存し、そのパスをXComで渡す

XComはAirflowメタデータDBに保存されるため、大きなデータを格納するとパフォーマンスが低下します。

Cloud Composerでタスクを作成する基準のまとめ

Cloud Composerで高品質なワークフローを構築するには、タスクを「アトミック」で「冪等」に設計することが最も重要です。専用オペレータを活用し、Composer自身には重い処理を持たせず、外部サービスを適切に組み合わせることで安定した運用が可能になります。
また、タスク間のデータ受け渡しはXComの特性を理解し、必要最小限に留めることが性能維持の鍵です。
これらの原則を守ることで、Composerの可用性・保守性・再実行性を最大限に高めた堅牢なDAG設計を実現できます。結果として、エラー対応の効率化と環境全体の安定性向上が期待できます。

Cloud Storageのマルチリージョンとデュアルリージョンを選択する際のポイント

Cloud Storageのマルチリージョンとデュアルリージョンは、どちらも高い可用性と耐久性を実現する強力なオプションです。しかし、目的やコスト、パフォーマンス要件によって最適な選択は異なります。

簡単に言うと、以下のように選ぶのがポイントです。

  • マルチリージョン：広域（大陸単位）での可用性とグローバル配信に最適
  • デュアルリージョン：2つの特定リージョン間での高可用性とDR対策に最適

マルチリージョン

マルチリージョンは、大陸レベル（例：asia、us、eu）でデータを自動的に複製・分散して保存します。
同一大陸内の複数のGoogle Cloudリージョンに冗長化されることで、高い可用性を実現します。

選択ポイント

  • 可用性：リージョン障害に対する耐性が非常に高く、別リージョンから自動的にデータ提供が継続されます。
  • パフォーマンス：同一大陸内の最適なリージョンから提供されるため、広域ユーザーへの配信に適しています。
  • コスト：デュアルリージョンより高価ですが、グローバル配信用途では費用対効果が高いです。

主なユースケース

  • ウェブサイトの静的コンテンツ配信（例：画像・動画）
  • 動画ストリーミング（グローバルな配信）
  • ゲーム・モバイルアプリのグローバルデータ保存

デュアルリージョン (Dual-Region)

デュアルリージョンは、ユーザーが指定した2つの特定リージョンにデータを複製して保存します。
マルチリージョンよりも制御性が高く、災害対策（DR）やリージョン間分析に適しています。

選択ポイント

  • 高可用性：一方のリージョンで障害が発生しても、もう一方からデータを提供可能。
  • 高パフォーマンス：Compute EngineやBigQueryを同じデュアルリージョン内に配置することで、低レイテンシーアクセスが可能。
  • 災害対策（DR）：物理的に離れた2リージョン間でデータを複製し、BCPや法的要件に対応。
  • コスト：マルチリージョンより安価ですが、単一リージョンより高価。

主なユースケース

  • 金融・基幹業務システムのデータ保存
  • BigQueryなどを利用した大規模分析
  • 特定国・地域内でのコンプライアンス対応

Cloud Storageのマルチリージョンとデュアルリージョンを選択する際のポイントのまとめ

観点マルチリージョンデュアルリージョン
対象ユーザー広域に分散する世界中のユーザー特定の2リージョンにアクセスするシステム
強み広域なコンテンツ配信と高可用性高可用性とDR対策の両立
コストデュアルリージョンより高価マルチリージョンより安価
最適なシナリオYouTubeのようなグローバル動画配信金融・基幹システムの災害対策（DR）

まとめ

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

  1. Cloud Composerの最適化
  2. Cloud Composerでタスクを作成する基準
  3. Cloud Storageのマルチリージョンとデュアルリージョンを選択する際のポイント

クラウド環境を最適に運用するためには、設計段階での品質と選択の判断が重要になります。
Cloud Composerでは、DAGやタスクの設計品質がシステムの安定性と拡張性を大きく左右し、最適化された構成がチーム全体の生産性向上につながります。
また、Cloud Storageでは、マルチリージョンとデュアルリージョンの特性を理解し、用途やコスト要件に応じた選択が信頼性を支えます。
それぞれのサービスでベストプラクティスを意識することで、無駄のないリソース運用と高可用性を両立できます。
最終的には、設計と選択の精度が、クラウドシステム全体の安定稼働と効率化を実現する鍵となります。

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

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

スポンサーリンク
タイトルとURLをコピーしました