Amazon Web Services ブログ

Category: Amazon RDS

Amazon RDS for SQL Server において SSAS / SSRS / SSIS がサポートされました

SQL Server を利用されているお客様の中には、SQL Server に搭載されている BI 機能、SQL Server Analysis Services (SSAS) / SQL Server Reporting Services (SSRS)  / SQL Server Integration Services ( SSIS ) を利用されているお客様も多いと思います。以前はこれらの機能を利用する際は EC2上に SQL Server を構成する必要がありましたが、Amazon RDS for SQL Server でも利用可能になり(※)、マネージド型サービスならではのメリットを享受できます。有用な情報をまとめましたので、ぜひご活用頂ければと思います。 サポートするバージョン / エディション 【SQL Server Analysis Services】 SQL Server 2016 Standard エディションまたは Enterprise エディション (13.00.5426.0.v1 以降)  か SQL Server 2017 […]

Read More

非アクティブな Amazon Aurora PostgreSQL ユーザーの管理

データはあらゆる組織にとって最も貴重な資産の 1 つであり、データを安全に保つことは常に最優先事項です。データベースの一般的なセキュリティ要件の 1 つは、ユーザーアクセスを制限することです。データベースユーザーが危険にさらされた場合、データに重大な損害を与える可能性があるからです。データベースユーザーの最小権限モデルに沿って実行する必要があります。つまり、作業に必要な一連の最小権限のみをユーザーに付与します。また、データベースユーザーが長期間非アクティブである場合は、無効にすることをお勧めします。これにより、ミスやセキュリティ違反による影響を制限できます。詳細については、PostgreSQL ユーザーとロールの管理を参照してください。 この記事では、アクティブでない Amazon Aurora PostgreSQL ユーザーを特定し、自動的にロックまたは削除するソリューションを提供します。記事では、サンプルコードと AWS CloudFormation テンプレートも共有しているため、そのまま開始できます。 次の使用例では、特定の日数 (この記事では 90 日) の間、非アクティブであったユーザーを特定する必要があります。これらのユーザーを特定したら、ロックアウトします。DBA は、いつでもこれらのユーザーをロック解除できます。ただし、ユーザーが 180 日間非アクティブである場合は、自動的に削除する必要があります。 ただし、PostgreSQL はこの機能をネイティブでサポートしていません。一部の商用データベースでは、この機能にユーザープロファイル機能を含めています。これにより、指定した日数の間データベースにログインしていないユーザーアカウントをロックできます。 PostgreSQL の場合、PostgreSQL はユーザーログインのタイムスタンプをどのカタログテーブルにも保存しないため、作業がより困難になります。したがって、ユーザーが非アクティブである期間を判別するのは簡単ではありません。さらに、PostgreSQL にはログイントリガーがないため、トリガーベースのソリューションを適用するのも不可能です。 ソリューション パラメータグループでパラメータ log_connections を 1 に設定することにより、成功した各ログインの詳細 PostgreSQL へのロギングを有効にできます。このパラメータを設定すると、PostgreSQL エンジンはログインが成功するたびに次のようなメッセージを記録します。 2020-01-07 03:51:56 UTC:10.0.0.123(52820):postgres@logtestdb:[18161]:LOG: connection authorized: user=postgres database=logtestdb SSL enabled (protocol=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384, compression=off) Aurora PostgreSQL では、これらのエンジンログを Amazon CloudWatch Logs […]

Read More

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 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