Amazon Aurora DSQL 入門ガイド：知っておきたい基本と使い方

---

Amazon Aurora DSQL (フェデレーテッドクエリ) 入門ガイド：知っておきたい基本と使い方

はじめに：現代のデータ課題とAurora DSQL

現代のビジネスにおいて、データはますます多様化し、さまざまな場所に分散して存在しています。リレーショナルデータベースに格納された構造化データだけでなく、アプリケーションログ、IoTデバイスからの時系列データ、クリックストリームデータ、ソーシャルメディアデータなど、非構造化または半構造化データが日々大量に生成されています。これらのデータは、Amazon S3のようなオブジェクトストレージにデータレイクとして蓄積されたり、別のデータベースシステム（他のRDSインスタンス、Redshiftなど）に格納されたりすることが一般的です。

このような状況下で、データサイエンティスト、アナリスト、開発者は、異なる場所に存在する複数のデータソースを組み合わせて分析したり、レポートを作成したりする必要に迫られます。従来のETL（Extract, Transform, Load）プロセスは、データを一元化されたデータウェアハウスやデータマートに集約するために利用されてきましたが、これは時間とコストがかかり、データの鮮度が失われるという課題があります。また、アドホックな分析や、特定のデータソースへのリアルタイムに近いアクセスが必要な場合には適していません。

Amazon Aurora DSQL（Distributed SQL）、より正確にはAmazon Auroraのフェデレーテッドクエリ機能は、この課題に対する強力なソリューションを提供します。この機能を使用すると、Amazon Auroraのデータベースインスタンスから直接、外部のデータソースに対してSQLクエリを実行できます。これにより、データを移動させることなく、Aurora内のデータと外部のデータを組み合わせて簡単に分析することが可能になります。

本記事では、Amazon Auroraのフェデレーテッドクエリ機能（以下、DSQLと呼びます）について、その基本概念、仕組み、利用方法、設定方法、具体的な使用例、そしてパフォーマンスやコストに関する考慮事項まで、初心者の方でも理解できるように詳細に解説します。

Aurora DSQL（フェデレーテッドクエリ）とは？

Amazon Auroraのフェデレーテッドクエリは、Auroraデータベースエンジン（現在、Aurora MySQLおよびAurora PostgreSQLで利用可能）から、他のAWSサービスや外部データソースに格納されたデータに対して、標準的なSQL構文を使用して直接クエリを実行できる機能です。

具体的には、以下のデータソースに対してクエリを実行できます。

1. Amazon S3: データレイクとして蓄積されたファイルデータ（CSV, Parquet, JSON, Text）に対してクエリを実行できます。
2. Amazon Redshift: データウェアハウスに格納されたデータに対してクエリを実行できます。（Aurora PostgreSQLからのみ）
3. Amazon RDS for PostgreSQL / MySQL: 別のRDSインスタンスに格納されたデータに対してクエリを実行できます。
4. Amazon Aurora Serverless v2: 別のAurora Serverless v2クラスターに格納されたデータに対してクエリを実行できます。

この機能の最も重要なポイントは、データをAuroraデータベースにインポートしたり、ETL処理で変換したりする必要がないという点です。クエリが実行されるたびに、Auroraが必要なデータを外部ソースから取得し、Aurora内のデータと組み合わせて処理します。

「DSQL」という用語は、もともと分散データベースや分散クエリエンジンを指す一般的な言葉ですが、Amazon Auroraの文脈ではこの「フェデレーテッドクエリ」機能、すなわちAuroraを起点とした外部データへの分散クエリを指すことが多いです。AWSの公式ドキュメントでは「フェデレーテッドクエリ」という名称が主に使用されています。本記事では、広く認知されているDSQLという言葉を用いつつ、それがAuroraのフェデレーテッドクエリ機能であることを明確にして説明を進めます。

なぜAurora DSQLを使うのか？解決できる課題

Aurora DSQLは、以下のようなデータ管理および分析における一般的な課題を解決します。

1. データサイロの解消: 異なるシステムや場所にデータが分散している「データサイロ」を、データを移動させることなく仮想的に統合できます。
2. ETLの回避または削減: 全てのデータを一元化する必要がないため、ETLプロセスを簡略化したり、完全に回避したりできます。これにより、データ準備の時間とコストを削減できます。
3. リアルタイムに近い分析: データをETLで移動させる待機時間がないため、外部ソースのデータに対して、より鮮度の高い状態でクエリを実行できます。
4. アドホック分析の容易化: データサイエンティストやアナリストは、慣れ親しんだSQLを使って、S3上のデータレイクや他のデータベースのデータを簡単に探索・分析できます。
5. ストレージコストの最適化: 大量の履歴データやログデータを安価なS3に保存しつつ、必要に応じてAuroraから直接クエリを実行できます。全てのデータを高性能・高コストなAuroraストレージに置く必要がなくなります。
6. 運用負荷の軽減: ETLパイプラインの構築、保守、監視にかかる運用負荷を軽減できます。

これらのメリットにより、Aurora DSQLは、データレイクの探索、オペレーションデータとログデータの統合分析、レガシーシステムデータの参照など、様々なユースケースで有効なツールとなります。

Aurora DSQLの仕組み（アーキテクチャ）

Aurora DSQLは、Auroraデータベースエンジンの拡張機能として実装されています。その基本的な仕組みは以下の通りです。

