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

連日 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_limit と batchSize が小さすぎると、Loaderバッチ(Lambda Function)が頻繁に行われてしまい待ち状態が発生してしまうと予想できるため、ファイルサイズとバッチサイズは流入ログのファイルサイズ、Redshiftに反映させたい時間(リアルタイム性)を考慮して決める必要があるといえます。