AWS Lambda Based Amazon Redshift Database Loader を使ってみた(3) 〜ファイルサイズの上限〜

投稿者: | 2016/09/04


連日 AWS Lambda Based Amazon Redshift Database Loader (以下、Redshift Loader)の内容です。
Redshift LoaderはS3にアップロードされたイベントを検知してAmazon Lambdaが実行されてRedshiftへデータロードされるのですが、1つ気になるのがS3へアップロードするファイルサイズです。
Amazon Lambdaの制約の1つにLambda Functionは最大5分間しか実行できません。Configuration Referenceを見るとRedshiftへのCOPYコマンド実行に費やせるのは約4分50秒までとありました。
では、どのぐらいのファイルサイズまでアップロード可能なのかを気になったので計測してみました。

実行環境

構築環境は前々回と同じです。
Redshiftのスペック・設定は以下の通りです。

  • dc1.large
  • Singleノード
  • COPYオプション ACCEPTANYDATE TRUNCATECOLUMNS COMPUPDATE ON

計測方法

テスト用のログをただひたすらコピーすることでファイルサイズを大きくしていき、Lambda Functionがタイムアウトした時点でのファイルサイズを調べました。
ログはここでは公開できないのですが、ファイルサイズの目安として、880,000レコードの場合 約1GBとなるようなログです(と言われても分からないと思いますが)。
データロード前にデータを削除してからログをアップロードするようにしました。
また、S3へファイルアップロードをしやすいように、1つのファイルサイズを256MBに分割してS3にアップロードしていました。ファイル数が増えるため、Redshift LoaderのbatchSizeもファイル数に応じて変更する必要があります。

結果

5GB弱(約4.7GB)までであればアップロードができました。Redshiftのクラスターサイズやノード数を増やせばさらにサイズを大きくすることができると思います。

No. レコード数 ファイルサイズ(MB) COPY実行時間(sec) Lambda実行時間(sec)
1 880,000 1,002.8 59.57 62.4
2 1,713,808 2,048 114.42 118
3 3,427,616 4,096 228.85 233
4 4,180,000 4,769 277.91 285
5 4,284,520 5,120 289.1 291(タイムアウト)

適切なファイルサイズとバッチサイズはどのぐらいか

S3へアップロードするファイルサイズ(Fluentdのbuffer_chunk_limit)とバッチサイズ(LoaderのbatchSize)をどのような値にすべきなのかを考えてみました。
Lambdaが処理できる(=5分以内で完了できる)ファイルサイズを超えなければどのファイルサイズでも構わないと思いますが、注意したいのが buffer_chunk_limit の上限を「Lambdaが処理できるファイルサイズ/batchSize」に留めておく必要があるということです。例えば、batchSize が4だとしたら、5GB/4 = 1,25GB が buffer_chunk_limit の上限値となります。
また、ファイルサイズが大きくなれば、Redshiftにデータが反映されるまでに時間がかかることが予想されますし、流入ログファイルサイズが多い場合 buffer_chunk_limitbatchSize が小さすぎると、Loaderバッチ(Lambda Function)が頻繁に行われてしまい待ち状態が発生してしまうと予想できるため、ファイルサイズとバッチサイズは流入ログのファイルサイズ、Redshiftに反映させたい時間(リアルタイム性)を考慮して決める必要があるといえます。

最後に

Redshift loaderで実行できるファイルサイズの上限について調べてみてファイルサイズ、バッチサイズについて考えてみました。適切なサイズというのは結論がでていないですが、実際のログを使って試していくのがいいですね。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*