【要約】AWS Glue Job でクロスアカウントのデータを取得・加工して S3 に出力する際に気をつけたこと [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がマルチアカウント環境でGlue Jobを実装する際、認証情報の管理や分散処理エンジンの挙動に起因するエラーに直面する。具体的には以下の問題が発生する。
- ・boto3で作成したセッションがSpark（Hadoop）に自動反映されない。
- ・Sparkの遅延評価により、認証情報が失効した後にデータ読み込みが走る。
- ・クロスアカウントでS3に書き込んだ際、バケット所有者がオブジェクトを操作できない。
- ・大量のファイルをUnionすると、Sparkの論理プランニングが極端に遅くなる。
// Approach
開発者がHadoop設定を動的に制御し、Sparkの実行ライフサイクルを適切に管理する手法を採用する。具体的には以下のステップで解決を図る。
- ・TemporaryHadoopS3Credsクラスを用いて、Hadoop設定に一時的な認証情報をセットする。
- ・cache()とcount()を組み合わせ、認証情報の有効期限内にデータをメモリへ確定させる。
- ・S3書き込み時にACL="bucket-owner-full-control"を指定し、所有権問題を回避する。
- ・Union処理をツリー型で行い、論理プランの深度をO(log N)に抑える。
// Result
開発者がクロスアカウントのデータパイプラインを、安定かつ効率的に構築できる。具体的な成果は以下の通りである。
- ・コンテキストマネージャによる認証情報のクリーンアップで、後続処理への副作用を防止する。
- ・cache()とcount()の併用により、認証切れによるAccess Deniedエラーを回避する。
- ・ツリー型Unionの採用により、大量ファイル結合時のプランニング時間を短縮する。
- ・DynamoDBのページネーション対応により、大量データの全件取得を確実にする。
Senior Engineer Insight
> 分散処理エンジンとクラウド認証のライフサイクルの乖離を突いた、極めて実践的な知見である。特に、Sparkの遅延評価と一時認証情報の有効期限の衝突は、大規模ジョブの失敗に直結する致命的な問題だ。設計段階で、認証情報のスコープとデータの確定タイミングを意識することは、運用の安定性を確保する上で不可欠である。また、Hadoop設定のクリーンアップまで考慮した実装は、大規模基盤を支えるエンジニアとして必須の作法と言える。