1. はじめに
Redshiftで集計したデータをHubDBに反映する処理をLambdaで実装しました。
最初はシンプルに「HubDBのAPIを1行ずつ叩いて更新すればよい」と考えていました。
しかし実装を進める中で、**Lambdaの最大実行時間が15分（900秒）**という制約が大きな問題となりました。
本記事では、
- HubDBへ1行ずつAPI更新する方法
- CSVファイルを作成して一括インポートする方法
この2つを実際に実装した経験をもとに、
それぞれのメリット・デメリットと使い分けについて紹介します。
2. システム構成概要
- EventBridge をトリガーに Lambda を起動
- Lambda から Redshift に接続し、集計データを取得
- 集計データのテーブルが2つ、①20行のデータ②900行のデータ
- 取得したデータを HubDB に反映
定期バッチとして動作する想定です。
3. 前提：HubDBのデータ更新方法
HubDBのデータ更新には主に以下の2つの方法があります。
- Rows API を使った1行ずつの更新
- CSV Import API を使った一括更新
| 方法 | 更新単位 | 特徴 |
|---|---|---|
| Rows API | 1行 | 実装がシンプル、細かい制御が可能 |
| CSV Import API | 複数行 | 実装が複雑、大量データ向き、処理が高速 |
4. シンプルな処理で、HubDBを1行ずつ更新する実装
4.1 実装イメージ
- RedshiftからデータをSELECT
- forループで1行ずつ処理
- HubDB Rows API を呼び出して更新
4.2 この方法を選んだ理由
- 実装が直感的で分かりやすい
- ログを追いやすくデバッグしやすい
- 行単位でエラー処理ができる
実装が比較的簡単で、コードも動くので、この方法で処理を実施した。
実施後、、、
計2つの集計テーブル①②の処理がスタート
①20行のテーブル：済
②900行のテーブル：タイムアウトエラーのため停止
5. 発生した問題：Lambdaの15分制限
5.1 Lambdaの制約
- Lambdaの最大実行時間：15分（900秒）
- HubDB APIの呼び出し：1回あたり約1秒（私の環境では）
5.2 実測ベースでの限界
| 内容 | 数値 |
|---|---|
| 1行更新にかかる時間 | 約1秒 |
| Lambda最大実行時間 | 900秒 |
| 更新可能な最大行数 | 約900行 |
データ件数が増えると、Lambdaがタイムアウトすることが分かりました。
6. CSVを作成して一括インポートする実装
6.1 方針転換の背景
1行ずつAPIを叩く方法では、
- API呼び出し回数が増える
- Lambdaの制限に引っかかる
という問題がありました。
そこで、API呼び出し回数を減らす方法として、
CSVを作成して一括でインポートする方式を採用しました。
6.2 実装の流れ
- Lambda関数にて、Redshiftからデータを取得
- 取得したデータをHubDBのテーブル定義に合わせて変換
- Lambdaの
/tmpディレクトリにCSVファイルを作成 - HubDB CSV Import APIを呼び出し、CSVファイルをHubDBへ一括インポート
7. Lambdaの /tmp を使ったCSV作成について
-
/tmpはLambda実行中のみ使える一時領域 - 最大512MBまで利用可能
- CSV作成 → インポート → 不要になったら削除
S3を使わずに、最小限の構成で完結できる点がメリットです。
8. 処理時間の比較結果
実行結果の具体例
実運用を想定し、2つの集計テーブルを同一のLambda関数内で順に処理する構成で実行しました。
・集計テーブル①：20行程度の小規模データ
→ 1行ずつのAPI更新方式で問題なく処理が完了
・集計テーブル②：約900行のデータ
→ CSVファイルのインポート方式で問題なく処理が完了
集計テーブル①②あわせて処理時間が1分程度で無事終了
この結果から、
・少量データでは1行ずつAPI更新でも問題ない
・一定以上のデータ量になると、Lambdaの実行時間制限がボトルネックになる
ことが明確になりました。
一部、CSV一括インポート方式に切り替えたことで、
両方の集計テーブルを安定して最後まで処理できるようになりました。
9. 更新方式によるメリット・デメリット整理
ここで、1つの疑問が出てきました。
両方とも、CSVファイルの一括インポートの方が、シンプルな構造で楽なんじゃないか？
それぞれの方式を理解し、判断実装が大切だと感じたので、整理したいと思います。
9.1 1行ずつAPI更新
メリット
- 実装がシンプル
- 行単位でエラー処理、更新が可能
デメリット
- Lambdaの実行時間制限に弱い
- データ件数が増えるとスケールしない
9.2 CSVインポート方式
メリット
- 大量データでも安定して処理できる
- 実行時間が短い
デメリット
- 実装がやや複雑
- CSVフォーマットの管理が必要
- 行単位の更新が不可能
10. 実運用での使い分け
- 少量データ・検証用途：1行ずつAPI更新
- 本番バッチ・大量データ：CSVインポート
両方を実装した上で、データ量によって、使い分ける構成が必須と感じました。
また、
テーブルの一部の更新をしない、一括のインポートができればいい。
という場合であれば、行数が少なくとも、CSVファイル経由のインポートも運用可能です。
11. まとめ
- LambdaでHubDBへインサート時、タイムアウトの問題が発生する
- HubDBはデータ量に応じて更新方法を選ぶ必要がある