Amazon Web Services ブログ

Category: Database

ネイティブツールと外部ツールに基づいた Amazon RDS PostgreSQL のクエリの最適化とチューニング

PostgreSQL は最も人気のあるオープンソースのリレーショナルデータベースシステムの 1 つです。30年以上の開発作業の成果である PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。Oracle などの商用データベースから移行する場合、PostgreSQL はオープンソースデータベースの主要な選択肢と見なされています。 AWS は、PostgreSQL データベースのデプロイを、コスト効率の良い方法でクラウドに簡単にセットアップ、管理、およびスケールできるサービスを提供しています。これらのサービスは、Amazon RDS for PostgreSQL および PostgreSQL と互換性のある Amazon Aurora です。 データベースのパフォーマンスは、アプリケーションレベルの多くの要因、および CPU やメモリなどのハードウェアに依存しています。この記事では、主要なパフォーマンス要因の 1 つであるクエリパフォーマンスを取り扱います。クエリの遅延は、ほとんどの環境で一般的に見られる問題です。この記事では以下について説明します。 ネイティブデータベースツールを使用して、どのクエリが遅いかを見つける方法。 Amazon RDS Performance Insights を使用してパフォーマンスの問題を見つける方法。 遅いクエリを修正する方法。 RDS および Amazon Aurora PostgreSQL 環境を管理する開発者と DBA にとって、遅いクエリを特定し、パフォーマンスを向上させるためのチューニングは重要なタスクです。 PostgreSQL には、人気のある pgBadger など、遅いクエリを識別するためのツールが多数用意されています。pgBadger は、PostgreSQL ログファイルからの完全なレポートを使用して速度を上げるために構築された PostgreSQL ログアナライザーです。これは、他の PostgreSQL ログアナライザーよりも優れた小さな Perl スクリプトです。このツールを使用してレポートを生成するには、それに応じてログレベルを設定する必要があります。 次の論理図は、pgBadger の使用方法を示しています。PostgreSQL ログをダウンロードして […]

Read More

Amazon Neptune が TinkerPop 3.4 機能をサポートするようになりました

Amazon Neptune は、Apache TinkerPop 3.4.1 のリリースをサポートするようになりました。この記事では、テキスト述語、valueMap の変更、ネストされた繰り返しステップ、名前付き繰り返しステップ、非数値比較、順序の変更ステップなど、Gremlin クエリとトラバーサル言語の新機能の具体例を紹介します。TinkerPop 3.4 には TinkerPop 3.3 との違いがほとんどないことに注意してください。エンジンリリースの互換性に関する注意事項を必ず確認してください。 エンジンのすべての最新機能と改善点は、Amazon Neptune リリースページに記載されています。 テストクラスターのセットアップ 以下の手順に従って、この記事の例を試すことができます。この記事は、以前に投稿した「Amazon SageMaker Jupyter ノートブックを使用して Amazon Neptune グラフを分析する」と「Let Me Graph That For You – Part 1 – Air Routes」の 2 本の記事に基づいており、航空路データセットを再度利用しています。 この例で使用する航空路データは、GitHub (こちら) で利用できます。 以下に示す例では、Gremlin Python が 3.4 レベル以上である必要があります。以前の投稿の AWS CloudFormation テンプレートを使用してノートブックのセットと Amazon SageMaker インスタンスを生成した場合、ターミナルウィンドウ (ノートブック内) または %% bash […]

Read More

Amazon DynamoDB Transactions を使用して複数のアイテムに調整された変更を加える

近年、NoSQL データベースをリレーショナルデータベース管理システム (RDBMS) の制約から解放するソリューションと見なす組織が増えているため、NoSQL データベースの使用が大幅に増加しています。NoSQL データベースの柔軟性、俊敏性、およびパフォーマンスは、移行をトリガーする主な利点ですが、組織の重要な要件の一部によって RDBMS は同じままでした。 RDMBS は、最も広く知られ議論されている機能であるトランザクションサポートのために、重要なデータを操作する場合 NoSQL データベースよりも好まれます。 Amazon DynamoDB Transactions 使用する理由 多くのアプリケーションでは、1 つ以上の項目に対して「アトミック」またはオールオアナッシングのデータベース操作を必要とするビジネスロジックが常に必要です。これにより、間違った操作が 1 つ発生した場合、すべてのデータベース操作をロールバックできます。通常、このニーズに対処しようとすると、接続されたすべての操作を追跡し、操作を元に戻すという点で、アプリケーションの実装が難しくなります。 Transactions は、re:Invent 2018 で DynamoDB の新機能として発表されました。データベース内のトランザクションのネイティブサポートを提供し、単一の AWS アカウントとリージョンにある複数の項目に ACID (原子性、一貫性、分離性、耐久性) を提供します。 従来、DynamoDB は単一の項目に対してのみ、これらのプロパティをサポートしていました。データの可用性と耐久性を確保するために設計されましたからです。Transactions は、複数の項目で 1 つ以上のテーブルに原子性 (オールオアナッシング) と分離性 (Transactions 同士は影響なし) を追加しました。 さらに、Transactions の ClientRequestToken キーを使用すると、API 呼び出しがべき等になる可能性があるため、複数の同一の呼び出しが同じ操作を再生せず、呼び出しが 1 つの場合と同じ効果が得られます。 Transactions を使用すると、データベース内でロールバック操作について心配したり、苦労したりする必要がなくなります。Transactions は、複数の項目とテーブルにわたってアクションを調整することにより、データの整合性を維持するのに役立ちます。 仕組みの説明 DynamoDB Transactions は現在、TransactWriteItems […]

