Amazon Web Services ブログ

Amazon Athena および AWS Storage Gateway を使用して、オンプレミスで作成されたデータを照会する



企業のお客様は、毎日データセンターで生成されるペタバイト規模のデータへのアクセスを維持、保護、提供する必要があります。従来、これには、未加工データをネットワークアタッチトストレージ (NAS)、ストレージエリアネットワーク (SAN)、またはダイレクトアタッチトストレージ (DAS) に保存し、それを変換してリレーショナルデータベースにロードして照会および分析活動をサポートする、一連の複雑な相互関連システムが含まれます。これは、一般に抽出、変換、ロードまたは ETL として知られています。

これらのシステムはそれぞれ、別々のチームによって別々に維持する必要があります。データベースは DBA によって、基盤となる物理インフラストラクチャはシステムエンジニアによって、などです。AWS では、常にお客様のために「Invent and Simplify」の方法を模索しています。この記事では、オンプレミスで生成された重要なデータを照会するプロセスを簡素化するための、お客様のデータセンターにデプロイできる AWS テクノロジ (AWS Storage Gateway) とサーバーレスのクラウドネイティブテクノロジ (Amazon Athena) の組み合わせた使用について説明します。

Tableau などの一般的なエンタープライズ分析ツールを使用してデータを分析するお客様は、ODBC または JDBC を使用してデータに接続し、データに対してクエリを実行しています。逆に、ファイルシステムはファイルの読み書きに SMB や NFS などのプロトコルを使用します。これまで、データを分析できるようにするためには、データを未加工の形式 (多くの場合はテキストファイル) からリレーショナルデータベースに変換する必要がありました。AWS Storage Gateway および Amazon Athena に入ります。

このブログ記事では、このアーキテクチャを使用して、Storage Gateway と Athena の機能の組み合わせを説明します。AWS Storage Gateway は、オンプレミスアプリケーションが AWS クラウドストレージをシームレスに使用できるようにするハイブリッドストレージサービスです。AWS Storage Gateway のファイルゲートウェイ構成は、アプリケーションデータファイルとバックアップイメージを永続オブジェクトとして Amazon S3 クラウドストレージに保存するためにクラウドに接続するシームレスな方法を提供します。ファイルゲートウェイは、ローカルキャッシュを使用して、Amazon S3 内のデータへの SMB または NFS ベースのアクセスを提供し、ファイルは S3 オブジェクトとして保存および請求されます。Amazon Athena は、標準 SQL を使用して Amazon S3 のデータを簡単に分析できるインタラクティブなクエリサービスです。Athena はサーバーレスであるため、インフラストラクチャの管理は不要であり、実行したクエリにのみ課金されます。

それでは、ACME Corp. の例を見てみましょう。ACME は架空の企業ですが、世界中の何百万もの IoT センサーから受信したデータを保存、保護、分析したいと考えています。

下の図は、提案されたソリューションの ACME のワークフローの各ステップ間でデータがどのように流れるかの概要を示しています。このソリューションが設定されると、ACME のアナリストの手に渡るデータの流れは完全に自動化され、手動の介入は不要です。

現在、ACME はテキスト (コンマ区切り) 形式で FTP を介して各センサーから毎日ファイルを受信しています。これらのファイルは共通の列セットを共有し、ファイルは FTP サーバーの背後にあるエンタープライズ NAS デバイスに保存されます。NAS デバイスは、日常的な災害対策のために 2 次施設にレプリケートされます。

毎日の終わりに、ETL プロセスが実行され、各テキストファイルが読み取られ、同様の列構造を持つリレーショナルデータベーステーブルにロードされます。ロードプロセスが完了すると、ACME アナリストは受信箱に E メールを受け取り、ロードに問題がなければ前日のアクティビティの分析を開始できます。ロードの問題が発生した場合は、運用スタッフが呼び出され、問題が解決するまでアナリストの作業の開始を遅らせることができます。

NAS に障害が発生した場合は、前日のデータを FTP サーバーに再生する必要があり、これはコストと時間がかかるプロセスです。データベースに障害が発生した場合の分析アクティビティに対する ACME の仮想的な回復時間目標は 4 時間です。 データの目標復旧時点は最大 1 日です。運用担当者は、FTP サーバー、NAS 環境、データベースサーバーを保守する必要があります。

