リアルタイム処理におけるDynamoDBとRedshiftの性能比較

イノベーション推進部 イノベーション開発グループの小松です。
不正検知システムのPoCや、「AIゼロフラウド^※」の開発支援などを行っています。

※ AI不正取引検知サービス：AIゼロフラウド
インターネットバンキングやATM取引における不正検知サービス。

今回は、AIゼロフラウドの設計にあたって初めて触れた、リアルタイムAPI処理におけるAWSのDynamoDBとRedshift Serverlessについて、レスポンスタイムの比較検証結果をご紹介します。

検証の背景

AIゼロフラウドでは、一部の特徴量の導出にあたって、提供元が銀行とは異なるデータを使用することがあります。この銀行外データは数種類あり、データ種別によっては数千万件のデータがあります。これらのデータをモデル作成や不正取引の判定に使うため、DBに格納しようと考えましたが、課題となったのがDBのレスポンス性能でした。リアルタイムに銀行のデータの処理を行うことを想定すると、DBのレスポンスは1秒程度に抑える必要があります。

そこで今回は、部内で自由に利用可能な検証用AWS環境で、「1リクエストにつき、4つのテーブルからデータを検索し、1秒以内に応答すること」が可能かを検証することにしました。DBの候補としては、Dynamo DB、Redshift Serverless、Athenaの3種類がありましたが、クエリやその他の処理の性質上、Athenaは検証の対象外としました。

検証の前提

1. 検証環境はAWSとする
2. DBには4種類のデータを格納し、リクエストの都度4つのテーブルを検索する
3. 検証環境のシステム構成は、Lambda, DB（DynamoDB / Redshift Serverless）とする
4. VPC内のプライベートサブネットに配置可能なリソースはプライベートサブネットに配置し、不可の場合はエンドポイント経由で接続する

DBの特徴

今回の検証で使用したDynamo DBとRedshift Serverlessには、以下のような特徴があります。

Dynamo DB

• キーバリュー型のNoSQLのデータベースサービス
• データを一意に特定する方法として、2種類のプライマリキー（以下、PK）をサポートする。1つはパーティションキー、もう1つはパーティションキー＋ソートキー。PKはテーブル作成時に設定必須
• PKの代替キーとしてテーブルを検索するために、インデックスを設定することができる。インデックスにも2種類あり、1つはグローバルセカンダリインデックス、もう1つはローカルセカンダリインデックス。インデックスに設定する内容も、パーティションキーとソートキーの項目。インデックスの設定は任意
• ローカルセカンダリインデックスのパーティションキーは、テーブルのパーティションキーと同じで、ソートキーは元のソートキーと異なる。
  グローバルセカンダリインデックスは、パーティションキー、ソートキー共にテーブルの項目とは異なる
  

  

  例えば、データをインサートするためにはテーブル設定のような設計にする必要があるが、検索時は柔軟に他の項目も使いたい、といった場合に有用な設定。
• リレーショナルDBで応答速度が遅い際、マスターテーブルだけでもDynamoDBのようなNoSQL系のDBに切り替えることで、応答速度が改善することもあるとのことで、とにかく高速で応答可能な印象

Redshift Serverless

• サーバーレスなRedshiftで、従来のRedshift（Provisioned Cluster）と機能はほぼ同じ
• 列指向型のデータベースなので、計算に必要な列のみ抽出することができる。従来のRDBMSは行指向型で、行単位でレコードを格納しているため、特定の列だけを抽出する際にまず行全体を読み込む。このため、任意の列のみを参照する場合には、Redshiftでは高速なレスポンスが期待される
• 複数テーブルの結合や、サブクエリを伴う複雑なSQLを使用する場合など、大規模なデータに向いている。そのため、データウェアハウスとして利用されることが多い印象

検証結果

平均的な実行時間を測定するため、Lambdaは連続で6回実行し、最初の1回は検証結果から除外しました。

また検索のパターンとして、以下の2パターンの検索を実行しました。

• ①テーブル3,4においてPKに設定した項目が存在する（検索結果が1件以上）
• ②テーブル3,4においてPKに設定した項目が存在しない（検索結果が0件）

検索後にフォーマットの整形などの処理は行わず、DBへのリクエスト応答時間のみを測定しました。DynamoDBでの検索において、テーブル1,2はパーティションキー、テーブル3,4はそれぞれ別のグローバルセカンダリインデックスを検索キーにしました。

実行時間は、Lambdaのテスト画面で「所要時間」に表示された時間としました。
上記を前提に検証した結果、このようになりました。

PKに設定した項目の有無や、各DBの試行間では、検索時間に大きな差は見られませんでした。
今回はほぼデフォルト設定のまま検証していますが、この状態ではDynamoDBの方が圧倒的に速いようです。

終わりに

今回はテスト条件を合わせるため、テーブル設計やレコードの内容を同一にしましたが、それぞれのDBに適した設計とすることで、レスポンスは改善する可能性があります。導入にあたっての要件やコストの事情も大きく影響すると思いますが、DBの性能面で困ることがあれば、部分的にでもDynamoDBを試すと良いと感じました。この検証が、何か参考になれば幸いです。