Read More

トランザクションを使用した Amazon DynamoDB の一意制約のシミュレーション

大抵のリレーショナルデータベースシステム、そして一部の非リレーショナルデータベースシステムには、ユニークキーまたはユニーク制約として知られるコンストラクトがあります。この機能は、列またはフィールド内のすべての値が行全体で一意であることを確実にします。 たとえば、User テーブルがあるとします。それには、各ユーザーを一意に識別するプライマリキーとして UUID があるかもしれませんが、同じくユーザーにとって一意である必要があるユーザー名フィールドと E メールフィールド (DynamoDB 用語では「属性」) もあるかもしれません。このユースケースは、DynamoDB トランザクションに関する AWS Summit 2018 DAT374 セッションで言及されています。 Amazon DynamoDB では、プライマリキーがパーティションキー (テーブルにソートキーが選択されていない場合)、またはパーティションとソートキーの組み合わせのいずれかになります。プライマリキーは、テーブル内で一意であることが保証されています。しかし、DynamoDB には、プライマリキーではない属性の一意性を確実にするための組み込みメカニズムがありません。 この記事では、アプリケーション側からこのような類の一意性を実装するために使用されるパターンについて説明し、単一テーブルのスキーマ設計でこのパターンを使用するときに項目を作成、更新、および削除する方法の例をご紹介します。 ソリューションの概要 前述の例を使用して、User テーブルがあり、そのテーブルに以下のような属性があると考えてください。 pk (UUID として保存されたプライマリキー) userName email fullName phoneNumber UUID、userName、および email の各属性は一意である必要がありますが、fullName と phoneNumber にその必要はありません。複数の人物が同じ自宅電話番号を共有することができます。以下はサンプル行です。 pk userName email fullName phoneNumber b201c1f2-238e-461f-88e6-0e606fbc3c51 btables bobby.tables@gmail.com Bobby Tables +1-202-555-0124 8ec436a8-97e6-4e72-aec2-b47668e96a94 jsmith johnsmith@yahoo.com John Smith +1-404-555-9325 […]

Read More

[AWS Black Belt Online Seminar] Amazon Aurora with PostgreSQL Compatibility 資料及び QA 公開

先日 (2019/8/28) 開催しました AWS Black Belt Online Seminar「Amazon Aurora with PostgreSQL Compatibility」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。   20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatibility from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. サブネットグループで、AZを2つだけグルーピングしていた場合でも、ストレージ(データ)は、3つのAZに書込みされるのでしょうか? A. はい。サブネットグループの設定に関わらず、Amazon Aurora は自動的に 3 つのアベイラビリティーゾーンにかけて 6 個のデータコピーを保持します。サブネットグループには、プライマリインスタンス(Writer), Aurora レプリカ(Reader)を配置するために利用します。 Q. リードレプリカについては、追加インスタンス毎に、インスタンスタイプを変えることは可能という認識であっていますか? A. はい。ご認識の通り可能です。ただし、プライマリインスタンスとリードレプリカは同じインスタンスクラスを利用することを推奨しています。レプリカの追加方法についてはこちらのドキュメントをご確認ください。 Q. RDS for PostgreSQL を選択するメリットは、どういうものがあるでしょうか? A. […]

Read More

マルチリージョンでの高可用性のための SQL データベースのクライアント側暗号化の実行

