Amazon Web Services ブログ

Category: Database

Amazon Aurora を使用して概念実証を作成する

お客様がクラウドに移行するにつれて、アプリケーションを実行する最良のツールを探しています。リレーショナル データベースを検討するとき、Amazon Aurora はよく選択されます。Amazon Aurora が MySQL および PostgreSQL とワイヤー互換であり、どちらよりも高いスループットを提供できることを考えれば、これは驚くようなことではありません。Aurora は、標準 MySQL データベースのスループットを最大 5 倍、標準 PostgreSQL データベースのスループットを最大 3 倍提供します。 顧客は Aurora を調査しながら、Amazon Aurora がアプリケーションに適しているかどうかを確認するために、一般的に概念実証 (POC) を構築します。以下に、POC を作成する際に考慮する点をいくつか示します。 Amazon Aurora は正しいツールなのか? データとデータベースについて考えるとき、重要な要素の 1 つはデータの速度です。一方では、データベースへの読み取りと書き込みの両方で、おそらく数千の接続と数十万の同時クエリでデータが非常に速く移動します。この速度では、クエリは通常、一度に比較的少数の行に影響します。さらに、データがこの速度でアクセスされるときは、レコードのようにクエリが一度に複数の列にアクセスするのが一般的です。このアクセス タイプでは、より実用的にデータを行単位で保存および取得することができます。このワークロード タイプの一般的な例は、オンライン トランザクション処理 (OLTP) システムです。 一方では、データの速度が遅くなるにつれて、ほんの一握りの接続と並行して実行されている少数のクエリしかない可能性があります。ただし、ここでは、完全なテーブルのスキャンを含め、行の範囲が何倍も大きいことがよくあります。この速度でクエリは、おそらくテーブルの行すべてに集中するよりは、通常、より小さな列のサブセットに集中します。この方法では、より実用的にデータをカラムナ形式で保存します。さらに、遅い速度での書き込みパターンは大きく異なります。ほとんどのデータは、高速では定期的に一括で読み込まれ、より高速ではほぼ一定で個々に書き込まれます。このワークロードタイプの一般的な例は、データ ウェアハウジングまたはオンライン分析処理 (OLAP) システムです。 Amazon Aurora は、主に高速データを処理するために設計されました。ワークロードに応じて、単一 r4.16xlarge の Aurora クラスターでは、1 秒間で 600,000 を超える SELECT ステートメントを処理できます。このようなクラスターでは、1 秒間で […]

Read More

Amazon DynamoDB の大量の時系列データの設計パターン

