AWS Lambda Based Amazon Redshift Database Loader を使ってみた(1)

投稿者: | 2016/09/02

アプリケーションログをRedshiftにロードしたいという案件があったので色々調べていたところ、AWS Lambda Based Amazon Redshift Database Loader というのがあったので使ってみました。

AWS Lambda Based Amazon Redshift Database Loader とは

(名称が長いので以降はRedshift Loaderと略します)

解説記事

GitHub

Redshift Loader はAmazon謹製のツールで、S3にアップロードされたログなどのファイルをRedshiftへロードしてくれます。
Amazon Lambda, DynamoDB などマネージメントサービスだけで構成されているので管理の手間から開放してくれます。

Redshiftへデータをロードするツールは、Amazon Kinesis FirehoseやFluentdプラグイン(fluent-plugin-redshift)があります。また、自分でS3からRedshiftへデータロードするLambda Functionを作る方法もありますが、以下の点においてRedshift Loaderの方が優位性があります。

I. Tokyoリージョンで使える

Amazon Kinesis Firehose は現時点(2016/09/02)でTokyoリージョンで使うことができませんが、Redshift Loaderなら使うサービスすべてTokyoリージョンで提供されているため使うことができます。

II. データロード失敗時へのリカバリが簡単にできる

fluent-plugin-redshift のデメリットの1つにRedshiftへデータロードが失敗した後にリカバリが面倒だということです。このプラグインの挙動としては S3にファイルアップロード後、COPYコマンドでRedshiftへデータロードしますが、ロードに失敗するとS3上にロードされないファイルが残ってしまいます。

Redshiftのクラスタにノードを追加、削除する場合、クラスタリサイズ中にはデータ投入ができなくなります(読み取りは可能)。

その状態で fluent-plugin-redshift のデータ投入が走ると、S3へファイルをアップロードするところまでは成功した上、その後の COPY の発行でエラーになるため、fluentdの処理は「S3へのアップロード処理から」リトライされます。

リトライされるので最終的には問題なく取り込まれるのですが、S3には投入できなかったファイルが残ったままになり、投入できたファイルとできなかったファイルには部分的に同一のログが重複して含まれる状態になります。

エラーになって取り込まれなかったファイルをきちんと消しておかないと、後日まとめて再取り込みをしようとしたときに、ログを重複して読み込んでしまうことになります。

Amazon SQSを利用してS3からRedshiftにデータ投入するRinというツールを書いた

ロード失敗した場合の挙動について実際に検証してみました。Redshiftのクラスターをリサイズして書き込みができない状態において挙動を確認しました。
リサイズは約20分間行われ、その間はRedshiftへ接続不可になったり、書き込みができなかったりしていたため、FluentdプラグインによってS3にアップロード後、Redshiftへのデータロードに失敗していました。
Redshiftへのデータロードに失敗するとFluentdによって何回かリトライがかかりますが、S3へのアップロードからリトライが開始されるため、以下のようにRedshiftへロードされないファイルがS3に残ってしまっていました。
アップロードしたいファイルが最終的にはRedshiftへ取り込まれるので問題は無いと言えるかもしれませんが、RedshiftとS3で差分があるのは何となくもやもやします。
「リサイズするときにデータロード止まればいいのでは」という考えもありますが、メンテナンスウインドウによってロードできない時間帯がどうしても生じてしまいますのでロード失敗後のリカバリについて考えなければなりません。

一方で、Redshift Loaderの場合はDynamoDBにバッチ単位でデータロードの結果が保存されているため、失敗した場合はコマンド1つで失敗したバッチのみ再実行することでリカバリが容易に行うことができます。

アーキテクチャ

Architecture.png