Amazon Relational Database Service (RDS) と Amazon Aurora は、データベースインスタンス、自動バックアップ、リードレプリカ、およびスナップショットの基盤となるストレージを保護するために保存時の暗号化をネイティブに提供しますが、時折、使用中のデータを暗号化することによって機密性を強化する方法について尋ねられるお客様がおられます。 たとえば、プライマリアカウントナンバーをセキュアに保存してから読み込むときなど、トークナイゼーションソリューションが適切ではない場合には暗号化が必要となります。 お客様にとって、データベース列に保存された機密情報 (社会保障番号や銀行口座番号など) がデータベース管理者などの社内の人物に表示されないようにすることが必要であるという例もあります。 これらの暗号化シナリオでは、暗号化された列データで SQL WHERE 句述語のクエリを実行する必要はありません。列レベルでの暗号化を有効にするには、SQL データベースに永続化する前にクライアント側暗号化を使用できます。 この記事では、SQL データベースでのクライアント側暗号化を行うために考えられる 1 つのアプローチを段階的に説明します。暗号化キーは AWS Key Management Service (KMS) によって保護されており、復号化に必要なキーの制御を可能にします。その後、Amazon Aurora MySQL データベースエンジンに書き込む前にクライアント側暗号化を実行するサンプルアプリケーションについて説明します。 AWS 暗号化コンセプトの概要 ソリューションの概要を説明する前に、AWS KMS の機能の一部と AWS 暗号化 SDK について見直したいと思います。 AWS KMS は、キーポリシーを使用して、暗号化と復号化に必要なカスタマー管理の CMK の使用を制御することを可能にします。AWS KMS の CMK は、決して KMS を暗号化されていない状態のままにしておかず、エクスポートできません。さらに、AWS KMS は AWS CloudTrail […]

Read More

Amazon RDS Under the Hood: Multi-AZ