時系列データは、経時変化のパターンを示しています。たとえば、次のグラフの例に示すように、センサーを通じて環境データを記録するモノのインターネット (IoT) デバイスがあります。このデータには、温度、気圧、湿度、その他の環境変数が含まれる場合があります。各 IoT デバイスは定期的にこれらの値を追跡するため、バックエンドは毎秒最大数百、数千、または数百万のイベントを取り込む必要があります。 このブログ記事では、大量の時系列データを扱うシナリオ用に Amazon DynamoDB を最適化する方法について説明します。これを、自動化とサーバーレスコンピューティングを活用した設計パターンを使用して行います。 DynamoDB で大量のイベントを設計する 通常、データ取り込みシステムには以下が必要です。 現在の時間に関連する新しいレコードを取り込むための高い書き込みスループット。 最近のレコード用の低いスループット。 古いレコード用の非常に低いスループット。 このようなイベントをすべて単一の DynamoDB テーブルに格納する場合、ホットパーティション (最新のレコード) とアクセス頻度の低いパーティション (古いレコード) があります。アクセス頻度の低いパーティションは、プロビジョニングされた書き込み容量を、新しいレコードを保存しておきたいホットパーティションから逸らしてしまうため、最適ではありません。さらに、分析ニーズに適した期間を設計したいことがよくあります。たとえば、過去数日間または数か月間のデータを分析するとします。これらの期間の長さを調整することで、分析パフォーマンスとコストの両方を最適化できます。 DynamoDB の一般的な設計原則では、できるだけ少ない数のテーブルを使用することが推奨されていますが、時系列データでは、その設計原則に反して、各期間に複数のテーブルを作成します。この記事では、このようなアンチパターンを DynamoDB に使用する方法を説明しますが、時系列データには最適です。 オンデマンドキャパシティーモードを選択しない限り、すべての DynamoDB アクセスパターンは、読み取り容量単位と書き込み容量単位の異なる割り当てを必要とします。この記事では、レコードの読み書き頻度に基づいて、レコードを次の 3 つの異なるグループに分類します。 毎秒書き込まれる新しいレコード よく読み取られる最近のレコード あまり読み込まれない古いレコード 新たに取り込まれたレコードの書き込みスループットを最大にするには、期間ごとに新しいテーブルを作成し、最大数の書き込み容量単位と最小数の読み取り容量単位を割り当てます。また、各期間の終了前に次の期間のテーブルを事前作成して、現在の期間が終了したときにすべてのトラフィックをそのテーブルに移動できるようにします。古いテーブルへの新しいレコードの書き込みをやめると、その書き込み容量単位を 1 に減らすことができます。短期間の読み取り要件に基づいて、適切な読み取り容量単位もプロビジョニングします。次の期間が終了したら、読み取り容量や書き込み容量をオーバープロビジョニングしたくないので、割り当てられている読み取り容量単位も減らします。 また、新しい期間に切り替える頻度を見積もる際にも、分析上のニーズを考慮する必要があります。たとえば、昨年何が起こったのか分析したいと思った場合、4 つの並列クエリでデータをより効率的に取得して 4 つの結果セットを集計できるように、四半期ごとのテーブルを使用できそうです。 他のユースケースでは、前四半期のデータだけを分析したいと思うかもしれず、また毎月のテーブルを使用しようと考えるかもしれません。これにより、3 つの並列クエリを実行して分析を実行できます (四半期の各月に 1 回ずつ)。一方、この分析で特定の洞察が日単位で必要な場合は、日次テーブルを選択することを考えるかもしれません。 この記事の残りの部分では、日次テーブルを使用した後者のシナリオに焦点を当てます。昨日のデータが分析に適していて、より古いデータは頻繁にアクセスされないとします。真夜中の直前に新しいテーブルを作成し、真夜中の直後に古いテーブルの書き込み容量単位を減らすためにスケジュールされたジョブを設定しました。 このようにして、いつも以下があるようにします。 1,000 の書き込み容量単位と 300 の読み取り容量単位 (最大の書き込み数と一部の読み取り数) を持つ今日のテーブル。 1 […]

Read More

AWS CloudFormation を使用して、推奨されるベストプラクティスによって Amazon Aurora PostgreSQL DB クラスターをデプロイする

このブログ記事では、Amazon Aurora PostgreSQL クラスターのクイックスタートリファレンスデプロイメントを構築する方法について説明します。クラスターはセキュリティと高可用性のための AWS のベストプラクティスに基づいており、AWS CloudFormation を使用して速やかに作成できます。必要に応じてカスタマイズできる CloudFormation の一連のサンプルテンプレートを見ていきます。 Amazon Aurora は、クラウド用に構築された MySQL および PostgreSQL 互換のリレーショナルデータベースです。Aurora は、ハイエンドの商用データベースのパフォーマンスと可用性、ならびにオープンソースデータベースのシンプルさと費用対効果を兼ね備えています。 PostgreSQL 互換エディションの Aurora は、同じハードウェアで動作する標準 PostgreSQL の最大 3 倍のスループットを実現します。これにより、既存の PostgreSQL アプリケーションおよびツールを変更することなく実行できます。PostgreSQL の互換性と Aurora のエンタープライズデータベース機能の組み合わせは、商用データベースの移行にとって理想的なターゲットです。 Aurora PostgreSQL で道筋を始めて、AWS Well-Architected フレームワークの推奨ベストプラクティスに基づいて AWS リソースを設定したい場合は、ここで提供されている CloudFormation テンプレートを使用できます。 アーキテクチャの概要 下の図は、アーキテクチャの図であり、これから設定しようとしているものの簡単な要約です。 サンプルの CloudFormation テンプレートは、ネットワークインフラストラクチャとアーキテクチャの図に示されているすべてのコンポーネントをプロビジョニングします。CloudFormation テンプレートを次の 3 つのスタックに分割しました。 VPC、サブネット、ルートテーブル、インターネットゲートウェイ、NAT ゲートウェイ、S3 ゲートウェイエンドポイント、AWS Secrets Manager インターフェイスエンドポイント、およびその他のネットワークコンポーネントを設定する CloudFormation […]

