Amazon Web Services ブログ

Category: Database

[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

Amazon Linux 2 の SQL Server 2017 で Active Directory 認証をデプロイし、設定する

Windows 上での SQL Server は、SQL Server インスタンスを設定して、Active Directory アカウントで Windows 認証を使用できるようにします。この記事は、Amazon Linux 2 で SQL Server 2017 を扱う方法について取り上げます。このソリューションは、Amazon EC2 で SQL Server Linux インスタンスを管理するために Windows 認証を使用して、Active Directory アカウントにログインできるようにします。 この記事では、次の作業方法について説明しています。 ドメインに SQL Server Linux インスタンスをデプロイし、結合します。 新しい Active Directory ユーザーを作成して、SQL Server Linux のサービス プリンシパル名を設定します。 SQL Server サービス キータブを追加します。キータブ ファイルを使用して、Active Directory に認証します。 SQL Server Management Studio (SSMS) を使用して、Active […]

Read More

Amazon DynamoDB へのリファクタリング

リレーショナルデータベースから NoSQL への移行を考えていますか? 以下の記事では、Amazon EC2 インスタンスから Amazon DynamoDB への SQL Server データの読み取り、変換、書き込みについて詳しく説明します。AWS Glue を使用して、DynamoDB で複数のテーブルのソースデータモデルを 2 つのターゲットテーブルに変換します。 AWS Glue の代わりに、AWS DMS や AWS Marketplace ツールなど、データモデル変換のためのその他のオプションがあります。この 1 回限りの移行では、複数のテーブルを 1 つに変換するために AWS Glue および Scala コードを選択しました。 概要 このデモでは、商用リレーショナルデータベースをリファクタリングする方法を示します。選択したデータベースは、スポーツイベントのチケットを生成および販売します。データベースを DynamoDB にリファクタリングするためのベストプラクティスと、DynamoDB テーブルを設定し、AWS Glue を使用してデータを転送する方法を説明します。また、VPC エンドポイントと AWS Glue のセキュアな IAM ロールを設定する方法、ソースデータベースをクロールし、Apache Spark ETL ジョブを実行する方法も示します。 すぐに開始するには、DynamoDB リポジトリへのリファクタリングのコードにアクセスしてください。 問題と提案される解決策 環境内で AWS […]

Read More

Amazon DynamoDB Accelerator コンソールのウォークスルー – パート 2

Amazon DynamoDB は、応答時間が 1 桁のミリ秒単位で測定されるスケーラビリティとパフォーマンスを提供します。マイクロ秒単位の応答時間が必要なユースケースでは、DynamoDB Accelerator (DAX) がその実現に役立ちます。DAX は DynamoDB と互換性がある API マネージドキャッシュで、リアルタイムのゲーム、入札、気象分析、取引など、要求の厳しいアプリケーションに高速のインメモリパフォーマンスを提供します。DAX を使用すると、読み取り容量単位を効率的にプロビジョニングすることでコストを削減し、最終的に一貫した読み取りワークロードの応答時間がマイクロ秒に短縮されるため、スループットが向上します。 このブログ記事では、ウェブベースの DynamoDB コンソールを使用して、数回クリックするだけで DAX を有効にすることに焦点を当てています。このウォークスルーの過程で、クラスター、ノード、サブネットグループ、パラメータグループ、イベントなどの DAX 主要コンポーネントについて理解を深めることができます。 DynamoDB コンソール DynamoDB Accelerator セクションの詳細ウォークスルー DynamoDB の設定については、このブログ記事のパート 1 を参照してください。このウォークスルーは、DynamoDB コンソールに 1 回以上アクセスしたことを前提としています。コンソールの DynamoDB DAX セクションで利用可能なすべての機能と、そこからアクセスする方法についてステップバイステップのウォークスルーに沿って説明します。 DynamoDB DAX コンソールに初めてアクセスした後は、常にコンソールの [ダッシュボード] ページから始めます。ダッシュボードには、Amazon CloudWatch アラームによってトリガーされた最近のアラート、DAX サービスヘルス、DynamoDB Accelerator に関するその他の情報に関する DAX コンポーネントの詳細が表示されます。 上のスクリーンショットで番号付けされているように、ダッシュボードのセクションは以下のとおりです。 # セクション 説明 1 クラスターの作成 ダッシュボードから直接、DAX […]

Read More

Amazon RDS PostgreSQL レプリケーションのベストプラクティス

Amazon RDS for PostgreSQL では、読み込み負荷を取り除き、災害復旧 (DR) リソースを作成するために、ソース PostgreSQL インスタンスのレプリカを簡単に設定することができます。リードレプリカは、ソースと同じリージョン、または異なるリージョン内に設定できます。 RDS PostgreSQL リードレプリカインスタンスを使用すると、読み込みワークロードをレプリカインスタンスにオフロードすると同時に、書き込みアクティビティのためにソースインスタンスのコンピューティングリソースも確保します。ただし、レプリケーション遅延を避けるには、リードレプリカを正しく設定し、適切なパラメータ値を設定する必要があります。 概要 この記事では、リードレプリカを正しく設定するためのベストプラクティスをいくつかご紹介します。リージョン内、クロスリージョン、および論理レプリケーションなどのさまざまな RDS PostgreSQL レプリケーションオプションの長所と短所を取り上げ、適切なパラメータ値と、監視するメトリクスを推奨します。以下のステップでは、レプリケーション遅延を最小限に抑えながら、DR 戦略、読み込みワークロード、および健全なソースインスタンスを最適化する方法を説明します。 一般的な推奨事項 全体的なベストプラクティスとして、リードレプリカで実行するリードクエリが、ソースインスタンスとしてデータの最新バージョンを使用することを確認してください。データバージョンは、Amazon CloudWatch メトリクスでレプリケーション遅延を調べることによって確認できます。レプリケーション遅延を最小限に抑えることによって、古いデータに基づいたクエリ出力と、インスタンスの健全性に対するリスクの両方を避けることができます。 リージョン内のレプリケーション RDS PostgreSQL は、ソースインスタンスと同じ AWS リージョン内でリードレプリカを作成するために Postgres ネイティブストリーミングレプリケーションを使用します。ソースインスタンスでのデータの変更は、ストリーミングレプリケーションを使ってリードレプリカにストリームされます。このプロセスが何らかの理由で遅れると、レプリケーション遅延が発生します。以下の図は、RDS PostgreSQL が同じリージョン内のソースとレプリカの間でレプリケーションを実行する方法を示しています。 この後のセクションでは、同じリージョン内でホストされている RDS PostgreSQL インスタンスを最適にレプリケートするために Postgres インスタンスを調整する方法について説明します。 適切な wal_keep_segments の値 Postgres では、wal_keep_segments パラメータで pg_wal ディレクトリに保存される WAL ログファイルセグメントの最大数を指定します。Postgres は、このパラメータを超える WAL セグメントを Amazon S3 バケットにアーカイブします。 リードレプリカが […]

Read More