Google Cloud 上でのサーバーレス Apache Spark: アーキテクチャの選択と AI によるトラブルシューティング

※この投稿は米国時間 2026 年 8 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

現代のエンタープライズ データ エンジニアリングにおいて、Apache Spark は大量のデータセットを大規模に処理するための基盤となるフレームワークであり続けています。しかし、クラスタのプロビジョニング、YARN 構成のチューニング、アイドル状態のハードウェアのコスト回避といったインフラストラクチャの管理に追われ、最も重要である「復元力のあるデータ パイプラインの構築」に集中できなくなることが少なくありません。Google Cloud は、Managed Service for Apache Spark を通じてこの運用上のオーバーヘッドに対処し、特定の運用ニーズに合わせたサーバーレスおよびマネージド クラスタの柔軟なデプロイモードを提供しています。

この技術ガイドでは、Google Cloud で Spark をデプロイするためのアーキテクチャに関する意思決定マトリックスに加え、リソースと費用を最適化する手法を詳しく解説します。また、組み込みの Gemini Cloud Assist を適用して、サーバーレス バッチ パイプラインの障害を迅速にトラブルシューティングし、解決する方法を実演します。これら 3 つのパートは順番に読むとより理解が深まりますが、それぞれを個別に読んでも、Google Cloud での Spark 開発を進めるうえでの有用なヒントが得られます。

パート 1: Apache Spark デプロイモデルの選択

Managed Service for Apache Spark で Spark ワークロードを起動する際の最初の大きな意思決定ポイントは、従来のマネージド クラスタを構築するか、管理不要のサーバーレス インフラストラクチャ フットプリントに移行するかを評価することです。

検討事項 1: マネージド クラスタかサーバーレスか

従来の Managed Spark クラスタとサーバーレスのどちらを選択するかは、エコシステムの要件、そしてコスト効率を左右するリソースの利用パターンによって決まります。

• ワークロードの頻度、レイテンシの影響を受けやすいワークロード、コストの適合性: クラスタノードの使用率ベースラインが常に高く（80% 以上）、継続的で予測可能性の高い24 時間 365 日のストリーミングまたはバッチ処理パイプラインや、ワークフローの起動時間が積み重なることで SLA 目標の達成が危ぶまれるような場合は、カスタム YARN 自動スケーリング ルールを使用してファインチューニングした従来型クラスタを常時実行する方が、費用の予測可能性が高まります。一方、断続的、バースト的、アドホック、またはオーケストレーター トリガーのパイプラインの場合は、Managed Spark サーバーレスが極めて有効です。運用管理の手間が省けるだけでなく、計画にかかる時間を短縮でき、アイドル状態のコンピューティング時間に対して料金を支払う必要がありません。

• エコシステムとコンポーネントの要件: Managed Spark サーバーレスは、Apache Spark 3.x 以降のコードベースに完全に最適化されています。処理パイプラインが Apache Flink、Presto / Trino、Hive LLAP、Apache HBase などの他のエコシステム コンポーネントに依存している場合、または以前の Spark 2.x コードベースにロックインされている場合は、Managed Spark クラスタを使用する必要があります。

• インフラストラクチャのカスタマイズのニーズ: Managed Spark サーバーレスは、基盤となる仮想マシン（VM）レイヤを抽象化します。ワークロードで、OS レベルでの高度なハードウェア チューニング、カスタム OS の初期化アクション、インスタンスへの root SSH アクセス、特定のローカル SSD 構成、カスタム マシンシェイプが必要な場合は、従来のクラスタが必要です。なお、サーバーレスは特定のアプリケーション レベルのライブラリをバンドルするためのカスタム Docker コンテナ イメージをサポートしています。

検討事項 2: サーバーレス インタラクティブ セッションとサーバーレス バッチ

サーバーレス デプロイモードを選択したら、開発ステージと運用要件に基づいて適切な実行モデルを選択する必要があります。Managed Service for Apache Spark には、サーバーレス ワークロードを実行するための 2 つのオプションがあります。

