Amazon Web Services ブログ

Category: Database

新規 – Amazon ElastiCache での Redis 4.0 の互換性

Amazon ElastiCache は、Redis または Memcached での完全マネージド型のインメモリデータストアやキャッシュの設定を簡単にします。本日、ElastiCache が Redis 4.0 と互換になったことを発表いたします。これにより、すべての商用 AWS リージョンで、Redis 4.0 互換の ElastiCache ノードまたはクラスターを起動できるようになります。ElastiCache Redis クラスターは、テラバイト単位のメモリや毎秒当たり何百万回もの読み書きへスケールして、ゲーム、IoT デバイス、金融アプリケーション、ウェブアプリケーションなどの最も厳しいニーズに対応することができます。 AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (CLI) で Redis クラスターを起動する方法は、引き続き簡単です。新しい Redis 4.0 の機能を使ってみるための小さなクラスターを作成し、新しいバージョンを使用するために「Engine version compatibility」で 4.0 リリースを選択します。これにより、この記事を書いている時点で、4.0.10 互換のクラスターが起動します。 新機能 Least Frequently Used (LFU) キャッシュエビクションポリシー – Redis 4.0 は、新しい LFU キャッシュエビクションアルゴリズムを含めて多くのキャッシング機能が強化されたことで、Least Recently Used (LRU) より優れたパフォーマンスを実現できます。Antirez のブログが、いくつかの変更について深く掘り下げています。 非同期の FLUSHDB、FLUSHALL、UNLINK – […]

Read More

Amazon RDS for MySQL および MariaDB に MariaDB MaxScale を使用して Binlog Server を設定する方法

Amazon RDS for MySQL と Amazon RDS for MariaDB の主要機能の 1 つが リードレプリカ を作成する機能です。AWS マネジメントコンソールまたは AWS CLI を使用して、1 つのマスターデータベースインスタンスについて、最大 5 つのレプリカを簡単に作成できます。Amazon RDS は、マスターのバックアップを作成し、バックアップをレプリカとしてリストアし、マスターとレプリカへのレプリケーションチャネルを確立する、といった作業すべてを処理します。Amazon RDS のレプリケーションを完全に自動化した処理は、マネージドレプリケーションと呼ばれます。 非標準のレプリケーショントポロジを求めている場合は、Binlog Server を使用できます。たとえば、レプリカが 5 つ以上必要な場合や、下流のアプリケーションにレプリケーションログレコードを転送する場合です。Binlog Server はレプリカとは違い、マスターのログレコードを使用せず、マスターと 1 つ以上のサブスクライバーの間にキャッシングレイヤーを提供します。今回の記事では、このアプローチを使用した場合の利点 (といくつかの制限) について説明します。MariaDB MaxScale と ノンマネージドレプリケーション を使用して、Amazon RDS for MySQL および MariaDB に Binglog Server をセットアップする作業を紹介します。 Amazon RDS for MySQL および MariaDB […]

Read More

Performance Insights を使用した Amazon RDS データベースの負荷分析

AWSは Amazon Aurora with PostgreSQL compatibility の一般リリースを先日発表しました。このリリースには Performance Insights と呼ばれる Amazon Relational Database Service (Amazon RDS) に有用な機能の最初のリリースも含まれます。データベースの負荷(どのSQL文が負荷を発生させており、それはなぜなのか)を可視化するダッシュボードを使用して、エキスパートな方とエキスパートではない方の両方が、Performance Insights でパフォーマンス問題を容易に検出できます。

Read More

Amazon RDS for PostgreSQLにおける自動バキュームのケーススタディ

PostgreSQLデータベースにおいて、自動バキューム処理(autovacuum)は複数の重要なメンテナンス操作を実行します。周回を防止するためにトランザクションIDをフリーズすることに加えて、デッドタプルを削除し空きスペースを回復させます。書き込み回数の多いデータベースの場合は、自動バキュームを頻繁に実行するようにチューニングすることをお勧めします。そうすることで、テーブルやインデックスを膨らませるデッドタプルの蓄積を避けることができます。

この記事では、デッドタプルが蓄積される状況でどのように自動バキューム処理を監視し、チューニングするかを実際に示すために、ケーススタディを用いてご説明します。

Read More

Amazon DynamoDB グローバルテーブルを使用して、高速かつグローバルで利用可能なユーザープロファイリングシステムを作成する方法