Read More

Amazon RDS for Microsoft SQL Server で、クロスアカウントのネイティブバックアップおよびリストアを設定する

Amazon Relational Database Service (Amazon RDS) は、Microsoft SQL Server データベースのネイティブバックアップおよびリストアをサポートしています。複数の AWS アカウントがある場合、Amazon RDS インスタンスと Amazon Simple Storage Service (Amazon S3) バケットが同じ AWS リージョンにあれば、これらのアカウント間でネイティブバックアップおよびリストアを実行することができます。これらの手順を進める前に、この要件を理解しておくことが重要です。 この記事では、Amazon RDS for SQL Server でクロスアカウントのネイティブバックアップおよびリストアを実行するために必要なアクセス許可とポリシーを設定する方法について説明します。この手順では、これらのリソースを含む以下の AWS アカウントがあることを前提としています。 アカウント A – Amazon RDS for SQL Server インスタンス アカウント B – Amazon S3 バケット すべての設定は、S3 バケットが存在するアカウント B で行う必要があります。アカウント B で以下の作業を行います。 IAM ポリシーを作成する。 ロールを作成し、信頼ポリシーを設定する。 […]

Read More

2018 年に発表された Amazon RDS 機能についての要約

 Amazon Relational Database Service (Amazon RDS) で、クラウド内でのリレーショナルデータベースのセットアップ、運用、およびスケーリングが簡単になります。費用効果が高く、容量のサイズ変更も可能です。同時に、ハードウェアのプロビジョニング、データベースのセットアップ、パッチの適用、バックアップといった時間を費やす管理作業を自動化します。そのため、お客様はアプリケーションの開発に集中でき、アプリケーションが必要とする高速な性能、高可用性、セキュリティ、さらに互換性の実現に取り組むことができます。 Amazon RDS では、メモリ、パフォーマンス、または I/O に最適化したデータベースインスタンスタイプを複数利用でき、いつも使用しているデータベースエンジン 6 種類から選択できます。それらは、Amazon Aurora、PostgreSQL、MySQL、MariaDB、Oracle Database、および Microsoft SQL Server です。 2016 年、弊社は、各種データベースエンジンにわたり 50 種類の機能を発表しました。2017 年には、およそ 80 種類の機能を追加しました。そして 2018 年、各種エンジンにわたって、およそ 100 種類の機能を発表しました。以下は、これらトピックによって分類したすべての機能の要約です。 バージョンのサポート – 新しいメジャーまたはマイナーバージョン 管理性とセキュリティ – データベースのセキュリティ管理がさらに容易になる RDS 機能 パフォーマンスのスケーラビリティと可用性 – マルチ AZ の強化によりデータベースの可用性を高めながら、データベースのスケールアップとスケールダウンを向上させる RDS 機能 機能での開始 – データベース固有の開始に関連する機能 AWS リージョンでの開始 – さまざまな AWS […]

Read More

Amazon RDS for MySQL のパラメーターを設定するためのベストプラクティス。パート 3: セキュリティ、操作管理性、および接続タイムアウトに関連するパラメーター

