Redshift Serverless + dbtでデータ品質テストを100倍高速化した話

はじめに

初めまして、DeSCヘルスケア製品開発統括部データプラットフォーム開発部の俵です。

今回、データ品質のテストを行うシステムを新システムに移行しました。本記事では、システムの移行によって得られた成果や学びについて紹介します。

データ品質テスト

データ品質テストとは、管理するデータが期待通りのものであることを確認するプロセスです。以降はQC（Quality Checkの略）とよびます。誤ったデータは誤った判断や意思決定につながるため、データ品質を担保する上でQCは非常に重要なプロセスとなります。

QCのテスト観点は例として次のようなものがあります。

データ項目が未定義でない
データ項目が一意である
データ項目が数字である
データ件数が期待通りである
etc.

これらのテストを管理するデータセットの個々のエンティティ・項目に対して行っており、QCのテスト総数は1,000を超えます。

今回、上記QCを行うシステムを新システムに移行しました。

システム移行の背景

まず、システム移行前の旧QCシステムの構成について紹介します。旧システムは、QC対象のデータセットをAmazon EC2のインスタンスにアップロードし、Pythonのpandasライブラリを用いて処理するという非常にシンプルなものでした。

旧システムを新システムに移行するに至った理由としては主に2つあります。

1つ目がスピードです。 QC対象となるデータセットのデータ量は大きいもので数TBにおよび、その処理には数日〜数十日を要していました。今後ますますデータ量が増加する中で、処理時間の短縮は喫緊の課題でした。

2つ目がコストです。 pandasはデータをメモリ上にロードして処理するため、扱えるデータのサイズは基本的にマシンのメモリ容量に依存します。したがって、巨大なデータセットに対しては相応のメモリスペックを持つEC2インスタンスを用意する必要があり、クラウドコストの増加も大きな課題でした。

これら主に2つの課題を解決すべく、新システムへの移行を行いました。

新QCシステム

新QCシステムでは、主要な技術要素としてAmazon Redshift Serverlessとdbtを採用しました。まずはその2つの技術要素について簡単に紹介します。

Amazon Redshift Serverless

Amazon Redshift Serverless はAWSが提供するサーバーレスのデータウェアハウスサービスです。従来のRedshiftクラスターとは異なり、クラスターやノードの設定・管理が不要であり、使用したリソース（RPU）に対してのみ課金されるため、コスト効率が高いことが特徴です。 RPU（Redshift Processing Unit）はデータの処理能力を表しており、データ量に応じてRPUを増減することでスケールします。また、Redshiftは並列処理と列指向データストレージを組み合わせて高いクエリパフォーマンスを実現します。

dbt

dbt はデータのモデリング（変換）やテスト、ドキュメンテーションを効率的に行うためのOSSのツールです。 dbtはSQLとJinjaテンプレートを組み合わせることでデータパイプラインの構築と管理を簡素にします。また、dbtはRedshiftやBigQuery、Snowflakeなどの主要なデータウェアハウスとネイティブに連携します。

データテスト

dbtの主要な機能の1つにデータテストがあります。データテストは、dbtプロジェクト内のデータモデルやデータソースなどのリソースが期待通りであることを確認する機能です。次の例のように、YAML内で特定のリソース・列に対してunique（一意であること）やnot_null（未定義でないこと）を定義することでそれらをテストすることができます。また、オリジナルのデータテストを実装することもできます。

version: 2

models:
  - name: orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: status
        tests:
          - accepted_values:
              values: ['placed', 'shipped', 'completed', 'returned']
      - name: customer_id
        tests:
          - relationships:
              to: ref('customers')
              field: id

技術選定の背景

新QCシステムの技術選定を行う上で考慮した要件は次のようなものがあります。

巨大なデータを高速に処理できること
データ量の増加に対してスケールすること
保守・運用の負荷が低いこと（サーバーレス）
コスト効率が高いこと（従量課金）
AWS環境で動作すること（データがAWS環境にあるため）
QCテストの実装や保守が容易であること

Redshift Serverlessとdbtは、両者を連携させることで上記要件を全て満たすことができます。また、両者の連携が容易であることも採用の決め手となりました。その後PoCを行い、上記要件を全て満たすことを確認した上でシステムアーキテクチャを設計しました。

システムアーキテクチャ

新QCシステムのアーキテクチャ図（簡易版）は次になります。

