Amazon Web Services ブログ

Category: Amazon Aurora

SSL/TLS を経由して RDS MySQL, RDS MariaDB, and Amazon Aurora MySQL に sysbench を実行する

sysbench は MySQL 互換のデータベースでベンチマークを実行するために有用なツールです。もし、sysbench を使って Amazon Aurora MySQL のパフォーマンスの評価をしたい場合、Amazon Aurora Performance Assessment Technical Guide が役に立つでしょう。しかし、もし SSL/TLS を経由して sysbench を実行したい場合、このツールや AWS のサービスにあるいくつかの制限について考える必要があります。 この投稿では、RDS MySQL, RDS MariaDB, and Aurora MySQL で sysbench を実行するにあたっての考慮点と、どのように準備するべきかについて、お話いたします。 考慮点 sysbench の最新のパッケージリリースは 1.0.17 になります。もし、yum や RPM のようなパッケージマネージャから sysbench をインストールした場合、このバージョンがインストールされます。このバージョンでは、sysbench は SSL/TLS を使用するにあたって、以下のような制限を持っています: –mysql-ssl オプションは ON または OFF のみが指定可能で SSL_MODE は REQUIRED 固定 クライアント秘密鍵、クライアント公開鍵、CA […]

Read More

Amazon Aurora PostgreSQL から通知を送信する

企業のお客様は、Amazon Aurora PostgreSQL データベースで多くの日々のバッチジョブを実行し、そのようなジョブを完了した後にアクティビティを追跡するためにメールやテキストなどの通知方法が必要です。Aurora PostgreSQL はマネージドサービスであるため、セキュリティ上の理由から pgsmtp や pgplpythonu などのデータベース拡張機能へのアクセスを制限しています。これにより、他の自動メッセージングの手段で通知を送信するデータベースの必要性が高まります。 この記事では、組織が定期的にビジネス検証のために従業員の情報をプルし、ジョブの完了後に通知を必要とするシナリオを使用します。この記事では、Python を使用してサンプルジョブを作成し、AWS Lambda と Amazon SNS を使用して、E メールまたはテキストメッセージで通知する方法を示します。 前提条件 このソリューションには以下が必要です。 適切な AWS のサービスにアクセスできる有効な AWS アカウント。 Aurora PostgreSQL データベース。詳細については、「Amazon Aurora DB クラスターの作成」を参照してください。 VPC の外部に通知を送信するための、SNS の VPC エンドポイント。詳細については、「Amazon SNS の Amazon VPC エンドポイントの作成」を参照してください。 データベースに接続するための pgadmin または PSQL Client ツールなどのクライアントツール。 AWS Secret Manager にすでに設定および保存されているデータベースパスワード。詳細については、「AWS Secrets Manager とは」を参照してください ソリューションアーキテクチャ […]

Read More

AWS SCT および AWS DMS を使用した移行後のデータベースオブジェクトの検証

データベースの移行は複雑なタスクになりかねません。移行には、ソフトウェアプラットフォームの変更、ソースデータの複雑性の把握、データ損失チェック、既存機能の詳細なテスト、アプリケーションパフォーマンスの比較、およびデータの検証といったあらゆる課題が伴います。 AWS では、移行前チェックリストと移行評価を提供するツールとサービスをいくつかご用意しています。AWS Schema Conversion Tool (AWS SCT) は、既存のデータベーススキーマをひとつのデータベースエンジンから別のデータベースエンジンに変換するために使用できます。AWS Database Migration Service (AWS DMS) は、リレーショナルデータベース、データウェアハウス、NoSQL データベース、およびその他のタイプのデータストアの移行を容易にしてくれます。AWS DMS は、AWS クラウドへのデータの移行、またはオンプレミスインスタンス間 (AWS クラウドセットアップ経由)、クラウドとオンプレミスセットアップとの組み合わせの間でのデータの移行に使用できます。 さらに、AWS はデータベース移行の全体を通じてユーザーをガイドする幅広いドキュメントも提供しています。詳細については、「Oracle データベースの PostgreSQL への移行」を参照してください。 AWS SCT は、スキーマオブジェクトを変換するために役立ち、AWS SCT が PostgreSQL に変換した Oracle コードの割合と、手動で変換する必要があるコードの量を示すレポートを構築します。データベースオブジェクトの移行中は常に、ターゲットデータベースでオブジェクトが欠落している、新しいオブジェクトを作成する、またはソースオブジェクト全体を意図的に無視する可能性のリスクがあります。検証は、移行対象のすべてが正常に移行されたことを顧客に証明するプロセスです。 この記事は、データベースオブジェクトの移行とコードの変換の完了後に、ソース Oracle データベースと PostgreSQL ターゲット間でオブジェクトを検証する方法の概要を説明します。 オブジェクトの検証 問題になるのは、何を検証するかということです。 これを理解するためには、Oracle データベースオブジェクトの異なるタイプと、それらに相当する PostgreSQL データベースオブジェクトのタイプを知っておく必要があります。 以下の表は、Oracle (ソース) データベースのオブジェクトと、対応する PostgreSQL (ターゲット) のオブジェクトのタイプを示しています。DB 変換が正常に行われたことを確認するには、これらのオブジェクトを詳細に検証しなければなりません。 Oracle オブジェクト […]

