「Amazon S3」の一括処理に便利な「バッチオペレーション」入門――S3バケットから別のバケットへのコピー:AWSチートシート
AWS活用における便利な小技を簡潔に紹介する連載「AWSチートシート」。今回は「Amazon S3」の「バッチオペレーション」を紹介し、例としてログが保管されているS3バケットから別のS3バケットにコピーする手順を解説する。
「Amazon Web Services」(AWS)活用における便利な小技を簡潔に紹介する本連載「AWSチートシート」。
皆さんは、「Amazon Simple Storage Service」(S3)にある大量のファイルに対して何らかの一括処理を行いたいと思ったことはないでしょうか? 今回は、そういったことがフルマネージドで可能なS3の機能、「バッチオペレーション」について、その特徴と使い方を解説します。
※S3バッチオペレーションとS3の料金については下記公式の料金説明をご覧ください。
「S3バッチオペレーション」とは?
S3バッチオペレーションは次の特徴を持ったS3の機能です。
- S3のオブジェクトに対してバッチ処理を行う
- 対象のリストを作成して、処理するジョブを定義して実行する
- 数十億のオブジェクトに対してフルマネージドで処理できる
- 進捗(しんちょく)管理、通知、詳細な完了レポートの保存が行える
- AWSが用意している組み込み処理、もしくは自分で用意した「AWS Lambda」関数でカスタム処理もできる
まとめると、「S3にある大量のオブジェクトに対して、フルマネージドに処理を行える」機能です。
ログが保管されているS3バケットから別のS3バケットにコピーする
バッチオペレーションを利用するには下記の設定が必要です。
- 処理対象が記載された「マニフェストファイル」の準備
- 処理の設定を定義した「ジョブ」設定
ここからは具体的な設定内容を見ていきます。例として、ログが保管されているS3バケットから別のS3バケットにコピーするシナリオで手順を紹介します。
構成するリソースは下図の通りです。
バッチオペレーションでの処理は次の通りです。
- フェストファイルの取得
- マニフェストファイルに記載されている対象のファイルを送信先にコピーする
- 処理結果のレポートを出力先に出力する
STEP1:ログ保管バケットの作成
送信元のS3バケットを下記の通り作成してください(※{アカウントID}は自身のAWSアカウントIDで置き換えてください)。
- S3バケット名:batch-ope-{アカウントID}
バケット名以外はデフォルトのままで問題ありません。
加えて、作成したバケットの中に、適当なテスト用のテキストファイルを何個か
アップロードをしておいてください。
STEP2:ログ送信先保管バケットの作成
今度は、送信先のS3バケットを下記の通りに作成してください。
- S3バケット名:batch-ope-copied-{アカウントID}
こちらも同様に、バケット名以外はデフォルトのままで問題ありません。
STEP3:インベントリレポート兼処理結果保管バケット作成
今回はバッチオペレーションに必要な「マニフェストファイル」の出力先、さらにはバッチオペレーションの処理結果ファイルを保管するので、それ用にS3バケットを作成します。
- S3バケット名:batch-ope-inventory-{アカウントID}
こちらも同様にバケット名以外はデフォルトのままで問題ありません。
STEP4:インベントリレポートの出力設定
「batch-ope-{アカウントID}」バケットでマニフェストファイルの出力を設定します。
対象のS3バケットの「管理」タブから「インベントリ設定」で「インベントリ設定の作成」をクリックし、下記内容で設定します。
- インベントリ設定名:test-inventory
- インベントリスコープ:
- プレフィックス:設定なし
- オブジェクトのバージョン:現在のバージョンのみ
- レポートの詳細:
- このアカウント:選択
- 送信先:s3://batch-ope-inventory-{アカウントID}
- 頻度:日別
- 出力形式:CSV
- ステータス:有効にする
他のオプション設定「インベントリレポートの暗号化」「追加のメタデータフィールド」についてはデフォルトのままで作成してください。
STEP5:インベントリレポートが出力されているかどうかの確認
設定が正しければ、下記のように「最後のエクスポート」でエクスポートされた最後の日時が記録されます(※日次で出力されるので設定後、1日空けて確認してください)。
インベントリ情報として下記4ファイルが出力されるはずです。
- manifest.checksum:MD5のチェックサムが記載されたもの
- manifest.json:インベントリファイルの場所を記述したもの
- data/{ランダムな値}.csv.gz:インベントリファイルのリスト
- hive/dt=YYYY-MM-DD-HH-MM/symlink.txt:「Apache Hive」互換のマニフェストファイル
STEP6:「リージョンとマニフェストを選択」の設定
ここからバッチオペレーションの設定です。
S3のメニューから「バッチオペレーション」を選択し、「ジョブの作成」を選択して下記のように設定してください。
- マニフェスト形式:S3インベントリレポート(manifest.json)
- マニフェストオブジェクト:{上記設定したインベントリ情報の任意のmanifest.jsonファイル}を指定
他はデフォルトのまま「次へ」を押します。
STEP7:「オペレーションを選択」の設定
下記の通り設定してください。
- オペレーションタイプ:コピーする
- コピー先:batch-ope-copied-{アカウントID}を「参照」で選択
- 同じ名前の既存のオブジェクトは上書きされます:チェック
他はデフォルトのまま「次へ」を押します。
STEP8:「追加のオプションを設定」の完了レポート設定
下記の通り設定してください。
- 完了レポート:
- 完了レポートの生成:チェック
- 完了レポートの範囲:全てのタスク
- 完了レポートの送信先へのパス:s3:// batch-ope-inventory-{アカウントID}/ batch-report/
STEP9:バッチオペレーション用IAMロールの作成
「追加のオプションを設定」の際に、アクセス許可の設定でIAMロールの作成が必要になるので、ここでいったん「AWS Identity and Access Management」(IAM)で作業します。
必要なポリシーの内容は、「追加のオプションを設定」の「アクセス許可」で「IAMロールのポリシーテンプレートとIAM信頼ポリシーを表示」をクリックすると「IAMロールのポリシーテンプレート」「IAM信頼ポリシー」が表示されるので、それを利用します。
要注意ポイントとして、ポリシー内で「{{SourceBucket}}」となっている部分はログ保管バケット名の「batch-ope-{アカウントID}」で置き換えます。ここを修正しないとバッチオペレーションのジョブ実行が失敗します。ロール名は好きに付けてもらって問題ありませんが、筆者は「s3-batchope-role」で作成しました。
STEP10:「追加のオプションを設定」の残りの設定を完了する
「追加のオプションを設定」での設定に戻り、次のように設定します。
- アクセス許可:
- 既存のIAMロールから選択:チェック
- IAMロール:STEP9で作成したIAMロールを選択
他はデフォルトで「次へ」を押します。
STEP11:確認画面で設定の確認
各種設定を確認し、問題なければ「ジョブの作成」をクリックします。
STEP12:ジョブの実行
バッチオペレーション画面で作成したジョブIDのステータスが「実行のための確認待ち」になったら、選択して「ジョブを実行」をクリックします。
ジョブの詳細画面に遷移するので確認して問題なければ「ジョブを実行」をクリックします。ジョブのステータスが「アクティブ」になり、最終的に「完了済み」になれば完了です。
「失敗した合計(率)」が「0」になっていれば全ての対象が問題なく処理されたことになります。
処理結果の確認
まず「ログ送信先保管バケット」を確認して、マニフェストファイルに記載されている対象が全てコピーされていることを確認します。
次に、処理結果のレポートファイルを確認して処理が全て問題なく成功していることを確認します。レポートファイルはレポート処理出力先のバケットに「job-{ジョブID}」のパス以下にCSVファイルとして出力されます。
ファイルの中身としては、下記のように、対象ファイルごとの結果が記載されます。
失敗したときの確認ポイント3つ
もし処理が全て、もしくは一部失敗している場合は、下記3点を確認します。
- S3のバケットポリシーでバッチオペレーションによるアクションがDeny(拒否)されている
- バッチオペレーションが利用するIAMロールに付与されている信頼ポリシーかIAMポリシーの不備
- マニフェストファイルに記載されているファイルがもう既に存在しない
1、2、3はいずれも処理ステータスコードは「403」になります。1、2の場合は全てのファイルに対して失敗、3の場合は存在しないもののみ失敗扱いとなるはずなので、それをヒントに問題の切り分けと特定を行います。
まとめ
今回はS3バッチオペレーションを紹介しましたが、いかがでしょうか。大量のファイルに対して組み込みで用意された処理、もしくは必要に応じてLambda関数でカスタム処理を、バッチ基盤、オペレーションの管理などを気にせず、必要な設定だけで行えるのは、「便利だ」と感じていただけたのではないでしょうか。ぜひ実務に利用してみてください。
筆者紹介
沼崎 伸洋(ぬまざき のぶひろ)
株式会社システムシェアード 開発事業部所属。
ここ数年はAWSを利用したシステムの設計、開発、構築を行っています。
仕事以外では、AWSの資格をあと2つでコンプリートできるので制覇に向けて頑張っています!
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- Amazon S3の大量データをローカルにマウントできるファイルクライアント「Mountpoint for Amazon S3」登場
AWSはAmazon S3にある大量のデータを、ローカルコンピュータのファイルシステムにマウントすることができるファイルクライアント「Mountpoint for Amazon S3」を公開した。 - AWSがAmazon S3でデータ暗号化の自動適用を開始、暗号化されていない既存バケットはどうなる?
AWSはオブジェクトストレージの「Amazon S3」で、新規オブジェクトをユーザー側の操作なしにデフォルトで暗号化するようにしたと発表した。2023年1月5日より、世界中の全リージョンで適用が開始された。 - ここでハマる! AWSにEC2インスタンスとしてSplunkログ基盤を構築、検証してみた
リクルートのSOCによるログ基盤クラウド化検討プロジェクトの概要や失敗談、そこから得た学びを紹介する連載。今回は、EC2インスタンスとしてSplunkを構築する上でハマったポイントや、「最適」と考えるアーキテクチャについて。