Amazon Web Services ブログ

Category: Database

Amazon Neptune が一般向けにご利用いただけます

Amazon Neptune は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、および欧州 (アイルランド) でご利用いただけます。Amazon Neptune は高速で信頼性が高いフルマネージドグラフデータベースサービスであり、これを使用することで高度に接続されたデータセットと連携するアプリケーションの構築と実行が簡単になります。Neptune の中核となるのは、数十億の関係を保存し、ミリ秒単位のレイテンシーでグラフをクエリするために最適化された、専用設計の高性能グラフデータベースエンジンです。Neptune は Apache TinkerPop Gremlin と SPARQL を使用する 2 つの一般的なグラフモデルである Property Graph と RDF をサポートしており、高度に接続されたデータセットを効率的にナビゲートするクエリを簡単に構築することができます。Neptune は、リコメンデーションエンジンやナレッジグラフから医薬品創薬やネットワークセキュリティにいたるまで、あらゆるものを駆動するエンジンとして活用することができます。Neptune は、自動マイナーバージョンのアップグレード、バックアップ、暗号化、およびフェールオーバーによる完全マネージド型です。昨年、私が「AWS re:Invent」向けに寄稿した、「Naptune in detail」では、顧客はプレビューを使用していて、チームが GA 向けサービスを準備に活用した際の素晴らしいフィードバックについてご紹介しています。 今後、Amazon Neptune が一般的に利用できるようになったため、プレビューには次のいくつかの変更点があります: 多項目のパフォーマンス強化および更新内容 AWS CloudFormation サポート AWS コマンドラインインターフェイス (CLI)/SDK サポート Apache TinkerPop 3.3.2 に対応して更新済み Amazon Simple Storage Service (S3) からのバルク読み込むによる IAM ロールに関するサポート […]

Read More

Amazon DynamoDB での多様なクエリのための Z オーダーインデックス: パート 2

以前の AWS データベースに関するブログ記事で、 複数の属性の範囲の境界を使用して Amazon DynamoDB のテーブルを効率的に照会できるように、データを並べ替えることができる Z オーダーインデックスを紹介しました。この記事では、インデックス用のスキーマを作成するプロセスについて説明します。スキーマに含める属性を決定する方法、インデックスのスキーマがクエリの効率に与える影響、さまざまなデータ型の操作方法について説明します。 この記事はパート 1 で説明した概念に基づいていますので、先へ進む前に少し時間をとってその内容を確認されることをお勧めします。 Z オーダーインデックスのスキーマの作成 前の記事で説明したように、インデックスに保存されている各レコードには Z アドレスが割り当てられます。Z アドレスとは固定長のバイナリ値であり、レコードの属性の既知のセットのビットをインターリーブすることで見つけることができます。次の図は、2つの属性 x と y による Z アドレスの計算を示しています。 Z アドレスは、DynamoDB テーブルのソートキー (またはローカルのセカンダリインデックスキー) として使用されます。ソートキーは、高速でバインドされたクエリを可能にするために保存されているテーブルのデータを並べ替えること、パーティション内のレコードを一意に識別することという 2 つの目的を果たします。パーティションおよびソートキーの詳細については、DynamoDB のドキュメントのプライマリキーを参照してください。 スキーマは、テーブルまたはインデックスに保存される情報の構造を記述します。Z オーダーインデックスの文脈では、スキーマには次のものが含まれます。 インデックス付けされる属性の名前 (上記の図の x と y)。 属性がエンコードされる順序 (y に続いて x)。 属性のそれぞれのデータ型 (x と y は符号なし整数、0 以上の整数) とそれらをバイナリで表現する方法。 新しいレコードをテーブルに挿入するか既存のレコードを更新するたびに、そのレコードの Z アドレスを計算する必要があります。同様に、クエリを作成するときは、範囲の境界を表す最小レコードと最大レコードの Z アドレスを計算する必要があります。Z […]

Read More

Amazon Aurora PostgreSQL で読み書き用に pgpool の単一のエンドポイント設定する方法

