Amazon Web Services ブログ

Category: Database

Amazon Athena を使用して高度な分析を行い、Amazon DynamoDB データの視覚化を行う

Amazon DynamoDB サービスでは、1 秒あたり数十億件のアイテムと数百万回のリクエストの中から膨大な分析値を取得することができます。ただし、その分析値を取得するには、データをエクスポートする必要があります。DynamoDB テーブルから分析プラットフォームにデータをコピーすることで、情報を豊富に抽出することができます。これを行うには、優れたアーキテクチャのビッグデータパイプラインが、トランザクションプロセスを分析から切り離すのに大変便利です。このブログ記事では、DynamoDB テーブルから Amazon S3 にデータを移行するビッグデータパイプラインを構築する方法を説明します。これは、完全管理型の Presto クエリサービスである Amazon Athena を使用して、高度な分析が実行でき、Amazon QuickSight を用いて、視覚化およびアドホック分析を構築することも可能です。 デカップリングしたビッグデータアプリケーションにはたいてい、ストレージとコンピューティングを分離する共通のパイプラインがあり、そのため、新しい処理技術が生まれた際にはそれを活用することができます。デカップリングにより、データの耐久性に影響を与えることなく、複数の分析エンジン用の計算リソースを柔軟にプロビジョニングできるようになります。また、パイプラインを設計して、ストレージと処理の段階を繰り返し、下流のアプリケーションがすばやく使用できる形式でデータを整形することも可能です。 ビッグデータパイプラインの設計には、3 つの大きな特性が作用しています。 パイプライン全体の遅延 – データから正しい情報を得るまでにどれくらいの時間を要するでしょうか? 数千分の 1 秒、数分、あるいは数日? データのスループット – どれくらいのデータを取り込んで処理する必要がありますか? 数ギガバイト、数テラバイト、あるいは数ペタバイト? コスト – アプリケーションのための目標予算はいくらですか? AWS の最も費用対効果の高いオプションが、普通、適切な選択と言えるでしょう。 ビッグデータパイプラインを設計する際に考慮すべきことは他にも、データ構造、アクセスパターン、データの温度、可用性と耐久性、そしてサービスが完全に管理されているかどうかなどがあります。これらの特性に基づいてジョブに適切なツールを使用することは、優れたアーキテクチャを持つビッグデータパイプラインにとって重要です。 階層化されているビッグデータパイプライン 階層化されたビッグデータパイプラインを解説する前に、このソリューションで利用する主なサービスと機能を見てみましょう。 パイプラインでの DynamoDB の機能 DynamoDB で用いる主要なコンポーネントは、テーブル、項目、および属性です。テーブルは項目の集合であり、各項目は属性の集合です。DynamoDB はプライマリキーを使って、テーブルの各項目を識別します。セカンダリインデックスを使用すると、クエリの柔軟性が向上します。詳細については、「Amazon DynamoDB の仕組み」を参照してください。これは「DynamoDB 開発者ガイド」の中にあります。 DynamoDB TTL (Time To Live) を使用すれば、ストレージコストを削減する手段として、すでに関連性がなくなった項目を自動的に削除することができます。このブログ記事では、テーブルの TTL を有効にし、ttl 属性を使用して削除のタイムスタンプを設定します。TTL の詳細については、「Time […]

Read More

トランザクションレプリケーションを使用して、Amazon RDS for SQL Server に移行する方法

ご使用のデータベースを Amazon RDS for Microsoft SQL Server へ移行するには複数の方法があります。通常、データベースのシンプルなバックアップと復元を実行するのが一般的です (logins などのシステムオブジェクトのスクリプトを書くとともに)。可用性をさらに高める、またはダウンタイムを短縮するオプションが必要であれば、AWS Database Migration Service (AWS DMS) を利用できます。このブログ記事では、ご使用のデータベースを RDS for SQL Server へ移行するために、3 番目のメカニズムである、トランザクションレプリケーションを使用する方法について解説します。このアプローチを使用すると、提供されているサービスを使用する必要なく、既存のインフラストラクチャを活用して Amazon RDS for SQL Server へデータを移動できます。 RDS for SQL Server は SQL Server のレプリケーションをサポートしていません。これは主に、RDS for SQL Server インスタンス上でホストされているとき、SQL Server Agent のレプリケーションサブシステムが実行されていないためです。しかし、オンプレミスまたは Amazon EC2 (SQL Server のホストインスタンス) 上のいずれかで SQL Server Agent が実行されているところでは、プッシュサブスクリプションはサポートされています。RDS for SQL […]