Redshift ServerlessやECS on Fargate（dbtの実行環境）をはじめとして多くのAWSサービスを使用しています。実際にはこれらの処理に加えて通知処理やその他の処理もあるため、アーキテクチャは更に大規模かつ複雑になります。これら多くのサービスを管理するにはIaCの導入がほぼ必須であり、我々はTerraformとGitHub Actionsを用いてサービスの管理やデプロイを実行しています。旧システムがEC2インスタンスのみの構成であったことを考えると非常に複雑化しますが、これがサーバーレスアーキテクチャの特徴です。

サーバーレスアーキテクチャ

サーバーレスアーキテクチャは、開発者がインフラを管理することなくアプリケーションを開発するためのソフトウェア設計のアプローチです。常時起動するサーバーを必要としないためコスト効率が高く、またスケーラビリティが高いことも特徴です。開発者が自前で管理していたシステムの機能をクラウドサービスが担うため、それらの機能はサービスごとに細かく分割されます。したがって、必然的にシステム全体は（マイクロ）サービスの集合となり、サービス間は疎結合になります。

本QCシステムでは、旧システムにおけるEC2インスタンス管理からの脱却がサーバーレス化に該当します。 QCシステムのサーバーレス化を通して感じたサーバーレスアーキテクチャのメリット・デメリットをまとめます。

メリット
- システム全体が疎結合になるためスケーラビリティや拡張性が高い
- 常時起動するサーバーを必要としないためコスト効率が高い
- インフラを最小限の工数で管理できる
  - IaCやCI/CDとも相性が良い
デメリット
- 多くのクラウドサービスを使用するため学習コストが高い
- 多くのクラウドサービスが連携するためデバッグや監視が難しい
  - サービス監視はLambda関数を実装して対応した
- コストの予測が難しい
  - リソースの使用量に対して課金されるため、使用量が予測しにくい場合にコストの予測が難しい
- セキュリティの管理が複雑になる
  - 多くのクラウドサービスが連携するため、それらのアクセス権限を全て適切に管理する必要がある

サーバーレスアーキテクチャを採用するかどうかはシステムの要件にも左右されますが、特にスケーラビリティやコスト効率が重要なシステムに適しています。また、開発者のクラウドサービス利用経験が浅い場合に学習コストが高いことはデメリットですが、裏を返せば多くのクラウドサービスを一度に学べるため、挑戦する価値は大きいといえます。

システム移行の成果

最後に、QCシステムの移行によって得られた成果を紹介します。

システム移行によって得られた最大の成果は、本記事のタイトルにもあるように、データ品質テスト（QC）の高速化です。システム移行の背景でも触れましたが、旧QCは巨大なデータセットに対して数日〜数十日を要していました。それが新QCでは1~2時間で完了するため、約100倍の速度向上を達成しました。 Redshiftによる並列処理と列志向データストレージの優秀性が確認できます。 QCの速度向上は、今後ますます増加するデータ量に対応するだけでなく、データ鮮度の向上にもつながります。データ鮮度を向上する（つまりデータを最新の状態とする）ことは、データに基づいた意思決定を迅速かつ高精度にするため、ビジネス上も大きなメリットがあるといえます。

また、サーバーレスアーキテクチャを採用したことによるコスト効率の向上も大きな成果です。こちらについては今後の運用次第ではありますが、数十%程度のコスト削減を見込んでいます。 FinOpsと呼ばれるクラウドコストの最適化手法が近年話題ですが、その実装としてサーバーレスアーキテクチャは強力な選択肢になります。さらにサーバーレスアーキテクチャの副次的効果として、システム全体が疎結合になったことが挙げられます。疎結合なシステムは各コンポーネント（サービス）が独立しているため、それぞれ個別にスケーリングできます。また、同様の理由から新しい技術やサービスを導入することも比較的容易であり、今後起きうるビジネス要件の変化に対して迅速かつ柔軟に対応できる点も大きな成果であるといえます。

まとめ

データ品質のテスト（QC：Quality Check）を行うシステムを新システムに移行しました。 QCは管理するデータが期待通りであることを確認するプロセスです。旧システムはQCの実行速度の面で喫緊の課題を抱えていました。新システムでは主要な技術要素としてRedshift Serverlessとdbtを採用し、サーバーレスアーキテクチャーとしました。その結果、新システムのQC実行速度は旧システムと比較して約100倍向上し、コスト効率も向上しました。