1. クエリの実行: ユーザーがAuroraデータベースに対して、外部テーブル（後述）を参照する SELECT クエリを実行します。
2. クエリの解析と最適化: Auroraのクエリオプティマイザは、クエリが外部テーブルを参照していることを認識します。可能な場合、オプティマイザは述語プッシュダウン（Predicate Pushdown）などの最適化を適用しようとします。これは、外部ソース側で可能な限りデータをフィルタリングしたり、不要なカラムを除外したりすることで、Auroraに転送されるデータ量を減らすテクニックです。
3. 外部サービスへの接続: Auroraは、外部テーブル定義に関連付けられた外部サービス定義（CREATE EXTERNAL SERVICE で定義）を使用して、対象の外部データソースに接続します。接続情報は、IAMロールやAWS Secrets Managerに格納された認証情報などが利用されます。
4. データソースコネクタの利用: Auroraエンジン内部または連携するコンポーネント（データソースコネクタ）は、外部ソース固有のプロトコルやAPI（例: S3 API, PostgreSQLプロトコル）を使用してデータにアクセスします。
5. データの取得: コネクタは、クエリの要求に基づいて外部ソースからデータを読み込みます。S3の場合は、指定されたURI（S3パス）からファイルを読み込み、指定されたフォーマット（CSV, Parquetなど）で解析します。RDS/Redshiftの場合は、JDBC/ODBCのようなプロトコルを通じてデータを取得します。
6. データのストリーミング: 取得されたデータは、Auroraエンジンにストリームされます。
7. クエリ処理: Auroraエンジンは、ストリームされた外部データと、必要であればAurora内のテーブルのデータを組み合わせて、クエリの残りの部分（JOIN, WHERE, GROUP BY, ORDER BYなど）を処理します。
8. 結果の返却: 最終的なクエリ結果がクライアントに返されます。

重要なのは、外部ソースのデータは永続的にAuroraストレージに格納されるわけではないという点です。クエリ実行時にオンデマンドで取得され、処理後には破棄されます。この「データ移動なし」のアプローチが、DSQLの大きな利点です。

サポートされるデータソースとファイルフォーマット

Aurora DSQLは、以下のデータソースタイプとファイルフォーマット（S3の場合）をサポートしています。

サポートされるデータソースタイプ

• Amazon S3: データレイク用途で最も一般的です。
• Amazon Redshift: Aurora PostgreSQLからのみ接続可能です。
• Amazon RDS for PostgreSQL: Aurora PostgreSQLからのみ接続可能です。
• Amazon RDS for MySQL: Aurora MySQLからのみ接続可能です。
• Amazon Aurora Serverless v2 (PostgreSQL): 別のAurora Serverless v2 PostgreSQLクラスターから接続可能です。
• Amazon Aurora Serverless v2 (MySQL): 別のAurora Serverless v2 MySQLクラスターから接続可能です。

S3でサポートされるファイルフォーマット

S3をデータソースとする場合、以下のファイルフォーマットとエンコーディングがサポートされています。

• CSV (Comma Separated Values):
  • オプション: デリミタ (csv.delimiter), ヘッダーの有無 (csv.header), 引用符 (csv.quote), エスケープ文字 (csv.escape), Null値の表現 (csv.nullvalue), BOM (Byte Order Mark) のスキップ (csv.skip_header_rows) など。
• Parquet: カラム指向フォーマットで、分析クエリに適しています。圧縮効率とクエリパフォーマンスに優れます。
• JSON (JavaScript Object Notation): JSON形式のデータ。
  • オプション: 特定のパスを指定してフラット化して取得 (json.path) など。
• Text: 単純なテキストファイル。各行が1つのカラムとして扱われます。
• ORC (Optimized Row Columnar): Parquetと同様のカラム指向フォーマット。Aurora PostgreSQLでサポートされます。

利用可能なフォーマットやオプションは、Auroraのバージョンやエンジン（MySQL/PostgreSQL）によって異なる場合があります。常に最新のAWS公式ドキュメントで確認することをお勧めします。

Aurora DSQLの利用準備：前提条件と設定

Aurora DSQLを利用するには、いくつかの前提条件を満たし、適切な設定を行う必要があります。これらは主に、ネットワーク、IAMアクセス権限、そして認証情報管理に関するものです。

1. Auroraクラスターのバージョン

Aurora DSQL機能は、特定のAuroraエンジンのバージョン以降でサポートされています。利用したいエンジンのバージョンがこの機能をサポートしていることを確認してください。通常、メジャーバージョンアップや特定のマイナーバージョンアップで導入されます。最新のサポート状況はAWS公式ドキュメントで確認が必要です。

2. IAMロールとポリシー

AuroraデータベースインスタンスがS3や他のAWSサービス（Redshift, RDS Data API, Secrets Managerなど）にアクセスするためには、適切なIAMロールとそのポリシーが必要です。