Read More

Aurora PostgreSQL ストレージの I/O コストを削減

多くの企業における IT 部門では、オンプレミスのワークロードをクラウドに移行することの最大の理由の 1 つがコスト削減となっています。今回の記事では、コスト管理についての実例を、Amazon Aurora PostgreSQL のチューニングに着目しながらご紹介していきます。 ヒストリー 私は最近、当社の自動車向けテレマティクスアプリケーションの、AWS への実装作業を指揮するという機会に恵まれました。少し説明しますと、テレマティクスアプリケーションとは、データ提供者から運転データをストリーミングで受信するものです。このデータは、検証、修正、および正規化されます。そして、処理に合わせた変換が行われた後、専用のスコアリングアルゴリズムを用いて、ドライバーの点数付け計算に使われます。このプロジェクトには、次に示す主要な目的がありました。 高い可用性 (HA) の実現 (99.999%) 。 レスポンスタイプは、数ミリ秒台という高いパフォーマンスの実現。 現状の TCO をその何割かまでに削減する。これには、人的および設備的なリソースの削減も含まれます。 実際の使用量を反映した、従量課金制の支払に移行する。 国や地域を問わず、デプロイと新規顧客の受け入れを容易にする。 規模の拡大と需要変動に適応できる、スケーラビリティと伸縮性の獲得。 コストと HA での目標を達成するため、アプリケーションはサーバーレス/マネージド型のアーキテクチャを用いて、ゼロから再設計と再コーディングが行われました。これにより、保守に必要なリソースの最小化と従量課金制の利用がはかられましたこの再設計は、ほとんどの目的を達成し大きな成功となりましたが、コストだけに問題が残りました。オンプレミスに比べればコスト削減ができたものの、依然として想定した金額の 3 倍の金額になってしまったのです。 概要 他のどの変更作業と同様に、オンプレミスから AWS への移行要素には、次の 3 つが含まれます。 人材 処理 テクノロジー 個人的には、人材の要素がキーになると思います。オンプレミス環境とは違い、AWS でのインフラストラクチャーのコストは、いわゆる埋没費用ではありません。AWS での運用コストは、サービス利用量をベースに変化するからです。この利用量には、サービスの実行/経過時間だけでなく、メモリー、ストレージ、I/O といった、サービス毎に違いがうまれるものの利用も含まれます。AWS での課金手法になじむには、少し時間がかかることもあります。作業の工程の見直しやサービスの自動化は、AWS の環境が提供するメリットを活用するための重要なポイントです。 AWS を利用する上でのコスト削減の取り組みは、次のようなステップにグループ分けされます。 AWS のコストを理解する: まず始めに、請求管理ダッシュボードの使用になれることです。それぞれのサービスが、AWS のコストにどの程度影響しているかを理解します。タスクを優先付けするために、まず上位 3 つの高コスト要件に取り組みます。また最終的には、これらの検証がコスト面での重要性だけでなく、セキュリティーの抜け道を洗い出す目的にも重要となります。 ハウスキーピング: サーバーレスでマネージド型のサービスに移行するからといって、データのクリーニングやアプリケーションの保守のためにオンプレミスで行ったベストプラクティスが完全に不要になるわけではありません。むしろ、そういった作業はより厳格に行う必要が生まれます。 アプリケーションとサービスの低い機能を特定し調整します。 詳細情報 […]

Read More

ネイティブツールと外部ツールに基づいた 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

