Amazon Web Services ブログ
Amazon S3 への Amazon RDS Snapshot Export によるデータレイクの構築とデータ保持ポリシーの実装
Amazon Relational Database Service (RDS) は、クラウドでリレーショナルデータベースを簡単に作成、運用、およびスケールするために役立ちます。2020 年 1 月、AWS は Amazon RDS for MySQL、Amazon RDS for PostgreSQL、Amazon RDS for MariaDB、Amazon Aurora PostgreSQL、および Amazon Aurora MySQL からのスナップショットを Apache Parquet 形式で Amazon S3 にエクスポートする機能を発表しました。これで、主要なトランザクションアプリケーションに影響を及ぼすことなく、ダウンストリームのレポート作成および分析アプリケーションが本番データベースからのデータを利用できるようになります。
データベース管理者とデータ所有者は、ビジネスインテリジェンスレポートの作成者、機械学習開発者、またはエンタープライズダッシュボード作成者から、データベーステーブルへのアクセス提供のリクエストを絶えず受け取っています。ここでの課題は、データ上で動作するビジネスクリティカルなアプリケーションに影響を及ぼさない方法でデータにアクセスできるようにすることです。リードレプリカを作成することもソリューションのひとつですが、ダウンストリームアプリケーションリクエストに対応するためにプロビジョニングされたコンピューティング性能を維持しなければなりません。
さらに厄介なことに、レポート作成システムには以前のタイムスタンプ時点でのデータのコピーを必要とするものもあります。これまでは、スナップショットから復元することで新しい RDS インスタンスを作成し、レポート作成システムがこの新しいインスタンスにアクセスできるようにすることが、これを実行する唯一の方法でしたが、
Amazon S3 への Amazon RDS Snapshot Export のローンチにより、リクエストされたテーブルを適切なスナップショットから S3 バケットにエクスポートするプロセスを作成し、ダウンストリームアプリケーションに Parquet ファイルへのアクセスを提供するだけで実行できるようになりました。
この記事では、Amazon RDS のスナップショットから Amazon S3 にエクスポートファイル (これを特定のテーブルにフィルタリングします) を作成する方法と、Amazon Athena にあるデータセットをクエリする方法を説明します。
ソリューションの概要
以下の図は、プライマリ RDS インスタンスで読み込み/書き込み操作を実行するビジネスクリティカルなアプリケーションに影響を及ぼすことなく、ダウンストリームアプリケーションへのデータの配信ストリームをセットアップする方法を示すものです。
このアーキテクチャでは、Amazon RDS コンソールを使ってセットアップされた読み込み専用ターゲット (リードレプリカ) にデータがレプリケートされます。ここでは、データベース全体の複製コピーが維持され、分析およびデータレイク構築用のクローラにデータを提供するため、プロビジョニングされたデータベースコンピューティングリソースを継続的に実行します。この方法で必要以上のリソースを維持するメリットは、本番データベースが、クリティカルなアプリケーション自体の負荷以外から分離されていることです。
Amazon Aurora では、リーダーがプライマリインスタンスと同じクラスター化されたストレージリソースを使用しますが、リードレプリカが分析アプリケーションにデータを提供できるようにするには、追加のコンピューティング性能がプロビジョニングされます。
この方法でリードレプリカを使用するときには、いくつかの要素を考慮しなければなりません。
- データベース全体がリードレプリカに複製される。ダウンストリームアプリケーションのアクセスが、アクセスする必要があるデータの部分のみに許可されていることに特段の注意を払う必要があります。
- ライブデータは継続的に複製されるため、アプリケーションのアクセスがライブデータ限定になっている。リードレプリカは、特定時点のスナップショットからのデータを必要とするリーダーにデータを提供できません。
- 分析クエリは、リードレプリカでは利用できないことがあるインデックス構造を必要とする場合があり、これはクエリの低パフォーマンスとリソースの高使用率につながります。
以下の図は、すでに存在するスナップショットを使用することによって、データベースを全体的にまたは部分的にエクスポートするプロセスを作成するもうひとつのアーキテクチャです。この方法は本番データベースに影響を及ぼさず、リードレプリカのための追加リソースも作成しません。
上記のユースケースでは、BI 分析アプリケーションがリードレプリカを維持する代わりに Athena を利用して、Snapshot Export 機能で作成された S3 バケット内の Apache Parquet データセットをクエリします。Parquet 形式は、テキスト形式よりもエクスポート速度が最大で 2 倍速く、Amazon S3 のストレージも最大 6 分の 1 になります。データレイクにデータをフィードする AWS Glue クローラはファイルに直接アクセスし、クエリダウンロードを実行する必要がなく、データレイクにデータをフィードするために必要となる場合がある後続のフォーマットも不要です。
Snapshot Export のパフォーマンスを最適化するため、特に大規模なテーブルの場合、自動インクリメントプライマリキーでテーブルを作成する必要があります。これは一般に、プライマリキーとクラスター化されたインデックスに複合キーを使用しないようにするための設計上のグッドプラクティスですが、自動インクリメントプライマリキーではエクスポートプロセスがはるかに高速であることから、このシナリオでは特に重要です。
Snapshot Export の作成
以下のユースケースでは、Amazon RDS データベースの既存のスナップショット使用し、エクスポート機能を使ってそのデータを S3 バケットに抽出します。これを実行するには、エクスポートを特定のテーブルにフィルタリングします。その後、AWS Glue クローラを作成して実行します。このクローラは、エクスポートからスキーマを抽出してテーブルを作成します。Athena でテーブルを手動で定義することと比較したこのアプローチのメリットは、クローラがスキーマ定義を推論できることで、これによって列とそのデータ型を特定する手間が省けます。最後に、Athena を使ってエクスポートされた Parquet ファイルをクエリします。
Snapshot Export を作成するには、以下の手順を実行してください。
- Amazon RDS コンソールで [データベース] を選択します。
エクスポートは自動バックアップ、手動で作成した DB スナップショット、または AWS Backup で作成したスナップショットから実行できます。 - エクスポートするスナップショットを選択します。
- [アクション] ドロップダウンメニューから、[Amazon S3 へのエクスポート] を選択します。
- エクスポート識別子には、エクスポートの識別子を入力します。
- 識別子では、エクスポートするデータのフィルタリング条件を指定します (例: スキーマのテーブル)。
データは常に Apache Parquet 形式でエクスポートします。この記事では、メジャーリーグベースボールの選手に関する情報が含まれたテーブルをエクスポートします。
- S3 バケットには、データをエクスポートする S3 バケットを選択します。
- オプションのステップとして、S3 プレフィックスにプレフィックス付きのサブフォルダを指定します。
- IAM ロールには、エクスポートを作成して、先ほど指定した S3 バケットに書き込むためのアクセス権がある IAM ロールを選択します。
オプションで、必要なアクセス権を持つロールを作成できます。エクスポートされたデータを保護するため、データは指定された AWS KMS キーで暗号化されます。 - 暗号化には、キー ARN を入力します。
- [S3 へのエクスポート] を選択します。
ロールを事前に作成してアクセス権を付与する場合は、以下の手順を実行します。
- 以下の CLI コマンドでロールを作成します。
- Create a policy with the following code:
- 先ほど作成したロールにポリシーをアタッチします。作成したポリシーの
policy-arn
を使用します。以下のコードを参照してください。 - エクスポートの暗号化に使用している KMS キーのキーユーザーとしてロールを追加します。
エクスポートダッシュボードに、ステータスがStarting
になっている新しいエクスポートが表示されます。
- ステータスが
Available
に変わるまで待ちます。
エクスポートプロセスが完了したら、エクスポートされたデータをクロールする AWS Glue クローラを作成し、エクスポートからスキーマを抽出して、テーブルを作成します。 - AWS Glue コンソールで、[クローラ] を選択します。
- [クローラの追加]] を選択します。
- クローラには、少なくとも以下のパラメータが必要です。
- 名前
- ソースタイプ – このユースケースでは AWS Glue がデータをスキャンしてテーブルを作成する必要があるため、[データストア] を選択します。
- データストア – Amazon S3 を選択して、Amazon RDS Snapshot Export 用に選択したバケット名を入力します。
- IAM ロール – このロールを使ってクローラプロセスを実行します (このロールは Snapshot Export を実行するために使用したものとは別のロールです)。これには、クローラを実行するためのアクセス権、エクスポートが格納される S3 バケット、およびエクスポートを暗号化するために使用される KMS キーが必要です。オプションで、クローラが使用する新しいロールを作成できます。ロールにアタッチするポリシーの調整に関する情報は、「AWS Glue アクセスコントロールポリシーの例」を参照してください。
- クローラのスケジュール – オンデマンド、または特定の頻度で実行されるようにクローラを設定します。
- 出力 – テーブルをホストするデータベースを定義し (または新しいデータベースを作成)、テーブル名に使用するプレフィックスを定義します。
- クローラを実行して、テーブルが作成されるのを待ちます。
クローラが完了したら、ステータスが Ready に更新され、作成または更新したテーブルの数を記載したメッセージが表示されます。クローラのダッシュボードで [ログ] を選択して、クローラが書き込んだ Amazon CloudWatch Logs を表示して、プロセスのすべてのステップが完了しているのを確認することもできます。
テーブルのクエリ
テーブルをクエリするには、Athena コンソールで先ほど作成したデータベースを選択します。
以下のスクリーンショットは、MLB 選手データからのクエリ出力です。
Athena を使って Amazon RDS にあるテーブルに分析クエリを実行することも可能です。これは Amazon S3 への Amazon RDS Snapshot Export 機能を使用して行います。
たとえば、異なるチームの全体における左利き選手、または左投げ投手の分布に関するクエリを実行するには、以下のクエリを入力します。
以下のスクリーンショットは、このクエリの出力です。
料金
Amazon S3 への Amazon RDS Snapshot Export 機能では、スナップショットサイズ 1 GB ごとの料金が発生します。詳細については、Amazon RDS for MySQL の料金 で [Snapshot Export] を選択してください。料金は、部分的なエクスポート (スキーマまたはテーブル) のみを実行する場合でも、フルサイズのスナップショットに基づきます。プロセスのその他の要素 (AWS Glue および Athena) はサーバーレスモードで実行されるので、使用する実際のコンピューティング性能のみの料金を支払います。エクスポートのストレージにかかる料金は従量制です。詳細については、Amazon S3 の料金を参照してください。このコストは、アクセス頻度の低いデータを Amazon S3 Glacier に移動させることで最適化できます。
まとめ
スナップショットからデータを直接エクスポートする機能は、データ所有者、管理者、およびアナリストが本番データベースのパフォーマンスと可用性に影響を及ぼすことなくデータへのアクセスを提供するための優れたツールです。データは、継続的なコンピューティングとストレージ配分を必要とするリードレプリカを維持せずに、セキュアで信頼性に優れた効率の良い方法で利用できるようにすることが可能です。それ以上に重要な点は、すでに作成済みのスナップショットを使用して、部分的なデータ、および前回のデータにアクセスできることから、元のデータベースを復旧できる点です。
Snapshot Export の作成、クエリ、およびスケジュールの詳細については、YouTube でAmazon RDS Snapshot Export to S3 をご覧ください。
著者について
Prasanth Kollarath は、アマゾン ウェブ サービスのシニアテクニカルアカウントマネージャーです。