はじめに

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

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

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

単体テスト

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

結合テスト

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

システムテスト

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

※ 生データの取り扱い

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

さいごに

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