サーバーレス インタラクティブ セッション

インタラクティブ セッションは、反復的なユースケースや試験的なユースケースに最適です。コードブロックを記述し、中間 DataFrame を検査し、変数を変更し、データセットをメモリに保持したままビジュアリゼーションを生成します。

• プライマリ インターフェース: 人間参加型のインタラクション向けに設計されています。デベロッパーは、Colab、Gemini Enterprise Agent Platform Workbench、Antigravity、Jupyter ノートブックなどの好みの IDE を使用して、コードをセルごとに実行します。

• アイドル時のコスト: コンピューティング リソースは、デベロッパーが検討している間も即座に実行できるようにアクティブな状態を維持します。セッションを非アクティブなままにすると、アイドル状態のコンピューティング料金が発生する可能性があります。

サーバーレス バッチ

バッチは、実行する内容がわかっていて、非インタラクティブな自動化された実行が必要な場合に便利です。このエンジンは、完成済みのパッケージ化された PySpark スクリプト（.py）または Java / Scala アプリケーション ファイル（.jar）を、人間の手作業による介入なしに最初から最後まで実行します。

• 主なインターフェース: Managed Service for Apache Airflow、Cloud Scheduler、CI / CD パイプラインなどの自動オーケストレーターによって管理されます。

• アイドル時のコスト: 実行時間に対してのみ、厳密に課金されます。コンピューティング リソースはオンデマンドでプロビジョニングされ、スクリプトを実行し、完了するとすぐにシャットダウンして、アイドル状態のコストを防止します。

開発から本番環境までのライフサイクル

これらの実行オプションは、自然なパイプライン ライフサイクルとして連携するように設計されています。開発の初期段階では、ノートブック インターフェース内でサーバーレス インタラクティブ セッションを開き、データセットの探索、スキーマのクリーンアップ、変換のプロトタイピングを行います。ロジックが検証され、変換が完了したら、コードを Python スクリプトにパッケージ化し、本番環境での実行のために Managed Service for Apache Airflow によってオーケストレートされるサーバーレス バッチジョブとしてスケジュールします。この移行により、運用の信頼性を確保しつつ、継続的な開発コストを最小限に抑えることができます。

パート 2: 高度なパフォーマンス チューニングと DCU コストの最適化

サーバーレスの Managed Spark は、クラスタ メンテナンスの運用オーバーヘッドを解消してくれますが、デフォルト設定のまま本番環境でエンタープライズ グレードのパイプラインを実行すると、パフォーマンスのボトルネックや予算の浪費を招く恐れがあります。効率的なデータ コンピューティング単位（DCU）のバーンレートを維持するには、送信時にランタイム構成プロパティを使用してリソース割り当てを明示的に宣言する必要があります。

Google は最近、履歴ベースの自動チューニングを導入しました。サーバーレスの環境においては、この機能がベストプラクティスや過去の実行履歴に基づいて、最適化を自動的に適用します。これは、繰り返し実行されるバッチ ワークロードを、Google がコホートと呼ぶものにグループ化することで実現されます。自動チューナーが、同じコホート名で以前に実行された際のテレメトリーと統計情報を分析して、ボトルネックがどこにあるかを特定します。

ドライバとエグゼキュータのシェイプのカスタマイズ

デフォルトでは、サーバーレス バッチは一般的な仕様（4 コア、16,000 MB RAM）を割り当てます。これは、アプリケーションの性質によっては、効率性に重大な問題を引き起こす可能性があります。

• メモリバウンド ジョブ: 圧縮されていない大量のデータを処理するパイプラインは、メモリ不足（OOM）エラーが発生してクラッシュする可能性があります。これに対処するには、spark.driver.memory と spark.executor.memory を使用してヒープサイズを個別に増やします。