このシリーズの前回のブログ投稿では、Amazon RDS for MySQL でレプリケーションを最適化するために使用する MySQL パラメータと、それらに関連するベストプラクティスについて説明しました。本日の記事では、RDS MySQL 環境でさまざまなセキュリティ機能を実装するために最も重要で一般的に使用されている MySQL パラメータについて説明します。また、RDS DB インスタンスの操作管理と問題のトラブルシューティングに役立つパラメータについても説明します。さらに、照合順序と文字セットに関連するいくつかの便利なパラメータについても説明します。 セキュリティに関連するパラメータ 今から、セキュリティ関連の各パラメータを設定するベストプラクティスをご紹介します。 init_connect このパラメータは、接続する各クライアントに対して実行するサーバーの文字列を定義します。このパラメータにはデフォルト値はありません。文字列は、セミコロンで区切られた 1 つ以上の SQL 文で構成されています。 たとえば、このパラメータを使用して、どのデータベースユーザーがデータベースに正常に接続したかの簡単な監査を作成できます。そのためには、まず監査テーブルとトリガーを作成します。その後、init_connect 値をトリガー名に設定します。設定したら、クライアントがパラメータを接続するたびに、接続の詳細が監査テーブルに書き込まれます。 次の例のように、このパラメータを使用して特定のユーザーアカウントの自動コミットを無効にすることもできます。 init_connect = ‘set autocommit=case current_user() when ‘test@localhost’ then 0 else 1 end’. old_passwords このパラメータは、PASSWORD 関数で使用するパスワードハッシュ方式を制御します。また、IDENTIFIED BY 句を使用してパスワードを指定する CREATE USER ステートメントおよび GRANT ステートメントによって実行されるパスワードハッシュにも影響します。 このパラメータを有効にしないことを強くお勧めします。有効にした場合、PASSWORD 関数は安全でないパスワードハッシュを使用してしまうからです。このパラメータのデフォルト値は 0 で、これは MySQL バージョン 4.1 のネイティブハッシュを使用します。 default_password_lifetime […]

Read More

Amazon DocumentDB (MongoDB 互換) を使って大規模なアプリケーションの構築と管理を行う方法

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージド型のドキュメントデータベースサービスです。Amazon DocumentDB 内のデータは JSON に似たドキュメントとして保存され、アプリケーションにおけるデータのモデル化方法に自然に対応します。このアプローチは、アプリケーションと Amazon DocumentDB の間でのデータの保存、クエリ、および処理を素早く直観的なものにします。 ドキュメントの柔軟な半構造の階層的性質は、各ドキュメントがアプリケーションのニーズと共に進化することを可能にします。このドキュメントモデルは、特に各ドキュメントがユニークで時間の経過とともに進化し得るカタログ、ユーザープロファイル、およびコンテンツ管理システムに適しています。MongoDB API を使用することにより、Amazon DocumentDB クラスターのために強力で直観的なクエリを作成することができます。これらのクエリは、単一のドキュメント、複数のドキュメント、またはドキュメントの集計にあるデータにアクセスできます。 Amazon DocumentDB は、AWS が提供する最新の専用データベースです。Amazon DocumentDB のオンデマンド料金により、長期間の契約や前払い料金なしで時間単位の料金を支払うことができます。これによって、ニーズに先立ってデータベースの容量を計画して購入するコストと複雑性から解放されます。料金と対応 AWS リージョンの詳細については、Amazon DocumentDB 料金を参照してください。 このブログ記事では、Amazon DocumentDB について紹介し、そのユニークな側面を明らかにしていきます。また、Amazon DocumentDB のアーキテクチャが、大規模なアプリケーションの構築と管理にどのように役立つかについても説明します。 Amazon DocumentDB の使用の開始 Amazon DocumentDB の使用は簡単に開始することができます (以下の動画をご覧ください)。Amazon DocumentDB クラスターは、AWS マネジメントコンソールもしくは AWS CLI、または AWS CloudFormation を使用することによって、数分でスピンアップできます。クラスターは、必要なくなれば削除することができます。スピンアップしたら、現在 MongoDB で使用しているものと同じアプリケーションコード、ドライバ、およびツールを使って、Amazon DocumentDB での開発を開始できます。 この記事では、以下のスクリーンショットにあるように、3 個の db.r4.large […]

Read More

Amazon RDS for MySQL のパラメータ設定 パート 2: レプリケーション関連のパラメータ