Amazon Web Services (AWS)のお客様はデータストアと、そのデータストアの高可用性にお客様のビジネスを委ねています。そのようなお客様に向けて、Multi-AZ配置は高可用性を実現する方法を容易に提供します。 Amazon Relational Database Service (Amazon RDS)でMulti-AZを有効にすることで、データの冗長かつ一貫した状態を維持します。もし、primaryデータベースサーバに問題が発生した場合は、standbyデータベースサーバに自動的に変更しデータへアクセスし続けられるようにします。2つのデータのコピーはそれぞれ別のAvailability Zones (AZs)内で管理されています(そのため、Multi-AZと呼ばれています)。別々のAvailability Zones を持つことで、両方のデータが同時に障害に見舞われるリスクを軽減させています。データの適切な管理、簡単な再構成、およびコピーへの信頼できるユーザーアクセスは、顧客環境が要求する高可用性要件に対処するための鍵です。 この投稿では、MySQL、MariaDB、PostgreSQL、およびOracleデータベースインスタンスのAmazon RDS Multi-AZ設定について説明します。Amazon RDS for SQL ServerおよびAmazon Auroraは、異なるテクノロジースタックを使用してマルチAZ機能を提供します。 基本デザイン Mult-AZ機能はデータベースアプリケーションとAmazon Elastic Block Store(Amazon EBS)ボリュームの間にあるレプリケーションレイヤーを使用して実装されています。このレイヤーは、アプリケーションの読み取りおよび書き込み要求を処理し、2つの個別のEBSボリュームコピーがある環境に適用されます。1つはローカルアクセス、もう1つはリモートアクセスです。 通常時は、レプリケーションレイヤーがインストールされた、2つのアクティブなAmazon EC2インスタンスがあります。 各インスタンスは、データの完全なコピーが行われているEBSボリュームを管理しています。この構成により、2つのインスタンスとそのボリュームがMulti-AZデータベースインスタンスとして稼働しています。 レプリケーションレイヤーは、TCP接続を介して互いに直接通信を行っています。 各インスタンスには特定のロールが割り当てられます。1つはプライマリであり、ユーザーがデータにアクセスするための外部エンドポイントを提供します。もう1つはスタンバイであり、プライマリから受信するすべてのデータを同期的に書き込むセカンダリインスタンスとして機能します。データベースの書き込みは、正常応答が呼び出し側アプリケーションに送り返される前に、データが両方のボリュームに適切に書き込まれます。ただし、読み取り操作は常にプライマリEBSボリュームを介して実行されます。データベースサーバープロセスは、スタンバイインスタンスで実行されていないため外部エンドポイントは公開されません。そのため、ユーザーはstandbyデータベースインスタンス上のデータのコピーは使用できません。 可用性を向上させるためにMulti-AZは、インスタンスの1つがプライマリロールにあることを一貫して保証し、データのコピーへのアクセスを提供します。もし可用性の問題が発生した場合、スタンバイインスタンスを自動的にプライマリロールに昇格させ、リダイレクトによって可用性を復元させます。 このイベントは、フェイルオーバーと呼ばれます。旧プライマリがまだ稼働している場合、スタンバイロールに降格されます。 新しいプライマリインスタンスへのリダイレクトは、DNSを介して提供されます。クライアントDNSクエリの結果に含まれるレコードのTTLは非常に短くなっています。アドレス情報の長期間のキャッシングを禁止することを目的としています。これにより、クライアントはフェールオーバープロセスで情報をより早く更新し、DNSリダイレクトの変更をより迅速に取得します。 以下の図が正常時のMulti-AZインスタンスの状態を示しています。 Figure 1: Multi-AZ instance データベースアプリケーション(黄色で表示されるDB APP)は、DNS)オレンジ色で表示)使用して、データへのアクセスを提供している現在の外部エンドポイントのアドレス情報を取得します。 このマルチAZインスタンスには2つのRDS DBインスタンスがあります。プライマリインスタンス(左側に緑色で表示)とスタンバイインスタンス)右側に青色で表示)です。この例では、DNSはアプリケーションをプライマリインスタンスEC2#1に向けており、Availability Zone#1で利用可能なEBS#1のプライマリコピーを提供しています。2つのEC2インスタンスの複製レイヤーが接続されています。アプリケーションが発行する書き込み操作は、2番目のインスタンスへの書き込みにもなります(パスは灰色で表示)。 レプリケーションレイヤーは、それ自体の可視性が制限されているため、より詳細な決定を下すことができません。たとえば、クライアントからの接続問題、ローカルまたはregionの停止、または予期せずサイレントな状態になったEC2ピアの状態などを知るすべがありません。このため、2つのインスタンスは、より重要な情報にアクセスし、インスタンスのステータスを定期的に監視する外部システムによって監視および管理されています。必要に応じて、管理システムは、可用性とパフォーマンスの要件が満たされてるためのアクションを実行します。 Multi-AZが提供する可用性と耐久性の改善は、最小限のパフォーマンスコストで実現しています。通常の使用例では、レプリケーションレイヤーが接続され、スタンバイEBSボリュームへの同期書き込み操作が発生します。スタンバイインスタンスとボリュームは、地理的に離れた個別のAvailability Zoneに配置されています。評価では、データベースのコミットへのオーバーヘッドが2ミリ秒から5ミリ秒増加していることが示されています。ただし、実際の使用例に対する実際の影響は、ワークフローに大きく依存します。ほとんどのお客様のMulti-AZインスタンスは、影響があったとしてもパフォーマンスにわずかな影響を示します。 この設計により、AWSはお客様のデータに対して99.95%の可用性を超えるサービスレベルアグリーメント(SLA)を提供しております。詳細については、Amazon RDSサービスレベルアグリーメントをご覧ください。 実装について ボリューム複製機能の設計は単純で簡単だと思われるかもしれません。しかし、実際の実装はかなり複雑です。これは、絶えず変化し、時には大きく変動する環境内で、2つのネットワークで接続された個別のインスタンスおよびボリュームが遭遇する可能性があるすべての事象を考慮する必要があるためです。 通常の進行中のレプリケーションは、すべてが適切に機能し、正常に動作していることを前提としています。EC2インスタンスが利用可能で、通常のインスタンス監視が機能し、EBSボリュームが利用可能で、ネットワークが期待どおりに動作しています。しかし、これらのピースの1つ以上が誤動作しているとどうなるでしょうか? 発生する可能性のある問題とその対処方法を見てみましょう。 […]

Read More

大規模なデータウェアハウスをダウンタイムなしで IBM Netezza から Amazon Redshift に移行する方法

