Amazon Web Services ブログ

Category: Database

Oracle Active Data Guard を使用した Amazon RDS for Oracle によるマネージド障害復旧とマネージドリーダーファーム

 多くの AWS ユーザーは、Amazon Relational Database Service (Amazon RDS) ポートフォリオのマネージドデータベース製品を利用して、日々の活動から均一な重労働を多く取り除いています。Amazon RDS for Oracle を使って、Oracle データベースの管理と保守にかかる管理費用を大幅に削減できます。 Amazon RDS for Oracle は、マルチ AZ 配置オプションを提供し、特定の AWS リージョン内のデータベース (DB) インスタンスの可用性と耐久性を強化しています。これは、多くの場合、ほとんどの顧客ユースケースに効果的な障害復旧 (DR) ソリューションです。ただし、ミッションクリティカルなデータベースを実行している一部のお客様は、異なる AWS リージョンにまたがる DR 構成のビジネス要件を抱えています。同時に、これらのお客様は DR への投資を活用して、本番環境の読み取りワークロードの一部を処理できることを望んでいます。 現在、Amazon RDS for Oracle のセルフマネージド DR ソリューションは、次のいずれかを使用して実装できます。 DB スナップショットを使用して、Amazon RDS for Oracle に低コストのクロスリージョン DR を実装します。詳細については、DB スナップショットと AWS Lambda を使った Amazon RDS […]

Read More

Amazon RDS for SQL Server での Microsoft SQL Server Reporting Services の設定

Microsoft SQL Server Reporting Services (SSRS) を Amazon Relational Database Service (RDS) for SQL Server DB インスタンスで直接実行できるようになりました。SSRS は、SQL Server 2017 Standard または Enterprise エディションの シングル AZ またはマルチ AZ インスタンスでアクティブ化できます。SSRS を Amazon Elastic Compute Cloud (Amazon EC2) で実行する場合は、SSRS を Amazon RDS for SQL Server で直接実行することによってコストを節約できるようになります。Amazon RDS for SQL Server は、SQL Server データベースと同じ RDS DB インスタンスで Report […]

Read More

PostgreSQL の行レベルのセキュリティを備えたマルチテナントデータの分離

Software as a Service (SaaS) プロバイダーには、基本的にテナントデータの分離を適用する責任があります。テナントの 1 つが別のテナントのデータにアクセスした場合、信頼はなくなり、ビジネスのブランドに永久的な損害を与える可能性があるだけでなく、さらにひどい場合には、ビジネスを失う可能性があります。 リスクが非常に大きいため、効果的なデータの分離を計画することが重要です。マルチテナントアーキテクチャは、各テナントのリソースをレプリケートするのではなく、すべてのテナントのデータストレージリソースを共有することで、俊敏性と運用コストを節約します。しかし、共有モデルで分離を適用することは難しいため、マルチテナントデータモデルで妥協して、テナントごとにコストがかかるデータベースのオプションに戻すことが可能です。 多くの場合、共有データベースモデルはソフトウェア開発者に依存しているため、記述してあるすべての SQL ステートメントで適切なチェックを実装することが唯一の選択となります。他のセキュリティ上の懸念事項と同様に、日常的なソースコードの変動性にあまり依存しないより一元的な方法で、テナントデータの分離ポリシーを適用するのがよいでしょう。 この投稿は SaaS アーキテクトと開発者を対象としており、テナントの共有データベースの利点を享受しながら一元型分離の適用を実現する方法について解説しています。 データパーティション分割のオプション マルチテナントシステムで使用する一般的なデータパーティション分割モデルには、サイロ、ブリッジ、プールの 3 つがあります。各モデルの分離方法には、それぞれ長所と短所があります。 サイロ – テナントごとに個別のデータベースインスタンスを使用すると、分離はたいていインフラストラクチャコストが高くなるだけでなく、テナントのセットアップがより複雑になります。これは、SaaS のサービスにオンボードする各テナントに、新しいデータベースインスタンスを作成および管理する必要があるためです。 ブリッジ – テナントデータをパーティション分割する 2 つ目のアプローチは、同じデータベースインスタンスを共有しながら、テナントごとに異なるスキーマを使用する方法です。リソースを共有することでモデルのコストを削減できますが、メンテナンスとテナントのセットアップはかなり複雑になる可能性があります。 プール – 3 つ目のパーティション分割モデルは、共有データベースインスタンスと名前空間の両方を使用するものです。この設計ではすべてのテナントデータを並べて表示しますが、各テーブルまたはビューには、データのフィルターに使用するパーティション分割キー (通常はテナント ID) が含まれています。 プールモデルは運用コストが最も節約でき、インフラストラクチャコードとメンテナンスのオーバーヘッドを削減します。ただし、このモデルはデータアクセスポリシーを適用するのが難しい場合があり、通常は、すべての SQL ステートメントに正しい WHERE 句を実装することが望まれます。 マルチテナントデータのパーティション分割の詳細については、次の AWS SaaS Factory ホワイトペーパーをご参照ください。 行レベルのセキュリティ RDBMS 分離ポリシーの適用をデータベースレベルで一元化することにより、ソフトウェア開発者の負担を軽減できます。このため、プールモデルの利点を活用し、かつテナント間のデータアクセスのリスクを軽減できます。 PostgreSQL 9.5 以降には、行レベルセキュリティ (RLS) と呼ばれる機能が含まれています。テーブルにセキュリティポリシーを定義すると、これらのポリシーが、SELECT クエリによって返されるそのテーブルの行、または INSERT、UPDATE、DELETE […]

