はじめに

AWSのデータレイク・データウェアハウス基盤における下記構成を例に、このようなフローにおいてどのようにテストを実施すればよいかについて説明します。本実装では、オンプレミスからS3、Redshiftへのデータの転送を、日次で定期的に行います。

テストの重要性

データレイク・データウェアハウス基盤では、ビジネスの意思決定に直結するデータを扱うため、データの正確性と信頼性が極めて重要です。適切なテストを実施することで、以下のリスクを回避できます

データの欠損や重複によるレポートの誤り
ETL処理の失敗によるデータ更新の遅延
不適切なアクセス権限によるセキュリティインシデント

「開発環境」「本番環境」の実施について

「単体テスト」「結合テスト」「システムテスト」全てにおいて、「開発環境」「本番環境」で実施するのがベストであるが、「開発環境」は、開発用の生データを用意できなかったり、「開発環境」分の工数が発生してしまうため、この場合「本番環境」だけでも最低限実施して欲しい。

単体テスト

各AWSサービスのパラメータ値が正しいことを確認
基本的には、IaC（Infrastructure as Code）を使用して構築することをおすすめします

結合テスト

Glueからオンプレミスに接続できること
ETL処理確認
- データの整合性の確認（件数及びデータの整合性チェック）
  - データソース元、データ転送先の整合性が一致していることをExcelやSQLを用いて確認
- データの加工結果の確認（マスキングや日付変換など）
- 処理結果の確認
  - 正常終了、異常終了：Glueジョブの正常終了、異常終了のパターンを確認
  - 更新対象0件：データソース元のデータが0件の場合の挙動を確認
ローカル環境からAthena,RedshiftへSQLを実行できること
ワークフロー(StepFunction)を実行して、オンプレミスからRedshiftまで正常通りにETL処理ができること

システムテスト

機能テスト
- 数日間期間を設けて、ワークフローの定期実行が正常通りであること
性能/負荷テスト
- バッチ処理時間内に処理が完了すること
- データ量が増加した場合のスケーラビリティ確認（現在の2倍、5倍のデータ量でテスト）
- 同時実行時の競合確認（複数のGlueジョブが同時に実行された場合）
障害/運用テスト
- ETL処理成功時に、Slackなどのツールへ通知されること
- ETL処理失敗時に、Slackなどのツールへ通知されること
- ETL処理失敗後に、復旧作業が問題なくできること
セキュリティテスト
- Athena,Redshiftへの権限のないテーブルに対して、アクセスできないこと
- Athena,Redshiftのアクセスログが取得できること
- インシデントや不正操作が発生した場合、Slackなどのツールへ通知されること

※ 生データの取り扱い

生データは個人・機密情報が含まれているなど、特にテスト段階では慎重に実施するべきです。
外部に漏洩しないようプライベート環境内でテストを実施 / 個人・機密情報のカラムをマスキング / 個人・機密情報のカラムへアクセスできないよう権限を設定 するなどして、工夫して取り組むことで、高品質な環境を構築することができます！

※ テスト自動化のすすめ

手動でのテスト実施は時間がかかり、ヒューマンエラーも発生しやすいため、以下のような自動化を検討することをおすすめします

データ整合性チェックの自動化: SQLクエリを定期実行し、差分がある場合のみ通知
CI/CDパイプラインへの組み込み: IaCの変更時に自動でインフラのテストを実行
定期的な疎通確認: 日次でデータソースへの接続確認を自動実行

これにより、継続的な品質担保と運用負荷の軽減が可能になります。

さいごに

テストの実施方法は、大企業やスタートアップ企業、もしくは現場ごとにやり方は異なります。
本記事は、どの現場にも共通して利用できるものを記述したため、是非参考にしていただけたら嬉しいです！