Amazon Web Services ブログ

Category: Database

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

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