Read More

Amazon RDS for PostgreSQL バージョン: 9.3.x リタイアメントのお知らせ

本投稿は、こちらのフォーラムでご案内されたアナウンスメントの参考和訳です。 本アナウンスメントは、Amazon RDS が RDS for PostgreSQL のバージョン9.3のサポートを2018年9月5日をもって終了することをお知らせするものです。 Amazon RDSは2013年からPostgreSQLメジャーバージョン9.3をサポートしています。本リリースの後、機能、セキュリティ、信頼性、パフォーマンスの観点で大幅な改善がなされたメジャーバージョンが続々とリリースされています。PostgreSQLコミュニティは、PostgreSQL 9.3のリリース終了時期を2018年9月と発表しています。コミュニティサポートモデルに合わせて、AWSは9.3.10, 9.3.12, 9.3.14, 9.3.16, 9.3.17, 9.3.19, 9.3.20, 9.3.22 のマイナーバージョンを含めて、メジャーバージョン9.3のサポートを終了いたします。Amazon RDS では引き続き、バージョン9.4 以降の PostgreSQLデータベースをサポートいたします。 できるだけ早いタイミングで、Amazon RDS PostgreSQL データベースインスタンスをバージョン9.6, もしくは、バージョン10 にアップグレードすることを推奨します。その際、RDS のメジャーバージョンアップグレードの機能をご利用いただき、次のバージョンにアップグレードできます。アップグレードを開始するには、AWS マネジメントコンソールにて、「Modify DB Instance(DB インスタンスの変更)」ページに移動し、データベースのバージョンをPostgreSQLの新しいメジャーバージョンに変更します。 [Apply Immediately(すぐに適用)]オプションを選択すると、「Modify DB Instance(DBインスタンスの変更)」ページを終了した直後にアップグレードが開始されます。変更をすぐに適用しない場合は、その後のメンテナンスウィンドウ中にアップグレードが実行されます。 RDS for PostgreSQL のメジャーバージョンのアップグレードの詳細については、PostgreSQL DB エンジンのアップグレードを参照してください。 Amazon RDS PostgreSQL 9.3 のリタイアメントプランの一環として、2018年8月6日 以降、AWSコンソールを使用して新たな PostgreSQL 9.3 インスタンスを作成することが出来なくなります。2018年11月には、残されている 9.3 インスタンスに対する、PostgreSQL […]

Read More

Amazon Elasticsearch Service を使い始める: Amazon Cognito を Kibana のアクセスコントロールに使用する

Elasticsearch および Amazon Elasticsearch Service (Amazon ES) に関するこの導入シリーズへようこそ。今回および今後のブログ記事では、AWS で Elasticsearch の使用を開始するために必要な基本情報を紹介します。 概要 2018 年 4 月 2 日、Amazon Elasticsearch Service と Amazon Cognito 間の統合がリリースされました。今後は Amazon ES ドメインへの Kibana アクセスにユーザーレベルのサインオンを提供し、それらを管理できるようになります。Amazon Cognito を使用することで、外部の ID プロバイダーに接続し、自社のユーザーにシングルサインオンを提供できます。また、ユーザーまたはユーザーグループに対してアクセスポリシーを設定することにより、アクセスコントロールの管理を簡略化できます。 本記事では、Amazon Cognito の認証と Amazon ES ドメインにある Kibana へのアクセスコントロールの追加セットアップについて説明します。前半では Amazon ES ドメイン、Amazon Cognito ユーザープール、Amazon Cognito ID プールなどの基本コンポーネントを作成します。このプロセスの最後には、Amazon Cognito を通じて提供された、共有 Auth_Role をベースにした Kibana にサインオンします。Auth_Role […]