Read More

Amazon DocumentDB (MongoDB 互換) について知っておくべき 12 のこと

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする、高速かつスケーラブルで可用性に優れたフルマネージド型のドキュメントデータベースサービスです。お客様は、基盤となるインフラストラクチャの管理を気にすることなく、現在ご使用のものと同じ MongoDB 3.6 向けのアプリケーションコード、ドライバー、ツールを、そのまま Amazon DocumentDB 上でワークロードを実行、管理、そしてスケールするのに使えます。ドキュメントデータベースである Amazon DocumentDB は、JSON データの保存、クエリ、およびインデックスを容易にします。 AWS は、可用性、信頼性、耐久性、スケーラビリティ、バックアップなどに関するお客様の課題を独自の方法を用いて解決するために Amazon DocumentDB を構築しました。その過程において、当社は、付加価値を生まない手間のかかる作業を取り除き、コストを削減するために、いくつかの斬新でユニークな機能を構築しました。この投稿では、Amazon DocumentDB で MongoDB ワークロードを構築およびスケーリングするのに役立つ、まだ認識されていないかもしれない 12 の Amazon DocumentDB 機能を紹介します。 1.最新のクラウドネイティブアーキテクチャ Amazon DocumentDB は、クラウドネイティブのデータベースアーキテクチャを使用してゼロから構築されました。独自のアーキテクチャによりストレージとコンピューティングが分離されているため、各レイヤーを個別に拡張できます。Amazon DocumentDB は、3 つの AWSアベイラビリティーゾーン (AZ) にまたがって 6 つの方法でデータをレプリケートすることで高可用性と耐久性を備えた、フォールトトレラントな分散型の専用自己修復ストレージシステムを使用しています。詳細については、YouTube のAWS re:Invent 2019: Amazon DocumentDB の詳細の動画をご覧ください。次の図は、Amazon DocumentDB アーキテクチャにおけるコンピューティングとストレージの分離、およびデータが 3 つの AZ にまたがって 6 […]

Read More

Amazon RDS for PostgreSQL で高速リフレッシュ機能を構築する