• コンピューティング バウンド ジョブ: 数学モデリングや大量のトークン化を実行する処理集約型のジョブでは、CPU が飽和状態になる一方で、高価な RAM がアイドル状態になる可能性があります。spark.driver.cores と spark.executor.cores を明示的に調整して、インスタンスごとの処理の同時実行をファインチューニングします。

デフォルトでは、コア数を増やすと、vCPU と RAM の比率に見合ったベースライン メモリが自動的にプロビジョニングされることに注意してください。そのため、コアとメモリの両方の値をオーバーライドすることが重要です。

自動スケーリングの境界の制御

Managed Spark サーバーレスは、未処理のタスクに基づいて、アクティブなエグゼキュータの数を動的にスケールアップおよびスケールダウンします。ただし、制約のないスケーリングは、不正なコードループや最適化されていないデカルト結合が導入されると、予算超過につながる可能性があります。

防御的なガードレールとして、spark.dynamicAllocation.maxExecutors を使用して常に明示的な上限を宣言してください。これは、予算超過を防ぐための安全装置として機能します。妥当な上限に制限することで、コードが最適に動作しない場合でも、ジョブが固定のインフラストラクチャ フットプリントを超えてスケールすることはありません。

• 高優先度（SLA 主導）: maxExecutors で上限を高く設定して、リソースのバーストを可能にし、全体的なランタイム期間を最小限に抑えます。

• 低優先度（夜間バッチ）: maxExecutors で上限を低く、厳しく設定します。ワークロードの実行時間は長くなりますが、DCU の消費は予測可能な一定のペースに保たれ、コスト効率に優れた運用が可能になります。

シャッフル ストレージの効率の管理

groupBy()、join()、distinct() などのワイド変換を伴う処理では、ネットワーク全体にデータを再配布する必要があり、シャッフル ストレージと呼ばれる中間ディスク書き込みが発生します。

Spark はデフォルトで、パーティション数が 200 に静的設定されています（spark.sql.shuffle.partitions）。数ギガバイトに及ぶ大規模なデータセットを処理する場合、パーティション数が 200 個のままだと、個々のチャンクが大きくなりすぎてしまいます。パーティションのサイズが利用可能なエグゼキュータ RAM を超えると（たとえば、1 GB のパーティションを、割り当てられたヒープ領域 0.5 GB 内で処理しようとする場合）、データがディスクにあふれ出します。これにより、実行速度が低下し、プレミアムまたは標準のシャッフル ストレージ ブロックの追加料金が発生します。目安として、各パーティションがメモリ内で約 100 MB ～ 200 MB のデータを処理できるように、合計データサイズに基づいてパーティション パラメータを動的にスケールするとよいでしょう。最適な結果が得られるまで、何回か繰り返す必要が生じる場合があります。

上述のプロパティは、主なチューニング可能なプロパティです。その他のサーバーレス ランタイム構成プロパティについては、こちらのリンクをご覧ください。

パート 3: Gemini Cloud Assist による運用診断

本番環境で自動データ パイプラインが失敗した場合、データ エンジニアは従来であれば、ドライバとエグゼキュータにまたがる冗長で断片的なログファイルを何時間もかけて精査する必要がありました。Managed Service for Apache Spark は、Gemini Cloud Assist を Google Cloud コンソールにネイティブに統合することで、こうした手間を取り除きます。これにより、エンジニアは自然言語を使用して障害を診断し、解決できます。

この運用スタイルの変化を具体的に示すため、ある PySpark ETL パイプラインの事例を見ていきましょう。このパイプラインは、Google Cloud Storage（GCS）バケットから顧客トランザクション データを読み取り、変換を適用する過程で、予期せぬランタイムエラーにより失敗したものです。この事例を通して、一般的なトラブルシューティングの流れを解説します。

ステージ 1: 欠落している実行パラメータの診断

新しいパイプラインの最初の実行試行中、バッチジョブのステータスが保留中から実行中に切り替わり、最終的には一般的な終了メッセージ「アプリケーションは終了コード 1 で失敗しました（Application failed with exit code 1）」とともに失敗状態になっています。