Read More

Redis 用 Amazon ElastiCache を使用してリアルタイムの販売分析ダッシュボードを構築する方法

Amazon ElastiCache について説明すると、ほとんどの場合、読み取り負荷の高いデータベースワークロードのパフォーマンスを向上させるという文脈になります。リードスルーまたはライトスルーのパターンを採用するようにアプリケーションを更新し、キャッシュ内のデータを最新に保ち、データベースの負担を軽減します。この文脈で使用すると、ElastiCache はデータをメモリにキャッシュして大量のワークロードを高速化し、ミリ秒未満のデータ取得パフォーマンスを実現します。さらに、Redis 用 Amazon ElastiCache は、マルチ AZ 設定の自動フェイルオーバーにより、ワークロードの可用性とフォールトトレランスを向上させます。 ただし、ElastiCache は、ワークロードをより効率的にするだけでなく、新しい機能を提供するなど他にも多くの利点をもたらすことができます。この記事では、Redis 用 ElastiCache で構築されたリアルタイムの販売分析ダッシュボードの文脈で、こうした機能のいくつかを検討します。 この例で使用されているダッシュボードのコードとサンプルアーキテクチャは、GitHubの aws-elasticache-retail-dashboard リポジトリから入手できます。 ダッシュボードの指標 このダッシュボードは、広範な製品カタログを持つ大量の電子商取引サイトについて、ほぼリアルタイムの指標を提供します。リレーショナルデータベースを使用してこうしたダッシュボードを構築するには、リソースを集中的に使用するクエリの複雑なセットが必要です。代わりに、少数の Redis コマンドを使用してこのデータを追跡します。 このダッシュボードは、5 つの主要な一般的販売指標に焦点を当てています。 毎日の注文数 まず、簡単な指標である、毎日の注文数から始めます。注文を受け取るたびに、注文数を 1 つ増やします。操作は高速でアトミックなので、リレーショナルデータベースのテーブルの行数を数える必要はありません。毎日、新しいキーを作成し、Redis は初期値 0 のキーを作成します。ダッシュボードは当日の注文数にのみ関係しています (履歴データは後で取り上げます)。 2018 年 3 月 11 日の注文数を増やすには、指定したキーに保存されている整数値をインクリメントする、Redis INCR 操作を使用します。キーが存在しない場合は、操作が実行される前に値が 0 に設定されます。 INCR orders:20180311 これで、次のように整数形式の値を取得できます。 GET orders:20180311 当日販売された一意の商品の数 毎日の注文数をカウントしたので、次はそれらの注文で販売されている商品に関するデータを収集しましょう。まず、毎日販売されている一意の商品の数 (SKU または一意の ID による) を追跡しましょう。注文数の指標と同様に、同じ結果を作成する SQL クエリ […]

Read More

AWS Lambda から Amazon DynamoDB Accelerator(DAX)を使用して、コストを削減しながらパフォーマンスを向上させる

Amazon DynamoDB Accelerator (DAX) で AWS Lambda を使用すると、 も使用するサーバーレスアプリケーションにいくつかの利点があります。DAX は、読み取りレイテンシを大幅に短縮することにより、DynamoDB を使用する場合と比較して、アプリケーションの応答時間を向上させることができます。また、DAX を使用すると、読み取り負荷の高いアプリケーションに必要なプロビジョニングされた読み取りスループットの量を減らすことで、DynamoDB のコストを削減できます。サーバーレスアプリケーションの場合、DAX には、次のようなメリットがあります。レイテンシが短くなると、Lambda 関数の実行時間が短縮され、コストが削減されます。 Lambda 関数から DAX クラスターに接続するには、特別な設定が必要です。この記事では、AWS Serverless Application Model (AWS SAM) に基づいた URL 短縮アプリケーションの例を示します。このアプリケーションでは、Amazon API Gateway、Lambda, DynamoDBmDAX、および AWS CloudFormation を使用して、Lambda から DAX にアクセスする方法をデモします。 シンプルなサーバレス URL 短縮機能 この記事のアプリケーション例では、シンプルな URL 短縮機能を示します。ここでは、AWS SAM templates を使用して、API Gateway、Lambda、および DynamoDB の設定を簡易化します。全体の設定は、繰り返し可能な展開のための AWS CloudFormation テンプレートに表示されます。DAX クラスター、ロール、セキュリティグループ、およびサブネットグループを作成するセクションは、SAM テンプレートに依存していないので、通常の AWS CloudFormation […]