最近、EMEA 地域の大企業がオンプレミスの IBM Netezza データウェアハウスの Amazon Redshift への移行を決定しました。データのボリューム (非圧縮容量 270 TB、および 27,000 個を超えるテーブル)、このデータを活用する相互接続されたシステムの数 (4,500 個を超えるビジネスプロセス)、かつダウンタイムなしという要件を考えると、このプロジェクトが困難であれどもやりがいがあるものなることは明らかでした。この会社は、データウェアハウスがデプロイされているデータセンターを 1 年以内に廃止することを計画していたので、時間的な制約もありました。 データウェアハウスは会社の中核を成す部分であり、あらゆる部門のユーザーが業務を遂行するために必要なデータを収集し、日報を生成することを可能にします。ほんの数年間で、クラスターにアクセスする事業部門はほぼ 3 倍に増加し、ユーザー数は当初の 5 倍となり、クラスターが設計された 1 日あたりのクエリ数 50 倍分のクエリが実行されるようになりました。レガシーデータウェアハウスは、これ以上これらの部門のビジネスニーズに対応できなくなり、毎晩の ETL プロセスの実行がその時間制限を超え、ライブクエリに時間がかかりすぎる原因となっていました。 この会社は、データセンターの廃止時期が近づいていたこともあり、ビジネスユーザー間における全般的な不満から移行の計画に踏み切り、IT 部門が新しいアーキテクチャの定義とプロジェクトの実施を担当することになりました。 アマゾン ウェブ サービス (AWS) の迅速かつスケーラブルな OLAP データウェアハウスであり、データウェアハウスとデータレイク全体における全データの分析をシンプル化してコスト効率性を高める Amazon Redshift は、この会社の問題を解決するために申し分ありませんでした。Amazon Redshift は今後の成長のための完全な伸縮性、および需要が高いピーク時を補うための同時実行スケーリングなどの機能を提供するだけでなく、簡単に統合できる分析サービスの完全なエコシステムも提供します。 この記事では、このお客様が綿密に計画された移行プロセスに従い、AWS Schema Conversion Tool (SCT) と Amazon Redshift のベストプラクティスを活用することによって、ダウンタイムなしで IBM Netezza から Amazon […]

Read More

SQL Server 2012 および 2016 での SQL Server Reporting Service 2016 の設定

 SQL Server Reporting Services (SSRS) への接続試行は、「Reporting Services インスタンスが見つかりませんでした」というエラーで失敗することがあります。 このエラーは、SSRS、SQL Server Integration Services (SSIS)、および SQL Server Analysis Services (SSAS) でインストールされた Amazon Machine Images (AMI) を使用するときに発生する場合があります。 この記事では、これらのエラーを避けるために SQL Server 2016 で SSRS 2016 を設定する方法のステップバイステップ手順を説明します。 エラーを確認する まず、SSRS が開始されたことを確認します。 関連する AMI を使用して Amazon EC2 インスタンスを起動します。 services.msc コンソールに移動します。これは 2 つの方法のいずれかを使って実行できます。 [ファイル名を指定して実行] から services.msc に入る。 SQL Server 構成マネージャーを使用する。 SQL Server […]

Read More

AWS DMS を使ってデータベースの移行とリフレッシュ処理を自動化する

アプリケーション開発者やシステム管理者は、データの移行、更新、マスクなどの目的で、データストア間での複製を行うことがあります。事前調査、スキーマ変換、スクリプト変換、データ移行、機能試験、パフォーマンスのチューニング、その他のタスクが伴うデータ複製作業は、多くの組織にとって複雑で複数のフェーズが必要な作業となります。そのため、データ複製をサポートするいくつものツールが存在します。 AWS Database Migration Service (DMS) は、データベースを AWS に迅速かつ安全に移行するためのツールです。ソースのデータベースは移行処理中でも完全な機能を維持するので、アプリケーションの中断時間を最小にできます。AWS DMS を利用すると、オープンソースで広く使われている商用データベースとの間で、双方向のデータ移行が行えます。 同種間および異種間、両方の移行をサポートする AWS DMS では、高い可用性を維持したまま、データストア間でのデータ複製を持続的に実行できます。AWS DMS では、全ロードで変更がキャッシュされたデータを、データストア間で継続的に複製できます。 今回の記事では、グローバルなデータの移行や更新、マスキングを自動で行うソリューションをご紹介していきます。このソリューションでは、DMS、AWS Lambda、Amazon CloudWatch リソースなどを統合しながら、AWS CloudFormation スタックをデプロイします。DMS のレプリケーションタスクが、オンプレミスから AWS Cloud 上にあるデータストアへのデータ移行もしくは更新を行います。 今回のデモでは、オンプレミス側のデータベースとしては Amazon RDS for Oracle DB インスタンスを使い、クラウドデータベースとしては Amazon Aurora MySQL インスタンスを使います。DMS のイベントサブスクリプション機能を有効にしておくと、DMS のレプリケーションタスクはすべてのタスクイベントを、Amazon SNS トピックを使い通知するようになります。この SNS トピックは、サブスクライブした Lambda 関数へ通知されます。この Lambda 関数が CloudWatch Events のルールを有効化もしくは無効化した後、DMS のレプリケーションタスクをトリガーします。 ネットワーク上の問題を簡素化するため今回のソリューションでは、すべてのサポートサービスを 1 つの […]

Read More