(https://github.com/awslabs/aws-lambda-redshift-loader/blob/master/Architecture.png)

仕組みは単純でS3にファイルがアップロードされると、それをフックにAWS Lambdaが実行されRedshiftへデータがロードされます。DynamoDBに設定値やロードするファイルリスト、ロードを実行するバッチの実行状況を格納することで管理をしています。

環境構築

Webサーバ、バッチサーバ、ログ集約サーバにFluentdを入れており、各サーバ(Web,バッチ)から集約サーバにログを送っています。
今回は集約サーバからS3にファイルをアップロードしたときに Redshift Loaderを使ってRedshiftへデータロードしてみました。
構成としては、以下の図のようにVPC内にLambda Function, Redshiftを作成し、Lambda Function は NAT Gatewayを経由してDynamoDBにアクセスするようにします。

VPC.png

(https://github.com/awslabs/aws-lambda-redshift-loader/blob/master/VPCConnectivity.png)

VPC, NAT Gateway

Lambda Functionが実行できるプライベートサブネットを作成し、インターネットにアクセスできるようにNAT GatewayかNATインスタンスを作成します。ここでは設定方法は紹介しません。

S3

以下のようなS3バケットを作成します。バケットポリシーは適宜変更してください(デフォルトでも良い)。

バケット 用途
redshift-loader データロード用。このS3バケットに置いたファイルがRedshiftへロードされる
redshift-manifests マニフェストファイルの保存用バケット

Lambda

Configure triggers

confire_trigger.png

S3のイベントを追加します。

項目 備考
Bucket データロードするS3バケット(redshift-loader)
Event type 後述
Prefix ログをアップロード先のパス。今回は buffer/ とする
Suffix 拡張子(.json)を指定する

Event typeについて以下の3つを設定します。

  • ObjectCreatedByPut ・・・ ファイルがアップロードされた場合
  • ObjectCreatedByCompleteMultipartUpload ・・・ マルチパートアップロードされた場合
  • ObjectCreatedByCopy ・・・ ファイルがコピーされた場合。バッチ再起動する際にフックされる

Configure function

configure_function.png

項目 備考
Name 今回はRedshiftDatabaseLoaderにした
Description Lambda Functionの説明を入れる。後で変更も可能
Runtime README.mdによると Node.js v0.10 か v0.12 を指定する必要がある
Code entry type 「Upload a .ZIP file」を選択
Function package AWSLambdaRedshiftLoader-2.4.1.zip をローカルにダウンロードしてアップロードする
Handler デフォルト(index.handler)でOK
Role 後述

Role

SS 2016-07-06 17.02.39.png

新規でRoleを作成します。ポリシーは以下のようにしました。
Redshift Loaderで必要なポリシーに加え、CloudWatch Logsへの記録とVPCエンドポイント化に必要なポリシーも追加しています。

Advanced settings

advanced_setting.png

項目 備考
Memory とりあえず最小(128MB)
Timeout 最大(5分間)
VPC Lambda Functionを実行したいVPC
Subnet Redshiftと5439ポートで通信ができる、S3, DynamoDBと通信できるサブネットを選択
SecurityGroup Redshiftと5439ポートで通信ができる、S3, DynamoDBと通信できるSecurityGroupを選択

Redshift

VPC内に構築します。Lambda FunctionからRedshiftに5439ポートでアクセスできるようにSecurityGroup, NetworkACLを設定してください。

クラスター名: test-redshift

IAM Role対応

次の記事を参考に設定しました。

[Amazon Redshift] RedshiftのIAM Roles利用が可能となりました。

IAM のマネジメントコンソールから先ほど作成したLambdaに関連づけられてロールを選択し、「Trust Relationships(信頼関係)」タブをクリックし、「Edit Trust Relationships(信頼関係の編集)」をクリック。
以下の信頼ポリシーに修正する。

保存すると以下のように redshift.amazonaws.com が信頼関係に追加されればOK。

trust_relationship.png

Amazon SNS

データロードの成功・失敗時にAmazon SNSに通知することができます。
作成したらTopic ARNをメモしておきます。

DynamoDB

セットアップする際に自動的に設定されるので何もしません。

Node.js

セットアップするために Node.js が動作する環境が必要です。
Lambda Functionで指定した時と同様に v0.10系かv0.12系で動作するようにします。

AWS SDKの設定

リージョンを設定します。
プロファイルがあれば設定します。

以上で環境構築は完了です。
次にセットアップします。

セットアップ

入力内容がたくさんあって大変ですが、Configuration Reference を見ながら設定していきます。(日本語訳もあります)。
途中で設定を間違えると最初からになるのが辛いです。。。

成功するとDynamoDBに以下のテーブルが作成されます。

テーブル 備考
LambdaRedshiftBatches バッチの実行状況
LambdaRedshiftBatchLoadConfig 各種設定(S3, Redshift)
LambdaRedshiftProcessedFiles バッチ処理するファイルのリスト

Fluentd側の設定

FluentdからS3にファイルをアップロードする設定を行います。
下記は設定ファイルから一部抜粋したものです。

buffer_chunk_limit は適当で良いですが、Lambda FunctionでRedshiftクラスターへデータロードできるサイズ/バッチサイズまでに留めておきます。
fluent-plugin-s3 ではデフォルトでGZIPに固めてアップロードされてしまいますが、Redshift Loader は生のJSONファイルでないとダメなので、JSONファイルでアップロードするようにしています。

実行結果の確認

S3にログを置くとLambda Function(RedshiftDatabaseLoader)が実行されます。
How many files should be buffered before loading?で指定したファイル数が置かれるとRedshiftへのデータロードが実行されます。
各バッチのステータスごとの一覧を取得する場合は以下のコマンドを実行します。

バッチの詳細を調べるには describeBatch.js を使います。

バッチの検索

S3のファイルパスを指定することでバッチIDなどを検索することができます。

ファイルの削除

S3上のファイルを削除することができます。

最後に

今回はAWS Lambda Based Amazon Redshift Database Loaderを使ってアプリケーションログをRedshiftへデータ投入してみたところまで紹介しました。
次回はデータロード時に失敗した場合のリカバリ方法などを紹介したいと思います。

このツールは良く出来ており、実際の運用でも使っていますが、Kinesis Firehoseが使えるようになればこのツールはお払い箱になるかもしれません・・・

コメントを残す

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

*