担当者が現在の状態を維持したいと望んでいる ACME の FTP プロセスに変更を加えることなく、最初のステップは ACME の既存の NAS を置き換えるために VMware インフラストラクチャにファイルゲートウェイをデプロイすることです。それでは、Amazon EC2 環境でテスト目的でファイルゲートウェイを設定する方法を簡単に説明しましょう。

ステップ 1: AWS マネジメントコンソールで、[Storage Gateway]、[Create Gateway:] の順に選択します。

ステップ 2: 「File Gateway」ゲートウェイタイプを選択して、[Next:] をクリックします。

ステップ 3: [Select host platform] で、[Amazon EC2] を選択し、画面の指示に従ってゲートウェイインスタンスを起動します。

ゲートウェイを設定してテストした後、既存の NAS の代わりに FTP サーバーにマウントされます。ここで、ACME が IoT センサーからのデータを確認できる ACME の S3 バケットが、Amazon S3 に表示されます。

設定された S3 バケットの内容と、オブジェクトキーが Windows マシンにファイルとして提示されているため、Windows エクスプローラでアクセス可能であることがわかります。

これが、ACME のアカウントでのファイルゲートウェイの設定です。作成したゲートウェイ「AthenaGateway」が起動されて実行中であり、最新であり、ファイル共有ストレージリソースにマッピングされていることがわかります。

ファイルゲートウェイの設定の詳細については、ファイルゲートウェイの作成を参照してください。

次の手順は、Amazon Athena の設定です。AWS コンソールを使用し、データ内の列を表すテーブル定義で、ファイルゲートウェイが書き込んでいる ACME の S3 バケットを指す新しい Athena データベースとテーブルを作成します。

ACME のポリシーは、保存時にデータを暗号化するよう求めており、ファイルゲートウェイは S3 バケットへのデータ書き込みで KMS による暗号化をサポートしています。Athena は、Amazon S3 の暗号化されたデータセットと暗号化されたクエリ結果の両方に対して、幅広い種類の Amazon S3 暗号化オプションをサポートしています。

これらのオプションは、Amazon S3 の保存データを暗号化します。これらのオプションを使用するかどうかにかかわらず、transport layer security (TLS) は、Athena リソース間およびAthena と Amazon S3 の間での転送中のオブジェクトを暗号化します。クエリ結果はプレーンテキストとして JDBC クライアントにストリーミングされ、TLS を使用して暗号化されます。その後、Athena コンソールでテストクエリを実行して、データが正しく返されていることを確認します。新しいデータがファイルゲートウェイによって受信されると、自動的に S3 に追加され、自動的に Athena のクエリスコープに含まれます。ここで、AWS Glue を使用して Athena データベースを作成します。これは、ファイルゲートウェイを介して S3 内の ACME の IoT デバイスデータを Athena 経由で照会できるようにするためです。

Glue はフルマネージド型の ETL (抽出、変換、ロード) サービスです。このサービスを使用すれば、データに対する分類、クリーニング、エンリッチ、信頼性の高い方法でのデータストア間でのデータ移行が行えます。AWS Glue は、AWS Glue データカタログと呼ばれる中央メタデータリポジトリ、Python または Scala コードを自動的に生成する ETL エンジン、および依存関係の解決、ジョブの監視、再試行を処理する柔軟なスケジューラで構成されています。AWS Glue はサーバーレスであるため、設定や管理が必要なインフラストラクチャはありません。

最初に、AWS マネジメントコンソールで Glue ホームページを開き、[Add tables using a crawler] を選択し、要求された場合は S3 バケットとプレフィックスを参照しながら、説明されている手順に従います。Glue クローラーの設定に関するドキュメントは、ここにあります。

クローラーを設定したら、実行します。S3 のデータをクロールし、完了するとフラグを立てます。

次に、AWS マネジメントコンソールで Athena ホームページを開きます。

Athena ホームページに、Glue によって作成されたデータベースとテーブルが表示されます。これは Athena で、S3 のセンサーデータをポイントし、それに対してテストクエリを実行するように設定されています。ここで使用するテストクエリは、以下のとおりです。

SELECT col1, count(col1)
FROM acmesensordata
WHERE (col3 > 50
	AND col3 < 60)
GROUP BY col1
LIMIT 100