このシリーズの前回のブログ投稿では、Amazon RDS for MySQL のパフォーマンスを調整および最適化するために使用する MySQL パラメータと、それらに関連するベストプラクティスについて説明しました。今回の投稿では、RDS MySQL 環境でのレプリケーション構成とレプリケーションの最適化に使用される最も重要な MySQL パラメータについて説明します。 シングルスレッドおよびマルチスレッドの両方のレプリケーションに関連するパラメータ 以下に、シングルスレッドのレプリケーションとマルチスレッドのレプリケーションの両方に使用できるパラメータと、それぞれを設定するためのベストプラクティスの提案を示します。 sync_binlog sync_binlog オプションは、MySQL がバイナリログをディスクにフラッシュする方法をコントロールします。 sync_binlog のデフォルト値は 1 です。マスターサーバで、sync_binlog が 0 に設定されているとディスクと同期しません。この場合、他のファイルと同様に、バイナリログの内容をフラッシュするタイミングはオペレーティングシステムに依存します。したがって、この設定は、MySQL がバイナリログ (binlog) をディスクにフラッシュしないようにすることでレプリケーションのパフォーマンスを向上させます。この方法で、最高のパフォーマンスが得られます。 ただし、MySQL がクラッシュした場合、いくつかのトランザクションが失われる可能性があります。通常、確実にレプリカをマスターと同期させるために、レプリカを再構築する必要があります。バックアップを無効にし、「チェーン接続された」リードレプリカがないRDS リードレプリカでは、binlog を同期する必要がないため、sync_binlog は適用されません。バイナリログが生成されないように、レプリカのバックアップ保存期間を 0 に設定することをお勧めします。 ただし、データの損失を最小限に抑えるには、レプリカソースで sync_binlog パラメータを 1 に設定する必要があります。設定する最善の値は、パフォーマンスと耐久性のどちらを優先するかによって異なります。 binlog_row_image binlog_format パラメータを使用すると、バイナリログでサポートされている 2 つのイベントフォーマットを指定することができます。STATEMENT と ROW です。行ベースのフォーマットを使用すると、非決定性のクエリをログに記録することができるので、レプリカで一時テーブルは作成されません。一方、ステートメントベースのフォーマットは、行ベースのフォーマットよりもコンパクトです。 binlog_row_imag パラメータを使用して、行ベースのイベントについてバイナリログに記録される情報量をコントロールすることができます。行の状態は、バイナリログの「イメージ」で表されます。どの行ベースのイベントでも、変更前イメージと変更後イメージの 2 種類のイメージがあります。変更が行われる前の行は、変更前イメージによって表されます。変更が行われた後の行は、変更後イメージによって表されます。すべてのイベントに、変更の前後のイメージがあるわけではありません。 次の表は、さまざまな行ベースのイベントとそれらの使用可能なイメージをまとめたものです。INSERT ステートメントは Write_rows イベントを作成します。 イベントのタイプ […]

Read More

MySQL との互換性を持つ Amazon Aurora での MariaDB JDBC ドライバーの使用

このブログ記事は、Amazon Aurora クラスターへの接続に MariaDB Connector/J として知られる MariaDB JDBC ドライバーを使用する方法について説明するものです。この記事では、フェイルオーバーの状況下でマスターとレプリカを迅速かつシームレスに切り替えるために、このコネクターの自動フェイルオーバー機能を使用します。MariaDB Connector/J は MariaDB サイトからダウンロードできます。 MariaDB Connector/J を使用した Aurora MySQL への接続 この記事を書いている時点でのコネクターの最新バージョンは MariaDB Connector/J 2.3.0 です。コネクターは 2 つの方法でインストールできます。 Maven または Gradle などのパッケージマネージャーを利用する .jar ファイルを直接使用する この記事では、.jar ファイルを使用します。完全なインストールガイドは、MariaDB サイトでご覧いただけます。 コネクターをインストールしたら、次のステップは Aurora MySQL クラスターの作成です。まず、AWS マネジメントコンソールにサインインします。RDS を選択してから [データベース] を選択し、次に [データベースの作成] を選択します。次のページで、エンジンのオプションをデフォルトの [Amazon Aurora] のままにしておき、エディションに [MySQL 5.6 との互換性] または [MySQL 5.7 との互換性] […]

Read More

Microsoft Excel を使用した AWS DMS タスクのための AWS CloudFormation テンプレートの作成

このブログ記事では、AWS Database Migration Service (AWS DMS) タスクのための AWS CloudFormation テンプレートの作成を自動化するツールについてお話します。DMS タスクのための CloudFormation テンプレートの作成方法をお探しで、CloudFormation に関する知識をお持ちでない場合は、ぜひこの記事をお読みください。

Read More