Amazon Aurora は、プライマリ DB インスタンス (クラスタエンドポイント) と、リードレプリカ (リーダーエンドポイント) のエンドポイントを提供します。Aurora は、クラスタエンドポイントを自動的に更新するので、常にプライマリインスタンスを指し示すようできています。リーダーエンドポイントの読み取り機能は、使用可能なすべてのリードレプリカの読み取り操作の負荷を分散します。 Amazon Aurora Replica では、通常 100 ms 未満のレプリケーションラグが発生します。したがって、アプリケーションで遅延が許容される場合は、クラスタエンドポイントとリーダーエンドポイントの両方を使用して、水平方向に拡張されたデータベースを利用できます (図 1)。 図 1: 使用するエンドポイントを決定するアプリケーションのアーキテクチャ ただし、読み取り用と書き込み用両方のデータベースエンドポイント管理は、複雑なアプリケーションになります。この記事では、pgpool を使った、書き込みデータ量を自動的にクラスタエンドポイントへ、また読み込みデータ量を読み込みエンドポイントに転送する PostgreSQL-Amazon Aurora 互換の単一エンドポイントの構築方法をご紹介します (図 2)。 図 2: pgpool ミドルウェアに基づいたソリューション提案 アーキテクチャ Pgpool は PostgreSQL データベースとデータベースクライアントの間に位置する BSD ライセンスのミドルウェアですこの例では、図 3 のアーキテクチャを使用します。 図 3: PostgreSQL-Amazon Aurora 互換クラスタ用の単一エンドポイントを構築するミドルウェアとしての pgpool の使用 Amazon Aurora クラスタは、1 つのプライマリインスタンス、2 つのアベイラビリティゾーンと 2 […]

Read More

暗号化技術を使用して個人データを保護しながら、Amazon Aurora の MySQL 互換版に移行する

AWS ではセキュリティが最優先です。また、お客様にとってもこれは同じことです。私たちは個人データを保護するために膨大な量のリソースを使用し、当社のお客様にとってデータの保護が容易になるよう継続的に機能強化を図っています。Amazon Aurora の MySQL 互換版を含め、AWS のサービスはすべて、EU の一般データ保護規則 (GDPR) に準拠しています。  詳細については、Amazon のウェブサイトで一般データ保護規則 (GDPR) センターを参照してください。 Amazon の主要データストレージと処理サービスの 1 つである、Amazon Aurora の MySQL 互換版では、幅広い暗号化とデータアクセスコントロールオプションを提供しています。これらはこうしたサービス上で保存した個人データを保護しやすいように設計されています。データ保護の責任は現在進行中の運用に限られたものではなく、データの移動や移行といったアクティビティにも伴います。 今日のお客様は個人データの保護方法に大きな関心を寄せており、彼らが保存および処理するデータにも目を配っています。この結果、暗号化されたデータベースへデータを移行したり、データの転送時に暗号化形式を使用したりといった決定を下すことが増えています。このブログ記事では、Amazon Aurora の MySQL 互換版と安全な移行を実行する様々なパターンと、それを可能にするサービス機能についてご紹介します。 Amazon Aurora の MySQL 互換版の暗号化データストレージと処理機能 Amazon Aurora の MySQL 互換版では、次に示すように、お客様が暗号化技術を使用して個人データを保存および処理できるようにするいくつかの機能を提供しています。 Amazon Aurora では AWS Key Management Service (AWS KMS) を通じて管理するキーを使用してデータベースを暗号化することが可能です。Amazon Aurora データベースで暗号化が有効になると、保存されているデータ、自動化されたバックアップ、スナップショットが暗号化されます。 Amazon Aurora の MySQL 互換版を使用することで、データベースインスタンスに暗号化された接続を確立でき、またクライアントに暗号化された接続を使用するよう強制することもできます。 復元時には自分の望む […]

Read More

Amazon DynamoDB テーブルのストレージをモニタリングするサーバーレスソリューション