• S3へのアクセス: S3バケットからオブジェクトを読み取るための s3:GetObject と、指定されたパス内のオブジェクトをリストアップするための s3:ListBucket (またはより限定的な s3:ListObjects, s3:ListObjectsV2) 権限が必要です。
  json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::your-s3-bucket-name/*",
"arn:aws:s3:::your-s3-bucket-name"
]
}
]
}
• RDS/Redshiftへのアクセス:
  • Aurora MySQLからRDS for MySQLへの接続には、RDS Data Service (Data API) を使用します。そのため、Data APIの実行権限 (rds-data:ExecuteStatement) が必要です。
    json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "rds-data:ExecuteStatement",
"Resource": "arn:aws:rds:<region>:<account-id>:cluster:<target-rds-cluster-name>"
}
]
}
  • Aurora PostgreSQLからRDS for PostgreSQL/Redshiftへの接続は、Foreign Data Wrapper (FDW) の仕組みを利用し、JDBC/ODBC接続に近いです。この場合、Secrets Manager経由で認証情報を使用することが推奨されるため、Secrets Managerへのアクセス権限が必要になります。
    json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-name>-*"
}
]
}
• IAMロールの信頼ポリシー: 作成したIAMロールは、Auroraサービス（rds.amazonaws.com）に引き受けられる（AssumeRole）ように信頼ポリシーを設定する必要があります。
  json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
• AuroraクラスターへのIAMロールのアタッチ: 作成したIAMロールを、Auroraクラスターにアタッチする必要があります。これはAWSマネジメントコンソール、AWS CLI、またはSDKから設定できます。

3. ネットワーク設定（セキュリティグループ、VPCエンドポイント）

Auroraクラスターと外部データソース間のネットワーク通信を許可する必要があります。

• セキュリティグループ:
  • Auroraクラスターのセキュリティグループ: 外部RDS/Redshiftに接続する場合、Auroraのセキュリティグループから、対象のRDS/Redshiftのセキュリティグループに対して、データベースのポート（PostgreSQL: 5432, MySQL: 3306, Redshift: 5439など）へのEgress通信を許可する必要があります。
  • 外部RDS/Redshiftのセキュリティグループ: AuroraのセキュリティグループからのデータベースポートへのIngress通信を許可する必要があります。
• VPCエンドポイント:
  • S3へのアクセス: AuroraクラスターがPrivate Subnetにある場合、S3へのアクセスにはVPCエンドポイント（Gateway EndpointまたはInterface Endpoint）が必要です。推奨はInterface Endpoint (com.amazonaws.<region>.s3) です。これにより、S3へのトラフィックがインターネットを経由せず、VPC内からプライベートにルーティングされます。
  • Secrets Managerへのアクセス: Secrets Managerに認証情報を格納する場合、AuroraクラスターがPrivate Subnetにある場合は、Secrets ManagerへのVPCエンドポイント (com.amazonaws.<region>.secretsmanager) が必要です。
  • RDS Data APIへのアクセス: Aurora MySQLからRDS for MySQLに接続しData APIを使用する場合、Data APIへのVPCエンドポイント (com.amazonaws.<region>.rds-data) が必要になる場合があります。

4. 認証情報の管理（RDS/Redshift接続の場合）

RDSやRedshiftに接続する場合、対象データベースへの認証情報（ユーザー名、パスワード）が必要です。セキュリティ上の理由から、これらの認証情報はAWS Secrets Managerに格納し、AuroraからIAMロール経由でSecrets Managerから取得して使用することが強く推奨されます。

• Secrets Managerに、接続先のデータベースのユーザー名とパスワードを含むシークレットを作成します。
• 作成したIAMロールに、このシークレットへの secretsmanager:GetSecretValue 権限を付与します。

これらの準備が整って初めて、Aurora DSQL機能を利用して外部データソースにアクセスできるようになります。

Aurora DSQLの基本的な使い方：SQL構文

Aurora DSQLは、標準的なSQL構文を拡張して外部データソースを扱います。主に以下の2つの新しいSQLコマンドを使用します。

1. CREATE EXTERNAL SERVICE: 外部データソースへの接続方法（タイプ、場所、認証情報など）を定義します。
2. CREATE EXTERNAL TABLE: 外部データソース内の特定のデータ（S3上のファイルパスや、外部データベースのテーブル）と、それを参照するAurora内の「外部テーブル」をマッピングさせます。

これらの定義が完了すれば、通常の SELECT 文で外部テーブルをクエリできます。

CREATE EXTERNAL SERVICE

外部データソースへの接続情報を定義します。一度定義すれば、複数の外部テーブルから参照できます。

sql
CREATE EXTERNAL SERVICE external_service_name
[ CATALOG 'catalog_name' ] -- Aurora PostgreSQL with Glue integration (Optional)
TYPE data_source_type
PARAMETERS (
parameter_name = 'parameter_value' [, ...]
);

• external_service_name: 作成する外部サービスの名前。Aurora内で一意である必要があります。
• CATALOG: Aurora PostgreSQLの場合、AWS Glueデータカタログとの連携を指定できます。これにより、Glueに登録されたテーブル定義を利用できます。S3データレイクでGlueを使っている場合に便利です。
• TYPE: 外部データソースのタイプを指定します。例: S3, Redshift, RDS_PG, RDS_MYSQL, AURORA_PG, AURORA_MYSQL.
• PARAMETERS: 接続に必要なパラメータを指定します。パラメータはTYPEによって異なります。
  • TYPE S3:
    • IAM_ROLE: S3アクセスに使用するIAMロールのARN。必須。
    • REGION: S3バケットのリージョン。クエリ実行リージョンと異なる場合に指定。
    • PROFILE_NAME: AWS認証プロファイルの指定（ほとんど使わない）。
  • TYPE Redshift (Aurora PostgreSQL):
    • HOST: Redshiftクラスターのエンドポイント。
    • PORT: Redshiftのポート番号 (通常 5439)。
    • DATABASE: 接続するデータベース名。
    • SECRET_ARN: Secrets Managerに格納された認証情報のARN。
    • IAM_ROLE: Secrets Managerへのアクセスに使用するIAMロールのARN。
  • TYPE RDS_PG, TYPE AURORA_PG (Aurora PostgreSQL):
    • HOST: ターゲットデータベースのエンドポイント。
    • PORT: ポート番号 (通常 5432)。
    • DATABASE: 接続するデータベース名。
    • SECRET_ARN: Secrets Managerに格納された認証情報のARN。
    • IAM_ROLE: Secrets Managerへのアクセスに使用するIAMロールのARN。
  • TYPE RDS_MYSQL, TYPE AURORA_MYSQL (Aurora MySQL):
    • CLUSTER_ARN: ターゲットデータベースクラスターのARN。RDS Data API経由で接続するため、エンドポイントではなくクラスターARNを指定します。
    • SECRET_ARN: Secrets Managerに格納された認証情報のARN。
    • IAM_ROLE: Secrets Managerへのアクセスに使用するIAMロールのARN。

例1: S3サービス定義

sql
CREATE EXTERNAL SERVICE s3_logs_service
TYPE S3
PARAMETERS (
IAM_ROLE = 'arn:aws:iam::123456789012:role/AuroraS3AccessRole',
REGION = 'ap-northeast-1'
);

例2: RDS for PostgreSQLサービス定義 (Aurora PostgreSQL)

sql
CREATE EXTERNAL SERVICE external_rds_pg_service
TYPE RDS_PG
PARAMETERS (
HOST = 'external-rds-instance.abcdefg12345.ap-northeast-1.rds.amazonaws.com',
PORT = '5432',
DATABASE = 'mydatabase',
SECRET_ARN = 'arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:external/rds/credentials-xxxxxx',
IAM_ROLE = 'arn:aws:iam::123456789012:role/AuroraSecretsManagerAccessRole'
);

例3: RDS for MySQLサービス定義 (Aurora MySQL)

sql
CREATE EXTERNAL SERVICE external_rds_mysql_service
TYPE RDS_MYSQL
PARAMETERS (
CLUSTER_ARN = 'arn:aws:rds:ap-northeast-1:123456789012:cluster:external-rds-cluster',
SECRET_ARN = 'arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:external/rds/credentials-xxxxxx',
IAM_ROLE = 'arn:aws:iam::123456789012:role/AuroraSecretsManagerAccessRole'
);

CREATE EXTERNAL TABLE

外部サービス定義を参照し、外部データソース内の特定のデータパスやテーブルと、Aurora内の論理的なテーブルをマッピングさせます。

sql
CREATE EXTERNAL TABLE external_table_name (
column1 datatype [options],
column2 datatype [options],
...
)
EXTERNAL_SERVICE_NAME external_service_name
SOURCE_TYPE source_type
[ LOCATION 'location' ] -- For S3 or Database
[ URI 'uri' ] -- For S3
[ TABLE 'external_table_name' ] -- For Database
[ FORMAT 'format' ] -- For S3
[ OPTIONS (option_name = 'option_value' [, ...]) ] -- For S3
[ PARTITIONED BY (column_name datatype [, ...]) ]; -- For partitioned S3 data

• external_table_name: 作成する外部テーブルの名前。Aurora内で一意である必要があります。
• カラム定義: 外部データソース内のデータに対応するカラム名とデータ型を定義します。データ型はAuroraがサポートするものを使用します。
• EXTERNAL_SERVICE_NAME: 参照する外部サービスの名前。
• SOURCE_TYPE: 外部ソースの種類。
  • S3: Amazon S3上のファイル。
  • Database: 別のRDS/Redshiftデータベース内のテーブル。
• LOCATION または URI:
  • SOURCE_TYPE S3: データが格納されているS3上のパス（URI）。ワイルドカード (*) を使用して複数のファイルやフォルダを指定できます。例: s3://your-bucket/logs/year=*/month=*/*/*.csv
  • SOURCE_TYPE Database: 外部データベース内のテーブル名。
• FORMAT: SOURCE_TYPE S3の場合に必須。ファイルフォーマットを指定します (CSV, PARQUET, JSON, TEXT, ORC)。
• OPTIONS: SOURCE_TYPE S3 および特定のFORMATの場合に、フォーマット固有のオプションを指定します。例: csv.delimiter = ',', csv.header = true, json.path = '$.users[*]'。
• PARTITIONED BY: S3上のデータがパーティション分割されている場合に、パーティションカラムを定義します。S3のパス構造と一致させる必要があります。これにより、クエリ時にパーティションプルーニング（Partition Pruning）が働き、不要なパーティションの読み込みをスキップしてパフォーマンスを向上させます。

例1: S3上のCSVファイルを参照する外部テーブル

S3パス: s3://my-log-bucket/weblogs/year=2023/month=10/day=01/logdata.csv, s3://my-log-bucket/weblogs/year=2023/month=10/day=02/logdata.csv …
これらのCSVファイルはヘッダー行を含み、カンマ区切りとします。

“`sql
CREATE EXTERNAL TABLE web_logs (
timestamp timestamp,
user_id bigint,
request_path varchar(255),
status_code int,
response_time double precision
)
EXTERNAL_SERVICE_NAME s3_logs_service — 先ほど定義したサービス名
SOURCE_TYPE S3
URI ‘s3://my-log-bucket/weblogs/’ — パーティションルートを指定
FORMAT CSV
OPTIONS (
csv.delimiter = ‘,’,
csv.header = true
)
PARTITIONED BY (
year int,
month int,
day int
);

— パーティション情報をAuroraにロード
— これは一度実行すれば、新しいパーティションが追加されたら再実行が必要です。
— (またはGlueカタログ連携を利用するか、自動発見機能があればそれを利用)
— Aurora MySQLの場合:
CALL mysql.scan_external_partitions(‘web_logs’);
— Aurora PostgreSQLの場合:
— ALTER EXTERNAL TABLE web_logs ADD PARTITION (year=2023, month=10, day=1) LOCATION ‘s3://my-log-bucket/weblogs/year=2023/month=10/day=01/’;
— または、Glueカタログ連携や、パスのワイルドカード指定とスキャンで自動発見される場合もあります。
``
*注:* パーティションの扱いはAuroraのバージョンやエンジンによって異なります。Aurora MySQLではCALL mysql.scan_external_partitions(‘table_name’)で指定URI以下のパーティションを自動発見するのが一般的です。Aurora PostgreSQLでは、手動でALTER EXTERNAL TABLE … ADD PARTITION`で登録するか、Glueカタログ連携を利用します。URIにワイルドカードを使うだけでもスキャンされる場合もあります。利用するバージョン・エンジンのドキュメントを確認してください。

例2: S3上のParquetファイルを参照する外部テーブル

S3パス: s3://my-data-lake/users/part-00000.parquet

“`sql
CREATE EXTERNAL TABLE users_data (
user_id bigint,
user_name varchar(255),
registration_date date
)
EXTERNAL_SERVICE_NAME s3_data_lake_service
SOURCE_TYPE S3
URI ‘s3://my-data-lake/users/’ — 特定のディレクトリを指定
FORMAT PARQUET;

— Parquetは自己記述型なので、カラム定義はParquetファイルのスキーマと一致させる必要があります。
“`

例3: 外部RDS for PostgreSQLデータベース内のテーブルを参照する外部テーブル (Aurora PostgreSQL)

外部データベースに customer_orders というテーブルが存在すると仮定します。

sql
CREATE EXTERNAL TABLE external_customer_orders (
order_id bigint,
customer_id bigint,
order_date timestamp,
amount numeric(10, 2)
)
EXTERNAL_SERVICE_NAME external_rds_pg_service -- 先ほど定義したサービス名
SOURCE_TYPE Database
TABLE 'customer_orders'; -- 外部データベース内のテーブル名
注: LOCATION または URI の代わりに TABLE を使用します。カラム定義は外部テーブルと一致させる必要があります。

例4: 外部RDS for MySQLデータベース内のテーブルを参照する外部テーブル (Aurora MySQL)

外部データベースに product_inventory というテーブルが存在すると仮定します。

sql
CREATE EXTERNAL TABLE external_product_inventory (
product_id int,
stock_count int,
last_updated timestamp
)
EXTERNAL_SERVICE_NAME external_rds_mysql_service -- 先ほど定義したサービス名
SOURCE_TYPE Database
TABLE 'product_inventory'; -- 外部データベース内のテーブル名

SELECT 文でのクエリ

外部サービスと外部テーブルが定義されれば、通常のSQL SELECT 文で外部テーブルにアクセスできます。内部テーブルと同様に、JOIN, WHERE, GROUP BY, ORDER BY などの句を使用できます。

例5: S3上のログデータとAurora内のユーザーデータをJOIN

sql
-- Aurora内のユーザーテーブル
SELECT
l.timestamp,
l.request_path,
l.status_code,
u.user_name
FROM
external_web_logs l -- S3上のログデータ (外部テーブル)
JOIN
internal_users u ON l.user_id = u.id -- Aurora内のユーザーデータ (内部テーブル)
WHERE
l.year = 2023 AND l.month = 10
AND l.status_code = 200
LIMIT 100;

例6: S3上のParquetデータを集計

sql
SELECT
registration_date,
COUNT(*) AS num_users
FROM
external_users_data -- S3上のParquetデータ (外部テーブル)
WHERE
registration_date >= '2023-01-01'
GROUP BY
registration_date
ORDER BY
registration_date;

例7: 外部RDSテーブルのデータをクエリ (Aurora PostgreSQL)

sql
SELECT
customer_id,
SUM(amount) AS total_spent
FROM
external_customer_orders -- 外部RDS PGのテーブル (外部テーブル)
WHERE
order_date >= '2023-10-01'
GROUP BY
customer_id
HAVING
SUM(amount) > 1000;

これらの例からわかるように、Aurora DSQLを使うことで、異なる場所に存在するデータを、あたかも同じデータベース内にあるかのように扱うことができます。

高度なトピックと考慮事項

Aurora DSQLは非常に便利な機能ですが、その特性を理解し、適切に使用するためにはいくつかの高度なトピックや考慮事項があります。

パフォーマンス

Aurora DSQLのパフォーマンスは、内部テーブルへのクエリとは異なります。外部データソースからのデータの読み込みには、ネットワークI/Oや外部サービス側の処理が伴うため、パフォーマンスに影響を与える可能性があります。

• データ転送のオーバーヘッド: 外部ソースからAuroraへデータが転送される際にネットワーク遅延が発生します。
• データソース側の処理能力: S3からのデータ読み込み速度や、外部RDS/Redshiftインスタンスのクエリ処理能力がボトルネックになる可能性があります。
• 述語プッシュダウン (Predicate Pushdown): Auroraオプティマイザは、可能な限り WHERE 句などのフィルタリング条件を外部ソースにプッシュダウンしようとします。
  • S3の場合: S3 Prefixフィルタリング（URIに指定されたパスやパーティションカラムに基づくフィルタ）や、ファイル形式によってはカラムの読み込みをスキップする機能（Parquet/ORC）が利用されます。これにより、Auroraに転送されるデータ量が大幅に削減され、パフォーマンスが向上します。
  • RDS/Redshiftの場合: WHERE 句全体が外部データベースに送信され、外部データベース側でフィルタリングが実行されます。これは非常に効果的な最適化です。
• データフォーマット: S3の場合、ParquetやORCのようなカラム指向フォーマットは、特定のカラムだけを読み込む際に効率的であり、分析クエリのパフォーマンスを向上させます。CSVやJSONは行指向であり、特定のカラムだけが必要でも行全体を読み込む必要があるため、一般的に分析には不向きです。
• パーティショニング: S3上のデータをパーティション分割し、CREATE EXTERNAL TABLE でパーティションカラムを定義することで、クエリ時に不要なパーティション（ファイル群）の読み込みをスキップできます（パーティションプルーニング）。これは非常に効果的なパフォーマンス最適化手法です。
• データ量: 外部テーブルから読み込むデータ量が多ければ多いほど、クエリ実行時間は長くなります。必要最小限のカラムだけを SELECT する、適切なフィルタリング条件を使用するなど、読み込むデータ量を減らす工夫が必要です。

最適化手法

パフォーマンスを最大化するために、以下の手法を検討してください。

• 述語プッシュダウンの活用: WHERE 句や JOIN 条件で、外部テーブルのカラムを効果的に使用し、Auroraオプティマイザがフィルタリングや結合条件を外部ソースにプッシュダウンできるようにします。特にS3の場合は、パーティションカラムによるフィルタリングが最も重要です。
• S3データの適切なフォーマットとパーティショニング: 分析ワークロードにはParquetやORCを使用し、データを日付やカテゴリなどのキーでパーティション分割します。
• 必要なカラムのみをSELECT: SELECT * ではなく、必要なカラムだけを指定します。
• Auroraのインスタンスサイズ: DSQLクエリの処理はAuroraインスタンスで行われるため、十分なCPUとメモリを持つインスタンスサイズを選択することが重要です。
• EXPLAIN の活用: EXPLAIN コマンドを使用して、DSQLクエリの実行計画を確認します。外部テーブルへのアクセスがどのように行われているか、述語プッシュダウンが効いているかなどを分析できます。
• 統計情報の更新: Auroraが外部テーブルのデータ分布を把握できるよう、必要に応じて統計情報を更新します（S3の場合は自動または手動スキャン、データベースの場合は外部データベースの統計情報）。

セキュリティ

Aurora DSQLを使用する際は、以下のセキュリティ対策が重要です。

• IAMロールの最小権限: 外部データソースへのアクセスに必要な最小限の権限のみを持つIAMロールを作成し、Auroraクラスターにアタッチします。
• Secrets Managerの利用: RDS/Redshiftへの認証情報は、直接SQLに記述せず、必ずSecrets Managerに格納し、IAMロール経由でアクセスします。Secrets Managerへのアクセス権限も最小限にします。
• ネットワークアクセス制御: セキュリティグループやネットワークACLを使用して、Auroraクラスターと外部データソース間の通信を必要なポートとIPアドレス/セキュリティグループに限定します。VPCエンドポイントを利用してプライベートな通信経路を確保します。
• Auroraユーザー権限: DSQL機能を使用できるAuroraデータベースユーザーを適切に管理します。CREATE EXTERNAL SERVICE や CREATE EXTERNAL TABLE の実行権限は、信頼できるユーザーに限定します。外部テーブルへのSELECT権限も同様に管理します。

コスト

Aurora DSQLの使用には、以下のコストが関連します。

• Auroraインスタンスコスト: DSQLクエリの実行は、Auroraインスタンスのリソース（CPU, メモリ, ネットワークI/O）を使用するため、インスタンス稼働時間に応じたコストが発生します。
• S3コスト: S3からのデータ読み込みには、データ取得リクエスト（GETリクエストなど）と、読み込まれたデータ量に応じた料金が発生します（S3 SelectやAthenaのようなスキャンベースの課金とは仕組みが異なりますが、データ量に応じたコストは発生します）。
• RDS/Redshiftコスト: 外部RDS/Redshiftインスタンスへの接続およびクエリ実行により、これらのインスタンスの負荷が増加し、コストに影響を与える可能性があります。
• Secrets Managerコスト: Secrets Managerに認証情報を格納している場合、シークレットの数に応じた料金が発生します。
• ネットワークコスト: Auroraと外部データソース間のデータ転送（特に異なるアベイラビリティーゾーンやリージョン間の転送）には、データ転送料金が発生する場合があります。VPCエンドポイントを使用することで、インターネット経由のデータ転送料金を回避できますが、エンドポイント自体にも料金が発生します。

コストを最適化するためには、クエリパフォーマンスを向上させる（読み込むデータ量を減らす、プッシュダウンを効かせるなど）ことが、インスタンスの使用リソースやデータ転送量を減らす上で重要です。

制限事項

Aurora DSQLにはいくつかの制限事項があります。

• 読み取り専用: DSQLは基本的に外部データソースからの読み取り（SELECT）のみをサポートします。外部テーブルへの INSERT, UPDATE, DELETE, TRUNCATE など、データを変更する操作はできません。
• データ型マッピング: Auroraのデータ型と外部データソースのデータ型との間で、自動的にマッピングされない場合や、精度に関する問題が発生する可能性があります。必要に応じて型変換関数 (CAST など) を使用する必要があります。
• クエリの複雑さ: 非常に複雑なクエリ、特に外部テーブル間や内部テーブルと外部テーブルを多数JOINするクエリは、パフォーマンスが低下したり、サポートされなかったりする場合があります。
• データソース固有の制限: 接続する外部データソースやそのデータ形式（特にS3上のファイル形式）によって、サポートされる機能やパフォーマンスに制限があります。
• メタデータの管理: S3上のデータの場合、ファイルの追加や削除、スキーマ変更があっても、外部テーブルの定義やパーティション情報は自動的に更新されません（Glueカタログ連携や手動スキャンが必要です）。
• トランザクション: 外部テーブルへのアクセスは、Auroraのトランザクションには含まれません。外部ソースへのクエリが成功しても、その後のAurora内部の処理が失敗した場合にロールバックされることはありません。

これらの制限を理解した上で、DSQLが解決しようとしている特定のユースケースに適切かどうかを判断することが重要です。

監視とトラブルシューティング

DSQLクエリの実行状況を監視し、問題発生時にトラブルシューティングを行うためには、以下のツールやログが役立ちます。

• CloudWatch Metrics: AuroraインスタンスのCPU使用率、ネットワークI/O、データベース接続数などの標準メトリクスに加えて、DSQL関連のカスタムメトリクス（例: S3から読み込まれたバイト数など、バージョンやエンジンによって提供されるメトリクスが異なります）を確認します。
• Performance Insights: AuroraのPerformance Insightsを使用して、DSQLクエリがインスタンスのリソースをどのように使用しているか（待機イベントなど）を視覚的に確認できます。
• スロークエリログ: Auroraのスロークエリログ（実行時間が長いクエリを記録するログ）を有効にすることで、パフォーマンスが低下しているDSQLクエリを特定できます。ログには、外部ソースへのアクセスにどれくらいの時間がかかったかなどの情報が含まれる場合があります。
• Database Activity Streams (DAS): 詳細なデータベースアクティビティログが必要な場合に利用できます。
• 外部データソース側のログ/メトリクス: S3のアクセスログ、Redshift/RDSのクエリログやメトリクスを確認することで、外部ソース側での処理状況や問題点を特定できます。

Aurora DSQLのユースケース例

Aurora DSQLは、以下のような様々なユースケースで活用できます。

1. データレイク上のログ分析: S3に蓄積されたウェブサーバーログ、アプリケーションログ、IoTデバイスログなどを、Auroraに格納されたユーザーデータやマスターデータと結合して分析する。
2. トランザクションデータと履歴データの結合: Auroraに格納された現在のトランザクションデータと、S3にアーカイブされた過去のトランザクションデータを組み合わせて、トレンド分析や長期的なレポートを作成する。
3. オペレーションデータと分析データの統合: Auroraの運用データベースにあるリアルタイムデータと、Redshiftに集約された分析データを結合して、統合されたダッシュボードやレポートを作成する（Aurora PostgreSQLの場合）。
4. 部門間データ連携: 異なる部門が管理する別々のRDSインスタンスに格納されたデータを、ETLなしで一時的に連携してクエリする。
5. データ探索とプロトタイピング: S3上の新しいデータセットや、他のデータベースのデータを、ETLプロセスを構築する前にSQLで迅速に探索し、分析の可能性を評価する。
6. レガシーデータへの参照: アクセスの頻度は低いが、時折参照が必要なレガシーシステムやアーカイブされたデータの参照ポイントとして利用する。

これらのユースケースでは、全てのデータをAuroraに集約するほどの頻度や必要性がない場合や、データ鮮度が重要な場合にDSQLが有効な選択肢となります。

代替手段との比較

Aurora DSQLはデータ統合の一つの手段ですが、他のAWSサービスや手法でも同様の目的を達成できます。それぞれの特徴を理解し、適切なツールを選択することが重要です。

• ETLツール (AWS Glue, AWS Data Pipelineなど): データを抽出、変換、ロードして、一元化されたデータウェアハウス（Redshift）やデータマート（Aurora, RDS）に格納します。
  • 利点: データの品質管理、複雑な変換、パフォーマンス最適化（ターゲットデータベースに合わせた設計）、セキュリティ、管理の集中化が可能。
  • 欠点: データ移動に時間がかかる（鮮度が落ちる）、ETLパイプラインの構築・保守が必要、アドホックなクエリには不向き。
  • DSQLとの比較: DSQLはETLを回避し、リアルタイムに近いアクセスやアドホック分析に適しています。しかし、大規模なデータ変換や長期的なデータ統合にはETLの方が適している場合があります。
• Amazon Athena: S3上のデータレイクに直接SQLクエリを実行できるインタラクティブなクエリサービス。サーバーレスで利用でき、スキャンしたデータ量に基づいて課金されます。
  • 利点: サーバーレス、運用不要、S3上の大規模データに強い、幅広いファイルフォーマットをサポート、AWS Glueカタログと連携。
  • 欠点: S3以外のデータソースへの直接クエリは限定的（Connectors経由）、リレーショナルデータベースの機能（トランザクション、複雑なJOIN、インデックスなど）には劣る、データソースによってはパフォーマンスに限界がある。
  • DSQLとの比較: AthenaはS3データレイク分析に特化しており、サーバーレスである点が異なります。DSQLはAurora内のデータとS3や他のRDS/Redshiftのデータを組み合わせてクエリすることに強みがあります。使い慣れたAurora環境内で完結できる点もDSQLの利点です。
• Amazon Redshift Spectrum: RedshiftからS3上のデータレイクにクエリを実行できる機能。Redshiftクラスターのリソースと連携して動作します。
  • 利点: Redshiftの強力なクエリエンジンと連携してS3データを分析できる、S3データのパーティショニングやフォーマットによる最適化が可能、Glueカタログと連携。
  • 欠点: Redshiftクラスターが必要、Redshift Spectrum自体の利用料（スキャンデータ量に基づく）が発生する、S3以外のデータソースへのアクセスは基本的にRedshiftに取り込む必要がある。
  • DSQLとの比較: Redshift SpectrumはRedshiftユーザー向けにS3データレイク分析機能を提供します。DSQLはAuroraユーザー向けにS3や他のRDS/Redshiftデータへのアクセス機能を提供します。既存のAuroraインフラストラクチャを活用したい場合にDSQLが有力な選択肢になります。
• データベース固有の外部データラッパー (FDW – Foreign Data Wrapper): PostgreSQLやMySQLなどのデータベースエンジンが持つ標準的な外部データ連携機能。
  • 利点: オープンソースの標準機能、様々なデータソースに対応できるコネクタが存在する。
  • 欠点: 設定が複雑、パフォーマンス最適化や信頼性がAurora DSQLほどAWSサービスに統合されていない場合がある、特定のエンジンバージョンに依存する。
  • DSQLとの比較: Aurora DSQLは、Auroraに最適化され、AWSサービス（S3, Secrets Manager, IAMなど）との連携が強化されたAWSマネージドなFDWと言えます。運用や設定の容易さ、信頼性で優れます。

これらの代替手段と比較して、Aurora DSQLは「既存のAurora環境を起点として、データを移動させずに S3 データレイクや他の RDS/Redshift のデータを組み合わせて分析したい」というユースケースに最も適しています。

まとめ

Amazon Aurora DSQL（フェデレーテッドクエリ）機能は、Amazon Auroraを起点として、Amazon S3上のデータレイクや、別のRDS/Redshiftインスタンスに格納されたデータに直接SQLクエリを実行できる強力な機能です。

この機能を利用することで、データサイロを解消し、ETLプロセスを削減または回避し、データ鮮度を保ったまま、異なる場所に分散したデータを統合的に分析することが可能になります。特に、S3上の大量のログデータや履歴データと、Aurora内のオペレーションデータを組み合わせて分析するようなシナリオで大きな力を発揮します。

利用には、IAMロール、ネットワーク設定（セキュリティグループ、VPCエンドポイント）、認証情報管理（Secrets Manager）といった適切な事前準備が必要です。基本的な使い方は、CREATE EXTERNAL SERVICE で外部データソースへの接続を定義し、CREATE EXTERNAL TABLE で外部ソース内のデータとAurora内の論理テーブルをマッピングするだけです。定義後は、通常の SELECT 文で外部テーブルをクエリできます。

ただし、外部データソースからのデータ読み込みには、ネットワークI/Oや外部ソース側の処理能力、データ量などがパフォーマンスに影響を与える可能性があります。最適なパフォーマンスを得るためには、述語プッシュダウンの活用、S3データの適切なフォーマット（Parquet/ORC）とパーティショニングが重要です。また、DSQLは基本的に読み取り専用であり、データを変更する操作はできません。

Aurora DSQLは、全てのデータ統合課題に対する銀の弾丸ではありませんが、特定のユースケースにおいては、従来のETLアプローチに比べて大幅な効率化と柔軟性をもたらす非常に有効なツールです。本記事が、Aurora DSQLの基本を理解し、実際に活用するための第一歩となることを願っています。

参考資料

• Amazon Aurora User Guide – Querying Amazon S3 with Amazon Aurora MySQL: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.Authorizing.S3.html
• Amazon Aurora User Guide – Querying Amazon S3 with Amazon Aurora PostgreSQL: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Integrating.S3.html
• Amazon Aurora User Guide – Querying remote databases with Amazon Aurora PostgreSQL (Federated queries): https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Federated.html
• Amazon Aurora User Guide – Querying remote databases with Amazon Aurora MySQL (Federated queries): https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Federated.html

これらの公式ドキュメントは、最新の機能、サポートされるバージョン、詳細なパラメータ、制限事項などを確認する上で非常に重要です。

---