Amazon Web Services ブログ

Category: Database

AWS Glue ジョブブックマークを使用して、さまざまなデータ取り込み頻度でデータを処理する

データの取り込み頻度がさまざまな複数のデータセットをマージする必要があるデータ処理の要件はよく見られます。これらのデータセットの一部は、一度にすべてが取り込まれ、受信頻度が低く、全体を通して常に使用されます。一方、その他のデータセットは増分で取り込まれ、一定の間隔で受信し、完全なデータセットと結合して出力を生成します。このような要件に対応するため、この投稿では、AWS Glue を使用して抽出、変換、ロード (ETL)パイプラインを構築する方法をご紹介します。 AWS Glue の使用 AWS Glue は、分析のために複数のソースから多数のデータセットを抽出、変換、およびロードするサーバーレス環境を提供します。AWS Glue には、スケジューリングされた間隔でジョブを再実行するときに増分データを処理するジョブブックマークと呼ばれる機能があります。ジョブブックマークは、ソース、変換、ターゲットなど、さまざまなジョブ要素の状態で構成されます。AWS Glue が古いデータを再度処理しないようにするジョブ実行からの状態情報を保持することで、これを実行します。 このユースケースでは、ジョブブックマークが有効になっている AWS Glue ジョブを使用して、さまざまな頻度で受信するファイル(一度に受信するファイルを示す完全なデータセットと、特定の定期的な間隔で受信するファイルを示す増分データセット)を処理します。これらのファイルは、まとめてマージされます。ジョブブックマークを有効にするだけでなく、AWS Glue PySpark 動的フレームでオプションのパラメータ transformation_ctx(変換コンテキスト)も使用します。これは、ETL 演算子インスタンスの一意の識別子として機能するもので、特定の演算子のジョブブックマーク内の状態情報を識別します。AWS Glue は transformation_ctx を使用して、キーをブックマークの状態にインデックス付けします。 変換コンテキストを使用することで、増分データセットの状態情報を取得および維持し、再処理を回避できます。完全なデータセットファイルでは変換コンテキストが省略されるため、完全なデータセットに対するジョブ実行状態情報が取得されず、次の処理イベント全体で使用されます。AWS Glue ジョブレベルでジョブブックマークフラグが有効になっている場合でも、完全なデータセットの変換コンテキストが省略されるため、ジョブを実行するたびに、完全なデータセットのデータ全体がジョブの一部として使用されます。一方で、新しく到着したデータセットのみが増分データセットとして処理されます。 ソリューションの概要 AWS Glue のジョブブックマークのユーティリティをデモするのに、TLC 移動レコードデータのデータセットを使用します。増分データセットとしてニューヨーク市イエローキャブの移動データの月間ファイルを使用し、フルデータセットとしてニューヨーク市のタクシーゾーンルックアップを使用します。月間イエローキャブ移動データには、PULocationID (乗客を拾った場所)という名前のフィールドがあり、ニューヨーク市タクシーゾーンルックアップファイルの LocationID フィールドと結合して、ニューヨーク市のタクシーゾーンルックアップデータセットの Borough、Zone、service_zone と、月間のニューヨーク市タクシー移動データファイルのすべてのフィールド(PULocationID フィールドを除く)を含む出力データセットを作成します。 次の図は、処理のハイレベルアーキテクチャを示しています。 図の説明 2 つの Amazon S3 Raw バケットの場所は、受信 CSV ソースデータ(ニューヨーク市タクシーの月間ファイル(増分データセット)とニューヨーク市タクシールックアップファイル(完全データセット))を格納するのに使用します。 ブックマークを有効にした Glue ジョブは、月間移動データファイルとタクシーゾーンルックアップファイル間のデータを結合して、出力 Parquet […]

Read More

Moovit は、Amazon Redshift クラスターを拡張して毎日何十億ものデータポイントを分析することにより、データレイクアーキテクチャを活用