エンジニアは、Cloud Logging を手動でクエリしたり、コンソールの複数のセクションを移動したりするのではなく、エラーログを見つけて [ログを調べる] オプションを選択できます。この操作により、ネイティブの会話ペインが開き、Gemini Cloud Assist によってドライバのテレメトリーとシステムログが自動的に分析されます。

このシナリオでは、送信時に必要なランタイム引数（ソース GCS バケットパスなど）が省略されたために PySpark スクリプトが失敗したことを、アシスタントがわかりやすい英語で説明してくれます。Gemini Code Assist は、これらの引数を想定しているスクリプト内の正確な行を即座に特定するため、スタック トレースを読み取る必要がなくなります。

ステージ 2: スキーマとデータ型の異常を解決する

不足している引数を解決してジョブを再送信すると、パイプラインは実行されますが、2 回目のデータ異常が発生します。大量のデータを取り込むパイプラインでは、アップストリームのソースファイルに破損したレコードや形式の不整合が含まれていることがよくあります。

2 回目の失敗後、エンジニアは再び Gemini Cloud Assist にログの調査を指示します。アシスタントは TypeError を特定し、クラッシュの原因となっている正確な DataFrame 変換を特定します。これは、スキーマが列を文字列として自動推論したために失敗した除算演算（df['amount'] / df['transaction_id']）です。

さらに、アシスタントは基盤となる GCS ファイルデータをスキャンして、根本原因を特定します。この場合は、ソース データセット内の非数値の異常（数値セル内のテキスト文字列など）です。

ステージ 3: 検証済みのコード修正の生成とデプロイ

エンジニアは、スキーマタイプをキャストして null 値をキャッチする PySpark ロジックを手動で書き換えるのではなく、Gemini Cloud Assist に直接プロンプトを入力して、復元力のあるソリューションを生成させることができます。

ユーザー プロンプト: 「transaction_id ではなく、quantity で amount を割るようにコードを書き換える方法を提案して。さらに、プロセスを失敗させることなく無効なレコードをスキップするロジックを追加して。」

アシスタントは、復元力のあるキャストと null 処理関数（coalesce や try_cast など）を使用して、修正された PySpark コードブロックを生成します。

この修正されたスクリプトを実装することで、オーケストレーション パイプラインは、バッチ実行全体をクラッシュさせることなく、不良なソースレコードをスムーズに除外できます。後続の実行は正常に完了し、データの更新速度に関する SLA が維持されます。

サーバーレス Apache Spark の活用: メリットと次のステップ

データ処理パイプラインの管理に、インフラストラクチャ構成に関する高度な専門知識は必要ありません。サーバーレス バッチのハンズオフ スケールと、動的割り当て上限やシャッフル サイズの計算など、リソースの明示的なチューニングを組み合わせることで、データチームはパフォーマンスとコストのプロファイルを厳密に管理できます。障害が発生しても、Gemini Cloud Assist をロギング ワークフローに直接統合することで、複雑なトラブルシューティングのあり方が一変します。手動でログを精査する手間がなくなり、迅速で自動化されたサイクルへと進化させることができます。

これらのアーキテクチャを実際に使用するには、Managed Service for Apache Spark のドキュメントを確認し、Google Cloud コンソールでサーバーレス バッチを直接実行してください。

これらのコンセプトのアーキテクチャ分析の詳細については、エージェントの時代における Apache Spark® の実務担当者向けガイドを今すぐご覧ください。このガイドには、Codelab、ステップバイステップのワークフロー、GitHub リポジトリから直接実行できる PySpark と Terraform のテンプレートが含まれています。Google Cloud を初めてご利用になる場合は、$300 分のクレジット付き無料トライアルに登録することで、サーバーレス クラスタやマネージド クラスタ上でこれらのブループリントを無料でお試しいただけます。

- Google Cloud、データ分析担当カスタマー エンジニア、Lior（Leo）Ginzberg