Amazon DynamoDB をアプリケーションの NoSQL データベースサービスとして使用する場合に、DynamoDB テーブルが使用するストレージ使用量を追跡したいとしましょう。DynamoDB は、サービスメトリックを Amazon CloudWatch に公開します。CloudWatch は、これらのメトリックをモニタリングおよび分析し、アラームを設定し、さらに AWS リソースの変更に対して自動的に反応します。現在のところ、DynamoDB は、ThrottledRequests、ConsumedWriteCapacityUnits、および ConsumedReadCapacityUnits を含む、多くの有用なメトリックを CloudWatch に送信します。 DynamoDB テーブルのストレージ使用状況を分析し、DynamoDB ワークロードが使用するストレージ使用量の履歴を把握し、ストレージコストを管理することは重要です。例えば、Time to Live (TTL) を使用して、不要なデータや陳腐化したデータを期限切れにしたいとします。そのような場合、ストリームを使用してそのデータを Amazon S3 または Amazon Glacier にアーカイブすることができるのです。この記事では、DynamoDB テーブルのストレージ使用状況をモニタリングする方法について解説します。 ソリューションの概要 DynamoDB は、6 時間ごとにテーブルのストレージ使用状況を更新します。この情報は、DynamoDB DescribeTable API を使用することで取得できます。テーブルのサイズを決定したら、カスタム CloudWatch メトリックを作成して、データを CloudWatch にプッシュできます。このソリューションでは、AWS CloudFormation を使用して、DynamoDB テーブルのストレージ使用状況をモニタリングするワンクリックデプロイメントアーキテクチャを作成する方法を解説します。これはインフラストラクチャをコードモデルとして実装するために必要です。 次の Python スクリプトと AWS CloudFormation テンプレートは、この GitHub リポジトリで入手できます。プロセスの仕組みは、上の図のようになります。(このソリューションは、DynamoDB ワークロードのあるすべての AWS リージョンでデプロイし、DynamoDB テーブルのストレージ使用量を継続してモニタリングすることを忘れないでください。) Amazon CloudWatch Events は、AWS Lambda 関数をスケジュールに従って実行します。 Lambda 関数は、DescribeTable […]

Read More

Amazon RDSデータベースプレビュー環境が ご利用可能になりました

Amazon RDSの利便性と柔軟性を備えたPostgreSQLデータベースエンジンのベータ版、リリース候補、およびearly productionバージョンを簡単にテストできる、Amazon RDSデータベースプレビュー環境が利用可能になりました。 PostgreSQLコミュニティから新しいバージョンがリリースされてから数日または数週間以内に、PostgreSQLの新しい機能をテストすることができるようになりました。現在のところ、Amazon RDSデータベースプレビュー環境では、PostgreSQLの次のメジャーバージョンの開発、ベータ、およびリリースの候補バージョンが提供されています。Amazon RDSデータベースプレビュー環境のデータベースインスタンスは全ての機能を有し、データベースのプレビューバージョンを自動でインストールし、プロビジョニング、および管理をお客様側で行って頂く必要がなく、新しいデータベースエンジンをテストできます。Amazon RDSデータベースプレビュー環境のデータベースインスタンスの価格は、米国東部(オハイオ)リージョンで作成されたRDSインスタンスと同じ価格です。 本番環境クラスのセキュリティ、パフォーマンス、信頼性、管理性、および可用性を確保するために、Amazon RDSは多くのテストを行った後で初めて新しいデータベースバージョンをリリースしてきました。Amazon RDSデータベースプレビュー環境は、新バージョンのデータベースエンジンがAmazon RDS環境への統合とテストが完了するのを待たずに、新しいPostgreSQLデータベースエンジンの信頼性、機能性、およびパフォーマンスの向上をすぐにお客様がテスト出来る環境を提供することで、お客様のリリースサイクルを数週間短縮することが可能になります。PostgreSQLのプレビュー版は、PostgreSQLコミュニティによってGA版がリリースされ、その後Amazon RDSでサポートされるまでAmazon RDSデータベースプレビュー環境で使用できます。 Amazon RDSデータベースプレビュー環境は、最新世代のインスタンスクラス(現在のところT2、M4、およびR4)でSingle-AZインスタンスとMulti-AZインスタンスの両方をサポートし、KMSキーを使用した透過的暗号化もサポートしています。Amazon RDSデータベースプレビュー環境データベースインスタンスは、最大60日間保持された後、自動的に削除されます。Amazon RDSデータベースのスナップショットは、プレビュー環境で作成し、データベースインスタンスの作成や復元に使用できますが、プレビュー環境内でコピーしたり、プレビュー環境外にコピーしたりすることはできません。代わりに、PostgreSQL標準のダンプとロード機能を使用して、データベースのロードとアンロードを行うことができます。 既存のAmazon RDSプロダクション環境のSLAはAmazon RDSデータベースプレビュー環境のインスタンスには適用されません。また、プレビュー環境で作成されたインスタンスについては、Amazon Customer Supportでサポートチケットを開くことはできません。私たちは、Amazon RDSデータベースプレビュー環境向けのフォーラムを作成しました。Amazon RDSチームは、PostgreSQLデータベースの候補バージョンとAmazon RDSデータベースプレビュー環境の両方に関する情報などをこちらで共有致します。 Amazon RDSデータベースプレビュー環境は今日からご利用可能です。詳細については、http://aws.amazon.com/rds/databasepreviewを参照してください。   翻訳は星野が担当しました。原文はこちら

Read More

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