このサンプルクエリは、ACME のすべてのデータをスキャンして、50 から 60 の範囲の値を送信したセンサーを使用して上位 100 の都市をカウントし、送信されたデータポイントの数を報告します。

最後の手順は、ACME の Tableau 環境を Athena の ODBC エンドポイントを指すようにリダイレクトすることです。Tableau の ODBC 設定は ACME によって一元管理されており、必要な詳細は既存のオンプレミスリレーショナルデータベースの代わりに Athena を指すように変更されます。

Tableau を起動すると、[Connect] の下に、Tableau Desktop でサポートされているファイルとデータベースの種類が表示されます。[More] を選択すると、完全なリストが表示されます。Tableau は、ODBC (Open Database Connectivity) をデータベースに接続する標準的な方法と見なしています。Amazon Athena 用の ODBC ドライバーおよび Tableau Other Databases (ODBC) コネクタを使用して、Tableau をデータに接続することができます。ODBC への接続に関する Tableau の完全なドキュメントは、こちらから入手できます。

それでは何を変えたのか、そしてテクノロジーやエンドユーザーへの影響をまとめましょう。

  • ACME のオンプレミス NAS を S3 バケットでサポートされた AWS Storage Gateway に置き換え、それらの FTP サーバーを既存のファイルゲートウェイの代わりにファイルゲートウェイのファイル共有を使用するように設定しました。
  • お客様の S3 バケットへのアクセスを NAS として提供するために、Storage Gateway をファイルゲートウェイとして設定しました。お客様のデータは現在 S3 にあります。
  • 前のリレーショナルデータベースを模倣するようにサーバーレスの Amazon Athena データベースを設定し、このデータベースに ODBC エンドポイントを公開しました。
  • この ODBC エンドポイントを指すように ACME の Tableau 環境を再設定しました。このシナリオのリレーショナルデータベースはアドホック SQL クエリを処理するためだけに使用されていたので、もう必要ではありません。

他に依存関係がない場合、ACME はこのシナリオのサポート専用のオンプレミス ETL、リレーショナルデータベース、NAS インフラストラクチャを廃止することができます。FTP サーバーと Storage Gateway 仮想マシンホスト以外に、このシナリオをサポートするサーバーを管理する必要はありません。

このデータを扱うエンドユーザーのアナリストは、分析を開始するために 1 日の始まりまで待つ必要がなくなりました。新しいセンサーデータは、センサーからの FTP 配信の直後に Athena S3 フォルダに到着し、すぐに照会で使用できます。ETL とリレーショナルデータベースインフラストラクチャを除外すると、アーキテクチャ内の潜在的な障害点が減少します。そして、災害が発生した場合、2 番目の AWS リージョン (S3 クロスリージョンレプリケーションに対応) の Athena エンドポイントが、レプリケーションが完了するとすぐにデータを Tableau で利用できるようにします。S3 には新しいデータが到着したときにイベントをトリガーする機能があるため、特定のセンサーグループからのデータが利用可能になったときにアナリストに通知して、できるだけ早く作業を開始することができます。

データはローカルゲートウェイにキャッシュされたままであるため、他のオンプレミスの高性能コンピューティング、ビッグデータ、またはその他のアプリケーションによる極めて迅速なアクセスが可能になります。ハイアベイラビリティを実現するために、ACME は、主な障害が発生した場合に既存の VMware インフラストラクチャで 2 番目の storage gateway インスタンスを迅速に起動することができます。さらなる改良は、AWS Storage Gateway の NotifyWhenUploaded 機能を使用して、データのグループがアップロードされてバッチ処理が有効になったときに CloudWatch イベントを提供することです。

以上です!

まとめ

このようなハイブリッドクラウドシナリオの複雑なアーキテクチャを扱う多くの企業顧客にとって、AWS Storage Gateway と Amazon Athena の組み合わせは、オンプレミスのクラウドネイティブシナリオとハイブリッドシナリオをアプリケーションポートフォリオ全体で実現しながら、簡素化と低コスト化に役立ちます。

ご意見やご不明な点がございましたら、お気軽にコメントをお寄せください。

 


著者について

James Forrester は、AWS グローバルアカウントのテクノロジー責任者です。彼は世界中の顧客と協力して、変革的価値、適用性、および幅広い種類の AWS のサービスの使用法についてソートリーダーシップを発揮しています。