Amazon Redshift は高速なフルマネージド型クラウドネイティブデータウェアハウスで、標準 SQL や既存のビジネスインテリジェンスツールを使用して、すべてのデータをシンプルかつコスト効率よく分析できます。 Moovit は、Mobility as a Service (MaaS) ソリューションプロバイダーで、都市型モバイルアプリのトップメーカーです。Moovit は、103 か国の 3,200 を超える都市の 8 億人を超えるユーザーに効果的かつ便利に街を歩き回るようにガイドを提供してきて、過去数年間でサービスが飛躍的に成長しました。同社は、1 日あたり最大 60 億の匿名データポイントを収集し、トランジットデータと都市モビリティデータの世界最大のリポジトリに追加します。これは、他では活用されない都市のローカル交通情報をマッピングおよび維持するのを支援する 685,000 人を超える Moovit のローカル編集者のネットワークで支えられています。 Moovit と同様に、今日多くの企業が Amazon Redshift を使用してデータを分析し、データをさまざまな形に変換しています。ただし、データが成長し、さらに重要になるにつれて、企業はデータから貴重な洞察を引き出すためのより多くの方法を模索するようになりました。これには、ビッグデータ分析、多数の機械学習 (ML) アプリケーション、新しいユースケースとビジネスプロセスを促進するさまざまなツールなどがあります。企業はいつでもすべてのデータにどのユーザーもアクセスでき、迅速な回答を得られるようにすることを求めています。これらすべての要件を満たす最適なソリューションは、企業がデータレイクを構築することです。データレイクは、規模を問わず、すべての構造化データ、半構造化データ、および非構造化データを格納できる中央リポジトリです。 Amazon Simple Storage Service (Amazon S3) で構築されたデータレイクを用いると、Amazon EMR や AWS Glue などのサービスを使用してビッグデータ分析を簡単に実行できます。Amazon Athena や Amazon Redshift Spectrum を使用して、構造化データ (CSV、Avro、Parquet など) および半構造化データ (JSON や […]

Read More

Apache Kafka 向け Amazon Managed Streaming を使用して、データキャプチャを Neo4j から Amazon Neptune に変更

Neo4j から Amazon Neptune へのポイントインタイムデータ移行を実行した後、進行中の更新をリアルタイムでキャプチャして複製することができます。Neo4j から Neptune へのポイントインタイムグラフデータ移行の自動化については、完全に自動化されたユーティリティを使用した Neo4j グラフデータベースの Amazon Neptune への移行をご参照ください。この記事では、cdc-neo4j-msk-neptune リポジトリのサンプルソリューションを使用して、Neo4j から Neptune へのキャプチャとレプリケーションを自動化する手順について説明します。 変更データキャプチャ (CDC) パターンを使用したデータベースの継続的なレプリケーションにより、データをストリーミングして他のシステムで利用できるようにすることができます。この記事では、最新の変更を Neptune にコピーできるように、CDC を使用して Neo4j からデータをストリーミングすることにより、グラフデータベースを最新化することに専念しています。Strangler パターンのイベント傍受戦略を使用して Neo4j を最新化することにより、すべての変更を Neptune に段階的にプッシュし、アプリケーションを変更して Neptune を使用できます。Neptune は、高速で信頼性が高い、完全マネージド型グラフデータベースサービスであり、高度に接続されたデータセットと連携するアプリケーションの構築と実行を容易にします。Neptune の中核にあるのは、何十億もの関係を保存し、ミリ秒単位のレイテンシーでグラフをクエリするために最適化された、専用の高性能グラフデータベースエンジンです。 アーキテクチャの概要 この記事のソリューションは、AWS アカウントでの次のアーキテクチャのデプロイを自動化します。このアーキテクチャは、レプリケーション用の疎結合システムを構築するためにソリューションがプロビジョニングする AWS リソースを示しています。 アーキテクチャには次の要素が含まれます。 Amazon VPC 内のすべての必須 AWS リソースをブートストラップする、エンドユーザーがトリガーする AWS クラウド開発キット (AWS CDK) アプリ レプリケーション用の Docker コンテナで実行される専用サービスを実行するための Amazon Elastic […]

Read More

Amazon Aurora Global Database の書き込み転送を使用してグローバルに分散された MySQL アプリケーションを構築する

AWS は 2018 年に Amazon Aurora Global Database をリリースしました。Aurora Global Database は主に 2 つのユースケースで使えます。最初のユースケースは、災害復旧ソリューションをサポートすることです。これにより、低目標復旧時点 (RPO) と低目標復旧時間 (RTO) でリージョン全体の障害に対処しながら、保護対象のデータベースクラスターへのパフォーマンスへの影響を最小限に抑えることができます。Aurora Global Database を使用すると、通常、RPO は 5 秒未満、RTO は 1 分未満に抑えることができます。書き込みワークロードが大きい場合でも、ソースクラスターとターゲットクラスターの両方に対するパフォーマンスへの影響は無視できるほどに小さいものです。 Aurora Global Database の 2 番目の主なユースケースは、最大 5 つのリモートリージョンに Amazon Aurora クラスターの読み取り専用コピーを供給して、そのリージョンに近いユーザーにサービスを提供することです。これにより、リモートリージョンのユーザーは、さらに離れたプライマリリージョンに接続する必要がある場合よりも低いレイテンシーで読み取りが行えます。 次のグラフは、2 つのリージョン間で MySQL 論理レプリケーションを使用した例を示しています。クエリの数が段階的に増加すると、ターゲットクラスターで観察されるレプリケーションタイムラグは指数関数的に増加します。さらに、テスト済みの設定で処理できる 1 秒あたりのクエリ数は、ピーク時に約 35,000 でした。 対照的に、次のグラフは、Aurora Global Database を使用したのと同じワークロードとインスタンスのサイジングを示しています。レプリケーションは 1 秒未満のタイムラグを維持し、1 秒あたりのクエリ数はピーク時に約 200,000 (+ […]

Read More

Amazon Redshift 横串検索のベストプラクティス

Amazon Redshift 横串検索では、Amazon Redshift の分析機能を使用して、Amazon Aurora PostgreSQL および Amazon RDS for PostgreSQL データベースに保存されているデータを直接クエリできます。横串検索を試すことができる環境のセットアップの詳細については、「AWS CloudFormation で Amazon Redshift 横串検索の採用を加速する」を参照してください。 横串検索では、リアルタイムのデータ統合と簡素化された ETL 処理を行えます。Amazon Redshift でライブデータソースを直接接続して、リアルタイムのレポート作成と分析を行えるようになりました。以前は、PostgreSQL データベースから Amazon Simple Storage Service (Amazon S3) にデータを抽出し、COPY を使用して Amazon Redshift にロードするか、Amazon Redshift Spectrum を使用して Amazon S3 からクエリを実行する必要がありました。横串検索の利点の詳細については、「Amazon Redshift 横串検索を使用して、簡略化された ETL およびライブデータクエリソリューションを構築する」を参照してください。 この記事では、統合データセットが大きい場合、横串検索が大量のデータを取得する場合、または多くの Redshift ユーザーが統合データセットにアクセスしている場合に、横串検索のメリットを最大化するための 10 のベストプラクティスをご紹介します。これらの手法は、横串検索を一般的に使用する際には必要ありません。これらは、この興奮を覚えるような機能を最大限活用したい上級ユーザーを対象としています。 ベストプラクティスは 2 つのセクションに分かれています。1 つ目は Amazon […]

Read More

Waves における大規模なユーザークエリとレコメンデーションへの Amazon Neptune の利用

本記事は、ClearScale のソリューションアーキテクチャディレクタであり、APN のプレミアコンサルティングパートナーとしてもクラウドの全体的なプロフェッショナルサービスを提供している、Pavel Vasilyev 氏の寄稿です Waves は Y Combinator から支援を受けているデートアプリです。同社の既存の IT アーキテクチャが、Google Cloud では維持しきれなくなると経営陣が認識したとき、それは AWS への移行を開始するタイミングとなりました。Waves は、Google Cloud から AWS への移行、およびグラフデータベースエンジン専用に設計された Amazon Neptune などのサービスを使った機能を実装するにあたり、 ClearScale とパートナーを結ぶことを決めました。Neptune を使用する開発者は、相互接続したデーセットを扱うアプリケーションの構築と実行が可能になります。これは、Waves が必要としていた機能そのものです それまで Waves アプリケーションは、急速に増加するユーザー数に起因する、いくつもの課題と対峙していました。これらの課題には、特定のデータベースクエリが原因となった信頼性やレイテンシーの問題が含まれます。これらのクエリは、アプリに組み込まれたレコメンデーションエンジンが実行しているものです。加えて、Waves でのインフラストラクチャ向け予算は想定外の速さで増加し続けており、その終着点も見えない状態だったのです。 この記事では、Waves のワークロードを AWS に移行するために、ClearScale が取った手法をご紹介します。またそこで、膨大なクエリボリュームを処理できる先進的なレコメンデーションエンジンを構築するために、Neptune を導入した方法についてもご説明していきます。加えて、AWS が提供する他の機能を使用しながら、ClearScale が Waves の全体的なアーキテクチャを強化した方法も解説します。 移行プロジェクト まず、Waves と ClearScale の両者は、この共同作業が、次のような 5 つのステージに分かれることを明確化しました。 Cloud Storage から Amazon Simple Storage […]

Read More

Amazon Aurora MySQL から Amazon S3 にデータをエクスポートおよびインポートするためのベストプラクティス

複雑なアプリケーションを小さな部分に分割することにより、多数の専用データベースを使用して高度に分散したアプリケーションを構築できます。これにより、ジョブに適したデータベースを選択できます。Amazon Aurora は、OLTP ワークロードの推奨される選択肢です。Aurora により、クラウド内でリレーショナルデータベースをセットアップ、操作、スケーリングするのが容易になります。 この記事では、Aurora MySQL から Amazon Simple Storage Service (Amazon S3) にデータをエクスポートおよびインポートする方法を示し、関連するベストプラクティスについて説明します。Amazon Aurora PostgreSQL では、データを Amazon S3 機能にエクスポートおよびインポートすることもできます。このブログでは、Amazon Aurora MySQL に焦点を当てます。 Aurora と Amazon S3 の概要 Aurora は、クラウド向けに構築された MySQL と PostgreSQL の互換性があるリレーショナルデータベースで、従来のエンタープライズデータベースのパフォーマンスと可用性、およびオープンソースデータベースのシンプルさと費用対効果を兼ね備えています。 Amazon S3 は、業界をリードするスケーラビリティ、データの可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスです。つまり、どの規模と業界の顧客もこれを使用して、任意の量のデータを保存および保護できます。 前提条件 始める前に、以下を完了してください。 Aurora MySQL DB クラスターを起動します。既存のクラスターを使用することもできます。 MySQL クライアントをインストールした Amazon EC2 インスタンスを起動します。ここでは、MySQL Workbench を使用することもできます。 次の必須の Identity and Access […]

Read More

Amazon DocumentDB (MongoDB 互換) の開始方法 – パート 3; – Robo 3T の使用

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする、高速かつスケーラブルで可用性に優れたフルマネージド型のドキュメントデータベースサービスです。お客様は、基盤となるインフラストラクチャの管理を気にすることなく、現在ご使用のものと同じ MongoDB 3.6 向けのアプリケーションコード、ドライバー、ツールを、そのまま Amazon DocumentDB 上でワークロードを実行、管理、そしてスケールするのに使えます。ドキュメントデータベースである Amazon DocumentDB は、JSON データの保存、クエリ、およびインデックスを容易にします。 このシリーズのパート 3 であるこの投稿では、Amazon DocumentDB と Robo 3T (旧 Robomongo) の開始方法を説明します。Robo 3T は、軽量でシェル中心のオープンソースプラットフォーム間のグラフィカルユーザーインターフェイスツールであり、MongoDB ワークロードを管理します。Robo 3T は、データベースとコレクションの作成、ユーザーやドキュメントの追加、オートコンプリート機能を搭載した 1 回限りのクエリの実行、GUI インターフェイスからの結果の視覚化を実現するため、より効率的です。 この投稿では、VPC 内に単一インスタンスの Amazon DocumentDB クラスター、同じ VPC 内の EC2 Linux VM を作成し、2 つの間に SSH トンネルを設定します。また、Robo 3T を使用してクラスターに接続し、ローカルコンピュータからいくつかのクエリを実行します。次の図は、このチュートリアルの最終的なアーキテクチャを示しています。 Amazon DocumentDB クラスターの作成 AWS コマンドラインインターフェイス […]

Read More

Amazon DocumentDB のスケーリング (MongoDB 互換性あり)、パート 1: 読み込みのスケーリング

 Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする、高速かつスケーラブルで可用性に優れたフルマネージド型のドキュメントデータベースサービスです。Amazon DocumentDB で、MongoDB で使用しているものと同じアプリケーションコードを実行し、同じドライバー、およびツールを使うことができます。この記事では、Amazon DocumentDB の最新クラウドネイティブデータベースアーキテクチャにより、クラスターの読み込みスループットを従来のアーキテクチャよりも高速かつ柔軟にスケーリングできる方法を示します。この記事では、Amazon DocumentDB クラスターへの接続とそこからの読み込みに関する推奨事項も提供されます。 Amazon DocumentDB クラウドネイティブアーキテクチャ 従来のモノリシックなデータベースとは異なり、Amazon DocumentDB のクラウドネイティブアーキテクチャは、ストレージとコンピューティングを分離しています。Amazon DocumentDB クラスターは、分散ストレージボリュームと、ストレージボリュームからデータを読み書きする 1 つ以上のコンピューティングインスタンスで構成されます。次の図は、1 つのプライマリインスタンスと 2 つのレプリカインスタンスを持つ Amazon DocumentDB クラスターを示しています。 コンピューティングインスタンスがリクエストを処理し、クラスターのストレージボリュームはすべてのデータのコピーを 6 つ (3 つのアベイラビリティーゾーンでそれぞれ 2 つのコピー) を維持することで耐久性を提供します。このアーキテクチャは、読み込みおよび書き込み操作用の単一のプライマリインスタンスと、読み込み操作用の最大 15 個の読み込みレプリカを提供し、1 秒あたり数百万回の読み込みにスケーリングします。 Amazon DocumentDB インスタンスにはデータが含まれていないうえに、新しいインスタンスを追加するときにデータをコピーする必要がないため、クラスターに新しいインスタンスをすばやく追加および削除できます。保存されているデータの量に関係なく、新しいレプリカインスタンスを追加し、既存のインスタンスのサイズを数分で変更することができます。新しいインスタンスは通常 8〜10 分でプロビジョニングされ、アクティブになるとすぐにクエリを処理できるようになります。Amazon DocumentDB の完全マネージド型のアプローチは、このアーキテクチャを利用して、ハードウェア障害が発生した場合にインスタンスをすばやく置き換えます。その結果、従来のデータベースアーキテクチャよりもはるかに迅速に回復できます。 Amazon DocumentDB エンドポイント Amazon DocumentDB は、3 種類のエンドポイントをサポートしています。 […]

Read More

非アクティブな Amazon Aurora PostgreSQL ユーザーの管理

データはあらゆる組織にとって最も貴重な資産の 1 つであり、データを安全に保つことは常に最優先事項です。データベースの一般的なセキュリティ要件の 1 つは、ユーザーアクセスを制限することです。データベースユーザーが危険にさらされた場合、データに重大な損害を与える可能性があるからです。データベースユーザーの最小権限モデルに沿って実行する必要があります。つまり、作業に必要な一連の最小権限のみをユーザーに付与します。また、データベースユーザーが長期間非アクティブである場合は、無効にすることをお勧めします。これにより、ミスやセキュリティ違反による影響を制限できます。詳細については、PostgreSQL ユーザーとロールの管理を参照してください。 この記事では、アクティブでない Amazon Aurora PostgreSQL ユーザーを特定し、自動的にロックまたは削除するソリューションを提供します。記事では、サンプルコードと AWS CloudFormation テンプレートも共有しているため、そのまま開始できます。 次の使用例では、特定の日数 (この記事では 90 日) の間、非アクティブであったユーザーを特定する必要があります。これらのユーザーを特定したら、ロックアウトします。DBA は、いつでもこれらのユーザーをロック解除できます。ただし、ユーザーが 180 日間非アクティブである場合は、自動的に削除する必要があります。 ただし、PostgreSQL はこの機能をネイティブでサポートしていません。一部の商用データベースでは、この機能にユーザープロファイル機能を含めています。これにより、指定した日数の間データベースにログインしていないユーザーアカウントをロックできます。 PostgreSQL の場合、PostgreSQL はユーザーログインのタイムスタンプをどのカタログテーブルにも保存しないため、作業がより困難になります。したがって、ユーザーが非アクティブである期間を判別するのは簡単ではありません。さらに、PostgreSQL にはログイントリガーがないため、トリガーベースのソリューションを適用するのも不可能です。 ソリューション パラメータグループでパラメータ log_connections を 1 に設定することにより、成功した各ログインの詳細 PostgreSQL へのロギングを有効にできます。このパラメータを設定すると、PostgreSQL エンジンはログインが成功するたびに次のようなメッセージを記録します。 2020-01-07 03:51:56 UTC:10.0.0.123(52820):postgres@logtestdb:[18161]:LOG: connection authorized: user=postgres database=logtestdb SSL enabled (protocol=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384, compression=off) Aurora PostgreSQL では、これらのエンジンログを Amazon CloudWatch Logs […]

Read More