[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 Aurora Multi-Master を使用して高度に使用可能な MySQL アプリケーションによりビルド

アップタイム要件が高いトランザクション性のアプリケーションをお持ちですか? これらの要件を満たすために、クラウドにリレーショナルデータベースが必要ですか? 新しく開始された Amazon Aurora Multi-Master は、ノードの障害に柔軟性のあるリレーショナルデータベースを必要とするアプリケーションのために設計され、読み取りと書き込みの両方に利用可能です。 Amazon Aurora は、ハイエンドな商用データベースの速さや可用性と、オープンソースデータベースのシンプルさと高い費用対効果とを組み合わせたリレーショナルデータベースエンジンです。MySQL 互換エディションの Aurora は、同じハードウェアで動作する標準 MySQL の最大 5 倍のスループットを実現します。これにより、既存の MySQL アプリケーションおよびツールを変更することなく実行できます。Amazon Aurora は 1 個のライターと最高 15 個の読み取りレプリカを 1 つ以上のアベイラビリティ―ゾーンとリージョンでサポートします。 Amazon Aurora Multi-Master は Aurora の MySQL 互換エディションに使用可能です。クラスターの各ノードはライターノードで、厳しいアップタイム要件をもつトランザクション性アプリケーションを実行するための追加パワーを与えます。 この記事では、MySQL 互換エディションのデータベース用の Aurora Multi-Master を最大限利用するために知っておくべきことを見直します。 アーキテクチャ Aurora Multi-Master は、データベースノードのクラスター全体で高可用性と ACID トランザクションを実現し、読み取り / 書き込み後の整合性を設定できるように設計されています。そのコアで、Aurora クラスターは計算 (データベース) ノードと共有ストレージボリュームのセットから構成されています。ストレージボリュームは、ユーザーデータの高可用性と耐久性のために、3 つのアベイラビリティーゾーンに配置された 6 つのストレージノードで構成されています。クラスターの各データノードは、ステートメントの読み取りと書き込みを実行できるライターノードです。 下図は […]

Read More

Amazon Aurora PostgreSQL でのクエリ計画管理のユースケース

このブログの投稿は一連の投稿の 2 回目です。前回のブログ記事では、SQL ステートメントの実行計画に回帰を引き起こす可能性があるその他の変更の中で、安定かつ一貫したデータベースパフォーマンスの必要性について説明しました。また、PostgreSQL と互換性のある Amazon Aurora のクエリ計画管理 (QPM) が、計画安定性と計画適応性の問題を克服できるようにする方法も述べています。 この記事では、引き続き Aurora PostgreSQL QPM の機能について説明します。特に、これらの機能によって、さまざまな高度なユースケースに対して計画安定性と適応性を実現する方法についてお話します。 ユースケース #1: QPM 手動取得による計画安定性と適応性の支援 最初のユースケースでは、QPM が計画安定性を確保する方法について例を挙げて説明します。次に、前回の記事 Aurora PostgreSQL クエリ計画管理の概要で説明した変更を行います。QPM を使用しない場合は、これらの変更により計画の回帰が生じる可能性があります。 ほとんどの場合、自動計画取り込みを使用するように QPM を設定して、2 回以上実行されるすべてのステートメントを取得することもできます。ただし、手動で指定した特定のステートメントセットの計画を取得することもできます。そのためには、デフォルトに capture_plan_baselines = off を設定します。セッションレベルでは、capture_plan_baselines = manual を設定します。設定の仕方については後で説明します。 手動計画取り込みを有効にして、目的の SQL ステートメントの実行計画を手動で取得するように QPM に指示します。 pg105db=> SET apg_plan_mgmt.capture_plan_baselines = manual; SET QPM がクエリ計画を取得できるように、クエリ説明計画を実行します (説明計画の以下の出力は、簡潔にするために省略されています)。 pg105db=> explain (hashes true) SELECT […]

Read More

Aurora PostgreSQL クエリ計画管理の概要

すべての AWS サービスと同様に、Amazon Aurora PostgreSQL のロードマップは、主にお客様のご意見と製品強化のご要望によって推進されます。Oracle と Microsoft SQL Server から Amazon Aurora にデータベースを移行した、複数の企業お客様からいただいたフィードバックは、2 つの点を示唆しています。重要なアプリケーションのデータベースワークロードを実行する企業は、最適なデータベースパフォーマンスを必要とします。また、企業には Aurora PostgreSQL と互換性のあるデータベースでさまざまなシステム変更を行っても、安定かつ一貫性を保つパフォーマンスが必要です。 PostgreSQL データベースのパフォーマンスが変動する主な原因の 1 つはチェックポイントプロセスにあります。多くの場合、パフォーマンスと回復性の間のトレードオフのことです。Aurora PostgreSQL では、データベースのチェックポイントを排除することでこの問題に対処してきました。ログ記録とストレージレイヤーを切り離すために、ログベースのストレージサブシステムを実装します。応答時間が変動するもう 1 つの主な原因は、クエリ計画の不安定性によるものです。クエリ実行計画を予期せずに変更する、さまざまな要因があります。以下に例を挙げます。 オプティマイザ統計の変更 (手動または自動) クエリ計画設定のパラメータに対する変更 新しいインデックスの追加など、スキーマに対する変更 クエリで使用されるバインド変数に対する変更 PostgreSQL データベースバージョンへのマイナーバージョンまたはメジャーバージョンのアップグレード。PostgreSQL 9.6.x から 10.x など クエリ計画管理 Aurora PostgreSQL クエリ計画管理 (QPM) 機能は、データベースユーザーが一連の管理 SQL ステートメントに対して安定かつ最適なパフォーマンスを維持できるようにすることで、計画不安定性の問題を解決します。QPM では主に 2 つの目的を果たすことができます。 計画安定性。システムに上記の変更が発生した場合、QPM は計画の回帰が生じないようにして、計画安定性を向上させます。 計画適応性。QPM は、新しい最小費用計画を自動的に検出し、新しい計画が使用されるときに制御し、その変更に適応します。 QPM の仕組み 以下のフローチャートは、QPM […]

Read More