ユーザープロファイリングシステムとは、ユーザーの名前、ID、連絡先情報、過去の行動、関心事項、その他の情報を保存するシステムです。こうしたシステムはまた、ユーザー情報を照会する方法も提供します。この記事では、グローバル化されたユーザープロファイリングシステムの重要性、Amazon DynamoDB グローバルテーブルを使用してこのシステムを作成する方法、機械学習でこのシステムを使用する方法について説明します。 概要 ウェブサイト、モバイルアプリケーション、ゲームは、グローバルなユーザーベースを持つことができます。たとえば、最近のトップトレンドゲームである PlayerUnknown の Battlegrounds を考えてみましょう。そのユーザーベースは、以下のような地理的な内訳です。 米国から 24% 中国から 19% ドイツから 6% このゲームや同様の他のゲームでは、レイテンシーが少なくグローバルに利用可能なユーザープロファイリングシステムが、世界中のユーザーに優れたエクスペリエンスを提供するのに役立ちます。 DynamoDB グローバルテーブルは、複数の AWS リージョンで DynamoDB テーブルを複製することにより、データへの高速なグローバルアクセスを可能にします。DynamoDB グローバルテーブルを使用すると、迅速で一貫性のあるグローバルなユーザープロファイリングシステムを構築できます。この記事で説明しているユーザープロファイリングシステムは、グローバルな低レイテンシーアクセス用のグローバルテーブルのローカルレプリカテーブルを使用し、そのデータには最終的な一貫性があります。 このグローバル化されたユーザープロファイリングシステムは、機械学習目的でも使用できます。DynamoDB はスキーマレスなので、任意の形式のデータを簡単に保存して照会することができます。したがって、DynamoDB ベースのユーザープロファイリングシステムで使用されるデータ形式を、選択した機械学習モデルに最適なデータ形式に調整することができます。この記事では、機械学習でユーザープロファイリングシステムを採用する方法を示します。 グローバルユーザープロファイリングシステムの構築 Example Corp. は世界的なオンライン書籍販売店であり、世界中に顧客を抱えているとしましょう。Example Corp. は、顧客の名前、ID、住所、支払い方法などの情報を記憶しておき、この情報を顧客の注文を遂行するために使用したいと考えています。この場合、Example Corp. はユーザーの情報を保存するためのユーザープロファイリングシステムが必要です。 このユーザプロファイリングシステムは、次の 2 つの要件を満たす必要があります。まず、Example Corp. はグローバルなオンライン書籍販売店であるため、このユーザープロファイリングシステムは世界中のユーザーをサポートする必要があります。次に、このユーザープロファイリングシステムは、顧客がウェブの遅延を経験しないように、迅速に要求に応答する必要があります。(注文にかかる時間が長くなるほど、顧客が注文を放棄する可能性が高くなります。) この 2 つの要件を満たすために、Amazon DynamoDB グローバルテーブルを使用して Example Corp. のサンプルユーザープロファイリングシステムを作成する方法を説明します。分かりやすくするために、この例では user_id と user_name の属性だけを使用します。 まず、米国西部 (オレゴン) リージョンに UserProfiles […]

Read More

Ora2pg と AWS DMS を使用して BLOB および CLOB テーブルを Oracle から PostgreSQL に移行する方法

多くの企業は、Oracle データベースを PostgreSQL に移行することを検討しています。プラットフォームと企業間の互換性が高く、またライセンスコストを削減するためです。Amazon RDS for PostgreSQL と Amazon Aurora with PostgreSQL の互換性により、コスト効率の高い方法で PostgreSQL のデプロイメントをクラウドに簡単にセットアップ、運用、拡張できます。 AWS は、AWS 環境またはオンプレミスデータセンターのいずれかで実行されている Oracle データベースを移行する 2 つのサービスを提供します。AWS Schema Conversion Tool (AWS SCT) は、既存のデータベーススキーマをターゲットデータベーススキーマに変換するのに役立ちます。AWS SCT がスキーマを自動的に変換できない場合は、ターゲットデータベースに同等のスキーマを作成する方法を示す評価レポートが表示されます。AWS Database Migration Service (AWS DMS) は、ソースデータベースからターゲットデータベースに実際のデータを移行するのに役立ちます。 AWS DMS の外部で大きな BLOB および CLOB を移行したいとお考えかもしれません。オープンソースツール Ora2Pg を既によく知っている場合は、このツールを使用してデータを一括読み込みし、AWS DMS を変更データキャプチャ (CDC) に使用できます。 このブログ記事では、Amazon RDS for Oracle データベースを Amazon […]

Read More

Amazon RDSでのIAM multifactor authenticationの利用について

お客様からよく頂くご要望に、インスタンス、スナップショット、クラスタなどのリソースを予期しない、または悪意のあるユーザの削除から保護する方法です。これは、複数のユーザーやチームで共通のAWSアカウントを使用する場合に特に重要です。アカウント内の利用を効率的に行うことも重要ですが、重要なデータを失うことを防ぐためにセキュリティも必要です。 1つの選択肢は、AWS Identity and Access Management(IAM)ポリシーをmultifactor authentication (MFA)で使用することです。MFAでは、AWSリソースに関連した操作を行う際に、承認された認証デバイスまたはSMSテキストメッセージから取得した一意の認証コードを入力する必要があります。この記事はMFAを用いたAmzon RDSのリソースの保護についてご説明します。 たとえば、* prod *のような命名規則でタグ付けされ保護されたリソースの削除を制限するIAMポリシーを作成します。 次に、AWSマネージメントコンソールにアクセスするためにMFA認証が必要な2つ目のIAMポリシーを作成し、このアカウントに対して特定の削除権限を与えます。このようにして、アクセス権のあるすべてのユーザーを監査し、選択されたユーザーのみが必要な権限を持っていることを確認できます。 2つのポリシーを利用します。1つはAWS managed policyの、AmazonRDSFullAccessです。もう1つはcustomer managedポリシーの、RDSDenyDeleteというポリシーを作成します。このポリシーは、リソースを削除する可能性のあるコマンドの実行を制限します。 First step: Start in the IAM console IAMコンソールを開きます。Create policyを選択し、次のJSONコードをポリシーエディタボックスに貼り付けます。 { “Statement”: [ { “Effect”: “Deny”, “Action”: [ “rds:DeleteDBClusterSnapshot”, “rds:DeleteDBSnapshot”, “rds:DeleteDBCluster”, “rds:DeleteDBInstance” ], “Resource”: “*” } ] } Review policyを選択し、ポリシーに名前と説明を付けます。 次に、AmazonRDSFullAccessポリシーとRDSDenyDeleteポリシーを組み合わせたグループを作成します。 IAMコンソールのGroupsから、Create new groupを選択し、グループ名を設定します。この例ではAWSDevelopmentTeamを利用します。 Next stepを選択します。AmazonRDSFullAccessおよびRDSDenyDeleteの横にあるチェックボックスをを選択します。 Next stepを選択し、Create groupを選択します。 […]

Read More

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