この記事は CDL によるゲスト投稿です。CDL は自社を次のように紹介しています。「CDL は英国を拠点とする主要なインシュアテック企業であり、Financial Times 誌の業界に影響を与えている高成長の英国企業 Future 100 のリストに掲載されています。保険と金融サービスの分野で強力な実績を残し、そのソリューションは英国で最も収益性の高い保険代理店を支えています。 CDL はシステム上で 700 万件を超える保険契約を取引し、Sainsbury’s Bank、Tesco Bank、Swinton Insurance、Moneysupermarket.com などをクライアントに抱えています」 この記事では、CDL が Amazon RDS for PostgreSQL のマテリアライズドビューログをどう使って高速リフレッシュ機能を開発したかについて説明します。変更を追跡するために構築したものを詳述し、完全リフレッシュに代わる代替手段を示します。これにより、必要な時間が数時間から数秒に短縮されました。また、高速リフレッシュを可能にするためのオープンソースソフトウェアをより広い PostgreSQL コミュニティと共有し、関連するインストールプロセスの概要を示します。 課題 CDL は毎日数百万のトランザクションを処理しています。当時はビジネスインテリジェンス (BI) プラットフォームを Oracle から PostgreSQL に移行することを検討していました。切り替えを実際に行うには、お客様が最新のビジネスインテリジェンスへ引き続きアクセスできるようにするため、リレーショナルデータベースでこの大量の変更を処理し、ほぼリアルタイムでリフレッシュする必要がありました。 PostgreSQL は完全リフレッシュ機能のみを備えています。けれども、Google のサービスレベルアグリーメントでは 15 分ごとにデータをリフレッシュする必要があります。そして CDL は大量の変更を処理していることから、完全リフレッシュプロセスではこのタイムスケール内でこの規模のマテリアライズドビュー (MV) を処理することは不可能でした。当社の最大の MV ログは 150 GB を超えており、完全リフレッシュプロセスでは構築するのに何時間もかかります。またお客様によっては、1 日あたりのビュー数が 150 回を超える方もいらっしゃいます。 当社は、BI ソリューションの MV […]

Read More

Amazon RDS for SQL Server での Microsoft SQL Server Integration Services の使用

Microsoft SQL Server Integration Services (SSIS) を Amazon Relational Database Service (RDS) for SQL Server 上で定義できるようになりました。SSIS は、シングル AZ およびマルチ AZ の DB インスタンスにおいて Standard および Enterprise のエディションで機能します。使える SQL Server は、2016 もしくは 2017 の メジャーバージョンです。 従来も、RDS for SQL Server を SSIS のターゲットソースとして使用できましたが、SSIS を RDS for SQL Server データベース自体と同じサーバー上で動作させることはできませんでした。現在でも SSIS は Amazon Elastic Compute Cloud (Amazon EC2) […]

Read More

Amazon RDS および Amazon Aurora for PostgreSQL データベースの一般的な管理者の責任

アマゾン ウェブ サービス (AWS) は、完全マネージド型のリレーショナルデータベースサービスとして、Amazon Relational Database Service (RDS) および Amazon Aurora を提供します。コマンドをいくつか使用するだけで、本稼働データベースのインスタンスを AWS で起動して実行することができます。 オンラインデータベースを使用すれば、データベース管理者 (DBA) は多くのメンテナンスタスクや管理タスクから解放されます。ただし、注意すべき重要な責任がいくつかあります。この記事では、PostgreSQL との互換性のあるデータベースを備えた Amazon RDS for PostgreSQL および Aurora で実行するための DBA タスクについて説明します。 DBA として、お客様はさまざまな分野でビジネスに価値を提供するという日々のプレッシャーに直面しています。ミッションクリティカルなデータベースを実行するための適切なプラットフォームを維持することは、ますます困難になってきています。メンテナンスも、課題の多い作業です。 Amazon RDS と Aurora のリリースにより、インストール、構成、モニタリング、セキュリティなどのタスクに費やす時間は大幅に短縮されました。それでも、複数の重要なタスクを実行する必要はあります。そのいくつかは毎日または週に数回実行し、またいくつかは Amazon RDS または Aurora のインストール時 (インスタンスの作成時) にのみ実行するものです。 実行する必要がある管理タスクには、以下が含まれます。 パラメータグループの設定 セキュリティ グループを使用した IP トラフィックの管理 データベースログファイルの監査 メンテナンスおよび管理アクティビティ バックアップおよびリカバリ戦略の計画 ユーザー管理 データベースのモニタリング パラメータグループの設定 オンプレミスの […]

Read More

Amazon RDS for PostgreSQL クロスリージョンリードレプリカのためのベストプラクティス