Read More

AWS Database Migration Service と AWS Schema Conversion Tool がソースとしての IBM Db2 LUW をサポート開始

AWS SCT がLinux、UNIX、Windows (LUW) 用の IBM Db2 からAWS上でサポートされているオープンソースデータベースにオブジェクトを変換できるようになりました。これには Amazon RDS for PostgreSQL と RDS for MySQL、Amazon Aurora (MySQL and PostgreSQL compatible) を含みます。同時に、AWS DMS のソースとしての IBM Db2 for LUW の一般リリースも発表します。この発表は、AWS DMS を使用して Db2 for LUW から AWS DMS でサポートされているすべてのターゲットに移行できることを意味します。これらの機能は、Db2 for LUW からクラウドへの移行に役立ちます。

Read More

AWS Glue を使って、分析処理のためにデータを抽出、変換、ロードする方法 (パート 2)

企業が直面している大きな課題に、信頼性の高い抽出と変換、およびロード (ETL) プロセスをいかに確立し維持するかがあります。なぜならこれらは、データから値と正しい情報を取り出すのに重要だからです。従来の ETL ツールは使用するにも複雑で、実装、テスト、およびデプロイに数カ月かかることもあります。ETL ジョブを作成すると、データフォーマットとスキーマが頻繁に変更され、新しいデータソースを常に追加する必要があるため、それらを維持するのは骨が折れる作業となります。 一方で AWS Glue は、データの発見、分類、クリーニング、充実化、および移行に関連する未分化の重労働の多くを自動化できるため、データ分析により時間を費やすことができます。AWS Glue はデータソースを自動的にクロールし、データフォーマットを識別して、適切なスキーマと変換を提案します。つまり、データフローを手作業でコーディングする必要がないのです。 AWS Glue は、分析用にデータセットを移行および変換する作業を簡素化するよう設計されています。普及している Apache Spark 実行フレームワーク上に構築したサーバーレスの完全管理型サービスです。 2 部構成となっている移行についてのブログシリーズのパート 2 では、AWS CloudFormation スタックの構築を行います。このスタックを使用して、AWS Glue が Amazon Aurora MySQL データベースとの間でデータを抽出、変換、そしてロードする方法を解説します。ソースとして Amazon Aurora MySQL を、そして AWS Glue のターゲットとして Amazon Simple Storage Service (Amazon S3) を使用します。Amazon Athena を使って簡単なクエリとレポートを行うために、Amazon S3 に集中型データレイクを構築する方法についても説明します。Amazon Redshift をデータウェアハウス戦略の構築のために、データターゲットとして使用することもできます。この記事では、AWS Glue を開始し、必要に応じてカスタマイズするためのフレームワークを説明します。 AWS Glue には、3 つのコアコンポーネントがあります。 […]

Read More

MySQLデータベースをAuroraへ移行する方法をマスターする

