はじめに
概要
本ドキュメントは、AWSを使ったバッチ処理に関する調査結果をまとめたものです。具体的には、AWS Glueを用いて処理を大幅に高速化した事例と、AWS Batchの基本的な概要や利用方法を分かりやすく解説します。
本書の目的
・バッチ処理の導入や改善を検討する方に、実践的な知見を提供します。
・技術的な背景が浅い方でも理解できるよう、具体例を用いて説明します。
想定読者
・バッチ処理を担当するエンジニアや運用担当者
・クラウドで処理を効率化したいシステム担当者
本書の構成
第1章 はじめに（本章）
第2章 AWS Glueを使ってバッチ処理を60倍高速化した話（事例と手順）
第3章 AWS Batchとは？基本的な概要と使い方を解説（概念と実践）
注意点
具体的な操作や設定例は実環境の構成によって結果が変わります。本書の手順は一例としてご利用ください。
AWS Glueを使ってバッチ処理を60倍高速化した話
概要
Digitization部で扱う顧客のアナログ画像データに対する削除漏れチェックが、従来は60日かかっていました。原因はデータ量増加に対してO(n²)の非効率なアルゴリズムを使っていたことです。AWS Glueを導入し、処理を1日以内に短縮して約60倍の高速化を達成しました。
課題の本質
従来はECS上でRubyスクリプトを使い、レコードごとに全件を比較する実装でした。レコード数が増えると比較回数が爆発的に増え、処理時間が伸びました。
解決アプローチ
・アルゴリズムを見直し、Sparkの分散処理で並列化しました。
・ECSのRubyスクリプトをAWS GlueのPythonジョブ（Spark）に書き換え、S3上のCSVをSpark SQLで処理しました。
・キーでの結合やパーティションを使い、不要な全件スキャンを避けました。
実装のポイント
・小さなサンプルでロジックを先に検証する。例：1000件で期待通りに並列・結合できるか確認する。
・Glueはメモリとワーカー数を柔軟に指定できるので、短時間で処理したいときは一時的にリソースを増やす。
・S3→Spark SQLの処理はI/Oを意識して、列選択やパーティションで読み込みを最小化する。
効果と学び
結果として処理は60日→1日以内に短縮しました。従量課金と設定の柔軟性により、必要なときだけリソースを増やし短時間で完了できました。アルゴリズムの見直しと分散処理の組み合わせが鍵です。
注意点
コストは短時間で増える可能性があるので、ジョブ実行時間とワーカー数をモニタして調整してください。
AWS Batchとは？基本的な概要と使い方を解説
概要
AWS Batchは大規模バッチ処理を簡単に実行できるマネージドサービスです。ユーザーはサーバーの起動や管理を意識せずに、ジョブ（処理単位）を登録して実行できます。データ集計、機械学習の学習、画像変換、バックアップなどに向きます。
主要コンポーネント
- ジョブ定義：実行するコンテナやコマンド、リソース要件を記述します。例：Pythonスクリプトを実行するイメージとメモリ指定。
- ジョブキュー：実行待ちのジョブが並ぶ場所です。優先度を設定できます。
- コンピュート環境：実際の計算資源（EC2やFargate）を管理します。オンデマンドとスポットを選べます。
基本的な使い方（手順）
- コンテナイメージを作る（Dockerでスクリプトを組み込み）
- ジョブ定義を登録する（コマンド、環境変数、リソース）
- ジョブキューとコンピュート環境を作る
- ジョブを送信して実行状況を確認する（管理コンソールやCLI）
実例
大量のログを1日分まとめて集計する場合、ジョブを並列で投げて短時間に処理できます。MLのハイパーパラメータ探索では多数の学習ジョブを自動でスケールさせられます。
ベストプラクティスと注意点
- 可能な処理はコンテナ化して依存関係を固定してください。
- スポットを使うとコストを下げられますが、中断対策（再試行やチェックポイント）を入れてください。
- リソースは過剰に割り当てないで、実測に基づき調整してください。
- ログとメトリクスはCloudWatchで監視し、失敗時に通知を受け取る設定にしてください。