Amazon RDS for PostgreSQL のマネージドサービスのひとつにクロスリージョンリードレプリカがあります。クロスリージョンリードレプリカを使用することで、災害対策ソリューションの確保、データベースの読み込みワークロードのスケーリング、およびリージョン間での移行が可能になります。クロスリージョンリードレプリカは、Amazon RDS コンソール、AWS CLI、または create-db-instance-read-replica API を使用して作成できます。クロスリージョンリードレプリカには、追加のデータ転送料金がかかります。 Amazon RDS はクロスリージョンリードレプリカを容易にしますが、最良の経験を実現するために認識しておく必要がある注意点がいくつかあります。この記事では、以下のトピックに関する Amazon RDS for PostgreSQL クロスリージョンレプリケーションのベストプラクティスを説明します。 クロスリージョンリードレプリカの作成の流れ レプリケーション遅延を最小限化する方法 Amazon RDS for PostgreSQL クロスリージョンレプリカの使用中における一般的な問題 クロスリージョンリードレプリカの作成の流れ クロスリージョンリードレプリカは、Amazon RDS for PostgreSQL のバージョン 9.5.2 以降でサポートされます。クロスリージョンレプリカの作成中、システムは以下のステップを実行します。 ソースインスタンスのスナップショットを作成する。 スナップショットをレプリケーション先のリージョンにコピーする。 ソースとクロスリージョンレプリカ間におけるストリーミングレプリケーションスロットを設定する。 ソースからレプリカへのログ先行書き込み (WAL) のストリーミングを開始する。WAL ファイルは PostgreSQL のトランザクションログです。データ変更は、まず WAL ファイルに記録されてから、永続ストレージに書き込まれます。 Amazon RDS for PostgreSQL のクロスリージョンレプリカは、以下の手順に従うことで最も簡単に作成できます。 Amazon RDS コンソールで、Amazon RDS for […]

Read More

論理レプリケーションを使用してオンプレミスまたは Amazon EC2 から Amazon RDS に PostgreSQL を移行する

PostgreSQL は、オープンソースのリレーショナルデータベースの中でも最も人気のある先進的なシステムの 1 つです。30 年以上におよぶ開発作業を経ている PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。PostgreSQL は、Oracle や Microsoft SQL Server などの商用データベースから移行する際に多くの人から選ばれるオープンソースデータベースです。クラウドの観点から、AWS は 2 つのマネージド PostgreSQL オプションを提供しています。それは、Amazon Relational Database Service (RDS) for PostgreSQL と Amazon Aurora for PostgreSQL です。 PostgreSQL データベースをオンプレミスから AWS マネージド PostgreSQL に移行またはアップグレードする場合、または AWS マネージドサービス内の PostgreSQL のメジャーバージョンにアップグレードする場合は、論理レプリケーションを使用して、ネイティブの PostgreSQL 機能を介して実行できます。pglogical 拡張機能は、バージョン 9.6.6 以降の Amazon RDS for PostgreSQL の一部で、コミュニティ PostgreSQL バージョン 9.4 以降で機能します。 pglogical 拡張機能は、バージョン […]

Read More

Netezza データウェアハウスの Amazon Redshift への移行

IBM により Netezza の製品寿命が終了する旨の発表がなされており、現状の分析アプライアンスからデータとワークロードを移動する必要性に迫られている人もいることでしょう。一部の人にとっては、これがクラウド移行の良いチャンスにもなります。 そこで Amazon Redshift の登場です。 Amazon Redshift は、大規模なワークロードを処理できるように構築された、クラウドネイティブなデータウェアハウスプラットフォームです。主要な部分が Netezza と共通なので、オンプレミスのアプライアンスの置き換え先として素晴らしい候補の 1 つとなります。Amazon Redshift を使えば、他の分析プラットフォームに対する場合より短い時間と少ない変更点で、データやアプリケーションを移行できます。このことは、開発者にとってみれば、新しいデータベースを再トレーニングする時間が削減できることを意味します。また経営側から見てみると、移行に関するコストと時間を節約できることになります。詳細については、「How to migrate a large data warehouse from IBM Netezza to Amazon Redshift with no downtime」をご参照ください。 この記事では、Netezza と Amazon Redshift の間での重要な共通点と相違点をご説明しながら、それらが移行タイムラインに与える影響についても解説していきます。 共通点 Netezza と Amazon Redshift の間には、3 つの大きな共通点が存在します。つまり、Postgres との互換性、強力な並列処理 (MPP) アーキテクチャ、そして Netezza では FPGA で実現している機能である Amazon Redshift の Advanced […]

Read More