By Nathaniel Kangpan, SVP Technology & Data Services, Kepler Group 私は過去12ヶ月の間に(a)クラウドベースのインフラストラクチャを使うことに踏み出していない、もしくはその様なチームがいない(b)2018年のロードマップにクラウドを使うことが乗っていないクライアントに会っていません。ハードウェアからクラウドへ移行した場合のTotal Cost of Ownership(TCO)の節約は無視できません。 しかし、所有しているハードウェアからAWSのようなクラウドベースのインフラストラクチャに移行する際には、本当に何を期待するべきですか? Amazon EC2などの仮想サーバー上にソリューションを複製するだけでいいですか、Amazon RDSのようなマネージドサービスを増やすべきででしょうか? Kepler Groupでは、インフラストラクチャの95%以上が2014年後半からAWS上で稼働しています。過去数年にわたり、多くのお客様に機転となる時に何を期待しているかをアドバイスしました。私達はマーケティングデータベース管理サービスを提供しています。クライアントとの最も一般的な議論の1つは、リレーショナルデータベースをAWSに移行する際に抱えるメリットと課題を理解する助けとなることです。   Global Fortune 100の例 私たちは通常、Global Fortune 100クライアントのために完成した代表的なプロジェクトを中心に、データベースクラウドの移行に関する会話行っています。この特定のクライアントにとって、私たちは最初に、データセンターのハードウェア上にMySQLデータベースを構築しました。その後、MySQLを実行しているEC2インスタンスに移行し、最終的にAmazon Aurora MySQLに移行をしました。クライアントのユースケースと基本的なデータスキーマは、この間にあまり変化しませんでした。そのため、私たちはソリューションの管理がますます効率化されるようになるにつれ、同じMySQLデータベースを複数のフレームワークで実行することの長所と短所について多くのことを学びました。 今回の対象のデータベースは、マーケティングおよびセールスカスタマーリレーションシップマネジメント(CRM)データベースでした。一連の電子メールおよびセールスチームベースのマーケティングキャンペーンで、レポートおよび分析ユースケースのために複数のサードパーティソースにデータを継続的に集約しました。私たちのチームは、データベースの管理に加え、マネージドサービスとしてレポートと分析の提供を担当する主なユーザーです。 このプロジェクトは、スコープと予算の面で一般的に管理していた物の小規模なものでした。クライアントのニーズを満たすことに加えて、次の点に細心の注意を払う必要がありました: データベースメンテナンスの負荷を低く抑える インフラストラクチャコストの制限 信頼性の高いバックアップおよびリカバリプロセスを確保する 前述のように、データベース用に3つの異なるインフラストラクチャソリューションを使い、各バージョンのメリットと課題についてかなりのことを学びました: v1.0:オンプレミスハードウェア上のLinuxでMySQLを実行する v2.0:Amazon EC2上のLinuxでMySQLを実行する v3.0:MySQLと互換性を持つAmazon Aurora 次の移行の概要では、各バージョンへの移行の決定と、その過程で得た利点と課題について説明します。   Version 1.0: オンプレミスハードウェア上のLinuxでMySQLを実行する 2013年後半にこのクライアントとの関係を開始したとき、クラウドベースのサービスを検討し始めましたが、私たちのインフラストラクチャは、データセンターを基盤とするハードウェアソリューションでした。クライアントサービスや厳しい締め切りで働いている多くの人が理解できるように、理想的な長期的なソリューションを最初から構築するのではなく、迅速に稼働させることを優先する必要がありました。私たちは、オンプレミスハードウェア上のLinuxとMySQLの組み合わせから開始することにしました。これは、このプロジェクトで作業しているエンジニアが最も慣れている構成だったからです。 利点 この初期のアプローチの唯一のメリットは、エンジニアがハードウェア+ Linux + MySQLの構成でよく作業していたことです。必要な開発フレームワーク、データ転送メカニズムなどはすべてかなり理解されており、大きな技術的驚きは期待できませんでした。これにより、限られたAWS経験を持つクラウドベースのソリューションに飛び込むのとは対象的に、納期と予算に対するリスクを最小限に抑えながら顧客の設定した期限を迎えることができるという自信が得られました。 チャレンジ しかし、ハードウェア環境で解決策を維持することには、かなりの数の問題がありました。AWSへの移行を後で行うまでは、これらの非効率性を十分に理解していませんでした。具体的には、クラウドと比較してハードウェアソリューションでは次のような課題に直面しました: かなり高いサーバーとデータベースのメンテナンスとアップグレードの運用負荷 時間の経過とともに増加するデータ量に対応する、シームレスではない垂直スケーリングプロセス […]

Read More